작성자: Simon Johnston, 설계자, IBM Corporation.
이 문서는 서비스, SOA 및 서비스 지향 솔루션의 모델링을 허용하는 UML 2.0용 프로파일인 소프트웨어 서비스용 UML 프로파일에 대해 설명합니다. 이 프로파일의 목적은 개발 라이프사이클의 여러 활동을 지원하는 서비스를 설명하기 위한 공통 언어를 제공하는 것이며 또한 다른 이해 당사자(stakeholder)에게 보기를 제공합니다. 따라서 예를 들어, 설계자가 논리 파티션을 사용하여 라이프사이클 초기에서 서비스를 자세히 설명함으로써 전체 엔터프라이즈 서비스 포트폴리오를 설명하는 기능을 제공합니다. 이 보기는 서비스 클라이언트와 구현자 간의 계약 기능을 수행하는 구조 및 동작 서비스 스펙을 개발하는 디자이너가 세부화합니다. 디자이너는 메시지 보기를 사용하여 공통 서비스 데이터 정의에 대한 정보 모델을 재사용할 수 있습니다.
이 프로파일은 Rational Software Architect에서 구현되었으며 복잡한 고객 시나리오 모델 개발 및 서비스 지향 솔루션 개발과 관련된 관심사항에 대한 교육에도 성공적으로 사용되었습니다.
다음 다이어그램은 서비스 모델링에서 중요한 개념을 보여주는 모델입니다. 그림과 같이 개념 수가 상대적으로 적으므로 서비스 지향 솔루션 관련 업무를 담당하는 사용자는 모두 숙지해야 합니다. 그러나 이 프로파일이 이 모델의 실현(realization)이기는 하지만 여러 개념이 프로파일의 명확한 스테레오타입이 아닙니다. 예를 들어, 오퍼레이션 또는 프로토콜에 대한 스테레오타입이 없습니다. 오퍼레이션과 프로토콜은 프로파일이 명확하고 제한조건 없이 재사용하는 UML 2.0의 기존 개념입니다.
다음 표에는 UML 프로파일의 스테레오타입에 대한 메타 클래스로 사용되는 UML 2.0 메타 모델의 요소가 나열됩니다.
UML 2.0 메타 클래스 | 스테레오타입 |
---|---|
클래스 | 메시지, 서비스 파티션, 서비스 제공자 |
클래스류 | 서비스 이용자 |
협업 | 서비스 협업 |
커넥터 | 서비스 채널 |
인터페이스 | 서비스 스펙 |
포트 | 서비스, 서비스 게이트웨이 |
특성 | 메시지 첨부 |
다음(클릭 가능) 다이어그램은 UML 2.0 프로파일 다이어그램으로서 프로파일의 실제 세부사항을 보여줍니다. 각 스레테오타입과 해당 메타 클래스는 확장 개념(화살촉 모양 표시)을 사용합니다. 또한 특히 프로파일 요소 간 공통 제한조건을 포함한 일부 제한조건이 모델에 표시될 수 있습니다.
다음 섹션은 현재 정의된 UML 2.0 프로파일 요소의 아웃라인을 설명합니다. 각 섹션은 개별 스테레오타입의 아웃라인을 설명합니다. 각각의 세부사항은 해당 메타 클래스, 특성 및 프로파일 사용 시 적용되어야 하는 제한조건을 지정합니다.
클래스
메시지는 WSDL 스펙에 정의된 개념을
나타냅니다(예: 서비스 및 이용자에게 의미가 있는 실제 데이터의
컨테이너). 메시지에는 오퍼레이션이 포함되지 않을 수 있으며 기타 클래스에
대한 연관 및 특성을 포함할 수 있습니다(특정 도메인 모델의 클래스 가정). 메시지
스테레오타입에는 가정된 해당 인코딩 양식을 표시하는 특성이 포함됩니다(예:
SOAP-literal
, SOAP-rpc
, ASN.1
등).
도구에서의 이 요소 사용은 두 가지 이유로 인해 선택적입니다. 먼저 모델링 수행자가 메시지를 지정하지 않고 오퍼레이션에 대한 매개변수로서 직접 도메인 모델의 요소를 사용할 수 있습니다. 또는 모델링 수행자가 오퍼레이션에 대한 입/출력(I/O) 메시지 세트를 지정하는 규칙을 사용할 수 있습니다. 이러한 경우 모델링 도구는 WSDL로 서비스 설명을 생성할 때의 매개변수와 동일한 입/출력(I/O) 메시지를 구성해야 합니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 인코딩 | 문자열 | 메시지 스키마 생성 시 사용할 플랫폼
인코딩 메커니즘을 표시합니다(예: SOAP-RPC, Doc-Literal, ASN.1 등).
|
특성
이 스테레오타입은 메시지의 일부 컴포넌트가 첨부임을 표시합니다(메시지에 직접 포함되는 경우와 반대). 일반적으로 이 스테레오타입은 상위 레벨 디자인 활동에서 주로 사용되지만, 많은 프로세스 첨부 데이터의 경우 임베드된 메시지 데이터와 구분해야 합니다. 예를 들어, 카탈로그 서비스는 메시지의 첨부 이미지가 아닌 구조화된 메시지의 일부로서 일반 제품 세부사항을 리턴할 수 있습니다. 또한 이미지 인코딩이 2진임을 표시할 수 있습니다(기본 메시지의 텍스트 인코딩과 반대).
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 인코딩 | 문자열 | 메시지 스키마 생성 시 사용할 플랫폼 인코딩
메커니즘을 표시합니다(예: SOAP-RPC, Doc-Literal, ASN.1 등).
|
포트
서비스 모델 요소는 서비스
상호작용(웹 서비스 용어)의 종료점을 제공하는 반면 이
상호작용 정의는 서비스 스펙의 일부입니다. 이 모델에서는
서비스가 제공된 인터페이스뿐만 아니라 콜백 인터페이스와
같은 필수 인터페이스를 식별합니다. 서비스에는
사용될 바인딩을 표시하는 추가 속성이 있습니다(예:
SOAP-HTTP
, SOAP-JMS
등).
없음
커넥터
채널은 서비스 간 통신 경로를 나타냅니다. 상호작용은 채널을 통해 이루어질 수 있지만 채널은 특정 상호작용을 나타내지 않습니다. 웹 서비스 환경의 경우, 각 서비스는 클라이언트가 액세스할 수 있도록 연관된 바인딩을 표시합니다. 모델링 프로파일에서는 서비스 간 또는 서비스와 이용자 간 통신에 대한 바인딩을 표시합니다. 이를 통해 다양한 방식으로 바인딩 요구사항을 이해할 수 있습니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 바인딩 | 문자열 | 서비스 바인딩 생성 시 사용할 플랫폼 바인딩 메커니즘을 표시합니다(예: SOAP-RPC , SOAP-Doc , HTTP-Get 등). |
협업
서비스 협업은 서비스 구현을 기타 서비스의 협업으로 지정하는 방법입니다. 이는 웹 서비스 관점에서 볼 때 서비스 구현 지정 시 BPEL4WS를 사용하는 것과 같습니다. 따라서 서비스 협업을 서비스 동작으로 사용하므로 BPEL과 같은 언어에 생성하려는 경우 다른 구현 특정 제한조건을 포함할 수 있음을 의미합니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 바인딩 | 문자열 | 협업 생성 시 프로세스 구성(choreography)으로 사용할 플랫폼 바인딩 메커니즘을 표시합니다(예: "BPEL", "WSFL" 등). |
클래스류
모든 클래스류(클래스, 컴포넌트 등) 서비스 이용자 역할을 수행하며 다른 서비스를 포함합니다. 이 스테레오타입은 선택적이지만 모델 요소(서비스가 아님)를 서비스 클라이언트로 식별하는 데 활용할 수 있습니다. 반면에 오버헤드로 인해 사용되지 않을 수 있습니다.
없음
없음
포트
서비스 게이트웨이는 서비스와 유사하게 보이지만 서비스 제공자가 아닌 파티션에서만 사용할 수 있습니다. 게이트웨이는 프록시 서비스 기능을 수행하며 프로토콜을 중개하거나 파티션이 사용할 수 있는 인터페이스를 표시하는 데 사용할 수 있습니다. 예를 들어, 하나의 파티션에서 여러 서비스를 구현하더라도 파티션 외부에서는 일부 서비스만 사용할 수 있는 것으로 표시할 수 있으며 이러한 경우 해당 서비스에 게이트웨이가 제공됩니다. 이를 통해, 다른 서비스 또는 파티션이 게이트웨이를 통해 노출되지 않은 서비스에 연결할 수 없습니다.
없음
클래스
파티션은 시스템의 논리 또는 실제 경계를 나타냅니다. 파티션 모델링에 선택적이지만 유용합니다. 예를 들어, 파티션은 전통적인 n-층 응용프로그램의 웹, 비즈니스 및 데이터 층을 나타내는 데 사용할 수 있습니다. 파티션은 또한 실제 경계(예: 기본 데이터 센터, 보조 사이트, 고객 사이트, 파트너 등)를 표시하는 데 사용할 수 있으며 이러한 경우 파티션 교차가 보안, 허용되는 프로토콜, 대역폭 등에 대한 특정 제한조건을 가질 수 있습니다.
파티션은 중첩된 파트(서비스 또는 기타 파티션)를 나타내는 특성만 포함할 수 있습니다. 이는 제한조건으로써, 현재 파티션에 표시될 수 있는 다른 요소가 없습니다.
파티션은 또한 "엄격"이라는 개념을 포함합니다. 즉, 특정 파티션이 해당 파티션과 다른 파티션 간의 모든 통신을 입력된 게이트웨이를 통해서 지정해야 하는 것으로 표시하는 경우 엄격한 파티션이라고 합니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 클래스류 | 문자열 | 이 파티션의 이름 공간 범위를 표시하는 분류 이름 |
클래스
서비스 제공자는 하나 이상의 서비스를 제공하는 소프트웨어 요소입니다. 모델링 관점에서 볼 때 일반적으로 여기에 UML 컴포넌트가 표시되는 것으로 예상하지만 이러한 제한은 임의적인 것이므로 유연성을 확보하기 위해 메타 클래스를 클래스로 표시합니다. 서비스 제공자는 해당 위치에 대한 정보를 캡처하는 특성을 갖습니다. 그러나 이 의미는 구현과 관련이 있습니다. 서비스 제공자 역할을 수행하는 클래스는 속성 또는 오퍼레이션을 직접 나타내지 않고 서비스로 스테레오타입이 지정된 공용 포트만 제공할 수 있습니다. 해당 포트는 서비스 스펙으로 입력됩니다.
구현/플랫폼 특정 위치 특성은 서비스 종료점 이름을
생성하는 데 유용합니다. 예를 들어, WSDL을 사용하는 경우 해당 위치는
http://svc.myco.com/
이며 서비스 이름은 CustInfo
입니다. 이
경우 서비스 종료점 이름은 http://svc.myco.com/CustInfo
로 생성됩니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | allowedBindings | 문자열 | 서비스 연결 시 채널이 사용할 수 있는 플랫폼 바인딩 메커니즘을 표시합니다(예: SOAP-RPC , SOAP-Doc , HTTP-Get 등). |
특성 | 위치 | 문자열 | 제공자 위치. 종료점 이름을 작성하는 생성자가 사용합니다. |
인터페이스
인터페이스 사용은 서비스가 제공하는 오퍼레이션 세트를 표시합니다. 서비스는 여러 인터페이스를 구현할 수 있습니다. 규칙에 따르면 프로토콜 상태 머신 또는 UML 2.0 협업을 해당 스펙에 첨부하여 서비스 스펙에 대한 오퍼레이션 호출 순서를 표시할 수 있습니다. 이러한 동작 스펙을 사용하는 경우 서비스 구현의 유효성은 해당 구조 및 동작의 정적, 동적 스펙에 따라 검증할 수 있습니다. 서비스 스펙은 공용 오퍼레이션만 제공할 수 있습니다.
유형 | 이름 | 유형 | 설명 |
---|---|---|---|
특성 | 공개됨 | 부울 | 이 특성은 서비스를 서비스 저장소에 공개하는 것으로 가정하는지 여부를 표시합니다. UML에서 제공하는 public/private 특성 개념과는 다릅니다. |