KR101109251B1 - 웹 서비스 애플리케이션 프로토콜 및 ｓｏａｐ 프로세싱모델 - Google Patents

Abstract

공용 메시지 오퍼레이션 세트에 기초하여 웹 서비스 애플리케이션 모델을 정의하는 SOAP 기반 프로토콜을 포함하는 웹 서비스 애플리케이션 프로토콜(WSAP)이 설명된다. WSAP는 웹 서비스들이 서로 상호작용하는 방법과 관련하여 웹 서비스들을 정의하기 위한 기초를 제공한다. WSAP에서, 한 서비스의 행위들은 개별 포트(예를 들어, URI)가 각각 구비되고, 이로 인해 서비스의 행위들은 직접 상호작용될 수 있다. WSAP는 또한 메시지가 무엇인지, 메시지의 프로세싱이 무엇인지, 및 그것이 수신기의 상태/행위에 어떻게 영향을 미치는 지를 식별하는 오퍼레이션들을 위한 공유 시멘틱을 정의한다. 메시지의 순서화는 또한 발생하고 있는 것에 대한 문맥을 제공한다. 오퍼레이션 및 순서화의 공지된 특성의 결과로서, 중간자는 통신에 값을 추가하기 위해 교환 메시지를 프로세스할 수 있다. SOAP 프로세싱 모델은 동시에 또는 순서대로 실행하도록 다수의 웹 서비스를 구성하는 것을 정의한다.

WSAP, SOAP, 바인딩 리스트, 가입 리스트, 헬퍼 서비스, 가입자 서비스

Description

웹 서비스 애플리케이션 프로토콜 및 ＳＯＡＰ 프로세싱 모델{WEB SERVICE APPLICATION PROTOCOL AND SOAP PROCESSING MODEL}

도 1은 본 발명이 구현될 수 있는 컴퓨터 시스템을 개괄적으로 도시한 블록도.

도 2는 본 발명의 한 실시양상에 따라, 웹 서비스 애플리케이션 프로토콜을 통해 서로 통신하는 서비스들을 개괄적으로 도시한 블록도.

도 3은 본 발명의 한 실시양상에 따라, WSAP 메시지를 통신할 때의 한방향 메시지 교환 패턴의 개념을 개괄적으로 도시한 블록도.

도 4는 본 발명의 한 실시양상에 따라, WSAP 메시지를 위한 예시적인 요청-응답 메시지 교환 패턴을 개괄적으로 도시한 블록도.

도 5는 본 발명의 한 실시양상에 따라, 상이한 행위(behavior)들을 갖는 서비스들의 세트로서 노출된 파일을 개괄적으로 도시한 블록도.

도 6은 본 발명의 한 실시양상에 따라, 동일한 서비스 값을 수반하는 지의 여부에 상관없이 상이한 서비스들로서 모델링된 상이한 액세스 모델을 개괄적으로 도시한 블록도.

도 7은 본 발명의 한 실시양상에 따라, 명시적 초기화 이전의 CREATE 오퍼레이션에서의 예시적인 메시지 시퀀스를 개괄적으로 도시한 도면.

도 8은 본 발명의 한 실시양상에 따라, 복잡한 서비스 생성을 위한 예시적인 메시지 시퀀스를 개괄적으로 도시한 도면.

도 9는 본 발명의 한 실시양상에 따라, LOOKUP 오퍼레이션에서의 예시적인 메시지 시퀀스를 개괄적으로 도시한 도면.

도 10은 본 발명의 한 실시양상에 따라, QUERY 오퍼레이션에서 GET 오퍼레이션으로 매핑하는 시퀀스를 개괄적으로 도시한 도면.

도 11은 본 발명의 한 실시양상에 따라, INSERT 오퍼레이션의 결과를 설명하기 위해 INSERT 오퍼레이션의 전과 후에 실행된 GET 오퍼레이션 간의 차이를 도시한 순서도.

도 12는 본 발명의 한 실시양상에 따라, DELETE 오퍼레이션의 결과를 설명하기 위해 DELETE 오퍼레이션의 전과 후에 실행된 GET 오퍼레이션 간의 차이를 도시한 순서도.

도 13은 본 발명의 한 실시양상에 따라, UPDATE 오퍼레이션의 결과를 설명하기 위해 UPDATE 오퍼레이션의 전과 후에 실행된 GET 오퍼레이션 간의 차이를 도시한 순서도.

도 14는 본 발명의 한 실시양상에 따라, 예시적인 REPLICATION 시퀀스를 개괄적으로 도시한 블록도.

도 15는 본 발명의 한 실시양상에 따라, 복제를 취소하는 예시적인 CANCELREPLICATION 시퀀스를 개괄적으로 도시한 블록도.

도 16은 본 발명의 한 실시양상에 따라, 이벤트 통지를 얻기 위한 예시적인 SUBSCRIBE 시퀀스를 개괄적으로 도시한 블록도.

도 17은 본 발명의 한 실시양상에 따라, 예시적인 UNSUBSCRIBE 시퀀스를 개괄적으로 도시한 블록도.

도 18은 본 발명의 한 실시양상에 따라, 단순한 서비스 종료의 한 예를 개괄적으로 도시한 블록도.

도 19는 본 발명의 한 실시양상에 따라, 추가적인 클린업(cleanup)을 갖는 단순한 서비스 종료의 한 예를 개괄적으로 도시한 블록도.

도 20은 본 발명의 한 실시양상에 따라, 복잡한 서비스 종료의 한 예를 개괄적으로 도시한 블록도.

<도면의 주요부분에 대한 부호의 설명>

202 : 웹 클라이언트 코드

204 : WSAP 웹 서비스

304 : 판독 서비스

306 : 실행 서비스

308 : 메타데이터 조작 서비스

411 : 판독 전용 액세스 서비스

412 : 판독 기입 액세스 서비스

413 : 암호화 애겟스 서비스

414 : 트랜잭트 액세스 서비스

본 발명은 일반적으로 컴퓨터 시스템에 관한 것으로, 더욱 구체적으로 웹 서비스에 관한 것이다.

컴퓨터 사용자들 및 애플리케이션들이 관리, 그렇지 않으면 액세스할 필요가 있는 많은 유형의 컴퓨팅 서비스들, 자원들 및 데이터가 있다. 그러한 자원들 및 데이터는 서비스들 및 국부적으로 유지된 데이터, 및 공동의 네트워크들과 그외 인트라넷 및 인터넷을 포함하여 원격으로 액세스가능한 사이트들 상에 유지된 데이터를 포함한다.

웹 서비스의 개념은 일반적으로, 사실상 교차 플랫폼(cross-platform)인 프로토콜 및 표준을 통해 클라이언트에게 컴퓨팅 서비스를 제공하는 것에 관한 것이다. 일반적으로, 웹 서비스는 요청하는 클라이언트가 실행하는 플랫폼의 유형에 상관없이, 분산 애플리케이션의 노드들을 함께 결선하는 기본 도구를 제공한다. 다수의 상이한 컴퓨팅 플랫폼이 있기 때문에, 네트워크 정보의 교환을 용이하게 하는 다양한 플랫폼-독립적 메카니즘 및 프로토콜은 웹 서비스에서 일반적인 것으로 되고 있으며, HTTP(HyperText Transfer Protocol), XML(eXtensible Markup Language), XML 스키마(Schema) 및 SOAP(Simple Object Access Protocol) XML을 포함한다. 비즈니스, 조직 및 그 밖의 제공자들이 사용자 및 애플리케이션에 서비스를 제공하는 종래의 웹 서비스는 현재 이들 표준에 기초하고 있다. 게다가, 본 발명의 양수인에게 양도된 미합중국 특허 출원 제10/328,714호에 설명된 바와 같이, 웹 서비스는 하드웨어 장치, 데이터베이스 등과 같은 기타 유형의 자원을 나타낼 수 있다.

현재, 웹 서비스가 클라이언트와 데이터를 교환하는 프로토콜은 웹 서비스에 의해 제공된 계약에 따라 협정된 방식으로, 클라이언트가 메시지를 서비스에 대응하는 서버 포트(예를 들어, URI)에 보낼 수 있게 하고, 메시지를 다시 클라이언트에서 수신할 수 있게 한다. 그러나, 한가지 가능한 문제점은, 서비스 자체가 분리된 엔티티들로부터 구성될 수 있을지라도, 클라이언트는 그 메시지를 서비스의 URI를 통해 보낼 필요가 있어서, 이로 인해 서비스의 URI를 통한 통신이 병목현상을 초래할 가능성이 있다는 것이다.

현존하는 프로토콜이 갖는 다른 문제점은, 임의의 주어진 메시지는 기본적으로 메시지가 존재한다는 것을 알아차리는 것 이외에, 메시지 포맷의 정통한 지식 없이는 관찰 불가능하다는 것이다. 결과적으로, 중간자(예를 들어, 다른 신뢰 서비스)가 메시지의 기본 특성 및/또는 목적을 확신할 수 없기 때문에, 중간자가 메시지 교환 대한 값을 제공하기 위한 방법이 없다.

필요한 것은 클라이언트들 및 웹 서비스들이, 중간자들이 통신에 값을 추가할 수 있게 해주는 하나의 서비스를 구성하는 엔티티들을 포함하여, 하나의 웹 서비스와 안전하고 효율적으로 통신할 수 있는 메카니즘이다.

간략하게 말하면, 본 발명은, 그 중에서도 특히, 포트(예를 들어, URI)를 통해 서비스의 상태 및 행위를 형식적으로 나타내고, 이로 인해 서비스 내의 엔티티 들이 상호작용을 위해 직접 접촉될 수 있는 웹 서비스 애플리케이션 프로토콜(WSAP)을 포함하는 방법, 시스템 및 메카니즘을 제공한다. 즉, 다른 프로토콜들과 달리, WSAP는 웹 서비스의 행위들을 형식화된 방식으로 기술하는데, 예를 들어 한 서비스의 각각의 행위는 그 자신의 포트를 갖는다. WSAP 프로토콜은 또한, 메시지가 무엇인지, 메시지의 프로세싱이 무엇인지, 및 그것이 수신기의 상태/행위에 어떻게 영향을 미치는지를 식별하는 동사로 공유 시멘틱(shared semantics)을 정의함으로써 중간자들의 이용을 용이하게 한다. 더욱이, 메시지들의 순서 및 오퍼레이션들은 발생하고 있는 것에 대한 문맥을 제공한다.

일반적으로, 서비스의 논리 엔티티의 행위들(또는 상태들)이 서로 다를 때마다, WSAP는 서비스가 각각의 행위/상태를 그 자신의 포트(예를 들어, URI와 같은 식별자)에 제공할 수 있게 한다. 이러한 방식으로, 클라이언트는 행위/상태를 제어하는 서비스 내의 논리 엔티티와 직접 통신할 수 있다. 예로서, 하드 디스크 드라이브와 같은 저장 장치로의 액세스를 제공하는 웹 서비스를 생각해보자. 종래에, 파일 시스템을 통해 파일을 열고 파일 핸들을 수신한 다음에, 연 파일에 데이터를 판독하고 기입하기 위해, 클라이언트는 파일 핸들을 파일 시스템에 보낼 수 있다. WSAP로써, 파일 핸들을 복귀하는 대신에, 중재인 서비스는 적절한 상태(데이터)로 행위(실행하기 위한 오퍼레이션)로의 액세스를 제공하는 웹 서비스의 다른 논리 엔티티(다른 서비스)에 URI를 복귀시킨다. 이 예에서, WSAP로써, 클라이언트는 다시 중재인을 통하지 않고, 저장 매체 자체 위의 허용된 위치로 (예를 들어, 적합한 XML 스키마를 사용하여) 기입하기 위한 포트, 및 저장 매체로부터 판독하기 위한 다른 포트를 수신할 수 있다. 판독 오퍼레이션은 저장 매체의 하나의 행위에 대응하므로, 다른 행위에 대응하는 기입 오퍼레이션과 다른 URI를 가질 수 있다는 것을 알기 바란다. 알 수 있는 바와 같이, 이러한 데이터 액세스 모델은, 특히 파일 시스템이 다른 상황에서 병목현상이 생길 수 있는 경우에, 각 오퍼레이션마다 파일 시스템 제어기로 가는것 보다 더욱 효과적이다.

게다가, 상태 및 행위를 노출하는 포트들 형태의 WSAP의 명백한 상호작용 점들 이외에, WSAP 메시지는 상호작용 점 상에서 행해질 수 있는 것을 설명하는 공유 시멘틱을 사용한다. 시멘틱은 (아마도 사유의) 메시지 상세와 분리되는 공유 메시지 동사들로 구성되어, 메시지 내용들을 안전하게 하면서, 어떤 임의의 중간자가, 발생하고 있는 것을, 알고있는 정도까지, 관찰할 수 있게 한다.

메시지 순서화는 또한 관찰자에게 문맥을 제공하는 역할을 할 수 있다. 예를 들어, 각각의 서비스는 WSAP 오퍼레이션들 중에서 그것이 수락하는 어떤 WSAP 오퍼레이션들을 그 순서로 정의할 수 있다. 더욱이, 각 포트와의 통신은 각 행위에 그 자신의 포트가 할당될 수 있기 때문에 요청되고 있는 행위를 보통 식별한다. 실제로 포트들의 리스트로서 유지될 수 있는 서비스 포트들 간의 이들 상호작용 패턴은 어떤 WSAP 오퍼레이션들이 발생했는지, 그리고 어떤 순서로 그들이 발생했는지를 용이하게 관찰가능한 디렉토리를 제공한다.

결과적으로, 중간자는 통신들에 값을 추가하기 위해 교환 메시지를 프로세스할 수 있다. 예를 들어, 요청된 오퍼레이션 유형 및/또는 공지된 URI로부터, 메시지가 자원의 상태를 변경하지 않을 것이라는 것을 알 때, 캐시 서비스와 같은 중간 자는, 캐시를 무효화하고 다른 저장 매체를 액세스하기 위해 (다른 서비스로) 메시지를 보내기 보다는, 요청을 충족시키기 위해 그 자신의 캐시로부터 데이터를 안전하게 판독할 수 있다. 중간 캐시 서비스는 프로토콜의 시멘틱으로부터, 또는 판독 전용 서비스로 될 것을 알고 있는 경우에 URI로부터, 오퍼레이션 유형만을 알 필요가 있을 뿐이고, 안전하게 유지될 수 있는 (그리고 실제로 다른 중간자 서비스를 통해 암호화되어 있을 수 있는) 메시지의 내부 내용들을 모른다는 것을 알기 바란다. 수반되는 상태 변화가 전혀 없는 WSAP에서의 그러한 판독형 오퍼레이션의 예들은 QUERY 또는 GET의 공유 시멘틱을 사용하는 것과 관련된 오퍼레이션들을 포함한다. 그러한 오퍼레이션들은 본질적으로 판독 전용 액세스가 오퍼레이션 요청을 충족시키기에 충분하다는 것을 의미하는 안전상태(safe)인 특성, 및 본질적으로 동일한 오퍼레이션이 상태 변화 없이 언제까지나 반복될 수 있다는 것을 의미하는 멱등상태(idempotent)인 속성을 각각 갖는다. 캐시는 그러한 중간자의 한 예일 뿐이고, 중간자는 적절한 임의의 다른 서비스, 예를 들어 부하 분산장치(load balancer), 데이터 압축기, 복제 서비스, 암호화/복호화 메카니즘 등등일 수 있다는 것을 알기 바란다.

게다가, 그들 자신의 포트를 갖는 행위들 때문에, 다수의 웹 서비스들을 동시에 또는 순서대로 실행하도록 구성하는 방법을 정의하는 SOAP 프로세싱 모델이 제공된다. 모델은 SOAP-인식(aware) 직렬 변환기와 같은 몇몇 서비스의 구현이, 주어진 SOAP 메시지의 헤더 및 바디를 동시에 직렬화 또는 역직렬화할 수 있게 한다. 이것은 SOAP 엔벨로프(envelope)의 부분들에 의존하는 서비스들이, 한 서비스 가 신경쓰는 한 헤더가 이용가능할 때마다, 비블록화(unblock)할 수 있게 한다. 2개의 통신 당사자들이 같은 위치, 예를 들어 동일한 장치 상에 배치될 때, 포워딩(forwarding) 및 전송(transport) 서비스들은 성능상 이유로 SOAP 엔벨로프를 직렬화하지 않는다는 것을 알기 바란다.

그외 다른 장점은 첨부된 도면을 참조한 다음의 상세한 설명으로부터 명백해질 것이다.

예시적인 동작 환경

도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 도시한 것이다. 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 한 예일 뿐이고, 본 발명의 사용 또는 기능의 범위에 어떤 제한을 가하고자 하는 것은 아니다. 컴퓨팅 환경(100)은 예시적인 동작 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 조합에 관하여 임의의 종속성 또는 요구사항을 갖는 것으로 해석되어서는 안된다.

본 발명은 많은 다른 범용 또는 전용 컴퓨팅 시스템 환경 또는 구성과 함께 동작될 수 있다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경 및/또는 구성의 예로는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 태블릿 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋탑박스, 프로그램가능한 소비자 전자제품, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터, 상기 시스템 또는 장치 중의 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 포함될 수 있지만, 이것에 제한되는 것은 아니다.

본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 일반적으로 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 실행하거나 특정 추상 데이터형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크를 통해 링크되는 원격 프로세싱 장치에 의해 태스크를 실행하는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및/또는 원격 컴퓨터 저장 매체 내에 위치할 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지만, 이것에 제한되는 것은 아니다. 시스템 버스(121)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 제어기를 포함하는 몇가지 유형의 버스 구조 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 인핸스드 ISA(Enhanced ISA; EISA) 버스, 비디오 일렉트로닉스 표준 어소시에이션(VESA) 로컬 버스, 및 메자닌(Mezzanine) 버스로도 알려진 주변 컴포넌트 상호접속(PCI) 버스를 포함하지만, 이것에 제한되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨 터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형(removable) 및 비분리형(non-removable) 매체 둘다 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이것에 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체 둘다 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 컴퓨터(110)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함하지만, 이것에 제한되지 않는다. 통신 매체는 통상적으로 반송파 또는 기타 전송 메카니즘과 같은 변조된 데이터 신호에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하는 것은 같은 방식으로 설정되거나 변경된 특성을 하나 또는 그 이상 갖는 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이것에 제한되지 않는다. 상술한 것들 중의 임의의 조합은 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132)과 같은 휘발성 및/또는 비휘발 성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에 컴퓨터(110) 내의 구성요소들 간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스될 수 있고/있거나 프로세싱 유닛(120)에 의해 현재 동작되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서(제한하고자 하는 것은 아님), 도 1은 운영 체계(134), 응용 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시한다.

컴퓨터(110)는 또한 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1에는 비분리형 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(141), 분리형 비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 분리형 비휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 동작 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD, 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하지만, 이에 제한되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 체계(144), 응용 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 운영 시스템(134), 응용 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 운영 체계(144), 응용 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)는 최소한 다른 복사본임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 통상 마우스, 트랙볼 또는 터치 패드라 불리우는 포인팅 장치(161), 키보드(162), 마이크로폰(163) 및 태블릿 또는 전자 디지타이저(digitizer)와 같은 입력 장치를 통해 컴퓨터(110) 내로 커맨드 및 정보를 입력할 수 있다. 도 1에 도시되지 않은 기타 입력 장치는 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB)와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치는 또한 비디오 인터페이스(190)과 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191)는 또한 터치-스크린 패널 등과 통합될 수 있다. 모니터 및/또는 터치 스크린 패널은 태블릿형 퍼스널 컴퓨터에서처럼, 컴퓨팅 장치(110)를 넣을 수 있는 하우징에 물리적으로 결합될 수 있다는 것을 알기 바란 다. 또한, 컴퓨팅 장치(110)와 같은 컴퓨터는 출력 주변 인터페이스(194) 등을 통해 접속될 수 있는 스피커(195) 및 프린터(196)와 같은 기타 주변 출력 장치를 포함할 수도 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 1에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터(110)에 관하여 상술한 구성요소 중 다수 또는 모든 구성요소를 일반적으로 포함할 수 있다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷 및 인터넷에서 일반적인 것이다. 예를 들어, 본 발명에서, 컴퓨터 시스템(110)은 데이터가 이동되는 소스 기계를 포함할 수 있고, 원격 컴퓨터(180)는 수신지 기계를 포함할 수 있다. 그러나, 소스 및 수신지 기계는 네트워크 또는 임의의 다른 수단에 접속될 필요가 없지만, 그 대신에 데이터는 소스 플랫폼에 의해 기입될 수 있고 수신지 플랫폼 또는 플랫폼들에 의해 판독될 수 있는 임의의 매체를 통해 이동될 수 있다는 것을 알기 바란다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷과 같은 WAN(173)을 통해 통신을 구축하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서(제한하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 응용 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있다.

웹 서비스 애플리케이션 프로토콜 및 SOAP 프로세싱 모델

분산 프로그래밍 모델에서, 기본 프로그래밍 프리미티브(primitive)는 경량(lightweight) 포트로서, 상태를 저장하고 통신을 실행하기 위해 사용될 수 있는 비순서화된 메시지 집합(collection)을 포함한다. 아이템들은 레퍼런스(reference)에 의해 저장되고, 포트들은 (최소한) 2개의 프리미티브 오퍼레이션: Post() 및 Get()을 지원한다. 클래스 인스턴스(class instance)와 같은 아이템의 포스팅(posting)은 레퍼런스를 버퍼링하고, 즉시 복귀시킨다. 공급된 키에 기초한 아이템의 검색은 키를 갖는 아이템이 원격 서비스에 의해 조금도 포스트되어 있지 않으면 폐쇄될 수 있다. 포트들은 서비스에 의해 직접 사용될 수 있지만, 전형적으로, 특정 메시지 유형을 집합 내의 각 포트와 관련시키는 포트 집합의 문맥 내에서 사용된다. 포트 집합은 요구된 융통성 여하에 따라 고정 또는 동적 세트의 지원된 메시지 유형으로 생성될 수 있지만, 프로그래머의 관점에서, 하나의 포트 집합은 단순히 유형화된 포트이다.

본 발명에 따라, 엄격하게 포트 통신을 사용하면, 서비스 코드는 임계 구역(critical sections) 및 복잡한 I/O 프로토콜을 구현하고, 완전 동시 프로세싱 모델을 생성할 수 있다. 이 때문에, 본 발명은 부분적으로, 클라이언트 소비자가 서버 제공자에게 클라이언트를 위한 소정의 서비스를 실행하여 클라이언트에게 적절한 응답을 제공해 달라고 요청하는 웹 서비스와 통신하기 위한 프로토콜(웹 서비스 애플리케이션 프로토콜, 또는 WSAP)에 관한 것이다. 그러나, 알게 되는 바와 같이, 일반적인 웹 서비스 모델은 클라이언트를 위한 소프트웨어를 실행하는 서버에 제한되지 않고, 클라이언트가 액세스하고 싶어하는 임의의 자원에 적용되는데, 예를 들어, WSAP에 의해 지원된 균일 서비스 모델은 파일, 장치, 서비스 및 사람들을 모델링하기 위해 사용될 수 있다. 예를 들어, 하드웨어는 어느 정도까지 컴포넌트화될 수 있어서, 사용자가 하드웨어 컴포넌트 세트를 선택하여 그들을 상호접속해서 컴퓨팅 작업을 실행할 수 있다는 점에서, 여러 방식에서는 사실상 소프트웨어-지향 웹 서비스와 구별이 불가능할 것이다. 각 장치가 통신 프로토콜을 따르는 한, (그리고, 적절한 양의 대역폭이 이용가능하면), 실질적으로 임의의 권한이 부여된 장치는 다른 장치와 통신하여 그 자원을 사용할 수 있다.

도 2는 SOAP(Simple Object Access Protocol) 엔벨로프 내에서 통신된 WSAP 메시지를 통해 웹 서비스(204)와 통신하는 웹 클라이언트 코드(202)(예를 들어, 도 1의 컴퓨터 시스템(110)일 수 있음)를 포함하는 아키텍처(200)를 도시한 것이다. 서비스의 식별자는 명명된 포트(예를 들어, URI)에 의해 설명되고, 서비스의 상태는 전형적으로 XML 스키마에 의해 설명된다. 서비스는 로컬(클라이언트 코드와 동 일한 기계의 내부)일 수 있고, 또는 서버 또는 하드웨어 장치와 같은 원격 자원일 수 있다. 일반적으로, 후술되는 바와 같이, WSAP는 웹 서비스가 하는 일을 의미론적으로 정의하는 반면, SOAP 프로세싱 모델은 다수의 웹 서비스를 동시에 또는 순서대로 실행하도록 구성하는 방법을 정의하고, 예를 들어 메모리내 비XML 직렬화 데이터를 통해, 외부 웹 서비스와 거의 동일한 방식으로 컴퓨팅 장치에 대한 내부 서비스를 구성하도록 본 발명에 따라 사용될 수 있다.

다른 웹 서비스에서와 같이, WSAP-가능 서비스는 웹 서비스 계약 요청(206) 및 계약 제공(208)으로 도 2에 도시되어 있는 바와 같이, 계약 요청에 응답하여 계약을 제공함으로써 동작한다. WSAP에서, 계약을 얻기 위해, 포트는, 후술되는 바와 같이, LOOKUP 오퍼레이션에 대응하여 클라이언트에게 노출된다. 또한 후술되는 바와 같이, 바인딩(binding) 리스트 정보는, 후술되는 바와 같이, 예를 들어, 계약을 "인스턴스화"하는 키/값 쌍의 어레이에 대응하는 식별자/포트로서 응답(208)이 제공된다. 상호작용의 시멘틱이 WSAP 오퍼레이션과 호환성이 있을 때, WSAP 서비스가 WSAP 오퍼레이션을 구현할 수 있을지라도, 서비스들은 LOOKUP 오퍼레이션 이외의 WSAP 오퍼레이션을 구현하도록 요구되지 않는다. 서비스 제공 시에, 서비스 제작자는 WSAP 동사 및 표현을 사용하여 임의의 상호작용 또는 서비스 기능을 매핑할 수 있다. 모든 WSAP 동사가 특정 서비스를 위해 사용되어야 하는 것은 아니고, 그 대신에 시나리오에 따라, 서브셋(subset)이 사용될 수 있다.

본 발명의 한 실시양상에 따르면, WSAP는 식별자, 상태, 및 서비스의 행위에 따라 사용될 수 있는 오퍼레이션 세트와 관련하여 웹 서비스를 정의하는 분산 컴퓨 팅 환경에서 유용한 SOAP 기반 프로토콜이다. 이것은 효과적으로 서비스 및 그들의 상태가 일관되고 관찰가능한 방식으로 동작될 수 있게 한다. WSAP에서, 행위 웹 서비스는 식별자 및 행위를 갖는 프로세스의 추상 개념이다. 이 개념은 다수의 상이한 애플리케이션 모델 및 명칭공간에 적용될 수 있다는 점에서 추상적이다. WSAP는 일반 인터넷에 맞춰 크기 조정이 되도록 설계되어 있는 그러한 한가지 애플리케이션 모델을 정의하는데, 다수의 다른 애플리케이션 모델도 가능하다.

WSAP에서의 식별자의 개념은 종래의 웹 모델에서 URI에 의해 식별된 자원, 즉 식별자를 갖는 임의의 것의 식별자 개념과 유사하다. 식별자의 용도는 서비스가, 동일한 명칭공간 내에 존재할 수 있는 다른 서비스와 자신을 구별할 수 있게 하기 위한 것이다. 여기에서 설명된 바와 같이, WSAP 웹 서비스의 범위는 DNS 또는 IP가 URI "권한(authority)" 컴포넌트를 위한 명명 권한이라는 것을 의미하는 인터넷일 수 있지만, 장치 또는 제한된 네트워크 내에서와 같은 더욱 제한된 범위 내에서는 다른 명명 권한이 가능하다.

각각의 WSAP 웹 서비스는 도 3에 예시된 URI와 같은 유일한 식별자를 갖는다. (웹 상에서와 같은) 임의의 다른 URI에서와 같이, 시멘틱 지식은 URI에만 기초해서는 전혀 얻어지지 않고, 이와 마찬가지로, 2개의 WSAP 웹 서비스들 간의 관계(예를 들어, 포함(containment) 관계)도 그들의 URI로부터 추론될 수 없다. WSAP에서, URI는 상대적 또는 절대적일 수 있다. URI가 상대적이면, 그것의 베이스(base)는 XML 베이스에 의해 결정된다. WSAP는 URI의 길이에 어떤 제한도 두지 않으므로, 임의의 WSAP 수신기는 그것이 발행하는 임의의 URI의 길이를 조정할 수 있어야 되고; WSAP 구현은 최소한 2 킬로바이트 길이의 URI를 다룰 수 있어야 된다.

(프로토콜로서 간주될 수 있는) 서비스들 사이의 상호작용은 서비스의 행위이고, 행위 유형을 사용한 서비스의 설명인 계약을 갖는 행위 유형으로서 형식적으로 기술될 수 있다. 서비스는 구현하기 위한 권리를 주장하는 계약에 따르는 한, 임의의 수의 방식으로 구현될 수 있다. WSAP에서, 하나의 계약은 무엇보다도 본질적으로 하나의 서비스와 유사하고, 따라서 계약들은 포트들(예를 들어, URI들)에 의해 식별되고, 그 계약에 따라 임의의 다른 서비스로서 동작될 수 있다는 것을 알기 바란다.

행위의 개념은 서비스가 발생시키고 수락하는 메시지 유형의 시퀀스와 관련하여 서비스가 그것의 환경과 상호작용하는 방법에 기초하고 있다. 행위는 서비스가 자기의 특정 행위를 동일한 명칭공간 내에 존재할 수 있는 다른 서비스의 행위와 구별할 수 있게 하고, 행위는 서비스가 정의되는 특정 명칭공간을 위해 정의된 가능한 행위들의 세트에 따라 다르다. 즉, 행위는 서비스에 노출된 분산 상태 기계이다. 그러므로, 다른 서비스와의 그들 자원 또는 서비스의 상호작용을 포함함으로써, 행위는 자원을 식별하기 위한 현재의 웹 모델을 증대시킨다. 2개의 서비스는 통신하기 위해 호환가능한 행위들을 가질 필요가 있고; 즉, 그들은 구성되어야 한다. 서비스의 행위가 다른 서비스에 의해 알려지지 않으면, 이것은 2개의 서비스가 상호작용할 수 없다는 것을 암시하는데, 그것은 역참조를 위한 메카니즘이 URI의 홀더에 알려지지 않기 때문에 URI가 역참조될 수 없는 자원의 웹 모델과 유 사하다.

WSAP 서비스 관점에서, 임의의 데이터는 메타데이터든지 데이터든지 서비스로서 표현된다. 즉, (파일과 같은) 동일한 데이터 집합을 판독 또는 실행될 수 있는 단일 엔티티로서 노출하기 보다 오히려, 파일은 상이한 계약을 갖는 상이한 서비스로서 노출된다. 이것은 도 3에 나타나 있는데, 도 3은 각각의 서비스가 자신의 URI를 갖고 있고 상이한 행위들을 갖는 서비스 세트로서 노출된 종래 파일의 데이터(302)를 통해 식별자 및 행위에 있어서의 유일성 개념을 나타낸 것이다. 또한, 도 3에 나타낸 바와 같이, 파일의 행위에 대응하는 서비스들 중에서, 판독 서비스(304), 실행 서비스(306), 메타데이터 조작 서비스(308), 및 다른 서비스들에 대한 이 파일의 관계들의 디렉토리를 판독하는 서비스(310)를 포함한다. 본질적으로, 파일과 관련된 임의의 다른 행위(예를 들어, 기입)도 또한 서비스일 수 있으며, 도 3에 암시적으로 표시된다.

각각 자신의 URI를 갖는 서비스 세트로서의 파일의 노출은 파일이 열린 후에 그 복귀 핸들에 의해 파일 시스템을 통해 파일이 액세스되는 종래의 모델보다 중요한 이점을 제공한다. 예를 들어, 본 발명에서는, 매체 서비스에 대한 URI가 알려지면, 파일에 대한 오퍼레이션이 적절한 서비스를 통해 실행될 수 있어서, 파일 데이터로 어떤 일을 하기 위해 계속 파일 시스템을 통할 필요가 없다. 이것은, 예를 들어 파일 시스템이 다소 멀리있는 서버 상에 있고/있거나 본 발명을 통해 방지될 수 있는 병목현상이 생길 수 있는 분산 컴퓨팅 환경에서 특히 유리하다.

WSAP의 주요 목적은 WSAP 웹 서비스가 무엇인지 및 그것이 식별되는 방법, WSAP 웹 서비스의 행위가 무엇인지 및 그것이 다른 WSAP 웹 서비스와 통신하는 방법, 및 WSAP 웹 서비스가 일반적으로 다른 WSAP 서비스 및 다른 자원에 관련되는 방법을 분석하는 애플리케이션-레벨 프로토콜 프레임워크를 제공하기 위한 것이다. WSAP에 의해 제공된 프레임워크는 메시지 오퍼레이션 및 교환 패턴의 세트를 통해, 식별자 및 행위와 관련하여 행위 웹 서비스의 개념을 의도적으로 제한하지만, 구조 또는 복잡도와 관련해서는 제한하지 않는다. WSAP 웹 서비스는 다수의 다양한 애플리케이션 상황에서 사용될 수 있다. 예를 들어, 도 3의 예에 도시된 서비스로서의 파일의 개념 이외에, 식별자 및 행위에 있어서의 유일성의 다른 간단한 예는, 이를테면 한 장치의 서로 다른 행위들에, 또는 하나의 단순한 채트(chat) 서비스의 서로 다른 행위들에 포트들을 할당함으로써 실행가능하다. 간략하게 하기 위해, 여기에서의 예들은 비교적 로우 레벨의 엔티티 및 서비스를 사용하지만, 이러한 모델은 비즈니스 엔티티 및 그들의 관계와 같은 더욱 복잡한 엔티티에도 동일하게 잘 적용된다는 것을 알기 바란다.

서비스 식별자 및 서비스 행위 이외에, 행위 웹 서비스는 때때로 "서비스 값"으로 언급되는 서비스 상태의 개념을 갖는다. 더욱 구체적으로, WSAP 메시지 오퍼레이션은 서비스의 부분들 또는 하위 부분들(하지만, WSAP 서비스 자체는 아님)을 나타내는 직렬화 상태의 교환을 수반할 수 있다. 서비스의 직렬화 상태는 서비스 유형을 나타내는 행위와 대조적으로, 서비스 값이라 칭해진다. 서비스는 서비스의 행위에 의해 허용되는 임의의 값을 가질 수 있고, 그 값은 시간이 지나면 변화할 수 있다. WSAP는 서비스들을 동작시키고, 서비스의 직렬화 상태를 나타내 는 서비스 표현을 이용한다는 것을 알기 바란다. 서비스는 0 또는 그 이상의 가능한 표현을 가질 수 있고, 즉 서비스가 임의의 표현을 갖지 않는 것도 가능하다. WSAP 오퍼레이션은 서비스 표현의 교환을 수반할 수 있지만, 서비스 자체의 교환을 수반하지는 않는다. 서비스 표현은 시간이 지남에 따라 변화할 수 있고, 표현이 생성되게 한 조건의 함수대로 변화할 수 있다. 애플리케이션들은 서비스의 교환을 통해서가 아니라 표현의 교환을 통해 상호작용한다.

도 4는 서비스 값(403)을 도시한 것으로, 여기에서 서비스 값은 데이터베이스 데이터, 영숫자 데이터, 하우스의 이미지, 또는 플라워의 이미지와 같은 임의의 데이터(예를 들어, 파일의 상태 데이터)일 수 있다. 서비스 관점에서, 동일한 서비스 값은 상이한 상호작용 방식을 갖는 상이한 서비스로서 표현될 수 있다. 상술된 바와 같이, 상이한 행위들이 별개의 서비스로서 모델링되기 때문에, 액세스 권한 및 통신의 속성과 같이 행위에 영향을 미치는 속성은 상이한 서비스를 초래할 수 있다.

도 4에서, 동일한 서비스 값에 대한 상이한 액세스 모델은 판독 전용 액세스, 판독-기입 액세스, 암호화 액세스 및 트랜잭트 액세스를 각각 포함하는 상이한 서비스들(411-414)로서 모델링된다. 종속적인 서비스들 사이의 동기화는 후술되는 WSAP 복제 모델을 사용하여 행해질 수 있다는 것을 알기 바란다.

도 3 및 4를 고려하면, 파일 시스템은 데이터의 다수의 "뷰(view)"를 포함하는 엔티티, 즉 메타데이터(이를테면, 파일명, 길이, 소유권자 및 액세스 권한) 및 데이터(이를테면, 파일 내용)를 포함하는 파일의 한 예라는 것을 알 수 있다. 또 한, 파일의 뷰는 파일을 여는 엔티티의 액세스 권한에 의존하는데, 실제로, 판독 전용 파일의 행위는 판독 기입 파일의 행위와 다르다. 그 자체로, 파일 시스템은 행위 서비스들의 세트로서 용이하게 모델링된다.

일단 서비스들이 호환성있는 계약을 통해 접속되면, 서비스들은 특정 유형의 메시지의 시퀀스를 생성하고 받아들임으로써 서로 상호작용할 수 있다. 이것을 위해, WSAP는 시멘틱과 관련된 메시지 오퍼레이션의 세트를 정의한다. 각각의 메시지 오퍼레이션은 2개의 통신 당사자들 사이에 교환되는 특정 유형의 메시지 세트를 포함한다.

본 발명의 다른 실시양상에 따르면, WSAP는 식별자 및 행위를 결정하는 프레임워크가 메시지 오퍼레이션 및 메시지 교환 패턴의 공유된 세트와 관련하여 정의되는 행위 웹 서비스의 정의에 의거한다. WSAP 메시지 오퍼레이션은 클라이언트 코드(도 2), 전형적으로 응용 프로그램에 의해 정의되고, 하나의 오퍼레이션은 도 5 및 6과 관련하여 후술되는 바와 같이, WSAP에 의해 정의된 메시지 교환 패턴들 중의 하나를 사용한 특정 유형의 메시지 교환을 수반한다. 또한 후술되는 바와 같이, 포트들은 통신을 통해 동기를 제공하고, SOAP는 서비스들 사이에서 교환된 메시지를 위한 프로세싱 모델을 제공한다.

WSAP의 목적은 웹 서비스 및 그들의 상호작용을 정의하기 위한 공용 응용-계층 기초를 제공하기 위한 것이다. SOAP는 다수의 애플리케이션 모델을 지원하도록 설계되고, 애플리케이션은 전범위의 SOAP 확장가능성 모델을 자유롭게 사용한다. 그러나, WSAP의 한가지 목적은 일반적으로 광범위한 분산 애플리케이션에 유용한 애플리케이션 모델을 정의하기 위한 것이다. WSAP의 다른 목적은 높은 정도의 상호운용성을 가능하게 하여, 전체 시스템의 유용성이 잠재적으로 증가할 수 있게 하는 것이다.

이러한 목적 및 그외 목적을 달성하기 위해, WSAP는 공용 메시지 오퍼레이션 세트에 기초하여 웹 서비스 애플리케이션 모델을 정의한다. 웹 서비스에 적용된 공용 어휘의 개념은 지금까지 알려져 있지 않다는 것을 알기 바란다. WSAP는 LOOKUP, QUERY, INSERT, UPDATE, DELETE, GET 및 DROP과 같은 익숙한 이름들로 오퍼레이션의 시멘틱 및 전체 구조를 정의하고, 이로 인해 개별 서비스들은 나중에 바인딩하기 위한 지원을 유지하면서 이들 오퍼레이션의 뒤를 이을 수 있다. 일반적으로, 대문자는 여기에서 WSAP 오퍼레이션을 위해 보통 사용되어, WSAP 오퍼레이션을 종래의 동사와 구별하지만, 오퍼레이션이 대문자를 사용한다는 요구사항은 없고, 더 나아가 그외 다른 또는 다르게 명명된 WSAP 오퍼레이션 세트가 가능하고, 서비스는 그들 자신의 추가 오퍼레이션을 원하는대로 정의할 수 있다.

오퍼레이션은 애플리케이션이 다른 서비스와 통신할 수 있게 한다. 예를 들어, LOOKUP은 GET 및 QUERY가 서비스의 현재 상태를 검색하기 위해 사용될 수 있는 계약의 형태로 서비스에 대한 정보를 제공한다. CREATE 및 DROP 오퍼레이션은 후술되는 바와 같이 서비스를 생성하고 삭제하는 등등을 할 수 있다. 대부분의 오퍼레이션은 개별 서비스가 메시지의 구조를 서비스의 형태에 맞출 수 있도록 메시지의 특정 형태에 관해 다양한 형태를 갖는다. 예를 들어, 디렉토리 서비스에 의해 정의된 INSERT 요청 메시지의 SOAP 바디(Body) 요소는 로더(loader) 서비스에 의해 정의된 INSERT 요청 메시지와 다르지만, 그들은 둘다 동일한 기본 시멘틱을 따른다.

WSAP 메시지 오퍼레이션은 더욱 복잡한 계약 내로 구성될 수 있는 미니 계약으로 간주될 수 있다. 이것은 애플리케이션이 메시지 오퍼레이션을 그들의 특정 요구에 적합한 시퀀스로 결합할 수 있게 함으로써, 더욱 복잡한 서비스를 형성할 수 있게 한다. 즉, WSAP 오퍼레이션 자체는 서비스를 위한 더욱 복잡한 행위들을 정의하도록 구성되고/되거나 순서화될 수 있다. 예를 들어, 서비스는 UPDATE 오퍼레이션 이전에 QUERY 오퍼레이션을 수락하는 것으로 정의될 수 있다(QUERY 및 UPDATE 오퍼레이션은 후술된다). URI는 이와 같이 WSAP 오퍼레이션의 시퀀스를 나타낼 수 있는데, 이것은 URI 자체가 단일 행위 또는 복잡한 행위를 나타낼 수 있다는 것을 의미한다는 것을 알기 바란다. WSAP에 의해 요구되지는 않았지만, 계약은 원하는 구성력을 달성하는데에 상당히 유리하게 사용될 수 있다.

네트워크의 주변에서의 잠재적인 증가된 값 이외에, 가능한 경우의 공유 시멘트의 사용은 전체 시스템의 투명성의 정도를 더욱 높게 할 수 있다. 결과적으로, 캐싱(caching) 및 그외 중간 프로세싱 서비스와 같은 성능 최적화는 인터넷 전반의 시스템에 요구된 범위성(scalability)을 달성하기 위해 시스템 전체에 걸쳐 배치될 수 있다.

더욱 구체적으로, WSAP 오퍼레이션은 캐시 서비스, 부하 분산장치 서비스, 데이터 압축 서비스, 복제 서비스, 암호화/복호화 서비스 등등과 같은 중간자가 메시지를 프로세스할 수 있게 하는 속성을 갖는다. WSAPM 오퍼레이션을 한정하는 그 러한 2가지 속성은 오퍼레이션이 "안전상태(safe)"인지 "멱등상태(idempotent)"인지의 여부를 포함한다. 오퍼레이션은 연속적인 실행의 결과가 오퍼레이션이 실행되는 횟수에 무관할 때 멱등상태이다. 오퍼레이션은 그 시멘틱이 적용되는 자원에 대해 판독 전용 액세스에 제한되는 경우에 안전상태이다. 안전상태 오퍼레이션은 정의에 의해 멱등상태가 되지만, 그 반대는 맞지 않으므로, 판독 전용 오퍼레이션은 안전상태 및 멱등상태라는 것을 알기 바란다. 더욱이, 이들 한정어(qualifier)는 오퍼레이션에 적용되고, 그 오퍼레이션의 특정 구현에 적용되지 않는다는 것을 알기 바란다.

이들 한정어는 오퍼레이션을 시작하는 당사자와 타겟 서비스 사이의 서비스-레벨 기대값을 제공한다. 안전상태 또는 멱등상태 오퍼레이션의 특정 구현은 오퍼레이션의 실행과 관련된 이차적인 부작용(side effects)을 가질 수 있다는 것을 알기 바란다. 그러한 부작용의 전형적인 예는 로깅(logging), 동적 컨텐츠의 경우에 판독 전용 데이터의 생성과 관련된 프로세싱, 상태-관리 갱신 등등이다. 그러한 이차적인 부작용은 안전상태 및 멱등상태 오퍼레이션의 개념에 영향을 미치지 않는다.

결과적으로, 중간자 서비스는 통신에 값을 추가하기 위해 교환 메시지를 프로세스할 수 있다. 예로서, 캐시와 같은 중간자를 고려해보자. 이 예에서, 클라이언트는 데이터로의 액세스를 제공하는 서비스에 접속하고, 응답시, 클라이언트는 캐시에 대한 URI를 수신한다. GET 및/또는 QUERY 요청에 응답하여 데이터를 복귀시키기 위해, 캐시는 데이터의 내용들에 대해, 예를 들어 그것이 내부적으로 포맷 되는 방법, 그것의 암호화 여부 등등에 대해 아무것도 몰라야 되지만, 메시지가 캐시 이면의 하위 자원의 상태를 변경하지 않을 것이라는 것을 프로세싱하는 요청된 오퍼레이션 유형으로부터 알고 있다. 결과적으로, 캐시 서비스는 임의의 GET 및/또는 QUERY 요청을 충족시키기 위해 자신의 캐시 저장장치로부터 데이터를 안전하게 판독할 수 있다. 상태를 변경하라는 요청, 예를 들어 WSAP INSERT, DELETE 또는 UPDATE 오퍼레이션이 수신되면, 캐시 서비스는 메시지를 적절한 URI에 보낼 수 있고, 또는 대안적으로, 클라이언트는, 캐시 서비스가 그것의 일부가 무효라는 것을 통지받게 될 경우에, 상태를 변경하기 위해 상이한 URI를 사용할 수 있다.

본 발명의 다른 실시양상에 따르면, WSAP 오퍼레이션은 2개의 메시지 교환 패턴, 즉 한방향 패턴, 및 최종 응답 도달 전에 중간 응답에 대한 지원을 갖는 요청-응답 패턴에 기초하고 있다. WSAP 메시지는 잠재적으로 멀티캐스트 가능 기반구조를 통해 전달될 수 있지만, WSAP 메시지의 시멘틱은 점대점 통신의 기반구조이다. WSAP는 웹 서비스의 행위를 형식화 방식으로 설명하는데, 이것은 WSAP와 다른 프로토콜 간의 주요한 차이라는 것을 알기 바란다.

도 5 및 6은 각각 한방향 및 요청-응답 메시지 교환 패턴을 사용하는 WSAP 오퍼레이션을 도시한 것이다. 어떤 상황이든, 송신기 및 수신기는 (예를 들어, URL을 통해) 명명된 WSAP 서비스이다. 이것은 요청의 타겟 자원만이 명명되는 HTTP와 같은 클라이언트/서버 프로토콜과 다르다는 것을 알기 바란다.

한방향 메시지 교환 패턴은 도 5에 도시되고, 0개 또는 그 이상의 중간자를 통해 초기 송신기로부터 최종 수신기에게 보내진 메시지를 포함한다. 한방향 메시 지가 (후술되는) SOAP 장애를 발생시키게 되면, SOAP 장애 메시지는 초기 송신기에게 전혀 복귀되지 않는다는 것을 알기 바란다.

요청-응답 메시지 교환 패턴은 도 6에 도시되고, 0개 이상의 중간자를 통해 최종 수신기로부터 초기 송신기에게 보내진 0개 이상의 중간 응답 이전에, 0개 이상의 중간자를 통해 초기 송신기로부터 최종 수신기에게 보내진 요청 메시지를 포함한다. 이러한 메시지 교환 패턴에 부과된 시간 제한은 없으며, 이러한 메시지 교환 패턴을 지원하는 오퍼레이션은 동기 및 비동기 통신 모델에서 사용될 수 있다는 것을 알기 바란다. 더욱이, 요청 메시지가 후술되는 SOAP 장애를 발생시키게 되면, SOAP 장애 메시지는 초기 송신기에게 복귀되지만, 응답 메시지가 SOAP 장애를 발생시키게 되면, SOAP 장애가 발생은 되지만, 응답자에게 보내지지는 않는다는 것을 알기 바란다.

본 발명의 한 실시양상에 따르면, WSAP 오퍼레이션은 SOAP 바디 내용, 이들 메시지 유형의 행위, 및 오퍼레이션을 호출함으로써 수반된 시멘틱으로서 전달된 메시지 유형의 세트를 포함한다. SOAP 메시지를 위해, WSAP 메시지 유형은 전형적으로 SOAP 헤더 블록들로 표현된 SOAP 특징의 확장가능(open-ended) 수로 구성될 수 있다. 그러한 특징의 예는 보안성, 라우팅(routing) 및 신뢰성을 포함하는데, 이것에 제한되지는 않는다.

(IRP 데이터 구조와 같은 몇몇 경우에 사용된) 다음의 C# 클래스는 한가지 구현에서의 SOAP 엔벨로프를 나타낸다:

SOAP 엔벨로프의 핸들링은 메시지 생성, 메시지 교환 및 메시지 문장분석(parsing)을 수반한다. portHeader 포트는 직렬화가능의 또는 엄격하게 내부의 헤더 구조를 교환하기 위해 SOAP 프로세싱 그룹 내의 중간자에 의해 사용된다. 제2 포트인 portBody는 메시지의 바디를 저장한다. 이 컨테이너 내부의 포트들의 사용은 SOAP 엔벨로프의 동시 및 스레드-안전 조작을 허용한다. 엄격한 파이프라인 모델 또는 스택 기반의 모델(종종 SOAP 헤더 블록들 및/또는 SOAP 바디 사이의 상호작용을 처리하는 문제를 가짐)은 요구되지 않는다.

SOAP 프로세싱 모델의 WSAP 기반 구현의 장점은 이것이 SOAP 메시지의 동시 프로세싱을 위한 SOAP 내의 고유한 지원에 맞는다는 것이다. 행위에 대응하는 포트를 통해, 상기 구현은 몇가지 서비스에 의해 메시지의 동시 프로세싱을 용이하게 한다. 예를 들어, SOAP-인식 직렬변환기는 다른 서비스 오퍼레이션과 동시에 주어진 SOAP 메시지의 헤더 및 바디를 직렬화 또는 역직렬화할 수 있다. 이것은 SOAP 엔벨로프의 부분들에 의존하는 서비스들이, 서비스가 관심을 갖는 헤더가 이용가능할 때마다 비블록화할 수 있게 한다. SOAP 역직렬화 자체는 이 동시 문장분석 설계로 인해 원자가 아니다. 더 양호한 성능을 위해, 포워딩 및 전송 서비스는 2개의 통신 당사자가 동일 위치에 배치되면 SOAP 엔벨로프를 전혀 직렬화하지 않는다.

SOAP가 사용되므로, 요청-응답 MEP를 사용한 WSAP 오퍼레이션들 중의 임의의 오퍼레이션 실행 시의 장애는 SOAP 장애 구조를 사용하여 보고되고, WSAP 애플리케이션에 의해 생성된 SOAP 장애는 SOAP Action 요소 정보 아이템을 포함할 필요가 있는데, 그 아이템의 값은 S:Envelope/S:Body/S:Fault/S:Code/S:Value의 값으로 SOAP 장애를 나타낸다. 일반적으로, 장애 당 개별적인 액션들이 있다.

본 발명의 한 실시양상에 따르면, WSAP 메시지 유형이 식별될 수 있다. SOAP 바디의 특정 유형에 신경쓰지 않거나 또는 (예를 들어, 암호화되어 있는 경우에) SOAP 바디의 내용을 볼 수 없는 중간자 및 그 밖의 SOAP 노드는, 예를 들어 WS-Addressing에 의해 전달된 SOAP Action 요소 정보 아이템을 사용할 수 있다. WSAP 오퍼레이션은 유일한 Action 값을 정의한다.

SOAP 바디의 특정 유형에 신경쓰지 않는 SOAP 노드들은 SOAP 바디의 최외측 요소 정보 아이템의 XML 확장명의 유형을 사용할 수 있다. WSAP는 애플리케이션에 의해 정의된 메시지 유형을 대신하게 될 필요가 있는 추상 요소 정보 아이템 세트를 정의한다.

SOAP 장애의 경우, 모델은 유사하지만, SOAP 장애 코드의 사용은 SOAP 장애의 상세에 관심없는 중간자 및 그 밖의 SOAP 노드들이 SOAP 장애 코드를 조사할 수 있다는 점에서 조사성의 추가 레벨을 제공한다.

상술된 오퍼레이션 이외에, 상태의 노출은 모든 서비스에 일관되게 적용될 수 있는 균일한 발행/가입 (pub/sub) 모델뿐만 아니라 캐싱 및 복제와 같은 덜 전통적인 오퍼레이션을 가능하게 한다. 이것은 분산 동작 시스템 노드들 내에서와 노드들을 가로질러서 서비스를 테스트, 모니터 및 관리할 수 있는 일반 애플리케이 션을 구성하는데 사용되었다.

세션도 또한 WSAP 내의 서비스로서 모델링되는데, 세션 관리는 호출자에 따른 값 상태들 간의 구별과 관련된다. 세션 관리의 한 예로서, HTTP 쿠키는 독립적인 HTTP 오퍼레이션을 맞대고 있는 사용자에 따라 웹 페이지를 개인화하기 위해 종종 사용된다. 그러나, 쿠키가 갖는 문제는 서비스의 상태 및 아마도 행위가 행위 웹 서비스 모델과 모순되는 쿠키의 값에 의존한다는 것이다. 그러나, WSAP가 세션을 식별하기 위한 세션 식별자 또는 쿠키를 사용하기 보다 오히려, 세션을 다른 서비스로서 모델링하기 때문에, 세션은 마치 생성되고, 동작되며, 종료되는 임의의 다른 서비스처럼, 상태 및 행위를 갖는 서비스이다.

상술된 서비스 상호작용 이외에, 서비스들은 WSAP 메시지의 실제 교환을 수반하지 않는 방식으로 서로 관련될 수 있다. 그러한 관계의 예는 서비스 세트를 동일한 보안 그룹에 속하는 것으로 설명하는 보안 정책, 및 서비스 세트가 특정 당사자에 의해 관리되는 방법을 설명하는 관리 문장을 포함하는데, 이것에 제한되지는 않는다. 그러한 예의 경우에, 설명들은 서비스 세트에 관련되지만, 설명은 관련된 서비스들 간의 임의의 실제 통신을 수반하지 않는다. 그러나, 교환되고 있는 명시적 WSAP 메시지가 없더라도, 관계들을 캡처하는 것은 여전히 중요하다.

이들 관계를 행위 유형으로서 모델링할 수 있고, 그들을 계약의 일부로서 설명할 수 있다. 이들 계약은 이들 관계 계약을 WSAP 메시지 계약과 구별하기 위해 "그래프 계약"이라 칭해진다. 그래프 계약은 다른 계약과 동일한 설명 언어를 사용하여 설명된다.

공유 시멘틱의 설명과 관련하여, 일반적으로, 서비스는 다른 서비스에 의해 생성된다. 더욱 구체적으로, 서비스는 현존하는 서비스를 복사함으로써 새로운 서비스를 생성하는 CREATE 오퍼레이션을 사용하여 생성될 수 있다. 이 때문에, 새로 생성된 서비스는 생성 서비스의 서비스 행위 및 서비스 값을 갖고, 즉 CREATE 오퍼레이션을 수락하는 서비스는 새로 생성된 서비스의 값에 대한 템플릿으로서 작용한다. CREATE 요청은 새로 생성된 서비스를 초기화하는데 사용되는 추가 상태를 포함할 수 있다. 이것은 서비스가 달리 변경 불가능한 상태로 초기화될 수 있게 한다. CREATE 요청은 서비스의 형태에 따라 새로 생성된 서비스의 복사 상태를 변경하는 상태를 포함할 수 있다. 제안된 종단점을 CREATE 요청의 일부분으로 명명하거나, 이름을 제공하는 생성 서비스를 갖는 것이 가능하다. 기존의 서비스들은 하나의 웹 서비스로서 직접 생성되지 않는 웹 서비스들로서 노출될 수 있다.

WSAP에서, CREATE 오퍼레이션을 지원하는 서비스는 특정 행위의 서비스를 생성할 수 있다. 임의의 서비스는 CREATE 서비스를 지원할 수 있으므로, 원하는 만큼 많은 행위들의 생성을 지원할 수 있다. WSAP 오퍼레이션이 명시적 서비스와 관련되기 때문에, CREATE 오퍼레이션은 타겟 서비스가 새로운 서비스를 생성하기 위한 요청이다. CREATE 오퍼레이션은 타겟 서비스 자체를 생성하지는 않는다.

도 7은 CREATE 오퍼레이션이 하나 이상의 독립적 서비스가 생성될 수 있게 하는 방법을 도시한 것이다. 단순한 서비스 생성에 있어서, CREATE 오퍼레이션은 명시적 초기화 이전의 생성 시퀀스를 통해 단일의 서비스를 생성한다. 도 7에서, 클라이언트(702)는 CREATE 오퍼레이션을 처리하는 서비스(710)로 CREATE 오퍼레이 션을 시작한다. 일반적으로 웹 서비스에서와 같이, CREATE 요청은 서비스 유형이 생성될 계약을 포함한다. 서비스의 생성은 서비스를 위한 URI를 할당하고 서비스를 주어진 행위와 관련시키는 것을 포함한다. 한 서비스가 생성된 후, 추가 메시지 오퍼레이션은 서비스의 구조에 따라 서비스 값을 변경하는 것, 및/또는 관계, 액세스 제어 또는 그 밖의 메카니즘을 통해 새로운 서비스를 다른 서비스와 관련시키는 것을 수반할 수 있다.

응답은 새로 생성된 서비스(720)의 URI를 포함하는 인스턴스화 계약을 포함한다. 서비스는 생성된 후에, 적절하게 다른 서비스에 대한 그것의 행위 및 관계에 따라 동작될 수 있다. 예를 들어, 서비스는 보안 정책을 처리하는 서비스를 조작함으로써 보안 정책과 관련될 수 있다.

다음 표는 WSAP CREATE 오퍼레이션에 대한 속성을 설명한다:

CREATE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/createrequest
응답 액션	http://abc/def/ghij/10/wsap/createresponse
안전상태	아니오
멱등상태	아니오

다음의 데이터 구조는 샘플 CREATE 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 서비스에 의해 정의되고; 응답은 빈 응답을 위해 정의된 편의 유형을 사용한다:

더욱 복잡한 서비스 생성에 있어서, CREATE 오퍼레이션은 관련 서비스 세트를 생성한다. 예를 들어, 복잡한 서비스 생성은 서비스 세트가 항상 함께 존재하는 방식으로 서비스 세트가 관련된다는 것을 생성 서비스가 알고있는 경우에 발생할 수 있다. 도 8은 2개의 서비스의 생성을 예시하는 순서도이다. 도 8에서, 단순한 서비스 생성의 경우에서와 같이, 클라이언트(802)는 CREATE 오퍼레이션을 처리하는 서비스(810)(서비스 A를 생성하는 서비스)로 CREATE 오퍼레이션을 시작한다. 오퍼레이션 요청은 서비스의 유형이 생성될 계약을 포함한다. 서비스 A를 생성하는 서비스(810)는 서비스 B인 다른 새로운 서비스(824)를 생성하기 위해 서비스 B를 생성하는 서비스(812)에 대한 CREATE 오퍼레이션을 시작한다.

서비스 A 및 B(822 및 824)가 생성된 후, 서비스 B를 생성하는 서비스(812)는 서비스 A를 생성하는 서비스(810)에 생성 응답을 보내고, 이번에는 서비스(810)가 클라이언트(802)에게 생성 응답을 보낸다. 서비스 A를 생성하는 서비스(810)에 의해 보내진 생성 응답은 2개의 새로 생성된 서비스(812 및 822)의 URI를 포함하는 인스턴스화 계약을 포함한다. 복잡한 서비스 생성에서, WSAP는 서비스가 트랜잭션 문맥 내에서 생성된다는 고유 보증을 제공하지 않는다. 그러한 보증은 트랜잭션 지원을 갖는 서비스들의 행위를 증대시킴으로써 제공될 수 있다.

상술된 바와 같이, WSAP 서비스의 행위는 계약으로서 설명된다. 계약은 전형적으로 XML 문서로 직렬화되는데, 이것이 요구되지는 않는다. 계약 자체는 서비스이고, 그 자체로, 계약은 URI에 의해 식별되며, 임의의 다른 서비스처럼 그것의 계약에 따라 동작될 수 있다.

한 서비스는 다른 서비스의 URI를 가질수는 있지만, 2개의 서비스가 통신하도록 요구되는 그 서비스의 계약을 갖지는 않는다. 계약을 얻기 위해, WSAP 프로토콜은 모든 서비스가 LOOK 오퍼레이션을 지원할 것을 요구하고, 이 LOOKUP 오퍼레이션은 한 서비스가 다른 서비스에게 계약을 요청할 수 있게 하고, 그로 인해 한 서비스의 행위를 결정할 수 있게 한다.

LOOKUP에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/lookuprequest
응답 액션	http://abc/def/ghij/10/wsap/lookupresponse
안전상태	예
멱등상태	예

다음은 샘플 LOOKUP 오퍼레이션의 SOAP 바디 내용을 나타낸다. 요청 및 응답은 WSAP에 의해 정의된다:

도 9는 클라이언트(902)와 서비스(920) 사이의 LOOKUP 오퍼레이션을 나타내는 샘플 시퀀스를 도시한 것이다. 룩업 응답은, 계약 자체를 복귀시키는 것이 가능할 수 있긴 하지만, 상술된 바와 같이 또한 하나의 서비스인 계약의 URI를 포함 한다.

그러므로, 한 구현예에서, LOOKUP은 URI를, 계약/프로토콜의 직렬화를 포함하는 문서에 복귀시킨다. 하나의 계약은 메시지의 순서를 정의할 뿐만 아니라, 메시지가 교환되는, URI를 갖는 포트로 표시된 상호작용 점을 정의한다. 더욱이, 그 문서는 키/값 쌍의 어레이인 바인딩 리스트에 덧붙여, 계약 문서를 "인스턴스화"하는데 사용된다. 이것은 일반명이 실행시간에 참값에 의해 대체될 수 있게 하고, 서비스들의 인스턴스들 사이의 관계가 실행시간에 결정될 수 있게 하여, 서비스들의 인스턴스들 사이에 반사적인 능력을 제공한다. 계약/바인딩 리스트는 이와 같이 분산 설정시에 종속성의 관리를 가능하게 하고, 이와 동시에, 요구된 서비스를 기동시에 지정한다.

서비스 상태 검색을 위해, WSAP 프로토콜은 GET 및 QUERY라고 하는 2개의 오퍼레이션을 정의한다. 2개의 오퍼레이션은 안전상태 및 멱등상태이지만, GET와 QUERY 오퍼레이션 간의 차이는 후술되는 바와 같이, QUERY 요청은 구조화 조회를 포함하는 반면에, GET 요청은 서비스의 현재 상태의 스냅샷에 대한 애플리케이션-독립적 요청이라는 것이다. 결과적으로, QUERY 요청은 조회되는 서비스에 대한 특정 스키마 지식을 요구하는 반면에, GET 요청은 그것을 요구하지 않는다. 이러한 차이의 결과, QUERY 요청은 (구조화 조회)인 서비스의 이름의 일부분이 아닌 파라미터를 포함하고, GET 요청은 서비스의 이름의 일부분으로서 서비스를 식별하는 파라미터를 제공한다.

QUERY 및 GET를 지원함으로써, WSAP는 불투명 식별자뿐만 아니라 구조화 식 별자를 지원하고, 그러한 솔루션들 사이의 매핑을 가능하게 한다. 이것은 그들의 사용 문맥에 따라, 어느 한가지에 대한 장점이 있기 때문이다. 더욱 구체적으로, 명칭부여 서비스에서, 조회와 같은 구조화 이름을 사용하는 것과 URI와 같은 의미상 불투명한 이름을 사용하는 것 사이에 긴장감이 있다. 예를 들어, 사람들 이름의 구조화 표현을 제공할 수 있는 "http://example.com/people"로 식별된 예시적인 서비스를 고려해보자. 특정한 한 사람은 최소한 3가지 방식으로, 즉 구조화 조회로, URI 조회 컴포넌트 내에 인코딩된 비구조화 조회로, 또는 URI 경로 컴포넌트의 부분인 불투명 식별자로 칭해질 수 있다. 서비스에 대해 발행된 구조화 조회는 예시적인 서비스 "http://example.com/people"에 대해 발행된 구조화 조회의 다음 예에서 표시된 바와 같이, 임의의 특정 사람을 칭하기 위해 서비스의 구조에 대한 지식을 필요로 한다.

이와 대조적으로, URI 조회 컴포넌트의 비불투명 부분으로 인코딩된 비구조화 조회는 전형적으로 URI HTML 형식 인코딩을 사용할 수 있다. 이 모델은 이름-값 쌍의 세트에 대한 지식을 필요로 하지만, 이들 이름-값 쌍을 인코딩하는 URI를 구성하기 위해 특정 서비스에 대한 구조화 지식을 필요로 하지는 않는다. 다음의 예는 URI 조회 컴포넌트 내의 이름-값 쌍과 같은 인코딩된 비구조화 조회를 나타낸다:

http://example.com/people?first=santa&last=claus

URI 경로 컴포넌트의 부분인 불투명 식별자는 실제 분석이 조회를 수반할 수 있다는 것을 드러내지 않는다. 클라이언트가 알 필요가 있는 유일한 것은 이 경우에 HTTP를 사용함으로써 식별자를 분석하는 방법이다. 다음의 예는 임의의 조회 부분을 표현하지 않는 불투명 식별자를 나타낸다:

http://example.com/people/12345678

조회 솔루션의 장점은 조회 파라미터가 강하게 유형화될 수 있다는 것이다. 그러나, 결과는 구조화 조회가 사람에 대한 식별자의 일부분이 된다는 것이다. 이것은, 누구든지 그 사람을 칭하고자 하는 임의의 엔티티는 그 특정 구조화 이름을 사용하고 또한 이해할 필요가 있다는 것을 의미한다. 그 밖의 다른 것을 식별하는 구조화 이름은 또한 사용하기 위해 특별한 지식을 필요로 하는 상이한 형태를 가질 수 있다. 몇몇 경우에, 이것은 특히 사용자가 데이터를 조작하기로 되어 있을 때 잘 된다. 그러나, 특별 지식이 요구되기 때문에, 범위성이 곧 문제가 되는데, 그것은 그 특정 이름 유형에 대한 특정 지식을 갖는 그룹 외측에 이름의 개념을 배치하는 것이 어렵기 때문이다.

식별자들 간의 다른 중요한 차이는 존재하는 데이터-감춤 레벨이다. 더욱 구체적으로, 조회 솔루션은 조회의 구조에 관한 지식을 필요로 하지만, 비구조화의 인코딩된 조회 및 불투명 솔루션은 점점 더 작은 정보를 제공한다. 비구조화의 인코딩된 조회는 공개될 수 있는 키워드가 있는 경우에, 특히 매칭되어야 하는 URI의 수를 감소시키도록 돕는 경우에 사용된다. 그러한 애플리케이션의 전형적인 예는 Google(tm) ("http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=msft") 및 전형적 주식 조회 서비스 ("http://moneycentral.msn.com/scripts/webquote.dll?iPage=qd&Symbol=msft")와 같은 공중 검색 엔진이다.

비구조화의 인코딩된 조회 솔루션은 오늘날 웹 상에서 가장 일반적으로 사용된 식별자 유형이지만, URI 내의 구조화 데이터를 인코딩하는 것이 매우 어렵다. 더욱이, URI의 일부분으로서 인코딩된 데이터는 본질적으로 인프라스트럭처에 공개적이고, 이것은 식별자의 일부분인 임의의 데이터에 대한 보안 관련 문제를 처리하는 것을 어렵게 한다. 불투명 식별자 솔루션은 모델이 조회를 그 식별자에 매핑하기 위해 존재하지 않으면 조회 인터페이스를 지원하지 않는다. 조회의 구조가 (예를 들어, 프라이버시를 위해 또는 다른 이유로) 서비스의 잠재적인 사용자들의 일부에게만 알려지면, 이것은 비구조화의 인코딩된 조회 솔루션 또는 불투명 식별자 솔루션을 사용함으로써 비구조화 데이터의 어떤 부분도 노출하지 않거나 비구조화 데이터의 제한된 부분을 노출함으로써 행해질 수 있다.

그러므로, GET 오퍼레이션은 서비스의 직렬화 값 상태를 검색하기 위해 사용될 수 있고, 다음과 같은 속성을 갖는다:

GET에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/getrequest
응답 액션	http://abc/def/ghij/10/wsap/getresponse
안전상태	예
멱등상태	예

다음 표는 샘플 GET 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 서비스에 의해 정의된다:

QUERY 요청은 몇몇 경우에 GET 오퍼레이션에 매핑될 수 있는데, 예를 들어 그러한 매핑이 특정 조회에 대한 식별자를 효과적으로 제공하는 경우이다. 예를 들어, 이것은 동일한 조회가 다수의 상이한 문맥으로 발생할 때, 또는 URI 레퍼런스가 캐싱을 도입하기 위해 필요로 될 때 이점을 제공했다. 도 10은 QUERY에서 GET로의 매핑을 나타내는 샘플 시퀀스를 도시한 것이다. QUERY 응답은 A에 대한 QUERY와 동일한 결과를 제공할 수 있는 서비스 B의 URI를 포함한다. 매핑은 임의의 서비스에 행해질 수 있고, QUERY가 타겟이 되는 서비스에 관련될 필요가 없다는 것을 알기 바란다.

그러므로, QUERY 오퍼레이션은 또한 서비스의 직렬화 값 상태를 조회하기 위해 사용될 수 있고, 다음과 같은 속성을 갖는다:

QUERY에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/queryrequest
응답 액션	http://abc/def/ghij/10/wsap/queryresponse
안전상태	예
멱등상태	예

다음 표는 샘플 QUERY 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청 및 응답은 서비스에 의해 정의된다:

GET 및 QUERY 오퍼레이션이 안전상태 및 멱등상태이고, 공유 시멘틱의 관찰가능한 성질을 통해 그렇게 될 것이 알려져 있기 때문에, 다양한 중간자들은 메시지 교환에 값을 제공할 수 있다. 예를 들어, 캐시 서비스는 QUERY 및 GET 요청이 상태를 변경하지 않는다는 것을 알고있다. 결과적으로, 캐시는 상태를 변경하는 오퍼레이션이 검출되지 않는 경우 및 그것이 검출될 때까지 언제까지나 그러한 요청에 응답하여 상태 데이터를 계속 제공할 수 있다.

상태 검색 이외에, WSAP는 서비스의 상태가 INSERT, UPDATE 및 DELETE 오퍼레이션을 사용하여 갱신될 수 있게 한다. 이들 오퍼레이션은 서비스의 값에만 적용되고; 그들은 서비스를 생성하지 않거나 종료하지 않는다.

WSAP 서비스의 데이터 구조는 행위의 함수로서 서비스에 의해 정의된다. 결과적으로, INSERT, UPDATE 및 DELETE 오퍼레이션은 QUERY와 유사하게 서비스의 값에 영향을 미치기 위해 요청자가 이 구조에 대한 지식을 가질 것을 요구한다. 그러므로, INSERT, UPDATE 및 DELETE 오퍼레이션은 그들이 개별적인 서비스들에 맞춤화될 수 있도록 추상적으로 정의된다.

서비스의 값이 INSERT 오퍼레이션을 사용하여 변경될 때, INSERT 요청에 포함된 값은 서비스 값에 추가된다. 한 서비스가 분리되어 관찰되고 있다고 하면, INSERT 오퍼레이션의 결과는 일반적으로 도 11의 메시지 순서도에 나타낸 바와 같이, INSERT 오퍼레이션 전에 발행된 GET 오퍼레이션과 INSERT 오퍼레이션 후에 발행된 GET 오퍼레이션 사이의 차이를 고찰함으로써 검출될 수 있다. 도 11에서, 클라이언트(1102)는 INSERT 오퍼레이션 이전에 서비스(1120)로부터 상태 데이터를 수신하고, INSERT 오퍼레이션 다음에 오는 다음 요청시에 갱신된 상태 데이터를 수신한다.

INSERT 오퍼레이션은 다음과 같은 속성을 통해 설명된 바와 같이 서비스에 직렬화 값을 추가하기 위해 사용될 수 있다:

INSERT에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/insertrequest
응답 액션	http://abc/def/ghij/10/wsap/insertresponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 INSERT 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 서비스에 의해 정의된다. 이 예는 데이터가 삽입될 곳의 임의의 순서를 나타내지 않지만, 애플리케이션들은 순서 제한을 수용하도록 그들의 스키마를 정의할 수 있다:

서비스의 구조는 그 서비스에 의해 정의되고, WSAP는 값이 어떤 특정 방식으 로 삽입될 것을 요구하지 않는다. 그 구조의 일부로서, 서비스는 INSERT, UPDATE 및 DELETE 오퍼레이션이, 예를 들어 XPath 표현을 사용하여, 상기 오퍼레이션이 실행될 특정 위치를 식별할 수 있게 한다.

INSERT에서와 같이, 동일한 일반적인 관찰 특성은 DELETE 요청으로 식별되는 서비스 값의 일부가 삭제되는 DELETE 오퍼레이션을 사용하여 서비스의 값이 변경될 때 적용된다. 한 서비스가 분리되어 관찰되고 있다고 하면, DELETE 오퍼레이션의 결과는 일반적으로 도 12에 나타낸 바와 같이, DELETE 오퍼레이션 전에 발행된 GET 오퍼레이션과 DELETE 오퍼레이션 후에 발행된 GET 오퍼레이션 사이의 차이를 고찰함으로써 검출될 수 있다.

다음 표는 DELETE 오퍼레이션에 대한 속성을 나타낸 것이다:

DELETE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/deleterequest
응답 액션	http://abc/def/ghij/10/wsap/deleteresponse
안전상태	아니오
멱등상태	아니오

DELETE 요청은 서비스에 의해 정의되고; 응답은 빈 응답을 위해 정의된 편의 유형을 사용한다:

서비스의 값이 UPDATE 오퍼레이션을 사용하여 변경될 때, UPDATE 요청으로 식별된 서비스 값은 UPDATE 요청에 포함된 값으로 대체된다. UPDATE 오퍼레이션은 트랜잭션 문맥 내에서 보인 경우에 INSERT 이전의 DELETE와 유사하다는 것을 알기 바란다. 즉, UPDATE는 UPDATE 오퍼레이션에 의해 상술된 바와 같이 현존하는 서비스 값이 연속적으로 변경되는 경우에만 계속된다. INSERT 및 DELETE에서와 같이, UPDATE 오퍼레이션의 결과는 일반적으로 도 13에 나타낸 바와 같이, UPDATE 오퍼레이션 전에 발행된 GET 오퍼레이션과 UPDATE 오퍼레이션 후에 발행된 GET 오퍼레이션 사이의 차이를 고찰함으로써 고립하여 검출될 수 있다.

UPDATE 오퍼레이션은 현존하는 값 상태를 갱신하기 위해 사용되고, 다음과 같은 속성을 갖는다:

UPDATE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/updaterequest
응답 액션	http://abc/def/ghij/10/wsap/updateresponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 UPDATE 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청 및 응답 동사는 WSAP에 의해 정의되고; 요청에서와 같이, SOAP 엔벨로프의 바디는 서비스-정의 응답 요소를 포함한다.

이 예에서, 응답은 빈 응답을 위해 정의된 편의 유형이다. WSAP는 현존하는 상태가 식별되는 메카니즘을 지시하지 않고, 그 대신에 그것을 애플리케이션에게 맡긴다. 다음 표는 UPDATE 요청 및 응답의 예시적인 내용을 설명한다:

WSAP에 의해 용이하게 된 다른 오퍼레이션은 분산 서비스들 전반을 통해 동기된 상태를 유지하는 명백하고 투명한 방식을 제공하는 복제(replication)를 수반한다. 이것을 위해, WSAP는 한 서비스가 다른 서비스와 동기될 수 있게 하는 복제 모델을 제공한다. 동기된 2개의 서비스 상태를 유지하기 위해, 복제된 서비스는 복제된 서비스 상에서 실행되는 것과 동일한 복제하는 서비스 상의 오퍼레이션 또는 오퍼레이션들을 실행한다.

일반적으로, REPLICATE, SUBSCRIBE, CANCELREPLICATE 및 UNSUBSCRIBE는 가입자 리스트의 상태를 조작한다. WSAP가 상태를 노출하기 때문에, 가입자 리스트는 다른 WSAP 서비스(예를 들어, subscribeHelper)에서 유지될 수 있다. 주요 WSAP 서비스는 SUBSCRIBE, REPLICATE, CANCELREPLICATE 및 UNSUBSCRIBE 요청을 수신하면 적절하게 삽입/삭제 요청을 보낸다. 주요 서비스에 관한 LOOKUP 응답시에, 바인딩 내에서, 헬퍼가 식별되는데, 이것은 제3자가 서비스의 전체 상태를 캡처할 수 있게 한다. 가입 리스트를 포함한 이 전체 상태는 URI에 의해 표현되는 경우에 눈에 보인다. 가입을 그 자체 상태에 따라 분리함으로써, 제3자는 사라져서 상이한 URI로 재생되는 서비스를 가입자에게 통지할 수 있다.

도 14에 개괄적으로 나타낸 바와 같이, INSERT 오퍼레이션이 가입자(1450)로 부터의 사전의 REPLICATE 요청에 기초하여 복제된 서비스(1430) 상에서 실행되면, 복제된 서비스(1430)는 복제하는 서비스(1440) 상에서 INSERT 오퍼레이션을 실행할 것이다. WSAP 복제 모델의 시멘틱은 NOTIFY 메시지 수신시에 임의의 액션을 실행하기 위한 서비스를 요구하지 않는 WSAP 통지 모델(후술됨)과 다르다는 것을 알기 바란다.

REPLICATE 오퍼레이션은 서비스또는 서비스의 일부를 복제하기 위해 사용될 수 있다. 복제 행위는 요청시에 포함된 계약에 의해 설명된다. 다음 표는 REPLICATE 오퍼레이션에 대한 속성을 설명한다:

REPLICATE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/replicaterequest
응답 액션	http://abc/def/ghij/10/wsap/replicateresponse
안전상태	아니오
멱등상태	예

다음 표는 샘플 REPLICATE 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 서비스에 의해 정의된다. 이 예에서, 응답은 빈 응답을 위해 정의된 편의 유형이다.

복제는 사용될 복제 모델을 설명하는 계약을 포함하는 REPLICATE 오퍼레이션을 발행함으로써 시작된다. 예를 들어, 복제된 서비스는 INSERT 오퍼레이션을 통 해 상태 추가만을 복제하는 복제 모델을 지원할 수 있다. 이 예에서와 같이, 복제하는 서비스는 INSERT 오퍼레이션에만 관계하고 있으면, REPLICATE 오퍼레이션에서 상기 복제 계약을 참고함으로써 그와같이 나타낸다. REPLICATE 요청이 수락되면, 복제된 서비스는 복제하는 서비스에 대해 INSERT 오퍼레이션의 세트로서 그 현재 상태를 전송한다.

도 14에서와 같이, 가입하는 서비스(1450)는 복제하는 서비스(1440)와 다를 수 있다는 것을 알기 바란다. 또한, 복제하는 서비스는 이미 존재하고 소정의 상태를 가질 수 있다. 복제 계약에 따라, 이 상태는 복제가 시작될 때 무효로 되거나 무효로 되지 않을 수 있다. 상기 예에서, 복제 계약이 INSERT 오퍼레이션만을 허용하면, 복제된 상태는 복제하는 서비스의 현존하는 상태에 추가될 것이다.

복제 계약은 몇몇 경우에 저절로 종료될 수 있고, 복제는 만료 시간에 의해 제한되거나, 또는 무기한으로 상태를 계속 복제할 수 있다. 한 구현예에서, 만료는 계약의 일부로서 결정될 수 있지만, 대안적으로 값 파라미터로서 제공될 수 있다.

복제는 또한 CANCELREPLICATION 오퍼레이션을 사용하여 명시적으로 종료될 수 있다. CANCELREPLICATION 오퍼레이션의 샘플 순서도는 도 15에 도시된다. 알 수 있는 바와 같이, 클라이언트(1502)로부터의 초기 삽입 요청은 복제된 서비스(1530)에서 수신되고, 복제하는 서비스(1540)에 복제된다. 가입 해지자 서비스(1552)가 CANCELREPLICATION 오퍼레이션을 요청하면, 설정된 복제는 명시적으로 종료된다. 도 15의 예에서, 클라이언트(1502)로부터의 삽입 요청은 복제된 서 비스(1530)에 의해 복제하는 서비스(1540)로 더 이상 복제되지 않을 것이다.

CANCELREPLICATE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/cancelreplicaterequest
응답 액션	http://abc/def/ghij/10/wsap/cancelreplicateresponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 CANCELREPLICATE 오퍼레이션의 SOAP 바디 내용을 포함한다. 응답은 빈 응답을 위해 정의된 편의 유형이다:

복제 모델 이외에, WSAP는, 상태 변경이 발생했다는 것을 보고하지만 상태 변경이 발생한 상황을 드러내지는 않는 NOTIFY 오퍼레이션에 기초하고 있는 단순한 이벤트 통지 모델을 정의한다. 이벤트 통지 모델의 시멘틱은 복제하는 서비스가 복제된 서비스로부터 보내진 메시지의 결과로서 상태를 변경하는 복제 모델과 다르다는 것을 알기 바란다. 통지 모델에서, 가입자는 NOTIFY 메시지의 수신시에 소정의 액션을 실행하도록 요구되지 않는다. 결과적으로, 가입자가 취하는 소정의 액션은 오로지 그 자신의 시멘틱에 기초하고 있으며, 이벤트 통지 소스의 시멘틱에 기초하지는 않는다. NOTIFY 오퍼레이션은 가입되고, 따라서 만료될 수 있는데, 이것은 값 파라미터를 통해 설정될 수 있는 계약의 일부가 될 수 있다.

NOTIFY 오퍼레이션은 WSAP 통지 모델의 일부이고, 이벤트 통지를 발행하기 위해 사용될 수 있으며, 다음과 같은 속성을 갖는다:

NOTUFY에 대한 속성 시트
속성	값
MEP	한방향
요청 액션	http://abc/def/ghij/10/wsap/notify
안전상태	예
멱등상태	예

다음 표는 샘플 NOTIFY 오퍼레이션의 SOAP 바디 내용을 포함한다:

도 16은 가입자(1650)가 이벤트 소스(1670)에게 요청을 보내는 NOTIFY에 관련된 SUBSCRIBE 오퍼레이션을 도시한 것이다. 요청은 가입자가 상태 변경을 보는데에 관심있는 이벤트 통지 소스의 부분들을 식별하는 조회를 포함한다. SUBSCRIBE 오퍼레이션이 수락되면, 이벤트 통지 소스(1670)는 소스의 현재 상태를 나타내는 NOTIFY 오퍼레이션을 시작한다. 이 초기 NOTIFY 오퍼레이션 후에, 이벤트 통지 소스는 이벤트 통지 소스의 상태가 적절하게 변경할 때마다 새로운 NOTIFY 오퍼레이션을 발행한다. 이벤트 통지 소스의 행위를 설명하는 계약이 애플리케이션 시멘틱에 무관하기 때문에, 그것은 전체적으로 WSAP에 의해 정의된다.

SUBSCRIBE 오퍼레이션은 이와 같이 서비스의 상태 변경을 가입하기 위해 사용되고, 다음과 같은 속성을 갖는다:

SUBSCRIBE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/subscriberequest
응답 액션	http://abc/def/ghij/10/wsap/subscriberesponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 SUBSCRIBE 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 서비스에 의해 정의된다. 이 예에서, 응답은 빈 응답을 위해 정의된 편의 유형이다:

가입은 복제 모델과 유사하게 만료 시간에 의해 제한될 수 있다. 이와 마찬가지로, 가입은 가입 해지자(1752)가 더 이상의 통지를 취소하기 위해 이벤트 소스에 UNSUBSCRIBE 오퍼레이션을 보내는 도 17에 나타낸 바와 같이, UNSUBSCRIBE 오퍼레이션을 사용하여 임의의 시간에 종료될 수 있다.

가입을 취소하는 UNSUBSCRIBE 오퍼레이션은 다음과 같은 속성을 갖는다:

UNSUBSCRIBE에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/unsubscriberequest
응답 액션	http://abc/def/ghij/10/wsap/unsubscriberesponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 UNSUBSCRIBE 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 서비스에 의해 정의된다. 이 예에서, 응답은 빈 응답을 위해 정의된 편의 유형이다:

WSAP 이벤트 통지 모델은 이벤트 통지가 소스에서 싱크(sink)로 푸시되는 종래의 푸시 모델이라는 것을 알기 바란다. 그러나, 메시지 경로에서 버퍼링 중간자를 사용함으로써, 푸시 모델을, 이벤트 통지 싱크에 오프-라인 지원을 제공하는 풀(pull) 모델로 변환하는 것이 가능하다.

서비스 종료의 설명과 관련하여, WSAP 서비스가 종료되면, 더 이상 소정 유형의 메시지를 송신하거나 수신할 수 없다. 서비스는 서비스가 송신 또는 수신할 수 있는 유한 메시지 세트를 설명하는 서비스 행위를 가짐으로써 종료될 수 있다. 서비스는 그 계약을 완수했으면, 종료되고, 그것이 소비한 모든 자원은 회복될 수 있다.

부수적으로, 서비스의 행위는 서비스를 강제로 종료시키는 명시적 상호작용을 정의할 수 있다. 이것을 위해, WSAP는 DROP 오퍼레이션을 정의하고, 이로 인해 계약의 일부로서 DROP을 수락하는 서비스는 명시적으로 종료될 수 있다. 도 18에 나타낸 바와 같이, 클라이언트(1802)와 같은 서비스로부터 DROP 오퍼레이션을 수락할 때, 타겟 서비스(1820)는 단순히 임의의 더 이상의 메시지를 송신하거나 수신하는 것을 중지한다. CREATE 오퍼레이션과 유사하게, DROP은 도 18에서와 같이 단순하게 될 수 있고, 또는 도 20을 참조하여 후술되는 바와 같이 복잡하게 될 수 있다.

DROP 오퍼레이션은 다음과 같은 속성을 갖는다:

DROP에 대한 속성 시트
속성	값
MEP	요청-응답
요청 액션	http://abc/def/ghij/10/wsap/droprequest
응답 액션	http://abc/def/ghij/10/wsap/dropresponse
안전상태	아니오
멱등상태	아니오

다음 표는 샘플 DROP 오퍼레이션의 SOAP 바디 내용을 포함한다. 요청은 WSAP에 의해 정의되고; 응답은 빈 응답을 위해 정의된 편의 유형을 사용한다:

무한한 메시지량이 송신 또는 수신될 수 있게 하고, 서비스가 적절한 방식으로 종료될 수 없는 경우에 종료될 수 있는 명시적 오퍼레이션을 허용하지 않는 서비스 행위가 가능하다는 것을 알기 바란다. 더욱이, 설명된 WSAP 오퍼레이션의 수와 경과 클록 시간 내의 서비스의 수명 사이에는 고유한 관계가 없다는 것을 알기바란다. 기존 서비스에 대한 쓸모없는 레퍼런스가 동일 이름의 새로운 서비스에 적용되지 않게 하기 위해, 서비스 종료 후에 서비스 식별자가 다시 이용되지 않을 것이 권해진다(그러나, 요구하지는 않는다).

몇몇 경우에, 타겟 서비스는 디렉토리 서비스로부터의 등록해지 또는 최종 이벤트 통지의 발송과 같은 소정의 추가 클린업을 실행할 수 있다. 그러한 클린업은 도 19에 DELETE 요청 및 NOTIFY 오퍼레이션으로 나타낸 바와 같이, DROP 오퍼레이션이 종료되기 전에 실행된다.

도 20에 나타낸 복잡한 서비스 종료에 있어서, 다수의 관련된 서비스들은 한 세트로 종료된다. 이것은 서비스들 사이의 관계가 서비스들이 독립적으로 존재할 수 없게 되어 있는 경우에 발생할 수 있다. 복잡한 서비스 종료의 경우에, WSAP는 모든 서비스가 트랜잭션 상황에서 종료된다는 고유한 보증을 조금도 제공하지 못한다. 그러한 보증은 트랜잭션 지원을 갖는 서비스의 행위를 증대시킴으로써 제공될 수 있다.

상기 커맨드로부터, WSAP는 상이한 사이트에서의 상태가 캡처되어 재생성될 수 있게 하기 때문에 서비스가 다시 시작가능하게 되어 동적으로 부하 균형이 맞춰질 수 있게 한다는 것을 알 수 있다. 이것은 트랜잭션, 부하 균형을 구현하기 위해 사용될 수 있고/있거나, 가동시간을 최대로 유지하기 위해 라이브 버전 갱신을하는 데에 사용될 수 있다. 예로서, URI A를 갖는 유형 T의 서비스를 고려해보자. WSAP 커맨드를 통해, 다른 서비스는 A로부터 데이터를 얻고(예를 들어, GET 요청을 통해), 그 종속성을 얻기 위해 A를 조사하며(예를 들어, LOOKUP 요청을 통해), A를 중지(Drop)할 수 있다. 그 다음, URI B를 갖는 유형 T의 서비스를 생성하고, B에 대체(예를 들어, DELETE 및 INSERT)를 실행함으로써, 결과는 A가 중지된 곳으로부터 복제된 완전 동일한 상태 행위이다.

상기 상세한 설명으로부터 알 수 있는 바와 같이, 중간자가 통신에 값을 추가할 수 있도록 효율적이고 안전하면서 관찰가능하고 재사용가능한 방식으로, 한 서비스를 구성하는 엔티티를 포함하여, 클라이언트(서비스) 및 다른 웹 서비스가 웹 서비스와 통신하는 방법과 시스템 및 메카니즘이 제공된다. 그러므로, 본 방법 및 시스템은 현대의 컴퓨팅에 필요한 장점 및 이점을 제공한다.

본 발명은 다양한 변경 및 대안적인 구성을 할 수 있지만, 본 발명의 소정의 예시된 실시예가 도시되고 상세하게 상술되었다. 그러나, 본 발명을 개시된 특정 형태로 제한하고자 하는 것이 아니고, 오히려 본 발명은 모든 변경, 대안적인 구성, 및 본 발명의 정신 및 범위에 속하는 등가물을 망라하여 포함하고자 하는 것 이라는 것을 알기 바란다.

Claims (37)

1. 서비스의 상태 및 행위(behavior)를 나타내는 웹 서비스 애플리케이션 프로토콜(wep service application protocol; WSAP)을 포함하는 컴퓨팅 환경에서 수행되는 방법으로서,

   상기 서비스의 서로 다른 행위들(divergent behaviors)을 결정하는 단계;

   각각의 서로 다른 행위에 식별자를 할당하는 단계 - 상기 식별자는 해당하는 서로 다른 행위에 대응하는 서비스 상태로의 액세스를 제공함 -; 및

   클라이언트 요청에 응답하여 할당된 식별자를 반환하는 단계

   를 포함하고,

   상기 할당된 식별자는 상기 식별자가 할당된 상기 행위를 통해 상기 서비스 상태로의 상기 클라이언트 액세스를 제공하는, 방법.
2. 제1항에 있어서,

   상기 클라이언트에게 계약(contract)을 반환하는 단계를 더 포함하고,

   상기 계약은 상기 서비스가 처리할 수 있는 오퍼레이션들(operations)을 정의하는, 방법.
3. 제2항에 있어서,

   상기 클라이언트에게 계약을 반환하는 단계는 상기 클라이언트에게 문서의 식별자를 제공하는 단계를 포함하는, 방법.
4. 제1항 내지 제3항 중 어느 한 항에 있어서,

   각각의 서로 다른 행위에 식별자를 할당하는 단계는 각각의 서로 다른 행위에 URI를 할당하는 단계를 포함하는, 방법.
5. 제1항 내지 제3항 중 어느 한 항에 있어서,

   상기 할당된 식별자에 기초하여 엔티티에 보낸 클라이언트로부터의 메시지를 수신하는 단계를 더 포함하는 방법.
6. 제5항에 있어서,

   상기 엔티티는 중간자(intermediary)를 포함하고, 상기 중간자는 다른 신뢰 서비스(tursted service)이며,

   상기 방법은,

   상기 중간자에서 상기 메시지를 프로세싱하는 단계를 더 포함하는 방법.
7. 제1항 내지 제3항 중 어느 한 항에 있어서,

   상기 서비스로의 임의의 가입(subscription)이 각기 분리된 상태(seperate state)를 가지도록 식별자들 중의 하나의 식별자는 하나의 가입 리스트에 대응하는, 방법.
8. 제7항에 있어서,

   상기 가입 리스트 상의 가입자에게 통지하는 단계를 더 포함하는 방법.
9. 제7항에 있어서,

   상기 가입 리스트 상의 가입자 서비스에 데이터를 복제함으로써 다른 서비스를 동기화시키는 단계를 더 포함하는 방법.
10. 제1항에 있어서,

    상기 WSAP는 SOAP-기반 프로토콜이고,

    상기 방법은,

    상기 서비스에서, 계약에 대한 요청을 수신하는 단계 - 상기 계약은 상기 서비스가 처리할 수 있는 오퍼레이션들을 정의함 -; 및

    상기 요청에 응답하여 계약 문서의 식별자 및 바인딩 리스트 문서의 식별자를 제공하는 단계를 포함하고,

    상기 계약 문서는 메시지 순서, 및 상기 서비스의 행위들에 대응하는 상호작용 점들(interaction points)의 세트를 포함하는 계약 정보를 포함하고, 상기 바인딩 리스트 문서는 다른 서비스에 대한 상기 서비스의 관계인 서비스 관계 정보를 포함하는, 방법.
11. 제10항에 있어서,

    상기 바인딩 리스트 문서는 상기 서비스를 위한 적어도 하나의 가입 리스트를 유지하는 적어도 하나의 다른 서비스의 식별자를 포함하는, 방법.
12. 제10항에 있어서,

    한 상호작용 점에서 CREATE 요청을 수신하는 단계를 더 포함하는 방법.
13. 제1항에 있어서,

    제1 식별자를 가지는 제1 서비스의 상태를 캡처(capture)하는 단계;

    제2 식별자를 가지는 제2 서비스에서 상기 상태를 재생성하는 단계; 및

    상기 제2 식별자를 통해 상기 상태로의 액세스를 제공하는 단계

    를 더 포함하는 방법.
14. 실행시에 제1항 내지 제3항 및 제10항 내지 제13항 중 어느 한 항의 방법을 수행하는 컴퓨터 실행가능 명령어들을 가지는 적어도 하나의 컴퓨터 판독가능 기록 매체.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제

Images