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. “파트 데이터 유형 속성” 에 나열됩니다.
속성 | 설명 |
---|---|
이 부분의 데이터 유형은 elem_name 이라는 요소에 의해 정의됩니다. | |
이 부분의 데이터 유형은 type_name 이라고 하는 유형으로 정의됩니다. |
메시지는 부분 이름을 재사용할 수 있습니다. 예를 들어 메서드에 참조로 전달되는 매개 변수가 있는 foo
이거나 in/out인 경우 예 3.1. “재사용된 부분” 과 같이 요청 메시지와 응답 메시지 모두에 포함될 수 있습니다.
예 3.1. 재사용된 부분
3.7. 예제 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어, 개인 정보를 저장하고 직원의 ID 번호를 기반으로 직원의 데이터를 반환하는 방법을 제공하는 서버가 있다고 가정해 보겠습니다. 데이터를 조회하기 위한 메서드 서명은 예 3.2. “personalInfo lookup method” 과 유사합니다.
예 3.2. personalInfo lookup method
personalInfo lookup(long empId)
personalInfo lookup(long empId)
이 메서드 서명은 예 3.3. “RPC WSDL 메시지 정의” 에 표시된 RPC 스타일 WSDL 조각에 매핑할 수 있습니다.
예 3.3. RPC WSDL 메시지 정의
또한 예 3.4. “문서 WSDL 메시지 정의 줄 바꿈” 에 표시된 래핑된 문서 스타일 WSDL 조각에 매핑할 수도 있습니다.
예 3.4. 문서 WSDL 메시지 정의 줄 바꿈