한빛출판네트워크

By 『닷넷 프레임워크 에센스』의 저자 쑤안 타이 이 시리즈의 1부. 분산 컴퓨팅에서는 분산 컴퓨팅이 클라이언트와 서버 프로그래밍을 단순화 하는 법에 대해 설명했으며 2부. 컴포넌트화와 엔터프라이즈 서비스에서는 컴포넌트화가 소프트웨어 플러그 앤 플레이를 단순화하고 엔터프라이즈 서비스가 대규모 소프트웨어 개발을 단순화했다고 지적했다. 웹 패러다임의 전환 지난 10년간 인터넷을 계속해서 사용해왔다면 여러분은 패러다임이 연결성에서 프로그램으로의 표현으로 전환되었다는 것을 눈치챘을 것이다. 이번에는 이와 같은 각기 다른 전환에 대해 짧게 논의하고 단순하지만 정말 실용적인 프로토콜 SOAP(Simple Object Access Protocol)을 소개하겠다. 연결성 1993년 이전의 네트워크 컴퓨팅이란 근거리 통신망인 LAN 형태로 컴퓨터를 서로 연결시키는 것을 의미하였다. 그러나 엔지니어들은 곧 광역 통신망인 WAN으로부터 여러 개의 LAN을 연결시킬 수 있다는 것을 알아냈다. 오늘날과 같이 서로 고도로 연결된 인터넷은 이와 같은 WAN을 서로 연결시킴으로써 가능할 수 있었다. TCP/IP는 이러한 네트워크를 서로 연결시키기 위한 가장 유명한 프로토콜이다. TCP/IP는 de facto 표준이기 때문에 많은 소프트웨어 벤더들은 TCP/IP를 사용해 클라이언트 서버 애플리케이션을 개발했다. 이것은 여러분이 애플리케이션 수준 커뮤니케이션 프로토콜 명세로 발표해내는 한 다른 사람들이 이 서비스를 사용할 수 있었기 때문에 편리했다. 발표된 애플리케이션 수준 프로토콜의 예로는 SMTP(Simple Mail Transfer Protocol), FTP(File Transfer Protocol), 텔넷, 핑거 등이 있으며 이것들은 모두 TCP/IP에 기반을 두고 있다. 1993년경에 TCP/IP를 사용하는 HTTP의 인기가 갑자기 치솟았으며 그때부터가 아마도 소프트웨어 업계가 새로운 시대로 접어든 시기일 것이다. 표현 HTTP는 특히 인터넷 상에서 HTML문서를 전송하기 위해 개발되었다. 여러분도 이미 알다시피 HTML은 레이아웃을 구분해주며 HTML 문서에 저장된 데이터를 표현하기 위한 간단한 구문이다. HTTP 명세를 준수함으로써 소프트웨어 벤더들은 웹 서버와 웹 브라우저를 개발할 수 있었다.

		닷넷 프레임워크 에센스

왜냐하면 서버와 브라우저간에 교환된 데이터가 HTML 포맷이었기 때문에 브라우저는 HTML을 파싱할 수 있었고 정확한 모양과 느낌으로 데이터를 포맷하고 사용자에게 그래픽 유저 인터페이스를 제공할 수 있었다. HTTP와 HTML은 간단한 사용자 인터페이스를 가능하게 해준다. HTML은 여러분이 HTML 파일로 하이퍼링크와 그래픽을 삽입할 수 있게 해준다. 하이퍼링크는 사용자들이 웹 서핑을 쉽게 할 수 있도록 해주며 삽입된 그래픽은 사용자의 눈을 즐겁게 해준다. HTTP와 HTML이 소개되고 얼마되지 않아서 전 세계 모든 회사들은 웹사이트를 운영하기 시작했으며 사람들도 웹 브라우저를 쉽게 사용하기 시작했다. 한 가지 더 언급하자면 HTTP는 stateless 프로토콜이다. 각각의 HTTP요청에 대해 클라이언트는 서버로 연결되거나 서버에 있는 데이터를 검색하기도 하며 서버로부터 연결을 해제 하기도 한다. 여러분은 요청된 연결이나 연결 해제가 비쌀 것이라고 생각할지도 모르지만 각각의 요청에 대해 이 두가지를 실행하는 것은 확장에 의한 것이라 상관 없다. HTTP를 stateless한 프로토콜과 웹 서비스로 만드는 것은 하드웨어에 제약만 없다면 사용자 수에 제한을 두지 않고 할 수 있다. 프로그램화 웹 사이트를 구축하는 것은 쉽지만 전자 상거래와 같은 웹 애플리케이션을 구축하는 것은 HTTP의 stateless한 본질상 그렇게 쉬운일은 아니다. 따라서 이와 같은 웹 애플리케이션 개발을 좀더 쉽게 해보려는 시도가 있었다. 서버측에서 소프트웨어 벤더들은 ColdFusion과 ASP를 포함한 동적인 웹 페이지를 지원하는 도구를 소개했었다. ASP는 상태나 의뢰된 데이터에 따라 다르게 보이고 움직이는 웹 페이지를 개발하도록 해준다. ASP를 보다 강력하게 만들기 위해 개발자는 자바스크립트나 서버측과 클라이언트측 논리를 첨가한 VB스크립트를 사용할 수 있었다. 이러한 스크립트 언어는 웹 브라우저와 서버 모두에게 프로그램을 가능할 수 있게 해주었다.

---

마이크로소프드의 닷넷 기술에 관한 최신 기사와 도서에 대해 알고싶으신 분은 한빛의 .NET 분야별 페이지로 오세요.

---

그러나 ASP와 스크립트만으로는 충분하지 않았기 때문에 사람들은 풍부한 사용자 인터페이스와 강력한 비즈니스 로직을 가진 보통의 윈도우 애플리케이션과 같은 웹 애플리케이션 기능을 만들고 싶어했다. 게다가 그들은 서로 다른 B2B 파트너와 구조화된 데이터를 교환할 수 있기를 원했으며 같은 데이터를 브라우저로 통과시키고 싶어했다. 그 결과 전자 데이터 교환을 위한 매커니즘으로서 XML이 소개되었고 빠르게 인터넷 표준으로 자리잡아 갔다. XML은 구문이 HTML과 유사하기 때문에 사용 및 확장이 간단하다. 여러분이 시작 태그로 를 사용했다면 반드시 로 마침 태그를 사용해야 한다는 예외 규정만 잘 지켜준다면 어떤 태그도 사용할 수 있다. 아래 예제는 이용할 수 있는 XML 스니핏이다.

VI00000383148374 Accura Integra 1995

보다시피 XML은 정말 간단하다. XML 스니핏은 웹 서버나 웹 브라우저를 사용하는 car 객체를 나타낸다. 다른 각도에서 보면 XML 스니핏은 다른 애플리케이션에서도 공유될 수 있는 구조화된 데이터이다. XML의 도래로 많은 개발자들은 웹 서버와 웹 브라우저간 XML 변형 메커니즘을 개발했다. 마이크로소프트는 웹 애플리케이션 개발의 새로운 형태를 시작하는 두 가지 매우 중요한 COM 클래스를 탑재함으로써 개발자들을 도왔다. 이 COM 클래스의 프로그램 식별자(ProgID)는 Microsoft.XMLHTTP와 Microsoft.XMLDOM이다. Microsoft.XMLHTTP는 현재의 웹 페이지에서 웹 브라우저가 웹 서버를 프로그램에 따라 요청할 수 있게 해준다. 처리과정동안 웹 브라우저는 웹 서버에 있는 목표 ASP 페이지에 의해 해독되어질 수 있는 XML 버퍼를 보낼 수 있다. 반면 Microsoft.XMLDOM는 XML 버퍼를 조작하는 프로그램적 방법을 따른다. 이 두개의 COM 객체를 사용함으로써 누구라도 브라우저와 서버간에 XML 데이터를 교환할 수 있다. 여기 웹 서버로 의뢰하고 XML 버퍼로 환원하는 방법을 보여주는 코드 스니핏이 있다. 우선 특정 car에 좀더 많은 정보 요청을 나타내주는 XML 버퍼로 저장하기위해 Microsoft.XMLDOM 객체와 oDOM을 생성하는 것을 볼 수 있다. 그 다음 Microsoft.XMLHTTP 객체와 oHTTP를 생성하고 웹 서버로 간단하게 oDOM을 보낸다. 이전 코드는 GetCar.asp로 불리는 페이지(여기 제시된 페이지)를 요청하는 것을 보여준다. 이 페이지는 요청된 VIN(vehicle identification number)이 VI00000383148374인지 아닌지 체크한다. 만약 그렇다면 이 페이지는 웹 브라우저로 더 많은 정보를 환원시키고 그렇지 않으면 에러 XML 버퍼로 환원시킨다.

<%@LANGUAGE=JScript%> <% var oDOM = Server.CreateObject("Microsoft.XMLDOM"); oDOM.load(Request); var strVIN = oDOM.selectSingleNode("GetCar/vin") if (strVIN.text == "VI00000383148374") { Response.Write("Integra") } else { Response.Write("Invalid car"); } %>

중요사항으로 브라우저가 서버로 요청을 보내고 응답을 받을 때 페이지 전환이 없다는 것을 명심해야 한다. 첫 번째 페이지는 화면에 남고 페이지의 데이터(msg) 만이 변경된다. 이 간단한 예제는 XML이 매우 강력하다는 것을 보여준다. XML은 닷넷 플랫폼에 깔려있다. SOAP 개관 SOAP가 소개되기 이전 소프트웨어 상점들은 커스텀 XML 포맷과 COM 객체인 Microsoft.XMLHTTP 와 Microsoft.XMLDOM(이전 섹션에서 내가 제시했던 것과 비슷함)을 사용하는 SOAP형의 프로토콜을 개발했다. 이런 이미 SOAP형의 프로토콜이 있었는데 왜 다시 SOAP를 개발했어야 했을까? SOAP가 정답이며 XML 표준에 기본을 두고 있기 때문이다. XML은 모든 종류의 새롭고 간단하며 강력한 개념을 제공하는데 XSD(XML Schema Definition), XSL(Extensible Style Language), SXLT(XSL Transformation), SOAP 등등을 포함한다. 이런 주제에 대한 언급은 이 기사를 범주를 벗어나는 것이지만 닷넷이 이러한 개념을 초기에 고려사항으로 생각했기 때문에 XSD와 SOAP에 대해 짧게 언급하는 것으로 마무리 짓겠다. XSD SXD는 애플리케이션 특정적인 XML 기반 데이터 타입을 정의하기 위한 스펙이다. 재미있는 사실은 XSD가 완전히 XML로 표현된다는 것이다. 추상적인 데이터 타입을 정의하는 방법으로 XSD를 생각하면 C 또는 C++ 클래스에 있는 구조체와 비슷하다. 유일한 차이점은 XML로 정의한다는 것이다. 예를 들어 C++ 클래스는 다음과 같다.

class CCar { public: string vin; string make; string model; int year; };

똑같은 타입을 XSD를 사용한 XML에서는 다음과 같이 표현한다. XSD의 실례는 다음과 같이 표현된다.

VI00000383148374 Accura Integra 1995

새로운 애플리케이션 특정 타입을 생성해내는 능력 때문에 XSD는 아주 중요한 스펙이다. 예를 들어 SOAP는 전적으로 SOAP 특정 XSD를 사용함으로서 표현된다. SOAP 이전 XSD 예제는 XSD 정의가 C++ 클래스와 같은 데이터 형식을 직접적으로 표현하는 것을 보여준다. 그리고 특정 XSD에 근거한 XML 버퍼가 직접적으로 객체나 특정 타입의 변수로 표현하는 것을 보여준다. 지금까지 여러분은 타입 정의에 대해서는 들어봤으나 메소드 호출을 표현하는 방법에 대해서는 들어보지 못했을 것이다. SOAP는 특정 컴퓨팅 플랫폼에 상관없이 XML로 리모트 메소드 호출을 표현해주는 공개 표준이다. 무거운 RPC 기반 프로토콜이나 인프라스트럭처에 의존하는 것 대신에 SOAP는 어떤 형태로도 전송할 수 있는 직렬화 포맷을 상술한다. 이런 이유로 SOAP 메시지는 웹에서 SOAP를 활동적인 프로토콜로 만들어 주는 HTTP 메시지의 일부분으로서 쉽게 전송 될 수 있다. 사실 SOAP를 개발한 동기 중 하나는 DCOM과 같은 RPC 메커니즘이 방화벽과 NAT(Network Address Translation) 소프트웨어에서는 작동되지 않는다는 것이었다. 위에서 언급했었던 SOAP 메시지 포맷에 대해 좀 더 이야기해보도록 하자. SOAP는 선택적인 헤더와 요청된 본문으로 구성된 SOAP 봉투라 불리는 직렬화된 XML 버퍼로 구성된다. SOAP 헤더는 프로토콜 확장 정보를 저장할 수 있게 해준다. 이것은 어떤 정보라도 저장할 수 있지만 인증, 허가, 암호 정보를 삽입하느냐에 유의해야 한다. SOAP 본문은 입력과 호출 매개변수를 포함한 메소드 호출과 관련된 구조화된 XML 데이터를 저장하는 곳이므로 정말 중요하다. GetCar를 불러들이는 메소드 호출에 사용할 수 있는 SOAP 메시지에 대한 예제를 살펴보자. 선택적이므로 헤더가 없다는 사실에 유념하라. 또한 메소드 호출과 관련된 정보는 명세로 요구되기 때문에 SOAP 본문 내에 삽입되어진다는 사실도 유념해야 한다.

VI00000383148374

만약 직렬화된 XML 버퍼를 SOAP를 지원하는 플랫폼으로 보내면 GerCar 메소드의 출력을 포함하는 또 다른 직렬화된 XML 버퍼를 돌려 받을 것이다. 예를 들어 메소드 호출의 결과와 관련된 XML 버퍼를 포함한 본문 요소와 함께 SOAP 봉투를 돌려 받을 수 있다.

Integra

이 예제가 Microsoft.XMLHTTP와 Microsoft.XMLDOM.을 사용한 이전의 예제와 비슷하다고 생각될 것이다. 표준 SOAP에 반대되는 토착 SOAP 버전을 비교하기 위해 고의적으로 비슷한 예제를 사용했다. 성숙 요건 웹 애플리케이션 개발은 7년 정도밖에 되지않았지만 소프트웨어 산업은 웹 기반 시스템을 구축하고 개발하는데 있어 더욱더 성숙했다. 이로 인해 습득한 교훈은 다음과 같다.

• 상호운영성
• 확장성
• 유용성
• 관리성

그렇다면 이제 위와 같은 사항에 대해 간단하게 토의해보자.

• 상호운영성. 소프트웨어는 제로 코드 소스를 요구하는 이진 수준에서 다른 소프트웨어와 상호 운영할 수 있게 플러그 앤 플레이를 지원해야 한다. 이것은 도구가 소프트 웨어를 통합하는데 사용될 수 있는 타입 정보를 검사하고 출력할 수 있는 메타데이터를 포함하는 소프트 웨어를 요구한다. COM은 상호운영성을 지원하는 가장 우수한 기술이며 COM+ 컴포넌트 서비스는 이 개념을 대규모 엔터프라이즈까지 아우르는 애플리케이션까지 확장했다.
• 확장성. 웹 애플리케이션은 초기에는 백 명 정도의 사용자만 있을 수 있으나 두 달 후에는 수 십만 명의 사용자가 있을 수 있다. 웹의 본질상 웹 애플리케이션은 시간의 흐름에 따른 확장성이 있어야 한다. 애플리케이션은 하드웨어나 좀더 똑똑한 소프트웨어를 추가함으로써 확장될 수 있다. 다시 하드웨어 확장은 고성능의 CPU와 메모리를 추가하거나 물리적인 장비를 추가함으로써 할 수 있다. 일련의 장비를 추가하는 것은 병목현상을 방지하고 응답률을 높여줌으로써 웹 사이트에 접속하는 로딩량에 균형을 잡아준다. 이렇게 함으로써 시간의 흐름에 따라 엄청난 사용자 수를 지원하기 위한 애플리케이션 확장이 가능하다. 그러나 확장하기 전에 웹 애플리케이션을 정확하게 구축해주어야 한다. 확장성의 요지는 매우 간단하다. 그것은 웹 서버에서 완전히 stateless한 웹 애플리케이션을 디자인하고 구현하는 것이다.
• 유용성. 확장만으로는 충분하지 않다. 사용자는 시간과 상관없이 웹 애플리케이션을 이용할 수 있기 때문에 하루 중 어느 때라도 애플리케이션을 사용할 수 있도록 디자인해야 한다. 따라서 애플리케이션의 가동시간은 늘이고 휴지시간은 줄어들도록 해야한다. 애플리케이션이 다운되거나 하드웨어 작동이 실패할 경우에 대비해서 페일오버와 같은 장치를 추가 시켜야 한다. 예를 들어 소프트웨어를 견고하게 만들어주는 다른 장치를 취할 수도 있으며 확장성 뿐만 아니라 페일오버도 제공하는 로딩량에 균형 잡아주는 똑똑한 하드웨어를 추가하거나 데이터베이스 시스템에 클러스터를 추가할 수 있다.
• 관리성. 엔터프라이즈나 웹 시스템에서는 장비들이 클러스터를 이루고 있을 정도로 많이 있다. 몇몇 개의 장비는 관리하기가 쉬우나 클러스터를 이루고 있는 대규모의 장비를 관리하기란 매우 신경이 많이 쓰이는 일이다. 서버 장비를 많이 갖춘 환경에서 문제를 고치기 위해 돌아다니는 것은 효율적이지 않다. 그 대신 엔터프라이즈 내의 모든 서버를 관리하는 핵심 포인트를 구현하는 것이 중요하다. Terminal Services와 같은 프로그램은 매우 중요하기 때문에 위와 같은 사항을 종종 체크할 필요가 있다.

요약 이 3편의 시리즈에서 나는 간단한 분산 컴퓨팅에서 대규모 웹 기반 컴퓨팅까지를 다루었다. SOAP가 분산 컴퓨팅에서 플랫폼에 상관없이 작동하는 프로토콜이기 때문에 웹에 적당한 프로토콜이라 말했으며 소프트웨어 산업이 대규모 애플리케이션을 개발함으로써 습득한 교훈에 대해서도 언급했다. 이와 같은 사항들이 소프트웨어 산업에서 가치 있는 것이라고 이미 밝혀졌기 때문에 나는 여러분들이 이런 개념을 통해 배우는 것이 있었으면 한다. 이런 개념과 기술에 삽입된 원칙들은 마이크로소프트의 비전을 이해하는데 충분한 것들이다. 일반적으로 마이크로소프트는 이런 생각들을 취해서 실용적이며 응용 가능한 프로그램을 만들었는데 그것이 바로 마이크로소프트 닷넷이라 불리는 플랫폼이다. 이번 기사와 이전 두 기사에서도 보여졌듯이 소프트웨어 산업은 공개적인 웹 기반 컴퓨팅 플랫폼 개발에 많은 노력을 기울여왔다. 닷넷 플랫폼이 웹을 진정으로 껴안는 것이기 때문에 마이크로 소프트도 이러한 주류 중 일부임은 틀림없다. 만약 여러분이 닷넷 프래임워크를 소개하는 기술 사항에 대해 관심이 있다면 나의 동료이자 이 책의 공동 저자인 호앙 램과 함께 집필한 『닷넷 프레임워크 에센스』을 살펴보는 것도 좋을 것이다. 쑤안 타이는 『DCOM 제대로 배우기』 (한빛미디어, 2001)의 저자이며 『닷넷 프레임워크 에센스』 (한빛미디어, 2001)의 공동 저자이다. 2000년 8월에 있었던 마이크로소프트의 닷넷 발표이후 닷넷 플랫폼에 대한 기술관련 프리젠테이션을 하고있다.