가이드라인: 서비스 중개
이 가이드라인은 중개(이용자 요청 또는 프로토콜을 서비스 제공자가 이해할 수 있는 양식으로 변환)를 통해 호환되지 않는 이용자와 서비스 간의 통신을 사용할 수 있는 방법을 설명합니다.
관계
기본 설명

소개

중개는 대립하는 관계자 사이에 개입함으로써 조정 또는 타협을 장려하는 동작입니다. 특히 분산 시스템(일반적인 경우) 및 서비스 지향 솔루션(특별한 경우)에서는 세 가지 공통적인 조정 양식이 필요합니다.

  • 인터페이스 중개: 오브젝트 또는 컴포넌트 기반 시스템의 경우, 중개는 송신측과 수신측 간의 오퍼레이션 정의의 변경입니다. 서비스 지향 솔루션의 경우, 송신측과 수신측의 메시지 컨텐츠/스키마가 일치하지 않는 경우입니다.
  • 프로토콜 중개: 대부분의 일반 오브젝트 또는 컴포넌트 기반 솔루션은 일반적으로 통신용 공통 프로토콜 또는 프로토콜 세트를 기반으로 합니다. 서비스 지향 솔루션의 경우, 전체 솔루션의 프로토콜 혼합이 일반적이며 이는 아키텍처의 장점 중 하나입니다. 서비스 간 통신을 위해서는 메시지가 송신측과 수신측 간의 다양한 프로토콜을 이용해야 합니다.
  • 오퍼레이션 중개: 개발자에게는 이 중개 양식도 익숙할 수 있습니다. 일반적인 전략 패턴과 관련이 있습니다. 컴포넌트는 런타임 매개변수 또는 요청 컨텐츠에 따라 특정 서비스 또는 오퍼레이션의 구현 세트 중에서 하나를 선택할 수 있습니다. 컨텐츠 기반 라우팅이라고도 합니다.

명시적인 중개 컴포넌트를 개발하지 않고도 고급 중개 기능을 제공하는 미들웨어 플랫폼이 증가하고 있습니다. 이러한 경우, 미들웨어가 데이터 구조 또는 통신 프로토콜에서 일치하지 않는 내용을 발견하면 해당 런타임에서 중개를 수행할 수 있습니다. 또한 이러한 플랫폼은 메시지 컨텐츠 및 비즈니스 규칙(특정 이용자 요청의 올바른 구현 선택)을 기반으로 하는 스위치 기능을 수행하는 중개자를 제공할 수 있습니다.

활동의 데이터 중개

메시지 정의가 일치하지 않거나 메시지에 송신측과 수신측 간의 변환이 필요한 연결 서비스의 관점에서 볼 때, UML 2.0 활동이 제공하는 기능을 사용하여 송신측과 수신측 간 변환을 나타낼 수 있습니다. 이 기능은 UML 2.0 동작과 두 조치 간 ObjectFlow를 연관시킴으로써 특정 메시지를 다른 메시지로 전환할 수 있는 재사용가능 변환 동작을 식별할 수 있습니다(특히 UML 2.0 스펙 에지를 따라 전달되는 데이터 토큰 변경 또는 바꾸기 참조).

위에서 설명한 대로 변환은 재사용가능한 요소입니다. 따라서 특정 메시지 유형을 다른 메시지 유형으로 변환한 후 송신 서비스와 수신 서비스 간의 메시지 중개에 필요할 때마다 사용할 수 있습니다. UML은 구조를 읽고 탐색 및 갱신하는 조치 세트를 제공하지만 변환 정의에 사용하기에는 상대적으로 복잡하고 어렵습니다. 변환은 보다 간단한 표시로 링크되거나(XSL/T 언어 고려) 새로운 UML 조치 표현 방법을 제공해야 합니다.

데이터 중개는 구체적인 서비스 반복 패턴으로 간주할 수도 있습니다. 예를 들어, 하나 이상의 데이터 변환을 구현하는 명시적인 중개 서비스가 존재합니다. 이러한 경우 중개자는 아래와 같이 이용자가 보낸 메시지에 응답하여 메시지를 변환하고 서비스로 전달해야 합니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

서비스 게이트웨이에 대한 프로토콜 중개

반면에 프로토콜 중개는 잘 알려져 있으며 모델에서 명시적으로 지원됩니다. 프로토콜 정보는 서비스 채널에 대한 바인딩으로 지정되므로 추가 <<서비스>> 또는 프로토콜 스펙을 변경하는 <<서비스 게이트웨이>> 모델 요소를 도입할 수 있습니다. 예를 들어, 다음 컴포지트 구조 다이어그램에는 각각 웹 환경 서비스와 내부 서비스마다 하나씩 두 개의 파티션이 표시됩니다. 또한 웹 환경 서비스에 일반적인 "HTTP-SOAP" 바인딩을 사용한 서비스 채널이 파티션 간에 존재합니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

문제는 필수 성능 레벨 및 기타 비기능적 요구사항을 지원하기 위해 내부 파티션의 모든 통신이 플랫폼 특정 프로토콜을 통해 이루어져야 한다는 것입니다. 다음 다이어그램은 Java RMI 프로토콜을 사용하여 서비스 게이트웨이 "Port : ISvcTwo"에 서비스를 연결하는 방법을 보여줍니다. 이와 함께 HTTP-SOAP를 사용하여 동일한 게이트웨이에 웹 파티션을 연결하는 방법도 이해해야 합니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

해당 방법은 서비스 게이트웨이가 메시지 구조 및 호출의 형식을 변환하여 프로토콜을 중개하는 것입니다. 이는 ORB(Object Request Broker) 또는 메시지 브로커와 같은 미들웨어가 일반적으로 제공하는 공통 기능성입니다. 실제로, 필요한 경우 위의 모델에서 이러한 미들웨어로 생성할 수 있습니다. 또는 웹 파티션에서 호출하여 포함된 서비스로 다시 보내는 서비스로서 "Port : ISvcTwo"를 구체화할 수 있습니다.

또한 해당 중개를 서비스 게이트웨이가 아닌 서비스로서 명시적으로 모델링할 수 있습니다. 이 서비스는 이용자측 바인딩과의 올바른 인터페이스를 나타내고 다른 바인딩을 사용하여 제공자 서비스에 구현을 위임합니다.

서비스 컴포지션을 사용하여 호출 중개

소개 부분에서 설명한 대로, 일반적으로 특정 서비스가 특정 오퍼레이션을 위해 다른 서비스에 의존하는 구조를 정의할 수 있습니다. 그러나 특정 요청에 대해 호출될 실제 서비스는 요청에 임베드된 세부사항, 해당 요청자 및 이 정보를 사용하여 적용되는 비즈니스 규칙에 의존합니다. 이와 관련된 일반적인 예는 고객 요청이며 수신 서비스는 고객 레벨을 기반으로 두 구현 중 하나를 선택할 수 있습니다. 예를 들어, 많은 비용을 지출하는 고객을 우선적으로 처리할 수 있습니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

앞에서 설명한 것처럼, 이러한 유형의 중개에서는 실제 오퍼레이션 구현의 하나 이상의 제공자를 선택하는 데 사용되는 규칙을 구체화해야 합니다. 위의 다이어그램에는 중개 서비스에 첨부된 규칙 컴포넌트로 표시됩니다. 또한 중개자, 규칙 및 모든 구현자가 별도 서비스인 서비스 세트로 솔루션을 빌드할 수 있습니다. 다음 다이어그램을 참조하십시오.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

위와 같이, 중개 컴포넌트는 실현된 해당 서비스 스펙뿐만 아니라, 컴포넌트가 중개하는 모든 서비스에서 구현해야 하는 서비스 스펙을 소유합니다. 이를 통해 서비스의 컴포지트 구조(위에 표시)와 아래 표시된 동적 동작을 모두 정의할 수 있습니다. 위의 구조에서, 중개 서비스를 나타내는 파트는 필수 인터페이스로 나타나며 무한대의 다중성으로 표시됩니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

또한 이러한 유형의 컨텐츠 기반 또는 규칙 기반 메시지 라우팅은 솔루션 아키텍처의 일부로 선택한 미들웨어 플랫폼에서 수행할 수 있습니다.