브로커가 새 웹 서비스를 구현함 - 자세한 내용

브로커가 웹 서비스를 구현하는 일반적인 엔드-투-엔드 시나리오의 개요입니다.

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

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

웹 서비스는 기존 시스템이 이미 표시한 조작을 기초로 인터페이스를 제공하는 것입니다. 이 인터페이스는 기존의 모든 조작, 이 조작 중 일부 서브세트 및/또는 복합 조작으로 구성될 수 있습니다.

인터페이스를 정의하려면 다음을 수행하십시오.
  1. 기존 시스템이 제공하는 비즈니스 기능을 살펴보십시오.
  2. 노출할 비즈니스 기능 서브세트를 선택하십시오.
  3. 인터페이스에서 표시할 방법을 결정하십시오(많은 개별 조작으로 또는 몇 개의 다목적 조작으로).
기본적으로 웹 서비스 인터페이스가 RPC 양식인지 또는 문서 양식인지 여부를 결정해야합니다. (웹 서비스, WSDL 및 메시지 플로우WSDL과 메시지 모델과의 관계 참조).
  • RPC 양식 인터페이스는 일반적으로 특정 API에서 제공되는 기본적인 조작 세트에 대해 맵핑되도록 설계되므로 개별 조작(메소드 호출)은 상대적으로 적은 페이로드(payload)를 수반합니다.
  • 문서 양식 인터페이스는 각각 페이로드가 더 큰 몇 개의 조작을 수반할 수 있습니다. 예를 들어, 대출 요청을 표시하는 문서가 될 수 있습니다.
WS-I(http://www.ws-i.org/ 참조)에서는 문서 양식 WSDL만 사용할 것을 권장하지만 이전의 많은 웹 서비스에서는 RPC 양식을 사용하고 있습니다.

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

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

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

  2. WSDL 정의를 생성하십시오. 아직 필요한 메시지 범주를 작성하지 않았으면, 표시할 각 웹 서비스 조작마다 메시지 범주를 작성하고 기존 브로커 메시지를 해당하는 SOAP 역할(입력, 출력 또는 결함)과 연관시키십시오. (메시지 범주 파일에 대한 작업 참조).
    • 문서 양식 WSDL을 선택한 경우 메시지 세트 자체는 수정되지 않습니다.
    • RPC 양식 WSDL을 선택한 경우 각 WSDL 조작의 요청 및 응답에 해당되는 메시지가 작성되어 자동으로 메시지 세트에 추가됩니다.
  3. WSDL 생성 단계에서는 자동으로 메시지 세트에 포함될 적절한 SOAP mxsd(메시지 정의 파일)가 생성됩니다. 특히 SOAP 인벨로프 mxsd 및 (WSDL 양식이 RPC 인코드일 경우) SOAP 인코딩 mxsd가 포함됩니다.
  4. 새 웹 서비스 클라이언트를 작성 중일 경우, 선택한 웹 서비스 클라이언트 기술과 함께 생성된 WSDL을 사용하십시오. WebSphere Message Broker가 아닌 다른 도구(예: Rational Application Developer 또는 .NET)로 이를 수행하십시오.
  5. 메시지 플로우를 구현하여 웹 서비스 요청을 수신하십시오. 즉, 웹 서비스 제공자 역할을 수행하십시오. 엔드포인트 노드는 클라이언트에서 사용되는 전송 방식에 따라 HTTP 또는 MQ입니다. 입력 노드 등록 정보는 다음과 같습니다.
    • domain: "MRM"
    • set: SOAP 인벨로프 정의를 포함하는 메시지 세트
    • type: "Envelope"
    • format "XML1"
  6. 플로우에서 호출한 경우, 구문 분석기는 미리 준비된 SOAP mxsd에 의해 정의된 대로 SOAP 인벨로프로 구성되는 논리 트리를 작성합니다. 구문 분석은 SOAP 인벨로프(SOAP 본문 및 헤더) 내의 첨부 지점에서 자동으로 계속되어 메시지 세트의 다른 메시지 정의에 대해 일치시키려고 시도합니다. 필요에 따라 입력 노드에서 유효성 검증을 적용하십시오.

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

  7. 기존 시스템을 통해 허용되는 페이로드(payload) 메시지에서 필수 메시지로의 맵핑을 제공할 수 있습니다. 예를 들어, 동일 대상 message2에 맵핑된 메시지 message1amessage1b가 있는 단일 맵핑 정의를 가질 수 있습니다.
    또는 각각의 메시지 유형에 대해, 아니면 관련 메시지 유형 그룹에 대해 별도의 맵핑을 제공할 수도 있습니다. 이 방식을 사용하면 관리 가능성 및 재사용 가능성이 높은 맵핑 정의를 얻을 수 있습니다. 단점은 맵핑을 적용하기 전에 수신한 페이로드(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를 통해) 예상 응답을 검색한 후 웹 서비스 응답을 전달하십시오. 데이터플로우 설계자는 비즈니스 응용프로그램이 적당한 시간 내에 예상 응답을 송신하지 않을 수 있다는 점을 고려해야 합니다.

유사한 시나리오는 Web Service Host 샘플을 참조하십시오.

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