예제: SOA 모델 예제

문제점 설명 페이지 맨 위로

이 예제에서는 응용프로그램이 사용하는 특정 기능을 재구현하기로 선택한 소매업자의 문제점을 POS(Point of Sale) 터미널에서 서비스로 간주합니다. 오늘날 트레이딩 응용프로그램은 컴포넌트와 밀접하게 결합되지만 일부 컴포넌트는 ISS(In-Store Servers)에 상주하는 단일 응용프로그램으로 개발됩니다. 일부 요청은 ISS에 의해 엔터프라이즈 중심에 위치하는 서버로 전달됩니다. 문제는 일반적으로 상점 하부 구조와 특히 트레이딩 응용프로그램의 경우 컴포넌트가 밀접하게 결합되고 컴포넌트 개발 및 컴포넌트 간 연결에서 전용 프로토콜 및 기술을 사용하여 유지보수가 어렵다는 것입니다.

이전 세대 상점 시스템의 경우, PoS 터미널에 낮은 성능의 자체 시스템을 사용했으며 상점 내부 및 외부 대역폭이 제한적이었습니다. 이러한 제한은 현재 대부분 제거되었습니다. 이러한 점과 엔터프라이즈 백엔드 시스템 내부의 서비스 지향 아키텍처(SOA)로의 기존 이동을 고려하여, ISS 및 중앙 서버에서 제공하는 일부 기능이 트레이딩 응용프로그램 서비스에 제공되는 것으로 결정되었습니다.

프로젝트 범위 및 목적 페이지 맨 위로

현재 여러 데이터 스토어에서 정보를 조회하기 위해 트레이딩 응용프로그램에서 로직이 필요하고 이로 인해 공통 패턴을 공유하므로 먼저 고려할 기능을 선택했습니다. 따라서 제안되는 서비스는 공통 인터페이스를 제공할 뿐만 아니라 데이터 위치에 대한 명시적인 지식과 트레이딩 응용프로그램에서 분리시킵니다. 또한 여러 프로토콜을 처리하지 않아도 됩니다. 이러한 서비스는 트레이딩 응용프로그램에서 ISS 서비스로 RMI를 통해 액세스할 수 있으며 ISS에서 중앙 서비스로는 JMS를 통한 SOAP를 사용합니다.

서비스 식별 페이지 맨 위로

다음은 소매업체의 자체 IT 조직 구성원과 외부 컨설턴트로 구성되는 아키텍처 팀이 수행하는 단계를 설명합니다. 외부 컨설턴트는 서비스 지향 솔루션 개발 분야의 전문가로서 영입된 인력입니다. 아래 단계는 일련의 RUP 권장 활동을 나타내기 위한 것이 아니며 실제 프로젝트의 활동을 목록 형식으로 보여주기 위한 것입니다.

이 프로젝트의 목적은 기존 기능의 기술 구현을 개선하기 위한 것이므로 비즈니스 모델링 또는 분석에 많은 시간을 할애하지 않습니다. 원래 트레이딩 응용프로그램에 대해 작성된 모델을 재사용할 수 있기 때문입니다. 현재 모델 세트(아래 다이어그램의 왼쪽)는 아래 표시된 구조를 따릅니다. 즉, RUP 유스 케이스 모델, 세부 디자인 모델이 따르는 트레이딩 응용프로그램의 공통 컴포넌트에 대한 분석 모델 및 Java 개발 팀의 구현 모델 세트가 표시됩니다.

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

서비스 모델(위 다이어그램의 오른쪽)은 분석 모델을 자체 구현 모델을 갖는 서비스 세트로 정제한 결과로 도입되었습니다. 이제 트레이딩 응용프로그램 디자인을 수정하여 이러한 공통 서비스 사용법을 표시할 수 있으며 트레이딩 응용프로그램과 서비스 Java 모델 간의 관계 또한 표시됩니다.

서비스 모델 작성

상점 지원 서비스 모델은 아래 다이어그램에서 설명하는 대로 소프트웨어 서비스용 UML 프로파일 및 템플리트 모델(Rational Software Architect에 포함)에 따라 작성되었습니다. 이 모델은 위와 같이 분석 모델의 정제로서 식별되었습니다. 그림에서 알 수 있듯이 해당 구조는 템플리트가 권장하는 보기 간의 종속성을 나타내는 개요 다이어그램에 표시됩니다.

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

보기 패키지 옆의 다이어그램 링크를 이용하면 모델을 빠르게 검색할 수 있으며 다음 섹션에서 완성됩니다.

자세한 정보는 도구 사용 도움말 RSA에서 서비스 모델 작성을 참조하십시오.

서비스 파티션 식별(지역성)

위의 문제점 설명에서 알 수 있듯이 시스템 파티션은 여러 가지 방식으로 이해할 수 있습니다. 예를 들어, 인벤토리 관리, 서비스/보증 관리, POS(Point of Sale) 오퍼레이션(가격 찾아보기, 고객 등)을 나타내는 파티션을 도입할 수 있습니다. 그러나 이는 설계자의 주요 관심사항이 아니므로 모델에 추가된 파티션은 상점 내부 또는 엔터프라이즈 레벨에서 제공된 서비스에 대한 논리 지역성을 나타냅니다.

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

논리 파티션의 경우 상점 서비스 파티션에 상점 레벨에서 인스턴스화되는 서비스 세트가 포함되는 것을 알 수 있으며 단일 서버, 클러스터 등 해당 서비스의 실제 배치에 대해서는 언급하지 않습니다. 이러한 논리 파티션은 설계자가 솔루션의 중요 측면을 나타내기 위해 제공됩니다.

또한 위의 그림에서 설계자는 트레이딩 응용프로그램 자체를 추가 요소로 도입하여 응용프로그램과 서비스 간 통신에 대해 설명할 수 있습니다. 트레이딩 응용프로그램은 서비스 이용자로 스테레오타입이 지정된 UML 2.0 컴포넌트입니다.

자세한 정보는 솔루션 파티션 개념을 참조하십시오.

기존 기능 분석

다음 단계에서는 트레이딩 응용프로그램의 현재 구현을 분석하여 위의 문제점 설명에서 식별된 데이터베이스 액세스의 세부사항을 확인합니다. 그 다음에 다음 표가 개발됩니다. 이 표에는 고객 및 인벤토리 찾아보기에 대한 세부사항만 포함되어 있습니다.
 
이름 기술 입력 출력 주석
sp_get_custlist_by_phone SQL Server 스토어드 프로시저 phonenum (char 10) 목록:
custid (id)
custname (char 40)
이 스토어드 프로시저는 고객 세부사항 목록을 전화번호별로 리턴합니다. 고객은 이 목록에서 원하는 내용을 선택할 수 있습니다. sp_get_cust_details 호출은 단일 고객 레코드를 리턴하는 데 사용됩니다.
sp_get_cust_details SQL Server 스토어드 프로시저 custid (id) 고객 레코드 고객 세부사항(이름, 주소, 연락처 정보 등)이 리턴됩니다.
CUST_QUERY IBM MQSeries phonenum (char 10)
return-queue-name (char 120)
correlation-id (char 120)
없음 응용프로그램은 이 대기열에 조회할 고객의 세부사항을 배치합니다. 메시지는 중앙 서버로 전달되며 이 서버는 응답 메시지를 식별된 리턴 대기열에 게시합니다.
<return-queue-name> IBM MQSeries 없음 correlation-id (char 120)
고객 레코드 목록
고객 레코드를 리턴하는 경우 리턴 메시지에는 또한 응답이 해당 요청과 연관될 수 있음을 나타내는 상관 ID가 포함됩니다. 이를 통해 상점 내부 서버는 모든 터미널에 대해 단일 리턴 대기열을 사용할 수 있으며 해당 터미널은 대기열에서 해당 상관 ID를 가진 응답 메시지를 조회합니다.
sp_get_invstate_for_sku SQL Server 스토어드 프로시저 sku (char 13) 인벤토리 레코드
INVENTORY_QUERY IBM MQSeries sku (char 13)
return-queue-name (char 120)
correlation-id (char 120)
없음
<return-queue-name> IBM MQSeries 없음 인벤토리 레코드

위의 표에서 알 수 있듯이 이러한 항목은 기존 구현을 나타내며 기존 구현은 새 구현으로 바뀔 수 있습니다. 그러나 목적 및 기능은 유지됩니다.

초기 서비스 스펙 개발

서비스 식별 활동은 솔루션을 지원하는 데 필요한 서비스 및 서비스에 대한 오퍼레이션을 식별하는 여러 기법을 사용합니다. 이 예제의 경우, 레거시 갱신 양식, 즉 서비스 모델, 특히 서비스 구현 기술로의 기존 기능성 변환을 나타냅니다. 이 작업의 첫 번째 측면은 위에서 설명한 기능을 구현하는 서비스에 대한 계약을 제공할 서비스 스펙 세트를 개발하는 것입니다. 다음 다이어그램은 현재 비어 있는 세 가지 서비스 스펙을 보여줍니다. 해당 스펙은 소개 부분에서 설명한 각 서비스마다 하나씩 이 단계에서 작성됩니다.

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

다음으로 서비스의 가능한 사용법 패턴을 분석합니다. 예를 들어, 실제로 상점 내부와 엔터프라이즈에 하나씩 두 가지 서비스를 사용할 수 있으며 이러한 경우 데이터베이스 액세스 및 엔터프라이즈 액세스에 대한 로직은 모두 상점 내부 서비스에서 캡슐화됩니다. 또는 상점에서 로직을 캡슐화하고 동일한 두 서비스를 호출하는 Facade 서비스를 사용하도록 선택할 수 있습니다. 여기서, 한 서비스는 로컬 데이터베이스 액세스를 캡슐화하고 두 번째 서비스는 엔터프라이즈에 위치합니다. 두 번째 선택을 하는 경우 두 상점에 액세스하는 로직을 유연하게 변경할 수 있지만 동시에 상대적으로 단순한 기능에 대한 오버헤드 및 통신 비용이 추가됩니다. 따라서 고객 찾아보기 및 인벤토리 찾아보기의 경우 첫 번째 옵션을 선택합니다. 그러나 아직 서비스 분배 및 서비스 제공자는 결정되지 않았으므로 서비스 스펙에만 초점을 맞추는 경우 서비스 식별이 보다 효과적입니다.

이러한 서비스의 역할 및 책임을 식별하려면 서비스 협업과 특히 고객 찾아보기 서비스의 구성을 나타내는 UML 2.0 컴포지트 구조 다이어그램을 사용합니다. 이 구조 다이어그램은 아래에 표시되며 협업에서 각 요소를 나타내는 UML 2.0 파트를 확인할 수 있습니다. 트레이딩 응용프로그램과 상점 내부 서비스를 연결하는 커넥터와 상점 내부 서비스와 엔터프라이즈 서비스를 연결하는 커넥터는 서비스 채널로 스테레오타입이 지정되며 사용할 바인딩(위에서 식별된 RMI 또는 JMS)을 표시합니다. 상점 내부 서비스와 로컬 데이터베이스 컴포넌트(이후)를 연결하는 커넥터에 대한 바인딩은 정의되지 않습니다.

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

여기서 다룰 핵심 요소 중 하나는 LocalCustomerLookupProvider가 생성된 서비스라는 점입니다. 즉, 데이터베이스 조회와 관련된 thin 랩퍼 서비스로서, SQL select를 나타내는 단일 오퍼레이션이 있습니다. 이 접근 방식은 상점 내부 고객 찾아보기 서비스에서 데이터베이스에 직접 액세스하기 위해 선택되었습니다. 이 경우 로컬 서비스가 추가 비즈니스 규칙을 포함하거나 나중에 보다 완전한 서비스가 될 수 있습니다.

그러나 이 다이어그램에는 협업 구조만 표시되며 다음 상호작용 다이어그램(UML 2.0 시퀀스 다이어그램)은 서비스 간 실제 통신을 나타냅니다. 서비스 스펙에 getCustomerByPhone 오퍼레이션을 추가했습니다. 또한 UML 2.0은 시퀀스 다이어그램의 선택적 "단편" 스펙을 허용하며 이 경우 로컬 찾아보기에 실패할 때만 엔터프라이즈 서비스와 통신을 수행합니다.

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

정적 구조 및 통신 다이어그램의 조합을 통해 서비스 컴포지션 및 협업을 문서화할 수 있으며 이 경우 서비스 스펙에 대한 단일 오퍼레이션 요구만 식별했습니다.

자세한 정보는 서비스 식별 활동을 참조하십시오.

서비스 디자인 페이지 맨 위로

서비스 식별 활동의 모델을 채택하는 경우 식별한 후보 서비스 세트를 빌드할 서비스의 세부 디자인으로 전이합니다. 첫 번째 단계는 위의 스펙을 실현하는 서비스 스펙을 맵핑하는 것입니다. 위의 모델에서 서비스로 서비스 스펙을 실현하는 방법을 결정할 수 있기 때문입니다. 이 예제의 경우 여러 프로젝트에 공통적인 구조가 아닌 적절한 수준의 단순 구조를 나타냅니다. 이 경우 단일 서비스 제공자가 단일 스펙을 실현(realization)한 단일 서비스를 나타냅니다. 제공자당 여러 서비스를 소유할 수 있습니다. 이 모델에서 서비스 간 사용법 관계에도 유의합니다. 이러한 종속성은 시간 경과에 따른 서비스 전개 방식을 이해하는 데 중요합니다.

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

이 구조에서는 보다 많은 내용을 분배 공간으로 이동할 수 있습니다. 그러나 서비스 제공자는 서비스 모델의 배치 단위를 나타내므로 이 모델은 서비스의 논리 보기입니다. 서비스 제공자는 컴포지트 서비스를 정의하는 데도 필요합니다. 서비스 자체(UML 2.0 포트)는 컴포지션을 설명하는 데 필요한 구조를 소유할 수 없기 때문입니다.

메시지 디자인

위의 서비스 식별 활동에서는 서비스 스펙에 대해 설명하는 오퍼레이션 간에 교환되는 실제 메시지에 대해 설명하지 않았습니다. 이는 매우 일반적인 접근 방식으로서, 세부 메시지 디자인을 나중으로 연기하는 관점에서 서비스 책임을 캡처합니다. 경우에 따라 이 접근 방식이 역전되는 경우도 있으며 이러한 경우 메시지 구조를 미리 알고 오퍼레이션 세트로 집계됩니다.

이 경우 컴포넌트 분석 모델의 일부로 개발된 도메인 모델(이전에 개발된 자산)을 이용할 수 있으며 따라서 메시지 모델이 새로 빌드되지 않고 재사용할 도메인 모델의 서브세트를 식별합니다. 아래 예제는 이러한 관계를 보여줍니다. 여기서, 도메인 클래스는 기술 및 플랫폼을 전혀 인식하지 못하며 반면에 메시지는 서비스 간 전달된 구조인 데이터 전송 오브젝트로 가정됩니다. 따라서 도메인 모델을 변경하는 대신 클래스 구조 "외부"에서 내부 요소로 구성된 메시지를 작성합니다.

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

자세한 정보는 메시지 디자인 개념을 참조하십시오.

서비스 실현(realization) 페이지 맨 위로

이 경우 상점 내부 고객 찾아보기 서비스의 실현(realization)에 초점을 맞춥니다. 이 서비스는 서비스 모델에서 디자인 모델로의 변환에서 일반적인 서비스입니다. 변환 자체는 가이드라인에 문서화되고 해당 결과는 다음 모델 구조에 문서화됩니다.

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

이 모델 역시 디자인 모델이지만 도구를 사용하여 이 모델을 아래와 같은 EJB 구현으로 변환할 수 있습니다. 이 구현은 기본적으로 위의 CustomerByPhone 클래스에서 변환되며 고객을 세부화하는 메시지는 데이터베이스를 조회하는 데 사용되는 엔티티 Bean으로 변환됩니다.

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

자세한 정보는 가이드라인 서비스에서 서비스 컴포넌트로 이동을 참조하십시오.