3장. 서비스에서 사용하는 논리 메시지 정의

초록

서비스는 해당 작업이 호출될 때 교환된 메시지에 의해 정의됩니다. WSDL 계약에서 이러한 메시지는 message 요소를 사용하여 정의됩니다. 메시지는 부분 요소를 사용하여 정의된 하나 이상의 부분 으로 구성됩니다.

3.1. 개요

서비스의 작업은 작업이 호출될 때 교환되는 논리 메시지를 지정하여 정의합니다. 이러한 논리 메시지는 네트워크를 XML 문서로 전달되는 데이터를 정의합니다. 메서드 호출의 일부인 모든 매개 변수가 포함되어 있습니다. 논리 메시지는 계약의 message 요소를 사용하여 정의됩니다. 각 논리 메시지는 부분 요소에 정의된 하나 이상의 부분 으로 구성됩니다.

메시지에서 각 매개 변수를 별도의 부분으로 나열할 수 있지만 권장 방법은 작업에 필요한 데이터를 캡슐화하는 단일 부분만 사용하는 것입니다.

3.2. messages 및 parameter 목록

서비스에서 노출하는 각 작업에는 하나의 입력 메시지와 하나의 출력 메시지만 있을 수 있습니다. 입력 메시지는 작업이 호출될 때 서비스에서 수신하는 모든 정보를 정의합니다. 출력 메시지는 작업이 완료될 때 서비스에서 반환하는 모든 데이터를 정의합니다. 오류 메시지는 오류가 발생할 때 서비스에서 반환하는 데이터를 정의합니다.

또한 각 작업에는 여러 개의 오류 메시지가 있을 수 있습니다. 오류 메시지는 서비스가 오류가 발생할 때 반환되는 데이터를 정의합니다. 이러한 메시지는 일반적으로 소비자가 오류를 이해하기 위해 충분한 정보를 제공하는 한 부분만 있습니다.

3.3. 레거시 시스템과의 통합을 위한 메시지 설계

기존 애플리케이션을 서비스로 정의하는 경우 작업을 구현하는 메서드에서 사용하는 각 매개 변수가 메시지에 표시되어 있는지 확인해야 합니다. 또한 반환 값이 작업의 출력 메시지에 포함되어 있는지 확인해야 합니다.

메시지를 정의하는 한 가지 방법은 RPC 스타일입니다. RPC 스타일을 사용할 때 메서드의 매개 변수 목록에서 각 매개변수에 대해 하나의 부분을 사용하여 메시지를 정의합니다. 각 메시지 부분은 계약의 형식 요소에 정의된 유형을 기반으로 합니다. 입력 메시지에는 메서드의 각 입력 매개변수에 대해 하나의 부분이 포함됩니다. 출력 메시지에는 각 출력 매개 변수에 대한 한 부분이 포함되어 있으며 필요한 경우 반환 값을 나타내는 파트가 포함되어 있습니다. 매개변수가 입력 및 출력 매개변수 둘 다이면 입력 메시지와 출력 메시지의 일부로 나열됩니다.

RPC 스타일 메시지 정의는 서비스가 Tibco 또는 CORBA와 같은 전송을 사용하는 레거시 시스템을 활성화하는 경우 유용합니다. 이러한 시스템은 절차 및 방법을 중심으로 설계되었습니다. 따라서 호출되는 작업의 매개 변수 목록과 유사한 메시지를 사용하여 모델링할 수 있습니다. RPC 스타일은 또한 노출 중인 서비스와 애플리케이션을 더 깔끔하게 매핑합니다.

3.4. SOAP 서비스에 대한 메시지 설계

RPC 스타일은 기존 시스템을 모델링하는 데 유용하지만 서비스의 커뮤니티는 래핑된 문서 스타일을 적극 권장합니다. 포장된 문서 스타일로, 각 메시지에는 하나의 부분이 있습니다. 메시지의 부분은 계약의 형식 요소에 정의된 래퍼 요소를 참조합니다. 래퍼 요소에는 다음과 같은 특징이 있습니다.

  • 요소 시퀀스를 포함하는 복합 형식입니다.A complex type containing a sequence of elements. 자세한 내용은 2.5절. “복잡한 데이터 유형 정의” 에서 참조하십시오.
  • 입력 메시지의 래퍼인 경우:

    • 각 메서드의 입력 매개 변수에 대해 하나의 요소가 있습니다.
    • 해당 이름은 연결된 작업의 이름과 동일합니다.
  • 출력 메시지의 래퍼인 경우:

    • 각 메서드의 출력 매개 변수와 메서드의 inout 매개 변수에 대해 하나의 요소가 있습니다.
    • 첫 번째 요소는 메서드의 return 매개 변수를 나타냅니다.
    • 해당 이름은 래퍼가 연결된 작업의 이름에 Response 를 추가하여 생성됩니다.

3.5. 메시지 이름 지정

계약의 각 메시지에는 해당 네임 스페이스 내에서 고유한 이름이 있어야 합니다. 다음 명명 규칙을 사용하는 것이 좋습니다.

  • 메시지는 단일 작업에서만 사용해야 합니다.
  • 입력 메시지 이름은 작업 이름에 요청 을 추가하여 구성됩니다.
  • 출력 메시지 이름은 작업 이름에 Response 를 추가하여 구성됩니다.
  • 오류 메시지 이름은 오류 이유를 나타냅니다.

3.6. 메시지 부분

메시지 부분은 논리 메시지의 공식적인 데이터 단위입니다. 각 부분은 부분 요소를 사용하여 정의되며 name 속성 및 해당 데이터 유형을 지정하는 type 속성 또는 요소 특성으로 식별됩니다. 데이터 유형 속성은 표 3.1. “파트 데이터 유형 속성” 에 나열됩니다.

표 3.1. 파트 데이터 유형 속성

속성설명

element="elem_name"

이 부분의 데이터 유형은 elem_name 이라는 요소에 의해 정의됩니다.

type="type_name"

이 부분의 데이터 유형은 type_name 이라고 하는 유형으로 정의됩니다.

메시지는 부분 이름을 재사용할 수 있습니다. 예를 들어 메서드에 참조로 전달되는 매개 변수가 있는 foo 이거나 in/out인 경우 예 3.1. “재사용된 부분” 과 같이 요청 메시지와 응답 메시지 모두에 포함될 수 있습니다.

예 3.1. 재사용된 부분

<message name="fooRequest">
  <part name="foo" type="xsd:int"/>
<message>
<message name="fooReply">
  <part name="foo" type="xsd:int"/>
<message>

3.7. 예제

예를 들어, 개인 정보를 저장하고 직원의 ID 번호를 기반으로 직원의 데이터를 반환하는 방법을 제공하는 서버가 있다고 가정해 보겠습니다. 데이터를 조회하기 위한 메서드 서명은 예 3.2. “personalInfo lookup method” 과 유사합니다.

예 3.2. personalInfo lookup method

personalInfo lookup(long empId)

이 메서드 서명은 예 3.3. “RPC WSDL 메시지 정의” 에 표시된 RPC 스타일 WSDL 조각에 매핑할 수 있습니다.

예 3.3. RPC WSDL 메시지 정의

<message name="personalLookupRequest">
  <part name="empId" type="xsd:int"/>
<message/>
<message name="personalLookupResponse>
  <part name="return" element="xsd1:personalInfo"/>
<message/>

또한 예 3.4. “문서 WSDL 메시지 정의 줄 바꿈” 에 표시된 래핑된 문서 스타일 WSDL 조각에 매핑할 수도 있습니다.

예 3.4. 문서 WSDL 메시지 정의 줄 바꿈

<wsdl:types>
  <xsd:schema ... >
  ...
  <element name="personalLookup">
    <complexType>
      <sequence>
        <element name="empID" type="xsd:int" />
      </sequence>
    </complexType>
  </element>
  <element name="personalLookupResponse">
    <complexType>
      <sequence>
        <element name="return" type="personalInfo" />
      </sequence>
    </complexType>
  </element>
  </schema>
</types>
<wsdl:message name="personalLookupRequest">
  <wsdl:part name="empId" element="xsd1:personalLookup"/>
<message/>
<wsdl:message name="personalLookupResponse">
  <wsdl:part name="return" element="xsd1:personalLookupResponse"/>
<message/>