안전하고 안정적이며 거래된 웹 서비스: 아키텍처 및 컴퍼지션

아티클
04/03/2007

2003년 9월

IBM Corporation

도널드 F. 퍼거슨
IBM 펠로우 및 회장
IBM 소프트웨어 그룹 아키텍처 보드

토니 스토리
IBM Fellow

Microsoft Corporation

브래드 애인
고유 엔지니어

John Shewchuk
웹 서비스 설계자

콘텐츠

1.0 소개
   1.1 구성 가능한 서비스
   1.2 실제로 컴퍼지션의 예
2.0 웹 서비스: Service-Oriented 아키텍처
   2.1 서비스는 스키마로 설명되고 계약은 형식이 아닙니다.
   2.2 서비스 호환성이 형식 호환성 이상입니다.
   2.3 서비스 방향은 나쁜 일이 일어날 수 있고 일어날 것이라고 가정합니다.
   2.4 서비스 지향을 사용하면 유연한 서비스 바인딩이 가능합니다.
3.0 웹 서비스 사양 및 함수
   3.1 웹 서비스에 대한 구성 가능한 접근 방식
   3.2 기본 사항 – 전송 및 메시징
      3.2.1 전송 – HTTP, HTTP/S, SMTP
      3.2.2 메시지 형식 – XSD
      3.2.3 WS-Addressing
   3.3 설명
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 설명 가져오기
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 Service Assurances
   3.5 보안
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 신뢰할 수 있는 메시징
      3.6.1 WS-ReliableMessaging
   3.7 트랜잭션
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 서비스 컴퍼지션
      3.8.1 BPEL4WS
4.0 실제로 웹 서비스 – 예제
   4.1부 1부: 고객 환경
   4.2부 2부: 공급업체 환경
5.0 결론
6.0 승인

1.0 소개

현재 WSDL(Web Services Description Language)을 사용하여 XML로 인코딩된 SOAP 메시지를 처리하고, HTTP를 통해 전송되고, 설명된 분산 서비스인 웹 서비스가 광범위하게 배포되고 있습니다. (XML, SOAP 및 HTTP라는 용어는 현재 일반적으로 사용되며 여러 면에서 사용이 원래 머리글자어를 넘어 이동했습니다. 완전성을 위해 이러한 약어는 XML—eXtensible Markup Language, SOAP-Simple Object Access Protocol 및 HTTP-HyperText Transfer Protocol에 나열됩니다. 웹 서비스는 단순, 임시, 방화벽 뒤, 데이터 공유, 대규모 인터넷 소매 및 통화 거래에 이르기까지 다양한 애플리케이션 통합 시나리오에서 사용됩니다. 그리고 모바일, 디바이스 및 그리드 시나리오에서 점점 더 많은 웹 서비스가 적용되고 있습니다.

웹 서비스는 서로 다른 회사 간에 통신할 수 있고 서로 다른 인프라에 상주할 수 있는 소프트웨어 구성 요소 간의 상호 운용성을 제공합니다. 이렇게 하면 고객, 소프트웨어 개발자 및 파트너가 직면한 가장 중요한 문제 중 하나가 해결됩니다. HTTP 및 SOAP는 통신 및 메시지 상호 운용성을 제공합니다. WSDL은 개발 도구 간의 상호 운용성을 지원하는 서비스에 대한 설명을 제공합니다. 인터페이스 정의를 교환하는 기능과 통신 상호 운용성을 보완합니다.

기본 웹 서비스 사양 집합을 사용하면 고객과 소프트웨어 공급업체가 중요한 문제를 해결할 수 있습니다. 성공을 바탕으로 많은 개발자와 회사는 웹 서비스 기술로 더 어려운 문제를 해결할 준비가 되어 있습니다. 웹 서비스의 성공으로 인해 개발자는 웹 서비스에서 더 많은 기능을 원하게 되었습니다. 의미 있는 도구 및 통신 상호 운용성이 성공했으므로 개발자는 이제 향상된 기능이 상호 운용되기를 기대합니다.

개발자는 기본 메시지 상호 운용성 및 인터페이스 교환 외에도 더 높은 수준의 애플리케이션 서비스가 상호 운용되어야 하는 경우가 점점 더 늘어나고 있습니다. 많은 상용 애플리케이션은 보안 및 트랜잭션과 같은 기능을 지원하는 환경("미들웨어" 또는 "운영 체제")에서 실행됩니다.

IBM, Microsoft 및 업계의 다른 사람들은 웹 서비스를 보다 안전하고 안정적이며 트랜잭션을 더 잘 지원할 수 있도록 해야 하는 경우가 많습니다. 또한 현재 웹 서비스에서 찾을 수 있는 필수 단순성과 상호 운용성을 유지하면서 이러한 기능을 제공하라는 요청을 받았습니다.

이 문서에서는 이러한 요구 사항을 해결하는 웹 서비스 사양 집합에 대한 간결한 개요를 제공합니다. 사양의 세부 정보를 위해 실제 문서에 대한 참조를 제공합니다. 이 문서의 기본 목적은 이러한 사양이 고객에게 제공하는 가치를 간략하게 정의하는 것입니다. 또한 이러한 사양이 서로 보완되어 분산 애플리케이션에 대한 강력한 환경을 구성하는 방법에 대해서도 설명합니다.

필요한 것보다 복잡성을 더하지 않고 웹 서비스에 새로운 보안, 안정성 및 트랜잭션 기능을 제공하려면 어떻게 해야 할까요?

1.1 구성 가능한 서비스

SOAP 및 WSDL에서 수행한 것처럼 IBM, Microsoft 및 파트너는 웹 서비스 사양 정의에서 작성 가능성의 디자인 원칙을 따랐습니다. 우리가 따라온 접근 방식은 웹 서비스 사양 정의에서 작성 가능성 의 디자인 원칙을 기반으로 합니다. 우리가 개발한 각 사양은 즉각적인 필요를 해결하고 그 자체로 가치가 있습니다. 예를 들어 개발자는 신뢰할 수 있는 메시징을 채택하여 솔루션 개발을 간소화하거나 BPEL4WS를 채택하여 서비스 컴퍼지션을 정의할 수 있습니다. 그리고 각 사양은 자체적으로 서 있지만, 결합하고 서로 작동하도록 설계되었습니다.

더 강력한 기능을 제공하기 위해 결합할 수 있는 독립적인 사양을 설명하기 위해 구성성 이라는 용어를 사용합니다. 운영 체제 및 미들웨어 공급자는 구성된 기능을 지원할 수 있습니다. 예를 들어 공급자는 BPEL4WS 프로세스 통신을 위한 신뢰할 수 있는 메시징 지원을 통합할 수 있습니다. 이 예제에서는 두 가지 독립적인 사양을 결합하여 프로세스 디자인 중에 메시지 통신 오류를 처리할 필요가 없도록 하여 통신 프로세스의 개발을 간소화합니다.

작성성을 사용하면 새로운 개념, 도구 및 서비스를 점진적으로 사용 하거나 점진적으로 검색 할 수 있습니다. 개발자는 필요한 것을 배우고 구현하기만 하면 되며 더 이상 필요하지 않습니다. 솔루션의 복잡성은 문제의 요구 사항이 증가하고 기술 "bloat"로 인한 것이 아니기 때문에 증가합니다.

구성성은 웹 서비스의 주요 디자인 목표 중 하나이며 계속 되고 있습니다. 지난 몇 년 동안 기본적으로 컴퍼지션을 지원하기 위해 가장 기본적인 웹 서비스 사양(SOAP 및 WSDL)을 정의했습니다. 웹 서비스의 기본 특성 중 하나는 일반 다중 파트 메시지 구조입니다. 이 구조를 사용하면 새 기능을 구성할 수 있습니다. 기존 기능의 처리를 변경하지 않는 방식으로 새 서비스를 지원하는 새 메시지 요소를 메시지에 추가할 수 있습니다. 예를 들어 트랜잭션 식별자와 신뢰할 수 있는 메시징 시퀀스 번호를 독립적으로 추가할 수 있습니다. 두 확장은 서로 충돌하지 않으며 기존 메시지 구조와 호환됩니다.

그림 1. 구성성을 사용하면 필요에 따라 요소를 사용할 수 있습니다.

그림 1에서는 WS-Addressing, WS-Security 및 WS-ReliableMessaging에 대한 요소가 포함된 간단한 웹 서비스 메시지를 보여 줍니다. WS-Addressing, WS-Security 및 WS-ReliableMessaging 요소는 독립적이며 다른 요소의 처리를 변경하지 않고도 이러한 요소를 독립적으로 사용할 수 있습니다.

이 특성을 사용하면 구성 가능한 메시지 요소 측면에서 보안, 안정성 및 트랜잭션을 정의할 수 있습니다 .

컴퍼지션 개념을 사용하면 보안, 안정성 등을 지원하는 잘 정의된 구성 가능한 특정 웹 서비스 집합을 만들 수도 있습니다. 이러한 잘 정의된 서비스는 상위 수준 웹 서비스 기능을 지원하는 데 필요한 서비스의 동작을 지정합니다. 예를 들어 메시지의 보안 요소를 발급하고 유효성을 검사하는 WS-Trust 에 정의된 보안 토큰 서비스가 있습니다.

또한 서비스 소비자가 지원되는 필수 서비스 보증을 확인할 수 있어야 합니다. 서비스는 트랜잭션, 보안, 신뢰할 수 있는 메시징 등에 대한 요구 사항 및 지원을 문서화해야 합니다. WS-Policy 사용하면 웹 서비스가 WSDL을 증분 방식으로 보강하여 지원하거나 필요로 하는 트랜잭션, 보안 및 안정성 기능을 문서화할 수 있습니다. WSDL 및 WS-Policy 는 서비스 설명에 대한 컴퍼지션을 사용하도록 설정합니다. 이렇게 하면 다른 당사자가 서비스와 상호 작용할 때 사용할 메시지 요소 및 상위 수준 서비스를 이해할 수 있습니다.

1.2 실제로 컴퍼지션의 예

그림 2에서는 실제로 컴퍼지션을 보여 주는 개요를 제공합니다. 고객과 공급업체는 웹 서비스를 사용하여 주문을 처리합니다.

그림 2. 주문 처리 시스템의 컴퍼지션

이러한 웹 서비스를 빌드할 때 개발자는 WSDL 및 관련 문서를 사용하여 비즈니스 인터페이스를 설명합니다. 이러한 WSDL 문서에서는 고객 및 공급업체 웹 서비스에서 처리할 메시지 집합(예: 고객에서 공급자로 이동하는 SubmitPurchaseOrder(SubmitPurchaseOrder) 메시지)을 설명합니다. 그림 2의 맨 위에 표시됩니다. 애플리케이션의 핵심 부분이 준비되면 개발자는 추가 기능을 지원하기로 결정할 수 있습니다. 예를 들어 여기서는 주문 처리가 트랜잭션되도록 결정할 수 있습니다. 이렇게 하려면 다음 요소를 기존 구조체로 구성 합니다.

서비스는 트랜잭션에 대한 지원을 설명하는 WS-Policy 문서를 해당 서비스에 대한 WSDL 설명과 연결합니다. 이러한 정책 설명은 기존 비즈니스 기능을 보강하지만 근본적으로 변경하지는 않습니다.
트랜잭션 처리를 지원하기 위해 서비스는 기존 애플리케이션 메시지로 구성되지만 근본적으로 변경되지는 않는 트랜잭션을 설명하는 추가 메시지 요소를 추가합니다.
공급자 서비스에서 트랜잭션 요소가 포함된 메시지를 받으면 이 정보를 사용하여 트랜잭션 함수를 지원하는 코디네이터라는 지정된 웹 서비스와 통신합니다. 다시 말하지만, 이 추가 웹 서비스는 솔루션에 추가될 뿐이며 기존 비즈니스 기능에 대한 설명을 수정할 필요가 없습니다.
마지막으로, 서비스는 트랜잭션 코디네이터 서비스와의 통합을 지원하기 위해 추가 작업을 구현할 수 있습니다.

앞의 그림에서 이러한 추가 요소가 강조 표시됩니다.

모델은 다음과 같은 이유로 증분되고 구성 가능합니다.

새 함수를 추가하는 작업은 다른 함수를 추가하는 작업과 별도로 수행할 수 있습니다.
함수를 추가해도 기존 메시지, 메시지 처리 논리 또는 WSDL이 중단되지 않습니다.

구성성은 점점 더 중요한 디자인 원칙이지만 접근 방식이 항상 잘 이해되는 것은 아닙니다. 개별 웹 서비스 사양은 개별 요소와 서비스가 상호 운용되는 방식을 정의하지만, 이 백서는 보다 정교한 상호 운용 가능한 웹 서비스를 제공하기 위해 사양 컬렉션을 구성하는 방법에 대한 개요를 제공하기 위한 것입니다.

2.0 웹 서비스: Service-Oriented 아키텍처

최근 몇 년 동안 웹 서비스 개발을 중심으로 한 활동이 급증했습니다. 이 모든 활동을 통해 뒤로 물러서서 "왜?"라는 질문을 하는 것이 중요합니다. 물론 웹 서비스는 모든 웹 서비스가 기존 컴퓨터에서 계속 실행되고 동일한 명령 집합을 실행하고 동일한 데이터에 액세스한 후에도 새로운 종류의 계산 기능을 사용할 수 없습니다. 또한 대부분의 경우 웹 서비스 프로토콜은 실제로 지정된 작업에 대한 프로토콜 오버헤드를 증가시킬 수 있습니다.

웹 서비스에 관심이 있는 주요 이유 중 하나는 웹 서비스가 SOA(Service-Oriented 아키텍처)를 사용하도록 설정하는 데 적합하기 때문입니다. 웹 서비스를 사용하여 SOA를 빌드하는 경우 솔루션은 URL로 식별되는 자율 서비스 컬렉션과 WSDL을 사용하여 문서화된 인터페이스 및 잘 정의된 XML 메시지 처리로 구성됩니다. SOA는 솔루션 구현에 대한 OO(개체 지향), 절차 및 데이터 중심 접근 방식을 자연스럽게 보완합니다. 실제로 SOA 시스템을 만들 때 개별 서비스는 일반적으로 이러한 기술 중 하나 이상을 사용하여 구성됩니다.

Service-Oriented 아키텍처는 바인딩이라는 한 가지 주요 측면에서 OO 및 절차 시스템과 다릅니다 . 서비스는 제공하는 함수와 제공하는 방법에 따라 상호 작용합니다. OO 및 절차 시스템은 형식 또는 이름에 따라 요소를 함께 연결합니다. 다음 섹션에서는 자세한 내용을 제공합니다.

2.1 서비스는 스키마로 설명되고 계약은 형식이 아닙니다.

이전 시스템과 달리 웹 서비스 모델은 공통 구현이 필요한 공유 형식의 개념에서 작동하지 않습니다. 대신 서비스는 계약(메시지 처리 동작의 경우 WSDL/BPEL4WS) 및 스키마(메시지 구조의 경우 WSDL/XSD)를 기반으로 상호 작용합니다. 이를 통해 서비스는 이러한 메시지에 대한 제약 조건을 보내고 받거나 시퀀싱할 수 있는 메시지의 구조를 설명할 수 있습니다. 구조와 동작 간의 분리와 이러한 특성에 대한 명시적이고 머신에서 확인할 수 있는 설명은 다른 유형의 환경에서의 통합을 간소화합니다.

또한 이 정보는 애플리케이션 통합에서 메시지 구조 또는 동작을 만드는 데 공유 실행 환경이 필요하지 않도록 서비스 인터페이스의 특징을 충분히 지정합니다.

서비스 지향 모델은 스키마 및/또는 계약의 변경 내용을 서비스가 발생한 모든 당사자에게 전파하기 어려운 완전히 분산된 환경을 가정합니다. 서비스 방향은 계약 및 스키마가 이전 버전과 호환되며 특정 처리 시스템에서 불완전하게 이해되는 정보를 포함할 수 있음을 의미합니다.

이러한 이유로 서비스 지향 디자인에 사용하도록 설계된 계약 및 스키마 기술은 기존 개체 지향 인터페이스보다 더 유연하게 사용할 수 있습니다. 특히 서비스는 XML 요소 와일드카드(예: xsd:any), 스키마 확장 및 선택적 SOAP 헤더 블록과 같은 기능을 사용하여 배포된 애플리케이션을 중단하지 않는 방식으로 서비스를 발전합니다. 이러한 특성은 웹 서비스 구성의 핵심입니다.

2.2 서비스 호환성이 형식 호환성 이상입니다.

절차 및 개체 지향 디자인은 일반적으로 형식 호환성과 의미 체계 호환성을 동일합니다. 서비스 방향은 호환성을 결정하기 위한 보다 풍부한 모델을 제공합니다. 구조적 호환성은 계약(WSDL 및 선택적으로 BPEL4WS) 및 스키마(XSD)를 기반으로 하며 유효성을 검사할 수 있습니다. 또한 WS-Policy 도입되어 서비스 간 서비스 보증 호환성에 대한 추가 자동화된 분석을 제공합니다. 이 작업은 WS-Policy 문의 형태로 기능 및 요구 사항의 명시적 어설션을 기반으로 수행됩니다.

WS-Policy를 사용하여 서비스는 어설션 조합을 포함하는 컴퓨터에서 읽을 수 있는 정책 식의 형태로 서비스 보증 기능 및 요구 사항을 설명합니다. 이를 통해 서비스는 계약을 제공하는 "방법" 또는 "품질"에 따라 서로를 선택할 수 있습니다.

정책 어설션은 어설션이 적용되는 서비스에 관계없이 시간과 공간에서 의미가 일관된 안정적이고 전역적으로 고유한 이름으로 식별됩니다. 또한 정책 어설션에는 어설션의 정확한 해석을 한정하는 매개 변수가 있을 수 있습니다.

2.3 서비스 방향은 나쁜 일이 일어날 수 있고 일어날 것이라고 가정합니다.

분산 애플리케이션에 대한 일부 이전 접근 방식은 공통 형식 공간, 실행 모델 및 프로시저/개체 참조 모델을 명시적으로 가정했습니다. 기본적으로 "메모리 내" 프로그래밍 모델은 분산 시스템 모델을 정의했습니다.

서비스 지향은 단순히 서비스가 자율적으로 실행되고 로컬 실행 또는 일반적인 운영 환경에 대한 개념이 없다고 가정합니다. 이러한 이유로 SOA는 통신, 가용성 및 형식 오류가 일반적이라고 명시적으로 가정합니다.

시스템 무결성을 유지하기 위해 서비스 지향 디자인은 비동기 및 부분 오류 모드를 처리하기 위해 다양한 기술을 명시적으로 사용합니다. 비동기 메시징, 트랜잭션, 신뢰할 수 있는 메시징 및 중복 배포와 같은 기술은 서비스 지향 시스템의 표준입니다.

또한 메모리 내 모델과 달리 서비스 방향은 들어오는 메시지의 형식이 잘못되었을 수 있을 뿐만 아니라 악의적이거나 완전히 예기치 않은 목적으로 전송되었을 수도 있다고 가정합니다. 따라서 서비스 지향 시스템은 애플리케이션이 보낸 사람에게 필요한 권한이 부여되었음을 증명하도록 요구함으로써 모든 메시지 보낸 사람에게 증명의 부담을 갖도록 하여 자신을 보호합니다. 서비스 자율성의 개념과 일치하는 서비스 지향 아키텍처는 일반적으로 관리되는 신뢰 관계를 사용하여 클래식 웹 애플리케이션에서 일반적인 서비스별 인증 메커니즘을 방지합니다.

2.4 서비스 지향을 사용하면 유연한 서비스 바인딩이 가능합니다.

SOA( 서비스 지향 아키텍처 )의 핵심 개념 중 하나는 유연한 서비스 바인딩입니다. 보다 전통적인 절차, 구성 요소 및 개체 모델은 참조(포인터) 또는 이름을 통해 구성 요소를 함께 바인딩합니다. SOA는 요청자가 기대하는 인터페이스, 의미 체계 및 서비스 보증을 제공하는 서비스 인스턴스의 보다 동적 검색을 지원합니다.

절차 또는 개체 지향 시스템에서 호출자는 일반적으로 내보내는 형식 또는 공유 이름 공간에 따라 서버를 찾습니다. SOA 시스템에서 호출자는 UDDI 와 같은 레지스트리에서 서비스를 검색할 수 있습니다.

이는 호출자의 요구 사항과 호환되는 메시지입니다. 호환성은 WSDL 또는 잘 알려진 XML 스키마의 일치하는 메시지를 통해 발생할 수 있습니다.
해당 문서는 호출자에게 필요한 서비스 보증을 지원합니다. 예를 들어 호출자는 보안 또는 트랜잭션에 대한 특정 접근 방식을 원할 수 있습니다.

동작의 대체 구현을 가능하게 하는 서비스 구현과 관련된 느슨한 바인딩을 사용하여 다양한 비즈니스 요구 사항을 해결할 수 있습니다. 예를 들어 대체 구현은 공급망의 대체 공급업체에 해당하여 변화하는 시장 상황에 보다 신속하게 대응할 수 있습니다. 마찬가지로 대체 구현은 재해 허용 오차를 가능하게 하는 지리적으로 분산된 데이터 센터일 수 있습니다.

3.0 웹 서비스 사양 및 함수

이 섹션에서는 웹 서비스 사양에 대한 개요를 제공합니다.

3.1 웹 서비스에 대한 구성 가능한 접근 방식

이 섹션에서는 사용 가능한 웹 서비스 사양에 대해 간략하게 설명합니다. 솔루션 공급자에 대한 가치, 더 넓은 아키텍처에서의 역할 및 서로 칭찬하는 방법에 대해 설명합니다.

다음 그림에서는 IBM, Microsoft 등에서 게시한 웹 서비스 사양을 개략적으로 그룹화합니다. 이 그림은 그룹 간의 엄격한 계층을 의미하지는 않습니다. 대신 기능 영역 간의 관계에 대한 직관을 제공하기 위한 것입니다. 예를 들어 메시지 보안에는 설명이 필요하지 않으며 마찬가지로 설명은 메시징에 유용한 개발 시간 개념입니다.

그림 3. 상호 운용 가능한 웹 서비스 프로토콜 아키텍처

3.2 기본 사항 - 전송 및 메시징

프랑스어로 작성된 편지를 보내는데 영어로 전화를 받을 예정이라면 통신하지 않습니다. 웹 서비스의 상호 운용성은 동일한 문제에 직면합니다. 우리는 전송 및 메시징 기술의 일반적인 집합을 제공하여이 문제를 해결합니다.

또한 이러한 기술이 실제로 효과적인지 확인하기 위해 IBM, Microsoft 등은 WS-I(웹 서비스 상호 운용성 조직)를 만들었습니다. 최근 WS-I는 상호 운용 가능한 웹 서비스 전송 및 메시징 메커니즘을 공식적으로 문서화하는 기본 프로필을 발표했습니다.

3.2.1 전송 — HTTP, HTTP/S, SMTP

이 사양 집합은 웹 서비스 간에 원시 데이터를 이동하기 위한 핵심 통신 메커니즘을 정의합니다.

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

3.2.2 메시지 형식 - XSD

다음 사양 그룹은 전송을 위해 웹 서비스 메시지를 인코딩하기 위한 상호 운용 가능한 메커니즘을 정의합니다. 전송은 서비스 간에 "바이트" 블록을 이동합니다. 이는 참가자가 바이트를 애플리케이션이 처리하는 유용한 데이터 구조로 변환할 수 있는 경우에만 유용합니다.

메시징 사양 그룹은 메시지의 서식을 올바르게 지정하는 방법을 정의합니다. XML 및 XML 스키마 정의는 메시지(데이터) 구조에 대해 추상적으로 동의하기 위한 메커니즘을 제공합니다. SOAP 는 서비스가 전송을 통해 교환하는 바이트 정보의 XML 메시지를 나타내는 표준 인코딩을 정의합니다.

3.2.3 WS-Addressing

메시지와 응답은 모두 어딘가에 가서 어딘가에서 옵니다. WS-Addressing 은 메시지 보낸 사람 및 수신자를 식별하는 상호 운용 가능하고 전송 독립적인 접근 방식을 제공합니다. 또한 WS-Addressing 메시지를 보내거나 받아야 하는 서비스 내의 특정 요소를 식별하는 더 세밀한 접근 방식을 제공합니다.

현재 웹 서비스를 사용하는 대부분의 시스템은 HTTP 전송에 배치된 URL을 사용하여 웹 서비스 메시지의 대상을 인코딩합니다. 응답의 대상은 반환 전송 주소에 의해 결정됩니다. 이 방법은 HTTP의 기본 브라우저 서버 모델을 기반으로 합니다.

오늘날의 접근 방식을 사용하면 원본 및 대상 정보가 메시지 자체의 일부가 아닙니다. 이로 인해 몇 가지 문제가 발생할 수 있습니다. 전송 연결이 종료되거나(예: 응답 시간이 오래 걸리고 연결 시간이 초과되는 경우) 또는 방화벽과 같은 중개자에서 메시지를 전달하는 경우 정보가 손실될 수 있습니다.

WS-Addressing 대상, 원본 및 기타 중요한 주소 정보를 웹 서비스 메시지 내에 직접 배치하는 메커니즘을 제공합니다. 즉, WS-Addressing 특정 전송 모델에서 주소 정보를 분리합니다.

대부분의 시나리오에서 메시지는 서비스를 직접 대상으로 하며 메시지의 주소 지정 정보는 단순히 URL을 사용하여 설명할 수 있습니다. 그러나 실제로는 메시지가 서비스 내의 특정 요소 또는 리소스를 대상으로 하는 경우가 많습니다. 예를 들어 조정 서비스는 다양한 작업을 조정하는 것일 수 있습니다. 코디네이터는 대부분의 수신 메시지를 조정 서비스 자체가 아니라 관리하는 특정 작업 instance 연결해야 합니다.

WS-Addressing 서비스에서 관리하는 엔터티를 주소 지정하기 위한 엔드포인트 참조 라는 간단하면서도 강력한 메커니즘을 제공합니다. 이러한 정보는 서비스의 URL 내에서 임시 방식으로 인코딩할 수 있지만 엔드포인트 참조는 이 세분화된 주소 지정을 인코딩하는 구조적 접근 방식을 가능하게 하는 표준 XML 요소를 제공합니다.

메시지 원본 및 대상의 전송 중립 인코딩과 결합된 주소 지정에 대한 세분화된 제어의 조합을 사용하면 웹 서비스 메시지를 중간자를 통해 다양한 전송 간에 보낼 수 있으며 비동기 및 연장된 기간 통신 패턴을 모두 사용할 수 있습니다.

또한 WS-Addressing 발신자가 전송 독립적 방식으로 응답이 어디로 이동해야 하는지를 나타낼 수 있습니다. 메시지에 대한 응답이 반드시 보낸 사람에게 전달되는 것은 아닙니다. 예를 들어 HTTP에서 WS-Addressing 없으면 응답을 다른 곳으로 보내도록 지정할 수 없습니다.

메시징 모델에 대한 이러한 향상된 기능을 통해 웹 서비스를 사용하여 많은 비즈니스 시나리오를 지원할 수 있습니다. 예를 들어 특정 은행 업무는 특정 단계에서 승인을 위해 인적 검토가 필요합니다. 일반적으로 언제든지 작업의 활성 인스턴스가 많이 있습니다. WS-Addressing 들어오는 메시지나 나가는 메시지를 특정 작업과 연결하는 일반적인 메커니즘을 제공합니다. 서비스에서 사용하는 메커니즘은 엔드포인트 참조를 통해 서비스를 사용하는 사용자에게 투명합니다.

3.3 설명

전송 및 메시지 사양을 사용하면 웹 서비스가 메시지를 사용하여 통신할 수 있습니다. 그러나 참가자는 메시지가 무엇인지 어떻게 알 수 있습니까? 웹 서비스는 주고 받는 메시지를 어떻게 문서화하거나 설명하나요? 웹 서비스를 사용하려면 웹 서비스에서 사용하고 생성하는 메시지(웹 서비스에 대한 인터페이스 )를 이해해야 합니다. 사양의 설명 그룹을 사용하면 웹 서비스가 인터페이스 및 기능을 표현할 수 있습니다.

메시지 상호 운용성 외에; 이러한 사양을 사용하면 개발 도구 상호 운용성도 사용할 수 있습니다. 설명 사양은 다양한 공급업체의 다양한 도구가 개발자를 공동으로 지원할 수 있는 표준 모델을 제공합니다. 웹 서비스가 구현 및 인프라 선택에서 파트너를 격리하는 것과 동일한 방식으로 설명 사양은 파트너를 개발 도구 선택과 격리합니다.

3.3.1 WSDL

WSDL(Web Services Description Language) 및 XSD(XML 스키마)는 이 그룹의 기본 사양입니다. XML 스키마를 사용하면 개발자와 서비스 공급자가 구매 주문 및 메시지(예: CreatePO 메시지)와 같은 데이터 구조에 대한 XML 형식을 정의할 수 있습니다. WSDL을 사용하면 웹 서비스에서 수신하고 보내는 메시지를 문서화할 수 있습니다. 즉, 서비스에서 수신하고 보내는 메시지 측면에서 수행하는 "작업" 또는 "함수"입니다.

WSDL은 다양한 메시지 상호 작용 패턴을 지원합니다. 응답, 요청/응답이 없고 응답이 있거나 없는 단방향 입력 메시지를 지원합니다. 마지막 두 패턴을 사용하면 서비스에서 필요한 다른 서비스를 지정할 수 있습니다.

제안된 WSDL 향상 기능은 서비스에서 지원하는 프로토콜 및 메시지 형식 및 서비스의 주소를 문서화하는 데 대한 지원을 제공합니다.

3.3.2 WS-Policy

WSDL 및 XSD 정의는 웹 서비스를 호출하기에 충분한 정보를 제공하지 않는 경우가 많습니다. WSDL 및 XSD는 서비스의 인터페이스 구문을 정의하지만 서비스가 해당 인터페이스를 제공하는 방법 또는 호출자가 기대하는 서비스에 대한 정보를 표현하지는 않습니다. 예를 들어 서비스에 보안이 필요하거나 트랜잭션을 구현하나요?

WS-Policy 를 사용하면 서비스에서 호출자에게 기대하는 것과 해당 인터페이스를 구현하는 방법을 지정할 수 있습니다. WS-Policy 서비스의 상위 수준 기능 작업에서 상호 운용성을 달성하는 데 중요합니다. 보안, 트랜잭션, 신뢰할 수 있는 메시징 및 기타 사양에는 구체적인 WS-Policy 스키마가 필요합니다. 이를 통해 서비스는 기대하는 기능적 보증을 설명하고 호출자에게 제공할 수 있습니다.

WS-Policy 프레임워크는 정책 식을 정의하기 위한 기본 모델을 제공합니다.

WS-Policy 는 정책 문을 집계하기 위한 문법을 지원하며 보다 유연하고 완전한 정책 집합을 생성할 수 있도록 합니다.

WS-PolicyAttachment 는 정책 집합을 XML 메시지 및 WSDL 요소(작업 및 portTypes)와 연결하는 방법을 지정합니다.

WS-Policy WS-PolicyAttachment 함께 프레임워크를 제공합니다. 개별 사양은 도메인별 정책 문 및 스키마를 정의합니다.

마지막으로 @PageWS-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

서비스 컬렉션에 대한 메타데이터를 수집하고 검색 가능한 형식으로 정보를 사용할 수 있도록 하는 것이 유용한 경우가 많습니다. 이러한 메타데이터 집계 서비스는 조직에서 제공하는 서비스를 게시하고, 해당 서비스에 대한 인터페이스를 설명하고, 서비스의 도메인별 분류를 사용하도록 설정할 수 있는 유용한 리포지토리입니다. UDDI(유니버설 설명 및 검색 인터페이스) 사양은 메타데이터 집계 서비스를 정의합니다.

솔루션은 디자인 타임에 UDDI를 쿼리하여 요구 사항과 호환되는 서비스를 찾을 수 있습니다. 예를 들어 개발자는 BPEL4WS 워크플로의 정의에서 이러한 서비스를 사용할 수 있습니다. 솔루션은 런타임에 UDDI를 쿼리할 수도 있습니다. 이 시나리오에서 호출자는 필요한 인터페이스를 "알고" 기능 요구 사항을 충족하거나 잘 알려진 파트너가 제공하는 서비스를 검색합니다.

UDDI 서비스를 메타데이터로 채우는 데 사용할 수 있는 메커니즘 중 하나는 WS-MetadataExchange를 사용하여 서비스에서 메타데이터를 획득하는 것입니다.

3.4 Service Assurances

웹 서비스는 서로 다른 시스템을 연결하는 기능 때문에 부분적으로 많은 열정을 불러일으켰습니다. 개발자는 전송, 메시징 및 설명의 기본 기능을 사용하여 많은 완전 기능 솔루션을 생성했습니다. 그러나 보다 강력한 통합 솔루션을 만드는 개발자가 허용하려면 웹 서비스는 보다 전통적인 미들웨어 솔루션에서 제공하는 동일한 수준의 서비스 보증 을 보장하는 기능을 제공해야 합니다. 단순히 메시지를 교환하는 것만으로는 충분하지 않습니다. 애플리케이션 및 서비스는 보안, 안정성 및 거래된 작업과 같은 중요한 상위 수준 기능을 제공하는 미들웨어 및 시스템에 상주합니다. 웹 서비스는 이러한 함수 간의 상호 운용성을 위한 메커니즘을 제공해야 합니다.

3.5 보안

이 @Page사양 제품군은 organization 웹 서비스에 매우 중요합니다. 이러한 사양은 인증 및 메시지 무결성, 기밀성, 신뢰 및 개인 정보를 지원합니다. 또한 서로 다른 조직 간의 보안 페더레이션을 지원합니다.

3.5.1 WS-Security

WS-Security 는 보안 웹 서비스의 기본 구성 요소입니다. 오늘날 대부분의 분산 웹 서비스는 보안 기능에 대한 전송 수준 지원을 사용합니다. 예를 들어 HTTP/S 및 BASIC-Auth 인증이 있습니다. 보안에 대한 이러한 접근 방식은 보안 통신에 필요한 최소값을 제공합니다. 그러나 제공하는 함수 수준은 기존 미들웨어 및 분산 환경에서 제공하는 것보다 훨씬 적습니다.

두 가지 예제는 BASIC-Auth 및 HTTP/S의 결함을 강조 표시합니다.

는 메시지를 서비스 B에 보냅니다. B는 메시지를 부분적으로 처리하고 서비스 C에 전달합니다. HTTP/S는 A-B와 B-C 간의 인증, 기밀성 및 무결성을 허용합니다. 그러나 C와 A는 서로를 인증하거나 B에서 정보를 숨길 수 없습니다.
A, B 및 C의 경우 인증에 BASIC-Auth 사용합니다. 동일한 복제된 사용자 및 암호 정보를 공유해야 합니다. 이는 많은 시나리오에서 허용되지 않습니다.

WS-Security 이러한 문제를 해결합니다. 다음을 지원합니다.

서명된 암호화된 보안 토큰. 는 C가 A에서 온 것으로 확인할 수 있는 토큰을 생성할 수 있습니다. B는 토큰을 위조할 수 없습니다.
는 선택한 요소 또는 전체 메시지에 서명할 수 있습니다. 이를 통해 B와 C는 A가 보낸 이후 메시지가 변경되지 않았다는 것을 확인할 수 있습니다.
는 메시지 또는 선택한 요소를 봉인할 수 있습니다. 이렇게 하면 해당 요소에 대한 의도된 서비스만 정보를 사용할 수 있습니다. 이렇게 하면 B가 C용 정보를 볼 수 없으며 그 반대의 경우도 마찬가지입니다.

WS-Security 기존 보안 모델(Kerberos, X509 등)을 사용합니다. 사양은 상호 운용 가능한 방식으로 기존 모델을 사용하는 방법을 구체적으로 정의합니다. 다중 홉, 다자간 웹 서비스 계산은 WS-Security 없이는 안전할 수 없습니다.

3.5.2 WS-Trust

보안은 미리 정의된 신뢰 관계에 의존합니다. Kerberos는 참가자가 Kerberos 키 배포 센터를 "신뢰"하므로 작동합니다. PKI는 참가자가 루트 인증 기관을 신뢰하기 때문에 작동합니다. WS-Trust 는 트러스트 관계를 설정하고 확인하기 위한 확장 가능한 모델을 정의합니다.

WS-Trust 주요 개념은 STS(보안 토큰 서비스)입니다. STS는 보안 토큰을 발급, 교환 및 유효성을 검사하는 고유 웹 서비스입니다. WS-Trust 웹 서비스에서 "신뢰"하는 보안 서버를 설정하고 동의하고 이러한 서버에 의존할 수 있습니다.

STS는 광범위한 어설션을 만드는 보안 토큰을 발급하는 데 사용할 수 있다는 측면에서 광범위한 적용 가능성이 있습니다. 대부분의 경우 동일한 어설션을 실행하지만 다른 형식으로 발급하는 데 사용됩니다. 예를 들어 STS는 키 보유자가 Susan임을 어설션하는 Kerberos 토큰을 발급할 수 있으며 신뢰할 수 있는 인증 기관에서 발급한 X.509 인증서를 기반으로 이 작업을 수행할 수 있습니다. 이를 통해 조직은 다양한 보안 기술을 사용하여 페더레이션할 수 있습니다. STS는 ID 클레임을 어설션하는 들어오는 보안 토큰을 기반으로 키 보유자가 BankTellers 그룹의 구성원임을 어설션하는 보안 토큰을 발급할 수도 있습니다.

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 가명 모델을 지원합니다. 여행사에 인증된 사용자는 항공사 또는 호텔과의 상호 작용에서 "별칭"을 생성했습니다. 이렇게 하면 최종 사용자의 개인 정보 보호와 여행사가 사용자 속성을 알고 얻을 수 있는 경쟁 우위를 보호할 수 있습니다.

3.6 신뢰할 수 있는 메시징

인터넷 세계에서는 거의 모든 통신 채널이 신뢰할 수 없습니다. 메시지가 사라집니다. 연결이 끊어질 수 있습니다.

신뢰할 수 있는 메시징 표준이 없으면 웹 서비스 애플리케이션 개발자는 이러한 함수를 애플리케이션에 빌드해야 합니다. 기본 접근 방식과 기술은 잘 이해됩니다. 예를 들어 많은 운영 및 미들웨어 시스템은 메시지가 고유 식별자를 갖도록 하고, 시퀀스 번호를 제공하고, 메시지가 손실될 때 재전송을 사용합니다. 애플리케이션 웹 서비스 개발자가 애플리케이션에서 이러한 모델을 구현하는 경우 다른 가정이나 디자인 선택을 할 수 있으므로 신뢰할 수 있는 메시징이 거의 없습니다.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging 은 웹 서비스가 신뢰할 수 없는 통신 네트워크를 통해 메시지를 배달할 수 있도록 하는 메커니즘을 정의합니다.

WS-ReliableMessaging 서비스가 상호 운용 가능한 접근 방식을 구현하고 런타임 공급업체가 프로토콜을 구현하는 서비스를 제공하여 애플리케이션 개발을 용이하게 할 수 있도록 합니다. 이렇게 하면 애플리케이션 개발 작업이 크게 간소화됩니다 . 그러면 비즈니스 논리에서 처리해야 하는 오류 조건이 훨씬 적습니다.

마지막으로, 업계에는 메시지를 안정적으로 라우팅하고 배포하기 위한 다양한 메시지 지향 미들웨어 집합이 있습니다. 각 구현은 독점 프로토콜을 사용합니다. WS-Reliable 메시징 프로토콜을 사용하면 다양한 운영 및 미들웨어 시스템이 메시지를 안정적으로 교환할 수 있습니다. 따라서 두 개의 서로 다른 인프라를 논리적으로 완전한 단일 엔드 투 엔드 모델로 브리징할 수 있습니다.

3.7 트랜잭션

복잡한 비즈니스 시나리오에서는 여러 당사자가 여러 메시지 집합을 교환해야 할 수 있습니다. 예를 들어 보험 정책, 연금, 계좌 및 중개 계좌를 포함하는 금융 서비스를 설정하는 금융 기관의 집합이 있습니다. 참가자 간에 교환된 여러 메시지는 논리적 "작업" 또는 "목표"를 구성합니다.

성공을 위해 당사자는 다음을 수행할 수 있어야 합니다.

조정된 새 작업을 시작합니다.
작업을 논리 작업과 연결합니다. 당사자는 동시에 서로 다른 고객에 대해 여러 계정을 설정할 수 있습니다.
계산 결과에 동의합니다. 예를 들어 모든 사람이 금융 패키지가 설정되었다는 데 동의합니까?

WS-Coordination, WS-AtomicTransaction 및 WS-BusinessActivity 이러한 요구 사항을 지원합니다.

3.7.1 WS-Coordination

WS-Coordination@Page다자간 다중 메시지 웹 서비스 작업의 결과를 시작하고 합의하기 위한 일반적인 메커니즘입니다. WS-Coordination 세 가지 주요 요소가 있습니다.

웹 서비스가 계산 중에 교환하는 모든 메시지에서 흐르는 조정 컨텍스트라는 메시지 요소입니다. 조정 컨텍스트에는 조정 서비스에 대한 WS-Addressing 엔드포인트 참조가 포함되며, 조정 중인 특정 작업을 식별하는 정보가 포함됩니다.
코디네이터 서비스입니다. 코디네이터 서비스는 조정된 작업을 시작하고, 조정된 작업을 종료하고, 참가자가 작업에 등록할 수 있도록 하고, 그룹 내 모든 메시지의 일부인 조정 컨텍스트를 생성하는 기능을 제공하는 WSDL을 사용하여 설명하는 서비스를 제공합니다.
또한 조정 서비스에는 참여하는 서비스가 조정된 작업의 결과를 알리기 위해 사용하는 WSDL에 정의된 인터페이스도 포함되어 있습니다.

새 조정 컨텍스트가 있는 메시지를 수신하는 웹 서비스는 결과 정보를 수신하기 위해 컨텍스트에서 코디네이터 서비스에 등록됩니다. 다른 사양은 도메인 및 보증 특정 요구 사항에 대해 이 프레임워크를 보강할 수 있습니다.

WS-Coordination 일반적인 프레임워크 및 기능입니다. 분산 계산의 참가자가 결과를 강력하게 결정할 수 있도록 이 프레임워크를 WS-AtomicTransaction 및 WS-BusinessActivity 확장합니다.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction 은 기존 2상 원자 트랜잭션 프로토콜을 구현하기 위해 WS-Coordination 모델에 연결하는 특정 프로토콜 집합을 정의합니다. 원자성, 2단계 모델은 관련된 서비스와 관련된 경우에만 유의해야 합니다. 사이트 또는 인프라 제공 서비스는 2단계 커밋을 보급할 수 있지만 보상 또는 버전 관리와 같은 다른 엔터프라이즈 내 모델을 사용합니다. 이러한 자유는 간단한 2단계 커밋 모델을 장기 실행 인터넷 계산에 더 유용하게 만듭니다.

3.7.3 WS-BusinessActivity

WS-BusinessActivity 는 장기 실행 보상 기반 트랜잭션 프로토콜을 구현하기 위해 WS-Coordination 모델에 연결하는 특정 프로토콜 집합을 정의합니다. BPEL4WS는 비즈니스 프로세스에 대한 트랜잭션 모델을 정의하지만 해당 프로토콜 렌더링을 지정하는 것은 WS-BusinessActivity. 이는 웹 서비스 사양의 구성성에 대한 예입니다.

3.8 서비스 컴퍼지션

웹 서비스 계층화에서 가장 큰 요소는 서비스 컴퍼지션입니다. 서비스 컴퍼지션을 사용하면 개발자가 SOAP 메시지를 교환하고 WSDL에서 인터페이스를 정의하고 집계 솔루션으로 WS-Policy 서비스를 "작성"할 수 있습니다. 집계는 구성된 웹 서비스입니다.

3.8.1 BPEL4WS

BPEL4WS(웹 서비스용 비즈니스 프로세스 실행 언어) 사양은 서비스 컴퍼지션을 지원합니다. 이를 통해 개발자는 공유 비즈니스 솔루션을 공동으로 구현하는 웹 서비스 세트의 구조와 동작을 정의할 수 있습니다. 서비스 집합의 각 요소는 WSDL 및 WS-Policy를 사용하여 해당 인터페이스를 정의합니다. 구성된 솔루션은 자체적으로 HTTP/SOAP 메시지를 지원하고 WSDL 및 WS-Policy를 사용하여 해당 인터페이스를 정의하는 웹 서비스입니다.

컴퍼지션에는 구조, 정보 및 동작의 세 가지 측면이 있습니다 . BPEL4WS는 각 컴퍼지션 측면을 지원하는 세 가지 구문을 소개합니다.

partnerLink는 복합 서비스와 전체 솔루션에 참여하는 웹 서비스 간의 명명된 연결을 정의합니다. 복합 서비스 및 참여 서비스는 WSDL 및 WS-Policy를 사용하여 서로에 대한 인터페이스를 정의합니다. 예를 들어 제조 회사와 공급업체 간의 연결일 수 있습니다.

partnerLink 개념과 컴퍼지션과 파트너 간의 WSDL/WS-Policy 인터페이스는 서비스 컴퍼지션의 구조를 정의합니다. 구성을 구성하기 위해 공동 작업하는 서비스 유형과 보증 수준(보안, 트랜잭션 등)과 교환하는 메시지를 정의합니다.

BPEL4WS는 또한 서비스 컴퍼지션의 정보를 정의하기 위한 지원을 제공합니다. BPEL4WS는 변수의 개념을 정의합니다. 복합 서비스는 각각 XSD 정의가 있는 변수 집합을 정의합니다. 특정 서비스의 현재 상태는 해당 변수의 상태입니다. 이렇게 하면 수신하거나 보낸 메시지가 정의됩니다.

마지막으로 BPEL4WS는 활동의 개념에 따라 복합 서비스의 동작을 정의하는 것을 지원합니다. BPEL4WS 정의 서비스는 서비스의 동작을 정의하는 일련의 활동 또는 "단계"입니다. 가장 기본적인 활동은 파트너에게 메시지를 보내거나 파트너로부터 메시지를 받는 것입니다. 각 메시지는 변수에 해당합니다. BPEL4WS는 변수 간 데이터 이동을 지원합니다.

BPEL4WS 활동의 한 가지 주요 측면은 BPEL4WS가 비결정적 동작의 제어된 사용을 허용하여 서비스의 외부적으로 표시되는(공용) 동작을 정의하는 데 특별한 지원을 제공한다는 것입니다. instance 신용 검사 PO 수락 결정 과정에서 특정 방식으로 수행된다는 사실은 공급 업체의 사적인 문제일 수 있습니다. BPEL4WS를 사용하면 프로세스 설명에서 크레딧 검사 동작을 삭제하지만 PO에 대한 응답이 수락 또는 거부일 수 있음을 보여 줌으로써 의사 결정 프로세스를 숨길 수 있습니다. 이러한 유형의 추상 프로세스를 WSDL과 함께 사용하여 비즈니스 파트너와 공급망과 같은 수직 산업 도메인 간에 상호 운용 가능한 비즈니스 프로토콜을 정의할 수 있습니다.

BPEL4WS는 활동 실행 흐름을 제어하는 여러 방법도 지원합니다. 여기에는 시퀀싱 및 그래프 기반 흐름이 포함됩니다. BPEL4WS는 변수에 대한 조건자를 지원하여 복합 서비스가 따르는 제어 경로를 결정합니다.

요약하자면, BPEL4WS는 이전에 정의된 웹 서비스 사양에 두 가지를 추가합니다.

BPEL4WS는 WSDL 및 WS-Policy 서비스 설명 지원을 확장합니다. BPEL4WS는 웹 서비스를 집계 서비스로 결합하고 정보 흐름 및 동작과 같은 서비스 간의 연결을 문서화할 수 있습니다. 이렇게 하면 웹 서비스의 공동 설계를 지원하는 상위 계층 도구 간의 상호 운용성을 지원합니다.
BPEL4WS는 실행 언어입니다. BPEL4WS를 사용하면 개발자가 복합 웹 서비스의 동작을 완전히 지정할 수 있습니다. IBM, Microsoft 및 기타 파트너는 BPEL4WS 문서를 실행하고 파트너에게 디자인 및 실행 시간 바인딩을 지원하는 환경을 제공합니다.

4.0 실제로 웹 서비스 - 예제

다음 시나리오에서는 WS 사양을 함께 사용하여 실제 요구 사항을 해결하는 웹 서비스를 만드는 방법을 보여 줍니다. 이 시나리오는 다양한 WS 사양의 구성성으로 인해 개발자가 사용할 수 있는 강력한 기능의 예를 제공합니다.

이 시나리오에 설명된 웹 서비스는 2003년 9월 17일에 개최된 기술의 공동 IBM-Microsoft 데모를 위해 만들어졌습니다. 상호 운용 가능하고 안전하며 신뢰할 수 있으며 거래되는 애플리케이션을 만드는 데 사용되었습니다. 및 는 조직의 경계에 걸쳐 있습니다.

데모에서는 자동차 제조업체에서 부품을 주문하는 자동차 딜러를 위한 페더레이션 주문 처리 및 공급업체 VMI(관리 인벤토리) 시스템의 실행 예제를 보여 줍니다. 제조업체는 여러 창고를 운영하는 공급업체로부터 부품을 얻습니다. 시스템의 모든 애플리케이션 간 통신은 이전에 설명한 웹 서비스 프로토콜을 사용하여 단독으로 빌드되었으며 IBM 및 Microsoft 소프트웨어가 있는 컴퓨터 컬렉션에서 실행됩니다.

이 시나리오는 소매 비즈니스, 도매업체 및 도매업체 공급업체 간의 상호 작용과 같은 비즈니스 수행의 가장 일반적인 측면 중 일부를 다룹니다. 이 시나리오에서는 다음과 같은 비즈니스 프로세스 필수를 자동화하기 위해 다양한 WS 사양을 구성하는 방법을 보여 줍니다.

보안을 적용하기 위한 인증(WS-Security)
서로 다른 조직 간의 신뢰 페더레이션(WS-Trust 및 WS-Federation)
트랜잭션을 완료하기 위한 데이터 교환(WS-AtomicTransaction)
신뢰할 수 있는 메시징을 통해 주문이 제출되었는지 확인(WS-ReliableMessaging)

4.1부 1부: 고객 환경

이 예는 자동차 딜러라는 회사의 직원인 헤더가 대리점의 보안 인트라넷 웹 사이트에 로그인하는 것으로 시작됩니다. 이 웹 사이트는 표준 상용 웹 기술을 사용하여 빌드되었습니다. 헤더는 브라우저를 사용하여 사이트에 들어갑니다. 사이트에 대한 액세스는 암호로 보호됩니다.

그림 4. 헤더는 회사의 보안 인트라넷 웹 사이트에 로그온하고 사용자 지정된 내 페이지로 이동합니다.

헤더가 내 페이지를 클릭합니다. 백그라운드에서 애플리케이션은 Auto Dealer의 인벤토리 데이터베이스에서 정보를 수집합니다. 항목의 인벤토리 수준이 정의된 임계값보다 낮으면 보고서가 생성되고 헤더 페이지의 "경고" 표시에 나열됩니다.

헤더는 회사가 WindshieldPro 와이퍼 블레이드에 재고가 적다는 것을 확인합니다.

헤더는 링크를 클릭하고 헤더가 주문을 할 수 있는 자동 제조업체 엑스트라넷의 보안 웹 페이지로 원활하게 리디렉션됩니다. 자동 딜러 소프트웨어는 웹 서비스를 기반으로 하므로 환경이 원활하게 진행됩니다. 자동 딜러의 인트라넷과 Auto Manufacturer 엑스트라넷을 연결하는 웹 서비스는 WS-Federation을 사용하여 구성되었습니다. WS-Federation 한 사이트에서 부여한 보안 자격 증명이 두 번째 사이트에서 적용되도록 합니다.

작동 방식은 다음과 같습니다. 자동차 딜러와 자동차 제조업체는 사이트를 페더레이션하기로 합의했습니다. WS-Federation 일련의 서버 간 통신을 조정합니다. 헤더가 WindshieldPro 링크를 클릭하여 그녀를 자동차 제조업체의 웹 페이지로 데려가자마자 자동차 제조업체의 웹 페이지 서버는 권한 부여 서비스를 쿼리하여 자동 딜러의 권한 부여 서비스를 쿼리했습니다. 자동 딜러 권한 부여 서비스는 헤더가 헤더의 대리점 이름과 함께 자격 증명을 전송하는 권한 있는 사용자임을 확인하여 헤더 액세스 권한을 부여하는 자동차 제조업체의 권한 부여 서비스로 돌아갑니다. 이것은 너무 원활하게 발생, 모든 헤더 노트는 그녀가 한 웹 페이지에서 다른 갔다는 것입니다.

웹 서비스는 또한 헤더의 계정에 연결된 정보를 주문하기 위해 자동 제조업체 고객 데이터베이스를 쿼리합니다. 정보는 개인 설정된 "내 페이지" 자동 제조업체 웹 페이지에 표시됩니다.

그림 5: WS-Federated 사용하여 웹 서비스를 작성하면 헤더가 자동 딜러의 개인 설정 페이지에서 자동 제조업체의 개인 설정된 페이지로 원활하게 이동할 수 있습니다.

Auto Manufacturer 엑스트라넷에 있는 헤더의 개인 설정된 웹 페이지를 통해 현재 미해결 주문이 없음을 알 수 있습니다. 그녀는 운송 중 하나의 주문(50개의 SuperTires용)을 가지고 있습니다. 완료된 주문 목록에는 CDPlus 20개와 가죽 클리너 50대가 포함되어 있습니다.

헤더는 "새 주문 만들기"를 클릭하면 원하는 부분인 WindshieldPro 와이퍼 블레이드 및 주문 날짜로 미리 채워진 새 페이지가 열립니다. 그녀가 입력해야 할 것은 수량입니다. 주문을 완료하는 데 필요한 다른 모든 정보는 Auto Manufacturer 데이터베이스에서 채워집니다.

그림 6. 주문 데이터의 대부분이 이미 Auto Manufacturer 고객 데이터베이스의 헤더 파일에서 가져왔기 때문에 주문을 쉽게 수행할 수 있습니다.

헤더는 주문을 제출하고 구매할 추가 항목을 검색하거나 로그아웃을 클릭하여 세션을 종료하고 다른 사람이 무인 컴퓨터에서 주문을 하지 못하도록 합니다.

웹 서비스를 WS-Federation 구성하면 자동 딜러와 자동차 제조업체 모두 관리 비용과 엔드 투 엔드 보안을 제공합니다. 이 기술이 없었다면 자동차 제조업체는 모든 공인 대리점 직원과 암호 목록을 유지해야 했을 것입니다. 비용이 많이 들고 오류가 발생하기 쉬울 수 있으며 애플리케이션의 보안을 줄일 수 있습니다.

instance 경우 헤더가 직장을 그만두면 자동 딜러에서 사용자 계정이 제거됩니다. 그러나 대리점의 관리자가 자동차 제조업체에 그녀의 출발에 대해 연락하는 것을 잊어 버린 경우, 그녀는 구매 사이트에 계속 액세스 할 수 있습니다. WS-Federation에서는 변경해야 하는 유일한 시스템이 자동 딜러의 ID 공급자 서비스이기 때문에 문제가 되지 않습니다. 응용 프로그램 및 권한 부여 서비스인 자동차 제조업체의 시스템은 헤더, 사용자 이름 또는 암호에 대한 타고난 지식이 없습니다.

4.2부 2부: 공급업체 환경

헤더는 자동차 제조업체에서 WindshieldPro 와이퍼 블레이드를 주문하지만, 회사가 실제로 자체 블레이드를 만든 지 반세기가 지났습니다. WindshieldPro 와이퍼 블레이드는 공급업체 공급업체에서 제공됩니다.

Tony는 공급업체의 영업 담당자이며 헤더가 자동차 딜러 인트라넷에 로그인한 것처럼 공급업체의 인트라넷에 로그인하여 하루를 시작합니다. 그러나 Tony는 표준 웹 브라우저를 사용하는 대신 웹 서비스를 기본적으로 지원하는 Windows 애플리케이션에서 작동합니다.

그림 7. 공급업체 인트라넷에 있는 Tony의 개인 페이지는 그의 주요 고객 중 하나인 자동차 제조업체에서 주문과 재고를 검사 것을 상기시켜 줍니다.

Tony가 주문 및 인벤토리를 검사 때 애플리케이션은 웹 서비스를 사용하여 Tony가 액세스할 수 있는 인벤토리 데이터를 요청합니다.

데이터에 대한 이 애플리케이션 수준 웹 서비스 요청의 한 가지 주요 측면은 자동 제조업체의 엑스트라넷에 대한 액세스를 인증하는 WS-Federation 구성된다는 것입니다.

웹 서비스는 제품 유형 및 현재 재고 수별로 표시되는 공급업체의 페이지로 결과를 반환합니다.

그림 8. 웹 서비스는 Tony의 Supplier 페이지를 자동차 제조업체의 인벤토리 데이터베이스의 인벤토리 데이터로 채웁니다. 요청은 WS-Security 및 WS-Federation을 사용하여 작성하여 안전해졌습니다.

공급업체는 자동차 제조업체와 Just-In-Time 구매 계약을 체결했습니다. Tony는 재고가 20 미만이 되면 자동차 제조업체를 대신하여 공급업체 관리 인벤토리(VMI)의 일부로 자동 재공급 주문을 제공할 권한이 있습니다. Tony는 WindshieldPro를 클릭하여 주문을 합니다. 애플리케이션은 WS-Security 보호로 구성된 웹 서비스에서 지원되므로 Tony와 Auto Manufacturer 간의 모든 메시지는 보호됩니다.

그림 9. 토니는 자동차 제조업체와 Just-In-Time 계약을 체결하여 회사를 대신하여 주문을 입력할 수 있습니다.

Tony의 애플리케이션은 그에게 자동차 제조업체 구매 주문으로 공급업체에 대한 요청을 만드는 화면을 제공합니다. Tony는 50개의 WindishieldPros 와이퍼를 자동차 제조업체에 직접 배송하도록 주문합니다.

Tony가 확인을 클릭하면 WS-AtomicTransactions, WS-Security 및 WS-ReliableMessaging으로 구성된 웹 서비스인 Warehouse Service가 다른 웹 서비스인 하위 웨어하우스 서비스와 함께 주문을 수행하려고 시도합니다. 임시 네트워크 중단으로 인해 웨어하우스 서비스에서 응답이 즉시 반환되지 않는 경우 WS-ReliableMessaging 응답을 받을 때까지 쿼리를 계속 다시 보냅니다.

창고 서비스가 주문을 받으면 회사의 두 실제 창고에 내부적으로 릴레이합니다. 여기에는 두 웨어하우스 간의 데이터베이스가 포함되므로 WS-AtomicTransaction 데이터베이스 간의 트랜잭션 동작을 보장하는 데 사용됩니다.

Warehouse 애플리케이션은 재고 범위를 보장하기 위해 하위 웨어하우스 서비스 간에 주문을 나눕니다. 주문의 70%는 웨어하우스 1로 이동하고 나머지 30%는 웨어하우스 2로 이동합니다. 주 웨어하우스의 루트 코디네이터는 웨어하우스의 루트 코디네이터 2에게 주문의 30%를 요청하는 메시지를 보냅니다. 웨어하우스 2의 루트 코디네이터는 재고를 확인하고 재고가 충분하지 않다는 메시지를 주 웨어하우스의 루트 코디네이터에게 보냅니다.

기본 루트 코디네이터는 인벤토리가 충분하지 않다는 것을 알고 전체 트랜잭션을 취소하고 상태, 인벤토리 수준 및 트랜잭션이 취소되었음을 나타내는 메시지를 Tony의 웹 서비스 애플리케이션에 보냅니다. 루트 코디네이터는 트랜잭션을 철회하기 시작하고 완료되면 웨어하우스로 돌아가서 트랜잭션이 취소되었다고 말합니다.

현재 재고 지식이 있는 Tony는 창고에 또 다른 요청을 보냅니다. 루트 코디네이터는 다른 트랜잭션 엔터티(다른 트랜잭션의 컨트롤러)를 조정하고 이전과 동일한 프로세스를 거치는 2개의 웨어하우스에 이 요청을 제출합니다. WS-Security 사용하여 전체 메시지 본문에 서명하므로 사용자가 어떤 도메인에 있든 상관없이 사용자가 안전하다는 것을 알 수 있습니다.

이제 루트 코디네이터가 트랜잭션을 커밋하고, 리소스를 잠그고, 트랜잭션을 완료합니다. 트랜잭션이 성공적으로 완료되었음을 나타내는 메시지가 Tony로 다시 전송됩니다.

WS-AtomicTransaction 이러한 메시지에서 WS-ReliableMessaging 및 WS-Security 구성하여 완전한 엔터프라이즈 지원 분산 시스템을 제공합니다.

5.0 결론

IBM, Microsoft 및 파트너는 새로운 세대의 강력하고 안전하며 신뢰할 수 있는 거래 웹 서비스의 구성 요소로 사용할 수 있는 웹 서비스 사양을 개발하고 있습니다.

이러한 사양은 개발자가 필요한 기능만 활용할 수 있도록 모듈식으로 구성 가능한 방식으로 설계되었습니다. 이러한 "구성 요소와 유사한" 구성성을 통해 개발자는 간단하고 유연한 방식으로 강력한 웹 서비스를 만들 수 있을 뿐만 아니라 특정 애플리케이션에 의해 결정되는 복잡성 수준만 도입할 수 있습니다.

이 기술을 통해 조직은 SOA(Service-Oriented 아키텍처)를 사용하여 애플리케이션을 쉽게 만들 수 있습니다. 또한 IBM과 Microsoft는 이 방법을 사용하여 만들 수 있는 비즈니스 프로세스의 풍요로움을 보여 주는 안전하고 안정적이며 거래된 SOA 애플리케이션을 입증했습니다. 또한 이러한 데모는 IBM WebSphere 및 Microsoft .NET 소프트웨어로 구성된 다른 유형의 환경에서 페더레이션된 보안 환경에서 작동해 왔습니다.

이러한 웹 서비스 기술은 개발자가 이러한 기술을 더 쉽게 사용할 수 있도록 하는 도구를 사용하여 운영 체제, 미들웨어에서 사용할 수 있을 것으로 예상합니다. 개발자와 조직이 이러한 시스템을 사용하여 차세대 웹 서비스 기반 솔루션을 만들 때 나타나는 애플리케이션을 보는 것은 흥미로울 것입니다.

6.0 승인

우리는 이러한 아이디어에 기여 한 다음 개인을 인정하고 싶습니다 : (사전순) 토니 앤드류스, 밥 앳킨슨, 키스 발링거, 돈 박스, 존 브레작, 앨런 브라운, 펠리페 카브레라, 에릭 크리스텐슨, 조지 코플랜드, 마이클 쿨슨, 조반니 델라-리베라, 브렌던 딕슨, 마이크 더쉬, 콜린 에반스, 맥스 페인골드, 제프 프레이, 헨릭 프라이스티크 닐슨, 프레릿 가그, 오므리 가젯, 스콧 그레이, 조쉬 그레이, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, 짐 존슨, 라이언 존슨, 고팔 카키바야, 크리스 칼러, 요하네스 클라인, 스콧 코너스만, 브라이언 라마키아, 데이브 랭워시, 앤드류 레이먼, 폴 리치, 알 리, 프랭크 레이만, 로드니 림프레흐트, 조 롱, 스티브 루크코, 존 만페르델리, 아쇼크 말호트라, 조나단 마쉬, 스티브 밀렛, 안젤라 밀스, 토니 나달, 마틴 Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.

다음을 통해 공유