웹서비스는 분산 컴퓨팅과 웹 패러다임의 행복한 결합이다. 웹 기반 애플리케이션은 사용이 간편하지만 프로세싱 능력이 떨어진다. 분산 컴퓨팅 소프트웨어는 구성과 사용이 악몽일 수 있지만, 엔터프라이즈를 처리할 수 있는 능력이 있다. 웹서비스는 이 두 가지 세계에서 최상의 것들, 즉 강력한 분산 컴퓨팅 아키텍처 위에 기존의 웹 기술을 기반으로 하는 이용하기도 이해하기 쉬운 인터페이스를 합한 것이다.
배치 방법
웹서비스를 배치하는 일은 까다로울 수 있다. 주변의 업체들이 얘기하는 과대선전과 달리, 이것은 새롭고 순탄치 못한 과정이기도 하다. 일반적인 단계는 선호하는 개발 환경에 웹서비스를 쓰고, 소스 코드로부터 웹서비스 래퍼(wrapper)를 만들어내고(마이크로소프트 닷넷은 당신이 할 수 있게만 한다면 이 단계를 대신해줄 것이다), 웹서비스 래퍼로부터 서버 배치 패키지와 서버의 WSDL(Web Service Definition Language) 정의를 만든 다음, 서버의 WSDL 파일에서 클라이언트 ‘스터브(stub)’ 패키지를 만들고 웹서비스를 배치 및 테스트하는 것이다.
물론, 이것을 테스트하기 위해서는 클라이언트를 저작해야 하며, 따라서 다음 단계는 클라이언트 ‘스터브’ 파일을 이용해 클라이언트를 저작함으로써 인터페이스 계급을 만드는 것이다. 일이 너무 많아 보이는가? 다행히도 아파치/톰캡(Apache/Tomcap)과 마이크로소프트 IIS/닷넷(.Net)을 이용하면 이런 절차의 대부분은 자동화된다.
단계별 접근
1. 클라이언트 애플리케이션이 SOAP 지원 메시지를 이용해 RUI(Universe Resource Identifier)를 요청한다.
2. 웹 서버가 요청된 URI가 웹서비스인지를 인식하여 요청을 애플리케이션으로 전달한다(보통 닷넷의 경우 애플리케이션 서버를 통해 직접).
3. 애플리케이션이 요청을 지원하고 이것을 다시 웹 서버로 전달한다.
4. 웹 서버가 요청자에게 본문 안에 SOAP 포맷으로 인코딩된 웹서비스 결과가 있는 응답을 보낸다.
WSDL 사양은 애플리케이션이 ‘나에게 얘기하고 싶다면 어떻게 해야 하는지가 여기에 있다’라고 얘기할 수 있는 시스템 독립적 방안을 제공한다. 시스템 독립성은 XML 포맷의 파일로 정의를 기록하는 데서 비롯된다. 반면 SOAP(Simple Object Access Protocol) 사양은 애플리케이션이 클라이언트 애플리케이션과 통신할 수 있게 해준다. WSDL은 “나를 부를 때는 X, Y 그리고 Z를 갖고 있어야 한다”라고 말한다. SOAP는 X, Y, 그리고 Z가 어떻게 애플리케이션에 도달하고, 이것이 그 응답을 돌려보내 주는지를 말한다.
대부분의 SOAP는 HTTP를 통해 이루어지며 대부분의 웹서비스는 HTTP를 자신들의 ‘전송 메커니즘’으로 정의하고 있지만, 이는 전혀 요구되지 않는다. WSDL은 애플리케이션을 호출하기 위한 방법으로, 그리고 애플리케이션이 응답할 수 있는 방법으로 몇 가지 전송 메커니즘 중 어떤 것이든 설정할 수 있다. 예를 들어 ‘그 해의 책들을 정리하라’고 이야기하는 웹서비스가 있고 이 요청을 HTTP를 통해 보낸다고 해 보자. 연말 재고정리는 전혀 까다로운 작업이 아니며 분명 웹 브라우저가 이 작업을 마치는 데 기다림이 필요치 않을 것이다. 따라서 애플리케이션은 WSDL로 “책을 정리하고 있다면 그 응답 메커니즘은 SMTP가 될 것이다. 일이 끝나면 상사에게 e-메일로 이 사실을 알려주겠다”고 말하게 된다.
서버 스터브는 코드의 작은 부분들로 애플리케이션 서버에게 당신의 애플리케이션에 대해 알려주고 서버가 이것과 통신할 수 있게 해준다. 클라이언트 스터브는 클라이언트 애플리케이션에게 시스템 독립적인 방식으로 당신의 인터페이스에 대해 말해준다. 이들은 WSDL에서 만들어지며, WSDL은 시스템 독립적이기 때문에 당신의 인터페이스를 이들의 프로그래밍 언어로 번역하는 클라이언트쪽 번역기라고 생각하면 된다.
여러 가지 무료 애플리케이션들 중 하나를 이용하여 웹서비스용의 WSDL 파일을 만들 수 있다. 가장 인기 있는 생성기로는 자바 웹서비스용의 ‘자바투wsdl(Java2wsdl)’과 닷넷 웹서비스용 ‘WSDL.exe’가 있으며, 이들은 저작된 애플리케이션을 취해서 이를 위한 WSDL 파일을 만들어줄 것이다. 그러면 이 WSDL 파일로 서버와 클라이언트 스터브를 만들어 웹서비스를 배치 및 액세스하는 프로젝트에서 사용할 수 있다.
아키텍처
웹서비스는 호출 사양, 인터페이스 사양, 응답 사양, 그리고 작업을 하는 프로그램으로 이루어진다.
>> 호출 사양: 웹 서버와 통신하는 데 필요한 최소한의 이벤트 시퀀스(단순성을 위해, HTTP가 양방향 전송수단이라고 가정하자)는 다음과 같다:
1. 클라이언트가 웹서비스와 파라미터를 포함하고 있는 HTTP post 요청을 보낸다. HTTP get 사양도 사용 가능하다.
2. 서버가 결과나 요청된 프로세싱을 포함한 HTTP 응답을 보낸다.
>> 인터페이스 사양: WSDL: WSDL이 애플리케이션에 연결되는 방법에 대해 말해준다는 사실은 이미 알고 있겠지만, WSDL을 하나의 표준으로도 생각할 수 있다. 이것은 전화 번호가 하나의 표준인 것과 같은 의미다. 호출하고 있는 사람과 통신하고 싶다면 전화번호를 알아야 한다. 마찬가지로, 애플리케이션은 웹서비스와 통신하기 위한 인터페이스가 필요하다. 대부분의 환경에서는 WSDL 파일이 자동으로 생성되기 때문에 이들을 저작할 필요가 없다.
그렇다면 웹서비스의 WSDL 파일에 어떻게 손을 댈 것인가? 대부분은 www.mywebservice.com/someServiceURL/wsdl?의 형태로 요청에 응답할 것이다.
어떤 업체가 당신에게 그 회사의 원더풀 웹서비스에 대해 얘기했다고 가정하자. 제공받은 URL로 들어가서 ‘/wsdl?’을 추가하기만 하면 된다. 응답은 이 기사에서 거론된 포맷의 XML 문서가 될 것이다.
