브로커가 기존 웹 서비스 인터페이스를 구현함 - 자세한 내용

웹 서비스 클라이언트를 가지고 있으며 브로커를 통해 기존의 비 웹 서비스 기능이 해당 웹 서비스 클라이언트에 사용 가능하도록 하기 위한 전형적인 엔드-투-엔드 시나리오 개요입니다.

기존의 C 또는 Cobol 기반 시스템은 유용하게 웹 서비스로 표시할 수 있는 비즈니스 논리를 제공합니다.

이전 예(브로커가 새 웹 서비스를 구현함 - 자세한 내용)와 같이, 브로커가 기존 시스템의 조작을 호출할 수 있는 메커니즘이 있습니다. (즉, 시스템이 브로커에 인터페이스를 표시합니다.) 일반적으로 기존 시스템은 WebSphere MQ에 대해 사용됩니다. 이는 응용프로그램 데이터를 포함하는 MQ 메시지를 수신하고, 이 메시지를 기본적인 구현으로 디스패치한 후 리턴 값을 MQ 응답으로 패키징함을 의미합니다. 기존 조작에 제공되는 데이터 구조와 기존 조작이 리턴하는 데이터 구조는 C 헤더 파일이나 Cobol 사본에서 정의합니다.

그러나 이 예에서는 웹 서비스의 형태에 대한 제한조건도 있습니다. 즉, 이미 웹 서비스 클라이언트에 대한 WSDL 정의를 가지고 있습니다.

광범위하게 분배된 웹 서비스 클라이언트가 이미 사용자에게 특정 비즈니스 기능에 액세스할 수 있는 권한을 제공했으므로 브로커의 역할은 기존 시스템을 기초로 새로 구현한 시스템에 동일한 인터페이스를 제공하게 되는 시나리오가 있을 수 있습니다. 원래 웹 서비스 제공자가 다른 QOS를 제공하거나 특정 이유로 중단될 수 있습니다.

이전과 같이, 브로커는 WebSphere MQ를 통해 기존 시스템 기능을 호출할 수 있습니다.

시나리오를 구현하려면 다음을 수행하십시오.

  1. 기존의 API 데이터 구조를 들여오십시오(예를 들어, C 임포터를 사용하여). 문서 양식의 WSDL을 사용할 경우, 임포터 마법사가 브로커 모델에서 필요한 전역 요소를 작성하도록 해야 합니다. WS-I(http://www.ws-i.org/ 참조)는 웹 서비스 페이로드(payload)를 네임스페이스로 규정할 것을 권장하므로, 사용자는 들여오기에 대한 대상 네임스페이스를 지정해야 합니다.

    이 단계에서는 기존 조작을 호출할 때 사용할 데이터의 메시지 모델이 수반됩니다.

  2. 기존의 WSDL 파일을 들여와서 예상 인스턴스 문서에 적절한 메시지 모델을 작성하십시오(데이터 구조 들여오기 참조). 플로우는 해당되는 SOAP 요청을 구문 분석하고 필요한 기존 데이터 형식으로(부터) 변환할 것을 요구합니다. 들여온 메시지 정의를 검사하고 ESQL 및/또는 맵핑 편집기를 사용하여 플로우 작성에 도움을 받을 수 있습니다. 범주 파일을 작성하거나 브로커 모델에서 WSDL을 생성하지 않습니다.
  3. WSDL 들여오기 단계의 결과로, 해당되는 SOAP mxsd가 자동으로 메시지 세트에 포함됩니다. 특히 SOAP 인벨로프 mxsd와 필요할 경우 SOAP 인코딩 mxsd가 포함됩니다.
  4. 메시지 플로우를 구현하여 웹 서비스 요청을 수신하십시오. 즉, 웹 서비스 제공자 역할을 수행하십시오. 엔드포인트 노드는 클라이언트에서 사용되는 전송 방식에 따라 HTTP 또는 MQ입니다. 입력 노드 등록 정보는 다음과 같습니다.
    • domain: "MRM"
    • set: SOAP 인벨로프 정의를 포함하는 메시지 세트
    • type: "Envelope"
    • format "XML1"
  5. 플로우에서 호출한 경우, 구문 분석기는 미리 준비된 SOAP mxsd에 의해 정의된 대로 SOAP 인벨로프로 구성되는 논리 트리를 작성합니다. 구문 분석은 SOAP 인벨로프(SOAP 본문 및 헤더) 내의 첨부 지점에서 자동으로 계속되어 메시지 세트의 다른 메시지 정의에 대해 일치시키려고 시도합니다. 필요에 따라 입력 노드에서 유효성 검증을 적용하십시오.

    이 단계에서는 논리 트리가 수반되지만 수신된 SOAP 페이로드(payload)를 알 수 없습니다. HTTP SOAPAction/action 필드를 점검하여 적절한 컨텐츠를 판별할 수 있지만 이는 HTTP에 대해서만 작동합니다. (WS-I에서는 SOAPAction의 사용을 권장하지 않습니다.)

  6. 기존 시스템을 통해 허용되는 페이로드(payload) 메시지에서 필수 메시지로의 단일 맵핑을 제공할 수 있습니다. 예를 들어, 단일 맵핑 정의는 메시지 message1amessage1b를 동일 대상 message2에 맵핑할 수 있습니다.
    또는 각각의 메시지 유형에 대해, 아니면 관련 메시지 유형 그룹에 대해 별도의 맵핑을 제공할 수도 있습니다. 이 방식을 사용하면 관리 가능성 및 재사용 가능성이 높은 맵핑 정의를 얻을 수 있습니다. 단점은 맵핑을 적용하기 전에 수신한 페이로드(payload)를 사용자가 판별해야 한다는 것입니다. 이는 다음과 같이 ESQL로 수행할 수 있습니다.
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    또는 필드 참조를 사용합니다. 예를 들면 다음과 같습니다.
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    컨텐츠가 알려지면, 플로우는 컨텐츠 특정의 Mapping 및/또는 Compute 노드를 가지고 있는 각 분기에 대해 적절하게(예: RouteToLabel) 분기될 수 있습니다. 단순 플로우의 경우에는 모든 논리를 단일 Compute 노드에 보관할 수 있습니다(필요에 따라).

    이제 기존 시스템을 호출하고(일반적으로 WebSphere MQ를 통해) 예상 응답을 검색한 후 웹 서비스 응답을 전달하십시오. 이는 웹 서비스 클라이언트에서 사용하는 데이터 형식과 WebSphere MQ에 대해 사용가능한 기존 시스템에서 사용하는 형식 사이에도 데이터플로우를 맵핑해야 한다는 점을 제외하면 이전 시나리오(브로커가 새 웹 서비스를 구현함 - 자세한 내용)와 유사합니다. 데이터플로우 설계자는 비즈니스 응용프로그램이 적당한 시간 내에 예상 응답을 송신하지 않을 수 있다는 점을 고려해야 합니다.

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