지난 호에는 웹서비스가 어느 정도 진행되었고, 어느 부문에 가장 먼저 영향을 미칠 것인지에 대하여 알아보았다. 웹서비스가 비즈니스 분야에 본격적으로 적용되면서, 기존의 XML, WSDL(Web Service Definition Language), SOAP(Simple Object Access Protocol), UDDI라는 4개 표준만으로는 부족하고, 상세 수준에서의 본격적인 기술이 필요하다. 특히, 웹서비스가 기업환경에 도입되면서 보안, 트랜잭션과 라우팅 등에 대한 상세 기술에 대한 요구가 늘어나고 있다.
이번 호에는 WS-시큐리티, WS-라우팅, WS-리퍼럴과 같이 새로 디자인되고 있는 스펙에 대해 먼저 설명하고, 마이크로소프트의 윈도, 오피스, 서버 제품군의 근간이 될 웹서비스 하부구조인 GXA에 대해 알아보도록 하겠다.
웹서비스의 새로운 표준들
웹서비스와 관련된 표준기술들은 BEA, IBM, MS 등이 주도적으로 디자인하고 있지만 아직은 검토 및 평가용으로만 사용되고 있으며, 구현 또한 각 벤더들에게 맡겨져 있다. 또한 썬, 오라클 등도 자신들만의 보안(Security), 라우팅(Routing) 등에 대한 표준을 만들어가고 있다.
■ 웹서비스 시큐리티 버전 1.0
WS-시큐리티는 메시지 무결성, 메시지 기밀성과 단일 메시지 인증을 통해 SOAP 메시징의 보호수준을 높이고 있다. 이와 같은 메커니즘은 매우 다양한 보안 모델과 암호화 기술에서 사용될 수 있다.
WS-시큐리티는 또한 메시지에 보안 토큰(token)을 통합하는 범용적인 메커니즘도 제공한다. WS-시큐리티는 별다른 보안 토큰형식을 요구하지 않기 때문에 확장성이 좋을 것으로 기대된다.
이 밖에, WS-시큐리티는 바이너리 보안 토큰을 인코딩하는 방법을 설명하고 있다. 특히, 스펙은 X.509 인증과 ‘커버로스(Kerberos)’ 티켓을 인코딩하는 방법뿐 만 아니라 ‘Opaque’ 암호화된 키를 포함시키는 방법도 설명하고 있다. 또한 이것은 메시지와 함께 포함되는 기밀성의 특징들을 설명할 수 있는 확장성 메커니즘도 포함하고 있다.
SOAP 기반의 스펙은 SOAP 확장성 모델을 사용, 서로 결합해 풍부한 메시징 환경을 제공할 수 있도록 디자인됐다. WS-시큐리티는 그 자체만으로는 보안을 보장하거나 완벽한 보안 솔루션을 제공하지는 않는다. WS-시큐리티는 일종의 빌딩블록으로 다른 웹서비스와 애플리케이션 특유의 프로토콜과 함께 사용되어 다양한 보안 모델과 암호화 기술을 수용한다. WS-시큐리티를 구현한다고 해서 애플리케이션이 보호되거나 해킹을 방어할 수 있는 것은 아니다.
WS-시큐리티와 관련된 스펙은 아직은 검토와 평가용으로만 제공된다. 베리사인(VeriSign), IBM, 마이크로소프트는 기업과 개발자들의 제안을 받아 계속 향상시켜 가고 있다.
■ 웹서비스 라우팅 프로토콜
웹서비스 라우팅 프로토콜(Web Services Routing Protocol, WS-Routing)은 초기 발신자가 중개자들을 통해 최후위 수신자에게 단방향 SOAP 메시지를 전달하는 SOAP 기반의 무상태(stateless) 프로토콜이다. WS-라우팅은 요청/응답, 피어 투 피어(peer-to-peer) 대화와 같은 양방향 메시지 교환패턴, 그리고 메시지 인정과 오류를 반환할 수 있게 하는 선택적 역방향 메시지 경로(optional reverse message path)를 제공한다.
WS-라우팅은 SOAP 포장 내에서 SOAP 헤더 엔트리로 표현되기 때문에, 기본적인 프로토콜과는 비교적 무관한 편이다. 이 스펙은 TCP, UDP, HTTP에서 WS-라우팅을 사용하는 것을 정의하고 있지만, 다른 기본적인 프로토콜에서도 사용하는 것이 가능하다.
WS-라우팅과 관련된 스펙 역시 검토와 평가용으로만 제공되고 있다.
■ 웹서비스 리퍼럴 프로토콜
웹서비스 리퍼럴 프로토콜(Web Services Referral Protocol, WS-Referral)은 SOAP 라우터에 라우팅 엔트리를 삽입하고, 삭제하고, 질의할 수 있는 SOAP 기반의 무상태(stateless) 프로토콜이다. SOAP 라우터는 단독 또는 다른 서비스와 결합해 웹서비스로 전달되는 SOAP 메시지를 공개하는 SOAP 노드다.
SOAP는 발신자가 메시지의 어느 부분이 가상 메시지 경로를 따라 각각의 SOAP 동작자(actor)를 위한 것인지를 나타낼 수 있게 하는, SOAP 동작자 개념에 따른 분산형 처리 모델을 도입하고 있다. SOAP 노드가 SOAP 메시지를 처리할 때에는, 한 개 이상의 SOAP 동작자의 역할을 하도록 지시를 받는데, 각각의 역할은 SOAP 동작자 이름을 의미하는 URI로 식별된다. SOAP 동작자 이름의 목적은 웹 상의 리소스로 SOAP 노드를 파악하기 위한 것이다.
WS-라우팅은 특정 SOAP 메시지에 대한 실제 경로를 설명하도록 디자인됐다. 그러나, WS-라우팅은 SOAP 경로를 설명할 수는 있지만, 어느 SOAP 라우터가 메시지 경로에 포함되는지를 구성하는 메커니즘을 제공하지 않는다.
WS-리퍼럴의 목적은 SOAP 애플리케이션이 참조정보를 교환해 SOAP 라우터에서 라우팅 엔트리를 삽입하고, 삭제하고 질의하는데 필요한 메커니즘을 제공하는 것이다. 특히, 이 스펙은 다음과 같은 사항을 정의하고 있다
· 참조 정보를 설명하는 WS-리퍼럴 명령문의 XML 기반 구조
· WS-리퍼럴 명령문에 대해 SOAP 라우터를 질의할 수 있는 메커니즘
· SOAP 라우터에서 WS-리퍼럴 명령문을 삽입하거나 삭제하여 등록할 수 있는 메커니즘
· WS-리퍼럴 명령문을 SOAP 헤더 블록으로 캡슐화할 수 있는 메커니즘
