이전 세대 상점 시스템의 경우, PoS 터미널에 낮은 성능의 자체 시스템을 사용했으며 상점 내부 및 외부 대역폭이 제한적이었습니다. 이러한 제한은 현재 대부분 제거되었습니다. 이러한 점과 엔터프라이즈 백엔드 시스템 내부의 서비스 지향 아키텍처(SOA)로의 기존 이동을 고려하여, ISS 및 중앙 서버에서 제공하는 일부 기능이 트레이딩 응용프로그램 서비스에 제공되는 것으로 결정되었습니다.
이 프로젝트의 목적은 기존 기능의 기술 구현을 개선하기 위한 것이므로 비즈니스 모델링 또는 분석에 많은 시간을 할애하지 않습니다. 원래 트레이딩 응용프로그램에 대해 작성된 모델을 재사용할 수 있기 때문입니다. 현재 모델 세트(아래 다이어그램의 왼쪽)는 아래 표시된 구조를 따릅니다. 즉, RUP 유스 케이스 모델, 세부 디자인 모델이 따르는 트레이딩 응용프로그램의 공통 컴포넌트에 대한 분석 모델 및 Java 개발 팀의 구현 모델 세트가 표시됩니다.
자세한 정보는 도구 사용 도움말 RSA에서 서비스 모델 작성을 참조하십시오.
또한 위의 그림에서 설계자는 트레이딩 응용프로그램 자체를 추가 요소로 도입하여 응용프로그램과 서비스 간 통신에 대해 설명할 수 있습니다. 트레이딩 응용프로그램은 서비스 이용자로 스테레오타입이 지정된 UML 2.0 컴포넌트입니다.
자세한 정보는 솔루션 파티션 개념을 참조하십시오.이름 | 기술 | 입력 | 출력 | 주석 |
---|---|---|---|---|
sp_get_custlist_by_phone | SQL Server 스토어드 프로시저 | phonenum (char 10) | 목록:
custid (id) |
이 스토어드 프로시저는 고객 세부사항 목록을 전화번호별로 리턴합니다. 고객은 이 목록에서 원하는 내용을 선택할 수 있습니다. 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)에 초점을 맞춥니다. 이 서비스는 서비스 모델에서 디자인 모델로의 변환에서 일반적인 서비스입니다. 변환 자체는 가이드라인에 문서화되고 해당 결과는 다음 모델 구조에 문서화됩니다.
이 모델 역시 디자인 모델이지만 도구를 사용하여 이 모델을 아래와 같은 EJB 구현으로 변환할 수 있습니다. 이 구현은 기본적으로 위의 CustomerByPhone 클래스에서 변환되며 고객을 세부화하는 메시지는 데이터베이스를 조회하는 데 사용되는 엔티티 Bean으로 변환됩니다.
자세한 정보는 가이드라인 서비스에서 서비스 컴포넌트로 이동을 참조하십시오.