한빛출판네트워크

저자: 앨 새가니치(Al Saganich), 역 한빛리포터 이상화

웹 서비스는 B2B, B2C 서비스 제공방법에 혁명을 일으킬 수 있는 새로운 기술이다. 웹 서비스는 통신하고 있는 2개의 애플리케이션에 대해 다양한 기술들을 사용한다. 웹 서비스가 특별히 새로운 것이 아님에도 불구하고 여타 유사한 메커니즘과 다른 점은 서비스를 제공하는 기술에 있다.

웹 서비스는 통신 메커니즘의 핵심으로 XML을 가지고 있다. 결국 웹 서비스는 서비스를 등록하기 위한 메커니즘, 서비스를 찾기 위한 메커니즘, 두 상대방이 통신하기 위한 메커니즘으로 구성된 3개의 구체적인 기술에 기반을 두고 있다. 오늘날 개발자들은 웹 서비스를 제공하기 위해 J2EE API나 XML을 사용한다. 웹사이트 상에 존재하는 이러한 개발 도구들은 확장을 위한 단순한 메소드를 제공하고 이미 존재하는 J2EE기반 애플리케이션을 새롭고 흥미 있는 방법으로 서로 연결하거나 발행(publish)할 수 있게 해주고 있다.

본 기사에서는 기존의 컴퓨터 협업(collaboration)에 대해 검토해보고, 이러한 협업 문제들을 해결하기 위해 웹 서비스와 J2EE가 다양한 시스템 서비스들을 어떻게 제공하는가에 대해 살펴볼 것이다. 이후에는 각 서비스에 대해서 자세히 살펴 볼 것이며 현존하는 웹 애플리케이션 상에서 웹 서비스를 개발해 볼 것이다.

웹 서비스란 무엇인가?

이미 우리는 1년여 넘게 새로운 웹 프로그래밍 패러다임(웹 서비스)을 들어 왔다. 그러나 정확히 여기에서 말하는 웹 서비스가 무엇을 뜻하는가? 한마디로 웹 서비스는 RPC(Remote Procedure Call)가 자연스럽게 진화한 형태라고 할 수 있다. 사실 웹 서비스가 과거의 RPC보다 진보된 기술은 아니다. 그렇지만 이전의 비슷한 개념들은 전혀 새로운 방법으로 적용되고 있다!

우선 웹 서비스란 정확히 무엇인가? 필자는 BEA, 마이크로소프트, Ariba, HP, 썬을 비롯한 기타 업체들이 자신들 나름대로의 정의를 가지고 있을 것이라고고 생각한다. 일단 이에 대한 논의를 하려면 다음과 같은 구체적인 세 가지부터 살펴보아야 할 것이다.

• 서비스를 찾고 등록하는 방법
• 서비스에 접근하기 위한 전송 메커니즘
• 서비스를 위한 입/출력 파라미터를 정의하는 방법

이러한 세 가지 특성이 결합되면 새로운 형태의 분산 컴퓨터 환경을 제공하게 된다. 이러한 컴퓨팅 환경과 과거 DCE(Distributed Computing Environment)의 차이점은 표준과 실행방법에 있다. 표준 정의 메커니즘, 표준 검색 방법, SOAP를 통한 표준 전송 정의가 바로 여기에 해당된다. 이러한 것들은 근본적인 실행 메커니즘과는 상관없이 운용될 수 있다. 이론적으로 웹 서비스를 돋보이게 하는 것은 Microsoft IIS에서 운용되는 C로 프로그래밍 된 웹 서비스가 BEA Weblogic 서버에 있는 자바로 만들어진 웹 서비스에 접근할 수 있다는 점이다. 실제로 웹 서비스가 어떻게 실행되는지는 문제되지 않는다.

새로운 분산 컴퓨팅 환경에서의 위 3가지 요소는 간단할 수도 있고 한없이 많은 것을 요구 할 수도 있다. 예를 들어 UDDI와 ebXML은 비슷한 서비스를 제공한다. 전자는 단순한 경우인 반면 후자는 다소 까다로운 기술이다. 각 서비스에 대해 설명하기 전에 표준 웹 서비스 모델 그림을 참고해 보자.

[그림] 웹 서비스 개요

위 [그림]은 지난 몇 년간 이미 여러 종류의 형태들로 보아 왔던 그림이다. 그러나 정확히 이 그림이 나타내는 것은 무엇일까? 첫째, 우리는 서비스 제공자를 가지고 있는데, 이것은 많은 수의 서비스들을 가지고 있으며 이것들 중 몇몇은 웹 서비스로 노출(expose)되어 있다. 둘째, 클라이언트가 공개된 웹 서비스에 대한 정보를 검색할 수 있도록 발행(publish)된 정보를 가지고 있는 집중화된 서비스 저장소(repository)가 필요하다. 그리고 마지막으로 서비스를 검색하고 접근하기 위한 다양한 메커니즘이 필요하다.

이제 이러한 기능들을 가지고 있는 웹 서비스의 기반을 이루는 표준들을 각각 살펴볼 것이다. 하지만 먼저 [그림]에 나타난 프로세스들을 살펴보고 운용 방법부터 이해해보자.

• 1번은 서비스를 외부 저장소(repository)에 발행하는 서비스 제공자를 나타낸다. 한번 서비스가 레지스트리에 등록되면 서비스는 클라이언트에 의해서 사용될 수 있다.
• 2번과 3번 각각의 의미하는 바는 서비스를 저장소로부터 찾고(look up) 서비스에 관련된 정보를 되돌려주는 것(retrieve)을 나타내고 있다. 프로시저 요청 포맷에 대한 정보와 서비스 제공자의 위치는 일반적으로 다른 세부 사항에 의해서 제공되어 진다.
• 4번과 5번은 서비스에 바인딩(binding)하는 클라이언트와 서비스가 제공하는 기능들을 사용하기 위해 클라이언트가 서비스에 접근하는 과정을 나타낸다.

위 [그림]에서 새로운 것은 보이지 않는다. 사실 Sun/RPC, DCE/RPE, DCOM, EJB도 비슷한 서비스를 제공하고 있다. 차이점은 앞서 말했듯이 이러한 서비스가 어떻게 제공되고 있는가에 있다. 전통적인 RPC 서비스는 비슷한 기반의 구조와 바이트 포맷을 이루고 있다. 예를 들어 두 개의 상이한 RPC 도구가 상호 운영성을 확보하려면 양쪽은 반드시 의사소통을 위한 메커니즘을 제공해야 했다. 이러한 통신방법은 일반적으로 불완전하게 정의되거나 두 시스템의 상호운영을 만들기 위해 세심하게 주의를 기울여 취급해야 했다.

웹 서비스는 전통적인 RPC 메커니즘과 다음과 같은 면에서 다르다.

• 데이터는 전송을 위해 (마샬링(marshalling)/언마샬링(unmarshalling)방법을 향상시키거나 제거할 수 있는) XML을 이용하여 포맷이 지정되고, 다양한 전송 관련 요구 사항들은 개발자에 의해서 코딩된다.
• 데이터는 HTTP, SMTP과 같이 표준으로 정해진 프로토콜을 통해서 전송된다.
• 노출된 서비스는 잘 정의된 WSDL이라는 메커니즘을 사용하여 정의된다.
• 서비스는 ebXML보다 진보한 UDDI라는 잘 정의된 표준을 통해서 검색되어 진다.

이러한 모든 배경지식과 함께 현재 웹 서비스의 위치도 중요하긴 하지만 일단은 웹 서비스의 기초를 이루고 있는 기반 메커니즘과 웹 서비스가 과거 DCE, RPC와 근본적으로 어떻게 다른가에 대해서 살펴 보겠다.

XML

웹 서비스의 핵심은 XML을 기반으로 하는 기능들의 집합으로 이루어져 있다. XML은 뛰어난 기술이며 웹 서비스의 근간을 이루고 있다. XML의 장점인 데이터 처리 과정에 대해서 살펴보자. 일반적으로 2개의 시스템이 통신하기 위해서는 강한 결합(tightly bound)이 필요하다. 또한 이와 같은 강한 결합이 발생하는 경우는 데이터 처리과정이 대부분이다. 데이터가 전송될 때 양쪽 시스템은 전송에 관한 정보를 이해하고 읽을 수 있어야 한다. 이것을 해결하기 위해 "네트워크 일반 형식"이 존재한다. 네트워크 일반 형식은 Byte, Integer, Float, Double형을 수용할 수 있는 포맷이다. 이것을 통해서 데이터는 양쪽 시스템이 이해할 수 있는 포맷으로 전송된다. 하지만 몇 가지 단점도 있다. 즉, 데이터가 올바르게 묶여졌는지, 시스템 양쪽 엔드포인트(endpoint)가 데이터를 어떻게 묶고 푸는지, 이러한 포맷에 모두가 동의하는지와 관련된 많은 복잡한 문제에 대한 해결방법이 필요하다는 것이다. 이러한 것들은 공통된 데이터 표현방법과 정의방법이 없기 때문에 나타난 것이다. XML은 잘 정의된 데이터 표현방법 뿐만 아니라 잘 정의된 검증 집합과 규칙을 제공함으로서 앞선 문제점을 해결하였다. 그 결과 XML은 양쪽 시스템이 쉽게 이해하고 읽을 수 있는 포맷을 제공함으로써 데이터 전송을 위한 훌륭한 전달자 역할을 하고 있다. XML도 약간 복잡하다는 단점이 있긴 하지만 이러한 복잡성은 오늘날의 빠른 네트워크로 극복되고 있다.

서비스를 정의하는 WSDL(Web Services Description Language)

일반적으로 전통적인 RPC와 DCE환경은 엔트포인트를 정의하는 것이 가장 어려운 문제였다. 다양한 인터페이스 기술 언어(IDL)가 있었지만 인터페이스의 정의가 먼저 선행하고 그런 다음 구현을 했어야 했다. 웹 서비스 기술언어(WSDL, wisdel로 발음)는 XML과 이미 존재하는 애플리케이션의 인터페이스, 새로운 애플리케이션의 인터페이스에 대해 새로운 접근을 하고 있다. WSDL로 인터페이스를 정의하면 CORBA와 RPC에서 그랬듯이 IDL로부터 인터페이스를 생성할 필요도 없고, 코드에서부터 인터페이스를 생성할 필요도 없다. WSDL은 문법과, 시멘틱스(Semantics), 웹 서비스의 프로시저 호출에 대한 다양한 관리자적 관점을 정의한다.

WSDL은 웹 서비스에 대해 중요한 정보를 제공한다.

• , , 적절한 스키마 정의를 사용해서 양쪽 엔드포인트 간에 메시지 포맷 정의
• 서비스의 시멘틱스(Semantics): 동기식 요청/응답, 유일한 동기식 응답, 비동기적 통신을 하기 위해 어떻게 호출되는가에 대한 정보
• 요소를 이용하여 서비스를 제공하는 endpoint와 서비스 전송 정보
• 요소를 이용하여 어떻게 서비스에 접근할 수 있는가에 대한 인코딩 정보

WSDL 예제

  
    
      
       
         
           
         
       
      
      
       
         
           
         
       
      
    
  

  
    
  

  
    
  

  
    
      
      

    
  

  
    
    
      
      
       
      
      

       
      
    
  

  
    My first service
    
      
    
  

이제 데이터를 어떻게 전송하는지, 인터페이스를 어떻게 정의하는지에 대해 알아보았다. 하지만 아직 클라이언트의 작동방법과 어떻게 서비스를 찾고 바인딩 하는지에 대해서는 알지 못한다. 이제 UDDI와 ebXML에 관해 이야기해보자.

---

참고 도서 자바와 XML, 개정판 브렛 맥래프린 목차보기 샘플챕터보기

---

UDDI(Universal Discovery and Description Integration)

서비스를 실제로 사용하기 위해 클라이언트는 첫째, 서비스를 검색해야 하고 둘째, 서비스 사용법에 대한 정보를 획득한 다음 셋째, 서비스 제공자에 대한 식별이 필요하다. UDDI는 클라이언트가 웹 서비스에 접근하기 위해 요구한 정보를 검색하고 획득할 수 있게끔 많은 검색 서비스를 정의한다.

UDDI는 실제로 다음과 같은 세 가지 특별한 서비스를 제공한다.

• 이름으로 웹 서비스를 검색하게 하는 White Pages
• 주제별로 웹 서비스를 검색하게 하는 Yellow Pages
• 웹 서비스의 특징을 기반으로 하는 일반적인 검색을 위한 Green Pages

UDDI 서비스를 제공하는 벤더들은 제공되는 웹 서비스의 발행과 정보에 대해 접근할 수 있도록 UBR(UDDI Business Registry)이라고 알려진 서비스를 운영하고 있다.

SOAP(Simple Object Access Protocol)을 사용하여 모든 것을 연결할 수 있다

이제 우리는 웹 서비스가 어떻게 정의되는지, 웹 서비스가 발행되고 접근될 수 있는 곳이 어딘지 안다. 그러나 아직 언급하지 않은 문제 중에서 중요한 것은 실제로 웹서비스를 어떻게 검색하고 접근하는가이다. 웹 서비스는 SOAP을 사용하여 접근하게 된다. 사실 이전부터 우리는 잘 정의된 SOAP 호출을 사용하여 UDDI 레지스트리에 접근했었다! SOAP이란 HTTP와 같은 표준 통신 프로토콜을 사용하여 XML 페이로드 요청을 캡슐화 하기 위해 단순화시킨 프로토콜이다. SOAP은 단순하고, 실행하기 쉬우며, 업계에서 지원이 잘되기 때문에 강력한 힘을 가질 수 있었다.

전형적으로 SOAP 호출은 HTTP 요청 속에 포함되어 있다. 아래와 같은 W3C SOAP 예제는 HTTP 서버를 통해 GetLastTradePrice 서비스에 접근하는 SOAP 호출을 보여주고 있다.

SOAP 예제

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"



 
  DIS
 

SOAP은 메시지 기반의 표준 RPC와 같은 동기식/비동기식 호출 시멘틱스를 모두 지원하며 HTTP와 다양한 프로토콜 상에서 사용될 수 있다.

결론

이 기사에서는 웹 서비스에 대한 기본적인 개념에 대해 설명하였다. 또한 기존 분산 컴퓨팅 환경을 살펴봄으로서 웹 서비스가 이전의 비슷한 기술들을 어떻게 새로운 개념으로 만들었는지에 대해서도 언급해 보았다. 웹 서비스는 아직 초기 단계이지만 UDDI와 SOAP를 사용함으로써 분산 서비스에 대한 접근을 단순하고 간단하게 만들었다.

이후 초기의 웹 서비스는 클라이언트/서버 제공자와 같은 1:1 서비스가 될 것이지만 미래의 웹 서비스는 보안, 트랜잭션, 다양하고 복잡한 상호작용을 지원하는 완벽한 다중 참여(multi-participant) 시스템이 될 것이다. 다음 기사는 J2EE 애플리케이션 서버에서 웹 서비스를 사용하기 위한 다양한 자바 API와 커스텀 웹 서비스 개발에 대해 얘기할 것이다.

---

앨 새가니치(Al Saganich)는 BEA 시스템의 수석 개발자이며 자바통합을 비롯한 XML, 웹 서비스 애플리케이션과 같은 자바 기술 사업의 설계자이다.