브로커가 기존 웹 서비스를 호출함

이 시나리오에서는 브로커가 기존 웹 서비스 구현을 호출합니다.

다이어그램은 메시지 세트로 들여온 웹 서비스의
연관된 WSDL 파일을 보여줍니다. 메시지 세트는 브로커의 플로우에 전개됩니다.

기호에 대한 주요 사항:

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

가능한 사용

설계 단계

  1. WSDL을 들여와서 WSDL에 설명된 SOAP 메시지에 대한 정의를 포함하는 메시지 세트를 작성합니다.
  2. 메시지 플로우를 작성하여 웹 서비스를 호출합니다. 웹 서비스 전송 방식이 HTTP일 경우, HTTPrequest 노드가 사용됩니다. 웹 서비스 전송 방식이 JMS일 경우, 적절한 JMS 또는 WebSphere MQ 노드가 사용됩니다.

런타임

메시지 플로우는 적절하게 형식화된 웹 서비스 요청을 작성하고 웹 서비스를 호출한 후 웹 서비스 응답을 구문 분석합니다.

예 1

이 예에서 브로커는 웹 서비스의 중개자 역할을 수행합니다.

  1. HTTPInput, HTTPRequest, and HTTPReply 노드로 메시지 플로우를 작성합니다.
  2. 웹 서비스 클라이언트가 웹 서비스 요청을 생성합니다. 이 요청은 브로커에 의해 HTTPInput 노드로 보내집니다.
  3. 메시지 플로우는 어떤 방식으로든지 메시지를 처리합니다.
  4. HTTPRequest 노드는 요청을 원래 웹 서비스로 송신하고 응답을 수신합니다.
  5. 플로우는 웹 서비스 응답을 생성하여 HTTPReply 노드에 넣습니다. 응답은 HTTPRequest 노드에 의해 수신된 응답 전체 또는 일부를 근거로 할 수 있습니다.
  6. 브로커는 응답을 웹 서비스 클라이언트로 송신합니다.

WebSphere MQ에 사용되는 다른 응용프로그램이 다른 형식으로 된 정보를 요구하면 메시지 플로우가 예상 웹 서비스 응답을 송신하는 HTTPReply 노드와 플로우 끝으로 계속 진행하기 전에 응용프로그램으로의 전송을 위해 먼저 MQOutput 노드에 전달되도록 메시지에 맞게 메시지 플로우를 배열할 수 있습니다. 메시지를 변환하고(필요에 따라) 메시지 헤더를 조작하려면(예: MQMD 헤더 추가) 적절한 Compute 노드가 필요합니다.

예 2

이 예에서는 브로커가 웹 서비스에 대한 감사를 제공합니다.

  1. Warehouse 노드에 연결된 HTTPInput 노드를 포함하는 메시지 플로우를 설계합니다.
  2. 웹 서비스 클라이언트에서 수신한 입력 메시지는 Warehouse 노드에 의해 데이터베이스에 저장됩니다.
  3. Warehouse 노드는 웹 서비스와 상호작용하는 HTTPRequest 노드로 메시지를 전달합니다.
  4. 응답을 수신하면, HTTPRequest 노드는 HTTPReply 노드로 응답을 전달합니다.
  5. HTTPReply 노드는 웹 서비스 클라이언트에 대한 응답을 생성합니다.

예 3

WebSphere MQ 플로우가 웹 서비스와 상호작용합니다.
HTTP 연결을 통해 웹 서비스에 액세스하는 WebSphere MQ 메시지 플로우를 설계한다고 가정합니다. 예를 들어, 회사 인사 부서용 프로세스를 지원하는 메시지 플로우를 작성합니다. 프로세스가 직원의 ID 번호를 검색하고 이 정보로 메시지를 변경 및 강화해야 합니다. 직원 ID는 웹 서비스를 통해 액세스하는 회사 직원 디렉토리에 유지됩니다.
 이것은
MQInput, Compute1, HTTPRequest, Compute2, MQOutput 노드로 메시지 플로우를 표시합니다. HTTPRequest 노드는 HTTP 연결을 통해 회사 디렉토리 서버와 상호작용합니다.

이 시나리오에서 일반적으로 HTTPRequest 노드 등록 정보의 웹 서비스 응답으로 입력 메시지 바꾸기 선택란을 지우고 동일한 노드의 트리의 응답 메시지 위치 등록 정보에 지정된 메시지 트리의 임시 위치로 회사 디렉토리 서버의 응답을 옮깁니다. Compute2에서 ESQL을 코딩하여 결과 패키지를 풀고 해당 시에 최종 메시지를 보강합니다.

예 4

메시지 플로우가 웹 서비스 중계자의 역할을 수행합니다.
새 인터페이스를 모르는 웹 서비스 클라이언트 대신 인터페이스를 갱신한 웹 서비스와 상호작용하는 메시지 플로우를 설계합니다. 이 새 메시지 플로우를 사용하면 이전의 클라이언트가 보유한 인터페이스를 갱신하지 않고도 새 인터페이스를 사용하여 서버에 액세스할 수 있습니다.
이 플로우는 HTTPInput, Compute1, HTTPRequest, Compute2, HTTPReply 노드가 있는 메시지 플로우를
표시합니다. HTTPRequest 노드는 HTTP 연결을 통해 회사 디렉토리 서버와 상호작용합니다.

Compute1에서 ESQL을 코딩하여 클라이언트 요청을 서버 요청에 맵핑하고 Compute2에서는 서버 응답을 클라이언트 응답에 맵핑하십시오. 이 요청, 응답 및 응답 메시지를 MRM 도메인에서 정의하면 형식간의 변환을 단순화할 수 있습니다.

HTTPRequest 노드를 구성하여 HTTPInput 노드가 수신한 헤더에서 HTTP 헤더를 생성할 수 있으며, 이에 따라 쿠키 및 기타 응용프로그램 특정 헤더가 전달될 수 있습니다. HTTPReply 노드가 동등한 작업을 제공함으로써 생성 클라이언트로 리턴시할 수 있도록 웹 서비스의 응답에서 헤더를 추출합니다. 이를 수행할 경우 HTTPRequest 및 HTTPReply 노드의 적절한 .....에서 디폴트 HTTP 헤더 생성 선택란을 선택하십시오.

대부분의 시나리오에서 원래 요청에는 값이 없으며 서비스의 응답이 클라이언트의 응답 메시지를 생성할 수 있도록만 해야 합니다. 이 경우 HTTPRequest 노드에서 웹 서비스 응답으로 입력 메시지 바꾸기 등록 정보를 선택하십시오. 입력 요청의 데이터를 보존할 경우 이 데이터를 Compute1의 LocalEnvironment에 저장하고 응답에 포함시키도록 Compute2에서 검색할 수 있습니다.

관련 개념
웹 서비스, WSDL 및 메시지 플로우
브로커가 새 웹 서비스 인터페이스를 구현함
브로커가 기존 웹 서비스 인터페이스를 구현함
브로커가 웹 서비스가 아닌 서비스 인터페이스를 새 웹 서비스로 구현함
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ac34530_