시소당

안전하고 신뢰성 있는 웹 서비스

Average rating: (13 ratings)

Donald F. Ferguson: IBM Corporation
Tony Storey: IBM Corporation
Brad Lovering: Microsoft Corporation
John Shewchuk: Microsoft Corporation

2003년 10월 28일

오늘날 웹 서비스들은-특히 XML로 인코딩된 SOAP 메시지를 처리하고 HTTP를 통해 전송되며 Web Services Description Language (WSDL)로 정의된 분산 서비스- 광범위하게 전개되고 있다. 웹 서비스는 애플리케이션 통합 시나리오의 범주에서 사용되고 있다. 간단한 데이터 공유에서부터 대규모의 인터넷 판매 및 통화 교환까지 미친다. 이제 웹 서비스는 모바일, 디바이스, 그리드 시나리오에도 적용되고 있다.

Introduction
오늘날 웹 서비스는 광범위하게 전개되고 있다. 웹 서비스는 애플리케이션 통합 시나리오 범주에도 사용된다. 그리고 이제는 모바일, 디바이스, 그리드 시나리오에도 적용되고 있다.

웹 서비스는 소프트웨어 컴포넌트들 간 상호운용성을 제공한다. 다양한 기업, 다양한 인프라들 사이에서 통신이 가능하다. 이것은 사용자, 소프트웨어 개발자, 파트너들이 직면한 가장 핵심적인 문제를 해결한다. HTTP와 SOAP은 통신 및 메시지 상호운용성을 제공한다. WSDL은 서비스의 디스크립션을 제공하여 개발 툴들 간 상호운용성을 지원한다. 인터페이스 정의를 교환하는 기능으로 통신 상호운용성을 보완한다.

웹 서비스 스팩의 기초는 고객과 소프트웨어 벤더들이 중요한 문제들을 해결하도록 한다. 많은 개발자들과 기업들은 웹 서비스 기술로 보다 어려운 문제들을 해결 할 준비가 되었다. 웹 서비스의 성공으로 인해 개발자들은 더 많은 기능을 갖춘 웹 서비스를 꿈꾸게 되었다.

기본적인 메시지 상호운용성과 인터페이스 교환 외에도 개발자들은 보다 높은 수준의 애플리케이션 서비스들의 상호운용성을 요구하게 되었다. 많은 상용 애플리케이션들은 보안과 트랜잭션 같은 기능을 지원하는 환경에서 실행된다.

IBM, Microsoft 등은 보다 안전하고, 신뢰성을 갖추고 트랜잭션을 지원하는 웹 서비스를 만들어 줄 것을 요청받고 있다. 게다가 필수적인 단순함과 상호운용성 틀은 유지하면서 이러한 기능들을 제공할 것을 요구받고 있다.

이 보고서에서 그러한 필요들을 다루는 웹 서비스 스팩을 검토하고자 한다.

조합가능한 서비스
우리가 SOAP과 WSDL로 수행했기 때문에 IBM과 Microsoft 및 기타 파트너들도 웹 서비스 스팩 정의에 따라 조합(composability) 이라는 디자인 원리를 따랐다. 우리가 채택한 접근방식은 웹 서비스 스팩 정의에 있는 조합 원리에 기초한다. 우리가 개발한 각각의 스팩은 즉각적인 필요를 해결하고 가치도 있다. 예를 들어, 개발자들은 신뢰성있는 메시징을 채택하여 솔루션 개발을 단순화한다던가 BPEL4WS를 채택하여 서비스 구성을 정의할 수 있다. 각 스팩은 독립적이지만 서로 결합하여 작동하도록 설계되었다.

조합(composability) 이라는 용어는 보다 강력한 기능을 제공하기위해 결합될 수 있는 독립 스팩들을 설명할 때 쓰기로한다. OS와 미들웨어 제공자들은 조합된 기능들을 지원할 수 있다. 예를 들어 제공자는 BPEL4WS 프로세스 통신에 믿을 수 있는 메시징 지원을 통합 시킬 수 있다. 이 예제는 두 개의 독립된 스팩을 조합하여 통신 프로세스 개발을 단순하게 한다.

조합은 새로운 개념, 툴, 서비스의 증가하는 소비(incremental consumption) 또는 진보적인 발견(progressive discovery)을 가능하게 한다. 개발자들은 필요한 것만 배우고 구현하면 된다. 솔루션의 복잡함 또한 문제의 요구사항이 증가할 경우에만 늘어날 것이다. 기술의 증가와는 관계가 없다.

조합은 웹 서비스 디자인의 핵심 목표 중 하나가 되어야 한다. 지난 수년 동안 가장 기본적인 웹 서비스 스팩(SOAP과 WSDL)을 정의하여 조합을 지원했다. 웹 서비스의 기본적인 특성 중 하나는 균형있는 멀티 파트(multi-part) 메시지 구조이다. 이 구조는 새로운 기능의 조합을 가능하게 한다. 새로운 서비스를 지원하는 새로운 메시지 엘리먼트는 기존 기능의 프로세싱을 변경하지 않고 메시지에 추가될 수 있다. 예를 들어 트랜잭션 식별자와 믿을 수 있는 메시징 시퀀스 넘버를 독립적으로 추가할 수 있다. 이 두 개의 확장은 서로 충돌하지 않으며 기존의 메시지 구조와 호환된다.

그림 1. 조합

그림 1은 간단한 웹 서비스 메시지이다. WS-Addressing, WS-Security, WS-ReliableMessaging 등의 요소들이 포함되어 있다. WS-Addressing, WS-Security WS-ReliableMessaging 요소들은 독립적이며 다른 엘리먼트들의 프로세싱을 변경하지 않고 독립적으로 사용될 수 있다.

이러한 특성으로 인해 조합가능한 메시지 엘리먼트의 관점에서 보안, 신뢰성, 트랜잭션이 정의될 수 있다.

조합의 개념은 보안과 신뢰성 등을 지원하는 잘 정의된 조합가능한 웹 서비스의 생성에도 적용된다. 잘 정의된 서비스는 고급 웹 서비스 기능을 지원하는데 필요한 서비스 작동을 지정한다. 메시지에 보안 엘리먼트를 발행하고 확인하는 WS-Trust에 정의된 Secure Token Service가 그 예이다.

서비스 사용자가 지원을 받고 있고 요구사항이 충족된 서비스 보증을 선택할 수 있도록 하는 것도 중요하다. 이 서비스는 요구사항들을 문서화하고 트랜잭션, 보안, 신뢰성 있는 메시징 등의 지원도 문서화 해야 한다. WS-Policy는 웹 서비스가 점진적으로 WSDL을 늘려서, 트랜잭션, 보안, 신뢰성 기능 중 어떤 것을 지원하고 필요로 하는지를 문서화 할 수 있도록 한다. WSDL과 WS-Policy로 인해 서비스의 디스크립션을 위한 조합이 가능해진다.

조합(Composition) 예제
그림 2는 조합 개요이다. 고객과 제공자는 웹 서비스를 사용하여 주문을 처리한다.

그림 2. 주문 처리 시스템에서의 조합

웹 서비스를 구현할 때 개발자는 WSDL과 관련 문서들을 사용하여 비지니스 인터페이스를 기술한다. 이 WSDL 문서는 사용자와 제공자의 웹 서비스가 처리할 메시지 세트를 설명한다. (그림 2). 일단 애플리케이션의 핵심 부분이 제자리에 놓이게되면 개발자는 추가 기능을 지원할 것인지를 결정할 수 있다. 예를 들어 여기에서는 주문 처리가 트랜잭션 되도록 결정하였다. 이를 위해서 다음과 같은 요소들을 기존 구조에 추가(compose) 했다:

• 이 서비스는 트랜잭션에 대한 지원을 설명하는 WS-Policy 문서를 서비스의 WSDL 디스크립션에 연합한다. 이러한 정책 문장이 추가되어도 기존 비지니스 기능은 근본적으로 변하지 않는다.
• 트랜잭션 되는 프로세싱을 지원하기 위해 이 서비스는 같이 구성되는 트랜잭션들을 설명하는 추가 메시지 엘리먼트들을 추가한다. 하지만 기존의 애플리케이션 메시지는 변경되지 않는다.
• 공급자 서비스가 트랜잭션 엘리먼트를 포함하고 있는 메시지를 받으면 이 정보를 사용하여 트랜잭션 기능을 지원하는 코디네이터인 해당 웹 서비스와 통신한다. 또한 이 추가되는 웹 서비스는 솔루션에 추가되지만 기존 비지니스 기능의 디스크립션을 변경 할 필요가 없다.
• 마지막으로 이 서비스는 추가 작동을 구현하여 트랜잭션 코디네이터 서비스와의 통합을 지원한다.

이 모델은 증가할 수 있으며 조합 가능하다. 이유는 다음과 같다:

• 새로운 기능을 추가하는 것은 다른 기능을 추가하는 것과 별개로 수행될 수 있다.
• 기능을 추가한다고 해서 기존 메시지, 메시지 프로세싱 로직, WSDL에 영향을 끼치는 것은 아니다.

조합(composability)은 점차 중요한 디자인 원리가 되어가고 있다. 하지만 이러한 접근 방식이 모두에게 잘 이해되는 것은 아니다. 개별 웹 서비스 스팩이 개별 엘리먼트와 서비스의 상호 작동 방법을 정의하고 있지만, 이 백서에서는 스팩들이 어떻게 조합되어 보다 세련된 웹 서비스 상호운용성을 제공하는지를 설명하겠다.

웹 서비스: 서비스 지향 아키텍쳐
최 근에 웹 서비스 개발에 집중된 활발한 움직임을 보아왔다. 이러한 모든 움직임도 중요하지만 한발짝 뒤로 물러서서 "왜?" 라는 질문을 하는 것도 중요하다. 확실한 것은 웹 서비스는 새로운 유형의 전산 기능을 가능하게 하는 것은 아니라는 점이다. 결국 웹 서비스도 기존 컴퓨터 상에서 실행되면서 명령을 실행하고 같은 데이터에 접근한다. 게다가 많은 경우 웹 서비스 프로토콜은 실제로 주어진 태스크에 대해 프로토콜 오버헤드를 증가시킬 수도 있다. 중요한 이유 중 하나는 웹 서비스가 서비스 지향 아키텍쳐 (Service-Oriented Architecture;SOA)를 활성화 하는데 적합하기 때문이다. 웹 서비스를 사용하여 SOA를 구현할 때 솔루션은 자율적인 서비스들(URL로 구분되고 WSDL로 문서화된 인터페이스와 잘 정의된 XML 메시지를 처리함)의 집합체로 구성된다. SOA는 근본적으로 솔루션 구현에 대한 객체 지향(OO) 접근 방식, 절차적 접근방식, 데이터 중심 접근방식의 보완이다. 실제로 SOA 시스템을 구현할 때 개별 서비스들은 이 중 한 개 이상의 기술을 사용하여 만들어진다.

서비스 지향 아키텍쳐는 OO와 절차적 시스템과는 한 가지 측면에서 다르다. 바로 바인딩(binding)이다. 서비스는 그들이 제공하는 서비스가 무슨 기능을 하는 지 그리고 제공하는 방법에 준하여 인터랙팅한다. OO와 절차적 시스템은 유형(type) 또는 이름에 근거하여 엘리먼트들을 연결한다.

서비스는 유형(type)이 아닌 스키마와 콘트랙트에 의해 설명된다.
이 전 시스템과는 다르게 웹 서비스 모델은 공통된 구현을 필요로하는 공유 유형의 개념으로는 작동하지 않는다. 오히려 서비스는 콘트랙트(WSDL/BPEL4WS; 메시지 프로세싱 작동)와 스키마(WSDL/XSD; 메시지 구조)를 기반으로 인터랙팅한다. 이것은 서비스로 하여금 송수신 가능한 메시지 구조를 설명할 수 있도록 한다. 구조와 작동 간 분리, 분명한 머신 별 디스크립션 등 이러한 특성들이 이종 환경에서의 통합을 간단하게 한다.

게다가 이러한 정보는 서비스 인터페이스를 충분히 특성화했기 때문에, 애플리케이션 통합의 경우 메시지 구조 또는 작동을 만들기 위해 공유된 실행 환경이 필요 없다.

도저히 불가능한 완전히 분산된 환경일 경우 스키마 또는 콘트랙트의 변경을 서비스와 관계된 모든 부분들에 전달한다. 서비스 지향에는 콘트랙트와 스키마가 호환 가능함을 내포하고 있으며 특정 프로세싱 시스템에 의해 불완전하게 이해되는 정보를 포함하고 있음을 내포한다.

결국 서비스 지향 디자인에서 사용될 콘트랙트와 스키마 기술은 기존의 객체 지향 인터페이스 보다 훨씬 유연하다.

서비스 호환성은 유형 호환성 그 이상이다!
절 차적 디자인과 객체 지향 디자인은 의미 호환성과 유형 호환성을 동일시하고 있다. 서비스 지향은 호환성을 결정하는데 다채로운 모델을 제공한다. 구조적 호환성은 콘트랙트(WSDL과 BPEL4WS)와 스키마(XSD)에 기반하고 유효화될 수 있다. 게다가 WS-Policy의 등장으로 인해 서비스들 간 서비스 보증 호환성 분석의 자동화가 가능해졌다. 이는 WS-Policy 문장 형식 상의 기능과 요구 사항의 명백한 표명에 기반하여 수행된다.

WS-Policy를 사용하면서 서비스는 서비스의 보증 기능과 요구사항을 기술한다. 표명의 조합들을 포함하는 머신이 판독 가능한 정책 표현의 형태로 기술한다. 이로서 서비스는 "방법" 또는 "품질"에 기반하여 선택할 수 있다.

정책 표명(Policy assertions)은 표명이 어떤 서비스에 적용되든지 간에, 시간과 공간에 일정한 의미를 지닌 안정적이고 유일한 이름으로 구별된다. 정책 표명은 매개변수를 갖고 있는데, 이 매개변수는 표명의 정확한 해석을 보장한다.

서비스 지향은 나쁜 일이 발생할 가능성까지 가정한다.
분산 애플리케이션에 대한 이전의 접근 방식들은 일반적인 유형 공간, 실행 모델, 프로시져/객체 레퍼런스 모델을 가정했다. "인메모리(in-memory)" 프로그래밍 모델은 분산 시스템 모델을 정의했다.

객체 지향은 서비스가 자치적으로 실행하고 로컬 실행의 개념 또는 일반적인 운용 환경에 대한 개념이 없다는 것을 가정한다. 따라서 SOA는 통신 에러, 가용성 에러, 유형 에러가 일반적인 것임을 염두해두고 있다.

시스템 무결성을 유지하기 위해서는 서비스 지향 디자인은 비동기성과 부분적 오류 모드를 처리하는 다양한 기술들에 의존해야 한다. 비동기식 메시징, 트랜잭션, 신뢰성 있는 메시징, 과잉 전개 같은 기술은 서비스 지향 시스템에서는 하나의 전형이다.

게다가 인메모리 모델과는 다르게 서비스 지향은 인커밍 메시지가 엉성하게 형성되었을 뿐만 아니라 악의적 목적 또는 예기치 않은 목적을 위해 전송될 수도 있음을 가정하고 있다. 따라서 서비스 지향 시스템은 모든 메시지 전송자에게 입증 의무를 지운다. 애플리케이션은 전송자에게 필요한 권한이 허용되었는지를 학인 할 수 있도록 한다. 서비스 자치 실행의 개념에 더하여, 서비스 지향 아키텍쳐는 신용 관계를 관리 차원에서 담당하도록 하여 기존 웹 애플리케이션에서는 일반적인 서비스당 인증을 피할 수 있게 하였다.

서비스 지향에서는 서비스들의 유연한 바인딩이 가능하다.
서 비스 지향 아키텍쳐(SOA)의 핵심 개념 중 하나는 유연한 서비스 바인딩이다. 보다 전통적인 절차적 모델, 컴포넌트 모델, 객체 모델은 레퍼런스(포인터) 또는 이름으로 컴포넌트들을 하나로 바인딩한다. SOA는 서비스 인스턴트들의 동적 발견을 보다 잘 지원한다.

절차적 시스템 또는 객체 지향 시스템에서 콜러(caller)는 전형적으로 이것이 반출하는 것에 기반한 서버 또는 공유된 네임 스페이스를 찾는다. SOA 시스템에서 콜러는 서비스용 UDDI 같은 레지스트리를 찾을 수 있다.

1. 콜러의 요구사항들에 호환되는 메시지 이다. 호환성은 WSDL 또는 잘 알려진 XML Schemas의 매칭 메시지를 통해 발생할 수 있다.
2. 문서는 콜러가 요구하는 서비스 보증을 지원한다. 예를 들어 콜러는 보안 또는 트랜잭션에 대한 확실한 접근 방식이 필요할 때가 있다.

작동의 대안 구현을 가능하게 하는 서비스 구현에 관련된 약 바인딩 (loose binding)은 비지니스 요구사항 범위를 다루는데 사용될 수 있다. 예를 들어 대안 구현은 변화하는 시장 조건에 빠르게 부응하는 공급 체인의 대안 벤더들이 대처할 수 있다. 대안 구현은 재앙에도 견딜 수 있는 지역적으로 분산된 데이터 센터가 될 수도 있다.

웹 서비스 스팩과 기능

웹 서비스에 조합 접근방식 적용하기
다음은 IBM, Microsoft 등이 만든 웹 서비스 스팩의 고급 그룹핑이다. 이 그림이 그룹들 간 정확한 레이어링은 아니다. 기능 구역들 간 관계에 대한 이해를 돕기 위한 그림이다.

그림 3. 보안, 신뢰성, 트랜잭션 가능한 웹 서비스

기본 - 전송과 메시징
나는 불어로 편지를 써서 보내지만 상대방이 영어로 말하는 전화를 기대한다면 통신은 불가능하다. 웹 서비스 상호운용성도 같은 문제에 직면했다. 전송과 메시징 기술의 공통된 세트를 제공하여 이에 접근하고자 한다.

이 기술이 실효성을 거둘 수 있도록 IBM, Microsoft 등은 Web Services Interoperability Organization (WS-I)을만들었다. 최근 WS-I는 상호운용 가능한 웹 서비스 전송과 메시징 메커니즘을 공식 문서화한 기본 프로파일을 발표했다.

3.2.1 전송 - HTTP, HTTP/S, SMTP

이 스팩 세트는 웹 서비스 간 원시 데이터를 이동하는 핵심 통신 메커니즘을 정의한다.

HTTP, HTTP/S, Simple Mail Transport Protocol (SMTP)는 이 그룹의 예제들이다. 웹 서비스 구현은 다른 전송수단을 지원하기도 하지만 표준의 상호운용 가능한 프로토콜을 제공하는 것은 중요하다.

3.2.2 메시지 포맷 - XSD

다음 그룹의 스팩은 웹 서비스 메시지들을 전송에 맞게 인코딩하는 상호운용 가능한 메커니즘을 정의한다. 전송이라 함은 서비스들 간 "바이트" 블록을 이동시키는 것이다. 이는 참여자가 바이트를 유용한 데이터 구조로 변환 할 수 있을 경우에 유용하다.

이 메시징 스팩 그룹은 메시지를 정확하게 포맷하는 방법을 정의한다. XML과 XML Schema 정의는 메시지(데이터) 구조에 대한 추상적 동의를 위한 메커니즘을 제공한다. SOAP은 XML 메시지를 바이트 정보에 표현하기 위한 표준 인코딩을 정의한다.

3.2.3 WS-Addressing

메시지와 응답 모두 어딘가로 가고 언딘가에서 부터 온다. WS-Addressing은 상호운용 가능하고 전송 독립적인 접근방식을 제공하여 메시지 전송자와 수신자를 구별한다. WS-Addressing은 메시지를 보내거나 받아야하는 서비스 내의 특정 엘리먼트를 구별하는 세밀한 접근방식도 제공한다.

오늘날 웹 서비스를 사용하는 대부분의 시스템들은 웹 서비스의 목적지를 URL로 인코딩한다. 응답의 목적지는 리턴되는 전송 어드레스로 결정된다. 이러한 접근방식은 기본적인 브라우저-서버 모델의 HTTP에서 구현된다.

이러한 접근 방식에서는 소스와 목적지 정보는 메시지의 일부가 아니다. 이는 많은 문제들을 야기시킨다. 이 정보는 전송 연결이 종료되면 손실될 수 있다. 또는 메시지가 방화벽 같은 매개체에 의해 포워딩 될 경우에도 손실된다.

WS-Addressing은 웹 서비스 메시지내에 직접 목적지 정보, 소스 정보, 기타 중요한 주소 정보를 둔다. 간단히 말해 WS-Addressing은 어드레스 정보를 모든 특정 전송 모델로 부터 커플링을 해제한다.

많은 시나리오에서 메시지들은 서비스로 직접 가도록 되어있고 메시지의 어드레스 정보는 URL을 사용하여 설명된다. 예를 들어 협업 서비스는 다양한 많은 태스크를 합동 작업한다. 코디네이터는 대부분의 인커밍 메시지를 특정 태스크 인스턴스와 결합시킬 필요가 있다.

WS-Addressing은 간단하지만 강력한 메커니즘을 제공한다. 정보는 서비스의 URL 내에서 인코딩 될 수 있는 반면 엔드포인트 레퍼런스는 표준 XML 엘리먼트를 제공하여 세밀한 어드레스를 인코딩하는 구조적인 접근방식을 가능하게 한다.

메시지 소스와 목적지의 전송 중립적인 인코딩으로 커플링된 어드레싱을 통한 제어의 결합은 웹 서비스 메시지가 다양한 범위의 전송방법을 통해 송수신 될 수 있도록 한다. 또한 비동기식 및 확장된 기간의 통신 패턴도 가능하다.

WS-Addressing은 전송자가 전송 독립적인 방법으로 응답이 어디로 가야할지를 지시할 수 있도록 한다. 메시지에 대한 응답이 반드시 전송자에게 가야하는 것은 아니다. HTTP에서 WS-Addressing 없이 응답이 어디로 갈지 지정하는 것은 불가능하다.

디스크립션(Description)
전 송과 메시지 스팩은 웹 서비스가 메시지를 사용하여 통신할 수 있도록 한다. 하지만 참여자가 어떤 메시지가 있는지를 어떻게 알 수 있는가? 어떻게 웹 서비스가 메시지를 문서화를 하는지 또는 송수신 되는 메시지를 기술하는가? 웹 서비스를 사용할 때 웹 서비스가 소비하고 생산 할 메시지를 이해하는 것이 필요하다. 스팩의 디스크립션(description) 그룹은 웹 서비스가 인터페이스와 기능을 표현할 수 있도록 한다.

메시지 상호운용성에 더하여 이러한 스팩들은 개발 툴의 상호운용성도 가능하게 한다. 디스크립션 스팩은 표준 모델을 제공하여 다양한 벤더의 다양한 툴이 개발자를 지원한다. 웹 서비스가 파트너를 구현과 인프라 선택권에서 고립된 것과 같은 이치로 디스크립션 스팩은 파트너를 개발 툴과 분리한다.

3.3.1 WSDL

Web Services Description Language (WSDL)와 XML Schema (XSD)는 이 그룹의 기본적인 스팩이다. XML Schema를 이용하여 개발자와 서비스 제공자들은 데이터 구조의 XML 유형을 정의할 수 있다. WSDL을 이용하여 웹 서비스는 이것이 송수신하는 메시지를 문서화한다.

WSDL은 메시지 인터랙션 패턴을 지원한다. 응답이 없는 일방(one-way) 인풋 메시지, 요청/응답, 응답없는 일방 전송을 지원한다. 마지막 두 개의 패턴은 필요할 경우 하나의 서비스가 다른 서비스를 지정할 수 있도록 한다.

보다 향상된 WSDL은 문서화 프로토콜과 서비스가 지원하는 메시지 포맷, 서비스의 어드레스를 지원한다.

3.3.2 WS-Policy

WSDL과 XSD 정의는 웹 서비스를 호출하는 충분한 정보를 제공하지 않는다. WSDL과 XSD는 서비스의 인터페이스 신택스는 정의하지만 서비스가 인터페이스를 어떻게 전달하는지 또는 서비스가 콜러에게 기대하는 것이 무엇인지에 대한 정보는 나타내지 않는다.

WS-Policy는 서비스가 콜러에게 무엇을 기대하는지와 인터페이스를 어떻게 구현할 것인가를 지정할 수 있게 한다. WS-Policy는 고급 서비스 작동의 상호운용성에 있어 매우 중요하다. 보안, 트랜잭션, 신뢰성있는 메시징, 기타 스팩들은 구체적인 WS-Policy 스키마를 필요로 한다. 콜러가 무엇을 기대하는지와 콜러에게 어떤 것을 제공할 것인지에 대한 기능적 확인을 기술할 수 있기 때문이다.

WS-Policy 프레임웍은 정책 표현을 위한 기본 모델을 제공한다.

WS-Policy 는 정책 문장을 모으는 문법을 지원하고 보다 유연하고 완전한 정책 구현을 가능하게 한다.

WS-PolicyAttachment는 정책 세트가 XML 메시지와 WSDL 엘리먼트와 결합하는 방법을 정의한다.

WS-Policy와 WS-PolicyAttachment는 프레임웍을 제공한다. 개별 스팩들은 도메인 스팩의 정책 문장과 스키마를 정의한다.

마지막으로 WS-PolicyAssertions는 상호운용성을 위해 사용될 수 있는 일반적인 정책 문장을 제공한다.

3.3.3 디스크립션 얻기

XML, XSD, WSDL, WS-Policy는 서비스 인터페이스와 서비스 보증의 디스크립션을 지원한다. 하지만 중요한 사용자가 이 정보를 어떻게 찾아내는가가 문제이다.

현재 가장 일반적인 접근방법은 이메일이나 구두로 전해지는 것이다. 보다 일반적이고 확장가능한 모델이 필요하다. 두 가지 옵션이 있다. 서비스가 직접 서비스로 가서 WS-MetadataExchange를 사용하여 정보를 얻거나 UDDI 서비스를 사용하는 것이다.

개발자들은 서비스에 대한 레퍼런스가 있고 이것이 어떤 일을 하는지 알고자 할 때 WS-MetadataExchange를 사용한다. 특정 기능을 지원하는 서비스의 레퍼런스를 찾고 싶을 때에는 UDDI를 사용한다.

3.3.4 WS-MetadataExchange

앞서 설명했듯이 서비스는 WSDL, WS-Policy, XSD 같이 서비스 자체를 설명하는 정보를 제공한다. 결국 지금까지 서비스에 대한 정보를 메타데이터로 언급햇다. WS-MetadataExchange 스팩은 웹 서비스 인터페이스를 통해 다른 서비스에게 메타데이터를 제공한다. 웹 서비스에 대한 하나의 레퍼런스가 있다면 잠재적 사용자는 WSDL/SOAP 작동 세트에 액세스하여 이 서비스를 설명하는 메타데이터를 검색할 수 있다. 클라이언트는 WS-MetadataExchange를 디자인 할 때 사용할 수 있다. 또는 런타임이나 클라이언트를 구현할 때도 사용 가능하다.

3.3.5 UDDI

서비스 콜렉션에 대한 메타데이터를 모으고 검색가능한 형태로 정보를 사용할 수 있도록 하는 것이 유용할 때가 있다. 이와 같은 메타데이터 집합 서비스는 유용한 저장소가 된다. Universal Description and Discovery Interface (UDDI) 스팩은 메타데이터 집합 서비스를 정의한다.

솔루션은 설계 시점에서 UDDI를 쿼리하여 요구사항에 호환되는 서비스를 찾을 수 있다. 개발자들은 이 서비스를 BPEL4WS 워크 플로우 정의에 사용할 수 있다.

메타데이터를 가진 UDDI 서비스를 파퓰레이팅하는데 사용되는 방법 중 하나는 WS-MetadataExchange를 사용하는 서비스에서 메타데이터를 얻는 것이다.

서비스 보증
웹 서비스는 분산 시스템 간 다리 역할을 하는 것 때문에도 많은 광신도를 탄생시켰다. 개발자들은 전송, 메시징, 디스크립션의 기본 기능을 사용하여 완벽한 기능적 솔루션을 만들었다. 하지만 보다 강력한 통합 솔루션을 만드는 개발자들에 의해 채택되려면 웹 서비스는 전통적인 미들웨어 솔루션이 제공하는 것과 같은 급의 서비스 보증 기능을 제공해야 한다. 메시지를 단순히 교환하는 것만으로는 충분하지 않다. 애플리케이션과 서비스는 미들웨어와 시스템에 존재하고 보안, 신뢰성, 트랜잭션 같은 고급 기능을 제공한다. 웹 서비스는 이러한 기능들 간 상호운용성 메커니즘을 제공해야 한다.

보안
스팩군은 조직간 웹 서비스에 중요하다. 이러한 스팩들은 인증과 메시지 무결성, 기밀성, 신뢰, 프라이버시 등을 지원한다. 또한 다른 조직 간 보안 구성을 지원하기도 한다.

3.5.1 WS-Security

WS-Security는 안전한 웹 서비스를 위한 기본적인 구현 블록이다. 오늘날 대부분의 분산 웹 서비스는 보안 기능을 전송 레벨에서 지원한다. HTTP/S와 BASIC-Auth가 그 예이다. 이러한 접근방식은 보안 통신에 필요한 최소한의 것만을 제공한다. 그들이 제공하는 기능 레벨은 기존의 미들웨어와 분산 환경에서 제공하는 것에 훨씬 미치지 못한다.

BASIC-Auth와 HTTP/S의 부족현상을 두 가지 예제를 통해 설명하겠다.

• A가 B 서비스에게 메시지를 보낸다. B는 메시지를 부분적으로 처리하고 이를 C 서비스에 전달한다. HTTP/S는 A-B와 B-C간 인증, 기밀성, 무결성을 적용한다. 하지만 C와 A는 서로를 인증할 수 없다. 또는 B에게서 오는 정보를 숨길 수 없다.
• A, B, C가 BASIC-Auth를 인증을 위해 사용하려면 같은 중복된 사용자 정보와 패스워드 정보를 공유해야 한다. 납득될 수 없는 일이다.

WS-Security는 다음을 지원한다:

• 서명되고 암호화된 보안 토큰을 지원한다. A는 보안 토큰을 만든다. B는 토큰을 조작할 수 없다.
• A는 선택된 엘리먼트 또는 전체 메시지에 서명할 수 있다. 이것으로 B와 C는 그 메시지가 A로부터 전송될 때와 다르지 않음을 확인한다.
• A는 메시지 또는 선택된 엘리먼트를 봉인할 수 있다.

WS-Security는 기존의 보안 모델(Kerberos, X509 등)을 사용한다. 이 스팩은 기존 모델을 상호운용의 방식으로 사용하는 방법을 구체적으로 정의하고 있다. 멀티홉, 멀티 파티 웹 서비스 전산은 WS-Security 없이는 보안을 이룰 수 없다.

3.5.2 WS-Trust

보안은 사전 정의된 신뢰 관례에 의존한다. Kerberos는 참여자들이 Kerberos Key Distribution Center를 신뢰하기 때문에 작동한다. PKI는 참여자들이 root 인증 권한을 신뢰하기 때문에 작동한다. WS-Trust는 확장가능한 모델을 정의하여 신뢰 관계를 설정 및 확인한다.

WS-Trust의 핵심 개념은 Security Token Service (STS)이다. STS는 보안 토큰을 발행하고 교환하며 확인하는 구별된 웹 서비스이다. WS-Trust는 웹 서비스가 신뢰하는 서버를 설정할 수 있도록 한다.

STS는 적용 가능성이 풍부하다. 광범위한 표명을 하는 보안 토큰을 만드는데 사용될 수 있기 때문이다. 많은 경우 다른 포맷으로 같은 표명을 만드는데 사용될 것이다.

3.5.3 WS-SecureConversation

어떤 웹 서비스 시나리오에는 몇몇 서비스의 산발적 교환만을 포함하고 있다. WS-Security는 당연히 이 모델을 지원한다. 다른 시나리오에는 장기간, 멀티 메시지 통신이 포함되어 있다. WS-Security는 이 모델 역시 지원한다. 하지만 솔루션은 이상적이지 않다.

이 시나리오에서 사용할 수 있는 WS-Security 사용법은 다음과 같다:

• 퍼블릭 키 확인 같은 값비싼 암호화 작동의 반복 사용.
• 같은 암호 키를 사용하는 많은 메시지를 송수신하면서 코드 깨짐을 유발하는 정보를 제공하기.

이 같은 이유로 HTTP/S 같은 프로토콜은 퍼블릭 키를 사용하여 대화 스팩의 키를 정의하는 것으로 타협한다. 이러한 키 교환은 보다 효율적인 보안 구현을 가능하게 하고 특정 키 세트로 암호화되는 정보의 양을 줄인다.

WS-SecureConversation은 WS-Security와 비슷하다. 참여자들은 WS-Security를 퍼블릭 키와 같이 사용하여 "대화" 또는 "세션"을 시작하고 WS-SecureConversation을 사용하여 정보의 서명과 암호화를 위한 세션 스팩의 키에 동의한다.

3.5.4 WS-Federation

WS-Federation으로 하나의 가상 보안 도메인을 만들 수 있다. WS-Federation은 WS-Trust와 WS-SecureConversation 위상 간 프로토콜을 통해 연합된 보안성을 제공하는 여러 모델을 정의한다.

게다가 고객은 기업을 다룰 때 프로퍼티를 가지고 있다. WS-Federation은 멤버들이 연합된 속성 공간을 설정할 수 있도록 한다. 이로서 참여자는 엔드유저에 대한 속성 정보에 보안 접근을 할 수 있다.

개인에 대한 속성과 정보는 프라이버시 보호와 밀접하게 연결되어 있다. 이러한 요구사항을 지원하기 위해 WS-Federation은 익명 모델을 지원한다. 이로서 엔드유저의 프라이버시와 경쟁 업체의 악용으로 부터 보호할 수 있다.

Reliable Messaging
인터넷에서 거의 모든 통신 채널들은 믿을 수 없다(unreliable). 메시지는 사라지고 연결이 끊긴다.

Reliable Messaging 표준이 없다면 웹 서비스 애플리케이션 개발자들은 이 같은 기능을 그들의 애플리케이션에 구현해야 한다. 많은 OS와 미들웨어 시스템들이 고유 식별자를 가진 메시지를 확인하고 시퀀스 넘버를 부여하고 메시지가 손실 될 경우 재전송을 하는 것이 좋은 예이다.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging은 웹 서비스가 믿을 수 없는 통신 네트워크를 통해 전달되는 메시지를 확인할 수 있도록 한다.

WS-ReliableMessaging으로 인해, 프로토콜을 구현하는 서비스를 제공하여 애플리케이션 개발을 쉽게 하고 상호운용 가능한 접근 방식으로 구현할 수 있다. 애플리케이션 개발을 획기적으로 단순화시킨다. 비지니스 로직은 에러 조건도 줄어든다.

산업계는 메시지들을 라우팅 및 분산 할 메시지 지향 미들웨어 세트가 풍부하다. 각각의 구현은 상용 프로토콜을 사용한다. WS-Reliable Messaging 프로토콜을 사용하여 다양한 OS 및 미들웨어 시스템에서 메시지를 안전하게 교환할 수 있다.

트랜잭션
복 잡한 비지니스 시나리오 같은 경우 많은 참여자들이 다중의 메시지 세트를 교환해야 한다. 보험 정책, 연급, 수표 계좌, 증권 계좌를 포함하는 금융 오퍼링을 만드는 금융 기관을 예로 들 수 있다. 참여자들간 교환되는 다중 메시지들은 논리적 "태스크" 또는 "객체(objective)"를 형성한다.

성공을 위해서 당사자들은 다음을 수행 할 수 있어야 한다:

1. 새로운 협업 태스크 시작.
2. 작동과 논리적 태스크 연합. 당사자들은 동시에 다른 고객의 어카운트를 설정할 수 있다.
3. 전산 결과에 대한 동의.

WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity는 이러한 요구사항들을 지원한다.

3.7.1 WS-Coordination

WS-Coordination은 다자(multiparty), 다중 메시지 웹 서비스 태스크를 시작하고 결과에 동의하는 일반적인 메커니즘이다. WS-Coordination은 세 개의 핵심 요소가 있다:

1. 전산 중에 웹 서비스가 교환하는 모든 메시지에 흐르는 코디네이션(coordination) 콘텍스트를 메시지 엘리먼트라고 한다. 코디네이션 콘텍스트에는 코디네이션 서비스에 대한 WS-Addressing 엔드포인트 레퍼런스가 포함되어 있고 조정되고 있는 특정 태스크를 구별하는 정보를 포함하고 있다.
2. 코디네이터 서비스. 코디네이터 서비스는 WSDL을 사용하여 설명되는 서비스를 제공한다. 이 서비스는 코디네이션 태스크를 시작하고 끝낼 수 있는 기능을 제공하고 참여자가 태스크에 등록하고 그룹 내 모든 메시지들의 일부인 코디네이션 콘텍스트를 만들 수 있도록 한다.
3. 코디네이션 서비스에는 WSDL로 정의된 인터페이스가 포함되어 있다.

새로운 코디네이션 콘텍스트를 가진 메시지를 받는 웹 서비스는 콘텍스트에 이 코디네이터 서비스로 등록된다. 결과 정보를 받기 위해서이다. 다른 스팩들은 도메인과 보증 관련 요구사항을 위한 프레임웍을 증가할 수 있다.

WS-Coordination은 일반적인 프에임웍이며 기능이다. WS-AtomicTransaction과 WS-BusinessActivity는 이 프레임웍을 확장하여 분산 환경의 참여자들이 결과를 결정할 수 있도록 했다.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction은 WS-Coordination 모델로 플러그인되어 전통적인 2 단계(two-phase) 자동 트랜잭션 프로토콜을 구현하는 프로토콜 세트를 정의한다. 자동의 2 단계 모델은 관련된 서비스에만 해당된다는 점에서 중요하다.

3.7.3 WS-BusinessActivity

WS-BusinessActivity는 오랫동안 실행되는 전산 기반의 트랜잭션 프로토콜을 구현하는 WS-Coordination 모델로 플러그인되는 프로토콜 세트를 정의한다. BPEL4WS가 비지니스 프로세스용 트랜잭션 모델을 정의하는 반면 WS-BusinessActivity는 상응하는 프로토콜의 렌더링을 정의한다.

서비스 조합
웹 서비스 레이어의 최상에 위치한 엘리먼트는 서비스 조합(services composition)이다. 개발자들은 SOAP 메시지를 교환하는 서비스들을 "조합"하고 WSDL과 WS-Policy로 인터페이스를 정의한다. 집합(aggregate)은 조합된 웹 서비스이다.

3.8.1 BPEL4WS

Business Process Execution Language for Web Services (BPEL4WS) 스팩은 서비스 조합을 지원한다. 개발자들은 공유된 비지니스 솔루션을 합동으로 구현하는 웹 서비스의 구조와 작동을 정의할 수 있다. 서비스의 엘리먼트 세트는 WSDL과 WS-Policy를 사용하여 인터페이스를 정의한다.

조합은 세 가지 측면(구조, 정보, 작동)이 있다. BPEL4WS는 각각의 조합을 지원하는 세 개의 구조체를 적용한다.

partnerLink 는 조합 서비스와 전체 솔루션에 참여하는 웹 서비스 사이의 조합을 정의한다. 조합 서비스와 참여 서비스는 WSDL과 WS-Policy를 사용하여 인터페이스를 정의한다. 제조 회사와 공급자 간 연합이 한 예이다.

partnerLink 개념과 WSDL/WS-Policy 인터페이스는 서비스 조합의 구조를 정의한다. 이들은 조합을 구성하기 위해 협업하는 서비스 유형을 정의한다. 그들이 교환하는 메시지가 어떤 보안 레벨에 있는지도 정의한다.

BPEL4WS는 서비스 조합의 정보 정의를 지원한다. BPEL4WS는 컨테이너의 개념을 정의한다. 조합 서비스는 컨테이너 세트를 정의한다. 특정 서비스의 현재 상태는 컨테이너의 상태이다. 이것은 어떤 메시지가 송수신 되는지를 정의한다.

BPEL4WS는 작동 개념에 의해 조합 서비스의 작동을 정의한다. 서비스가 정의된 BPEL4WS는 액티비티 세트 또는 스텝(step)이다. 이는 서비스의 작동을 정의한다. 가장 기본적인 액티비티는 메시지를 파트너에게 보내는 것 또는 파트너로부터 메시지를 받는 것이다. 각각의 메시지는 컨테이너에 상응한다. BPEL4WS는 컨테이너간 데이터 이동을 지원한다.

BPEL4WS 액티비티의 중요한 점중 하나는 BPEL4WS가 외부에 보여지는(퍼블릭) 작동 정의를 특별히 지원한다는 점이다.

BPEL4WS는 또한 액티비티 실행 흐름을 제어하는데 다양한 접근방식을 지원한다. 여기에는 시퀀싱과 그래프 기반 플로우가 포함되어 있다. BPEL4WS는 어떤 제어 경로를 조합 서비스가 따를지에 대해 예견할 수 있도록 한다.

요약하면 다음과 같다.

1. BPEL4WS는 WSDL과 WS-Policy 지원을 서비스 디스크립션까지 확장했다. BPEL4WS는 웹 서비스를 집합 서비스에 결합하는 것을 지원하고 서비스들간 연합의 문서화도 지원한다. 웹 서비스의 협업 디자인을 지원하는 고급 툴 사이의 상호운용성도 가능하다.
2. BPEL4WS는 실행 언어이다. BPEL4WS는 개발자가 조합된 웹 서비스의 작동을 완벽히 정의할 수 있도록 한다. IBM, Microsoft 등은 BPEL4WS 문서들을 실행하고 디자인과 실행 시간 바인딩을 지원하는 환경을 제공하게 될 것이다.

웹 서비스 - 예제
다음 시나리오는 실제로 발생하는 문제들을 풀어가는 웹 서비스를 만들 때 WS 스팩이 어떻게 사용되는 지를 보여 줄 것이다.

이 시나리오의 웹 서비스는 IBM-Microsoft의 협업으로 만들어졌다. (2003년 9월 17일). 상호운용성, 보안, 신뢰성, 트랜잭션을 갖춘 웹 서비스를 만들었다.

이 시나리오는 가장 일반적인 문제를 다룰 것이다. 다양한 WS 스팩이 어떻게 조합되어 비지니스 프로세스를 자동화하는지 보게 될 것이다:

1. 보안 인증 (WS-Security)
2. 다양한 조직 간 신뢰 연합 (WS-Trust & WS-Federation)
3. 트랜잭션 완료를 위한 데이터 교환 (WS-AtomicTransaction)
4. Reliable Messaging을 통해 제출된 주문 확인 (WS-ReliableMessaging)

Part 1: 고객
예 제는 Auto Dealer의 사원인 Heather가 판매 웹 사이트에 로그인하는 것으로 시작된다. 이 웹 사이트는 표준 웹 기술을 사용하여 구현된다. Heather는 그녀의 브라우저를 통해 사이트에 들어간다. 사이트로 액세스는 패스워드로 보호된다.

그림 4. Heather가 웹 사이트에 로그인하여 자신의 My Page를 검색한다.

Heather는 My Page에 클릭한다. 후면에서는 애플리케이션이 Auto Dealer의 재고 데이터베이스에서 정보를 모으고있다. 아이템에 대한 재고 레벨이 정의된 임계값에 미치지 못하면 리포트가 만들어지고 Heather의 페이지에 "Your Alerts"라고 리스트 된다.

WindshieldPro 와이퍼 블레이드 재고 부족을 확인한다.

링크를 클릭하고 Auto Manufacturer 익스트라넷상의 보안 웹 페이지로 리다이렉트 된다. 이곳에서 주문을 할 수 있다. Auto Dealer 소프트웨어는 웹 서비스 기반이기 때문에 실행은 완벽하다. Auto Dealer의 인트라넷과 Auto Manufacturer 익스트라넷을 연결하는 웹 서비스는 WS-Federation을 사용하여 조합되었다. WS-Federation은 보안 기밀을 확인한다.

Auto Dealer와 Auto Manufacturer는 그들의 사이트를 연합하는데 동의했다. WS-Federation은 서비스 대 서비스 통신을 조정한다. Heather가 WindshieldPro 링크를 클릭하자마자 Auto Manufacturer의 웹 서비스에 가게된다. Auto Dealer 권한 서비스는 Heather가 권한을 부여받은 사용자라는 것을 확인하고 Credential을 전송하고 Heather의 딜러쉽 이름을 가지고 Auto Manufacturer의 권한 서비스로 가서 Heather의 접근을 허용한다. 이 모든 과정이 완벽하게 처리된다.

이 웹 서비스는 Auto Manufacturer 고객 데이터베이스를 쿼리하고 Heather의 어카운트에 링크된 주문 정보를 찾는다. 이 정보는 커스터마이징 된 "My Page" Auto Manufacturer 웹 페이지에 있다.

그림 5: WS-Federated를 사용한 웹 서비스 조합으로 개인 페이지와 Auto Manufacturer간 이동이 허용된다.

Auto Manufacturer 익스트라넷 상에 히더가 커스터마이징한 웹 페이지에서 뚜렷한 주문 내역이 없음을 확인한다. 현재 전송중인 한 개의 주문이 있다. (50 SuperTires).

Heather는 "Create New Order"를 클릭하여 새 페이지를 열고 WindshieldPro 와이퍼 블레이드와 주문 날짜를 선택한다. 주문 완료에 필요한 다른 모든 정보는 Auto Manufacturer 데이터베이스에서 파퓰레이트 된다.

그림 6. Auto Manufacturer 고객 데이터베이스

주문서를 제출하고 구입할 추가 아이템이 없는지 찾고 로그아웃을 클릭하여 세션을 끝낸다.

Part 2: 공급자
Tony는 공급자 측의 판매 담당자이고 공급자의 인트라넷에 로그인한다. 표준 웹 브라우저를 사용하는 대신 웹 서비스에 대한 빌트인 지원이 되는 Windows 애플리케이션으로 작업한다.

그림 7. Tony는 주문과 재고를 확인한다.

주문과 재고를 클릭하면 그의 애플리케이션은 웹 서비스를 사용하여 Tony가 액세스 할 수 있는 재고 데이터를 찾는다.

이 레벨에서 WS-Federation으로 조합된 데이터를 요청한다. WS-Federation은 Auto Manufacturer의 익스트라넷으로의 액세스를 인증한다.

웹 서비스는 공급자 페이지에 결과를 리턴한다. 페이지에는 제품 유형과 현재 재고량이 나타나있다.

그림 8. WS-Security와 WS-Federation의 조합으로 요청 보안이 이루어진다.

공급자는 Auto Manufacturer와 just-in-time 구매 계약을 맺었다. 재고가 20 이하로 떨어지면 Tony는 Auto Manufacturer를 대표하여 Vendor Managed Inventory (VMI) 의 일부로서 주문을 자동으로 재공급한다. WindshieldPro를 클릭하여 주문을 한다. Tony와 Auto Manufacturer 사이의 모든 메시지들은 보호된다. 애플리케이션이 WS-Security로 조합된 웹 서비스의 지원을 받기 때문이다.

그림 9. Auto Manufacturer와의 just-in-time 계약으로 회사를 대표하여 주문을 낼 수 있다.

50개의 WindishieldPros를 주문하고 Auto Manufacturer로 직접 선적되도록 한다.

OK를 클릭하면, Warehouse Service(WS-AtomicTransactions, WS-Security, WS-ReliableMessaging으로 조합된 웹 서비스)는 또 다른 웹 서비스인 하청 Warehouse Services에 주문한다. Warehouse Service에서 즉각적 응답이 오지 않으면 응답을 받을 때 까지 WS-ReliableMessaging은 계속하여 쿼리를 보낸다.