브로커가 새 웹 서비스 인터페이스를 구현함

이 웹 서비스 시나리오에서는, 브로커가 기존 비 웹 서비스 응용프로그램에 대한 웹 서비스 인터페이스를 제공합니다.

다이어그램은 정의 파일을 메시지 세트에
들여오는 기존 응용프로그램을 보여줍니다. 메시지 세트에서 WSDL 파일이 생성됩니다. 메시지 세트는 브로커의 플로우에 전개됩니다. 플로우는
런타임 시 원래의 기존 응용프로그램 및 웹 서비스 클라이언트와 상호작용합니다.

기호에 대한 주요 사항:

이 다이어그램은 다른 다이어그램에 사용되는 기호를
설명합니다. 다른 다이어그램 각각에는 고유한 설명이 있으므로 여기에서 설명하지 않습니다.

이를 간혹 웹 서비스 facade라고 합니다. 웹 서비스 인터페이스의 설계에는 일반적으로 기존 인터페이스의 재그룹화, 제한 또는 향상이 포함되며 기존 WSDL 정의의 제한을 받지 않습니다.

가능한 사용

브로커는 기존 응용프로그램에 대한 웹 서비스 인터페이스를 제공합니다. 선택적으로 요청 감사와 같은 다른 관련 기능도 제공합니다.

시간이 경과하면서 구현은 웹 서비스 클라이언트에 제시되는 인터페이스에 영향을 주지 않고 변경될 수 있습니다.

설계 단계

  1. C 헤더 파일이나 COBOL 사본과 같은 기존 인터페이스 정의를 들여와서 비즈니스 메시지의 메시지 세트를 작성하십시오.
  2. 메시지 세트에서 WSDL 정의를 생성하십시오.
  3. SOAP 툴킷(예:Rational Application Developer)을 사용하여 WSDL을 기초로 적합한 웹 서비스 클라이언트를 작성하십시오.
  4. 웹 서비스를 구현할 메시지 플로우를 개발하십시오.

런타임

메시지 플로우는 웹 서비스 요청을 수신하고 이 요청을 기존 응용프로그램이 예상하는 형식으로 변환한 후 기존 응용프로그램을 호출합니다. 기존 응용프로그램의 응답은 올바른 웹 서비스 응답으로 변환됩니다.

예 1

기존의 CICS 응용프로그램에는 COBOL 사본 인터페이스가 있습니다.

  1. COBOL 사본을 들여와서 메시지 모델을 작성하십시오.
  2. HTTPInput, HTTPReply 및 CICS 노드가 있는 메시지 플로우를 작성하십시오.
  3. HTTPInput 및 HTTPReply 노드를 사용하여 웹 서비스 facade를 제공하십시오.
  4. CICS 노드를 사용하여 원래의 CICS 구현을 호출하십시오.

예 2

메시지 플로우는 웹 서비스로서 호출됩니다.
HTTP를 통해 웹 서비스 클라이언트와 상호작용하도록 기존 메시지 플로우 설계를 수정합니다. 기존의 메시지 플로우가 잘 정의된 입력 메시지를 확보하며 클라이언트가 메시지 플로우 호출 과정에서 WebSphere Message Broker 도구로부터 내보내진 WSDL을 사용할 수 있습니다.

교체 또는 추가 프로토콜로 HTTP를 사용하기 위해 입력 또는 출력에 현재 WebSphere MQ를 사용하고 있는 메시지 플로우 대부분을 적용할 수 있습니다.

이것은 HTTPInput, Compute1, DataUpdate, Compute2, HTTPReply 노드로
메시지 플로우를 표시합니다.

MRM 도메인에서 입력 메시지를 모델화하고 모델에서 WSDL을 생성하거나 일반 XML 또는 XMLNS 도메인 메시지를 처리할 수 있습니다. MRM 도메인에서 메시지를 정의한 경우 HTTPInput 노드를 구성하여 입력 메시지를 유효성 검증할 수 있습니다. 노드는 메시지가 모델과 다를 경우 예외를 생성합니다.

HTTPReply 노드를 구성하여 클라이언트로 송신된 응답 메시지에 대한 디폴트 HTTP 헤더 세트를 생성할 수 있습니다. 이것은 WebSphere MQ 메시지를 처리하는 메시지 플로우를 HTTP 메시지를 처리하는 플로우로 변환하는 데 필요한 수정 작업을 줄일 수 있습니다.

예 3

메시지 플로우는 WebSphere MQ 응용프로그램으로의 액세스를 제공합니다.
웹 서비스 클라이언트에서 요청을 수신하고 응답을 송신하며 HTTP를 통해 통신하도록 적용하지 않는 기존 WebSphere MQ 응용프로그램과 상호작용하는 두 개의 메시지 플로우를 설계합니다.

첫 번째 메시지 플로우는 HTTPInput 노드에서 웹 서비스 클라이언트로부터 인바운드 요청을 수신합니다. 이 플로우에는 일부 방법에 따라 요청을 변환하는 Compute 노드와 수정된 요청을 WebSphere MQ 응용프로그램으로 송신하는 MQOutput 노드가 포함되어 있습니다.

두 번째 메시지 플로우는 MQInput 노드에서 응용프로그램의 응답을 수신합니다. 메시지가 Compute 노드로 전달되며, 이 노드에서는 메시지를 변환한 후 응답으로써 원래의 웹 서비스 클라이언트로 송신하는 HTTPReply 노드로 전달합니다.

각 Compute 노드가 완료한 변환이 사소할 수는 있지만 WebSphere MQ 응용프로그램의 응답이 원래의 요청을 송신한 클라이언트로 리턴될 수 있도록 첫 번째 ESQL 코드가 두 번째 ESQL 코드로 검색된 HTTP 상태 정보를 저장해야 합니다.

이것은 두 개의 메시지 플로우를 표시하며 첫 번째 플로우에는 HTTPInput, Compute1, MQOutput 노드가
있습니다. 두 번째에는 MQInput, Compute2, HTTPReply가 있습니다. 첫 번째 플로우를
종료하는 MQOutput 노드가 메시지를 기존의 응용프로그램에서 서비스를 제공하는 WebSphere MQ 큐에 넣으며
이에 따라 응답이 MQInput 노드에서 서비스를 제공하는 입력 큐에 삽입됩니다.

첫 번째 메시지 플로우가 메시지를 수신하고 필요한 변환을 수행하며 아웃바운드 메시지의 HTTP 요청 ID를 인코드합니다. (원할 경우 요청 ID도 데이터베이스에 저장할 수 있습니다.) HTTPInput 노드가 Destination.HTTP.RequestIdentifier라고 하는 LocalEnvironment 트리에서 필드로써 요청 ID를 제공하며 Compute1이 이 값을 읽고 저장할 수 있습니다.

두 번째 메시지 플로우가 응답 메시지를 수신하여 클라이언트 메시지 형식으로 다시 변환합니다. Compute2가 메시지에서 HTTP 요청 ID를 읽고 이 값을 사용하여 LocalEnvironment.Destination.HTTP.RequestIdentifier를 설정합니다. 메시지가 올바른 HTTP 클라이언트에 근접하도록 HTTPReply 노드가 요청 ID를 사용합니다.

이 시나리오를 구현하기 위해서는 MQMD를 올바르게 핸들링해야 합니다. HTTP를 통해 메시지 플로우로 유입되는 메시지에는 MQOutput 노드로 송신되기 전에 MQMD가 추가되어야 합니다. 또한 WebSphere MQ 상에서 유입되는 메시지는 HTTPReply 또는 HTTPRequest 노드 송신에 앞서 MQMD가 제거되어야 합니다(MQMD를 HTTP 스트림에 포함시키지 않을 경우).

Compute1의 ESQL 모듈에서 다음과 같이 명령문을 포함시키십시오.

SET OutputRoot.XML.A.MessageID =    
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

Compute2의 ESQL 모듈에서 다음과 같이 명령문을 코딩하십시오.

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XML.A.MessageID AS BLOB);
관련 개념
웹 서비스, WSDL 및 메시지 플로우
브로커가 기존 웹 서비스를 호출함
브로커가 기존 웹 서비스 인터페이스를 구현함
브로커가 웹 서비스가 아닌 서비스 인터페이스를 새 웹 서비스로 구현함
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ac34540_