가이드라인: 서비스 컴포넌트 패턴
이 가이드라인에서는 서비스 실현(realization) 시 서비스 컴포넌트 개발에 사용할 수 있는 패턴 세트를 보여줍니다.
관계
기본 설명

소개

서비스 컴포넌트를 해당 구성의 기능적 및 기술적 컴포넌트로 분해하는 경우, 서비스 컴포넌트에서 제공된 기능성에 서브시스템의 기능적 책임을 위임합니다. 기능적 컴포넌트에서는 필요한 비즈니스 기능성을 제공하지만 기술적 컴포넌트에서는 작동성 및 비기능성을 지향하는 일반 기능성(예: 인증, 오류 처리, 감사, 로깅 등)을 제공합니다.

서비스 모델은 디자인 시간 아티팩트입니다. 따라서 서비스 구현을 직접 처리하지 않습니다. 그러나 서비스 또는 서비스 세트의 실제 구현은 서비스 컴포넌트로 서비스 스펙을 실현(realization)함으로써 엄격히 수행됩니다. 서비스 스펙은 구현 계약을 제공합니다. 서비스를 구현하는 데 사용되는 기술 또는 기법은 해당 계약을 이행하는 경우에만 관련이 있습니다. 서비스 지향 아키텍처(SOA) 개념에서는 식별되는 서비스와 해당 서비스 구현을 제공하는 컴포넌트 및 오브젝트 간의 관계를 나타내는 다음 그림을 제공합니다.

 연관된 텍스트에 설명된 다이어그램

이러한 방식으로, RUP 디자인 모델을 사용하여 컴포넌트 및 오브젝트 계층의 디자인을 캡처하는 방법을 확인할 수 있습니다. 구현 모델 및 아티팩트는 오브젝트 계층과 연관 구현 및 배치 아티팩트의 세부사항을 캡처합니다. 서비스 모델과 컴포넌트 디자인 모델 간의 관계에서 중요한 측면은 서비스 스펙 세트가 이행해야 하는 계약을 나타내고, 스펙에서 식별된 오퍼레이션은 현 상태대로 구현해야 하며, 서비스 이용자는 이와 동일한 모델을 사용하여 사용할 서비스의 인터페이스 및 동작을 이해해야 한다는 것입니다. 이에 따라 서비스의 초기 구현 시작점 역할을 수행하는 일부 구현 아티팩트와 서비스 스펙 간에는 일반적으로 직접적인 일대일 관계가 존재합니다.

예를 들어, 해당 정의에서 사용되는 모델 요소의 세부사항을 보여주는 서비스 제공자에 대한 다음 다이어그램을 고려할 수 있습니다.

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

서비스 컴포넌트를 사용하려면 서비스 모델로 직접 추적할 수 있는 컴포넌트여야 합니다. 가장 쉬운 방법은 서비스 스펙 요소가 서비스 컴포넌트로 실현할 수 있는 UML 인터페이스라는 사실을 이용하여 구조 스펙을 준수하는지 확인하는 것입니다. 이 방법을 사용하면 다음과 같은 결과를 얻게 됩니다.

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

이제 결과 컴포넌트의 동작을 제공하는 컴포넌트 및 클래스 세트는 컴포넌트 구현자가 정의해야 합니다.

서비스 컴포넌트 유형

기능적 컴포넌트

이 기능적 컴포넌트가 대단위로 구분된 컴포넌트로 구성되면 이 컴포넌트는 구조적일 뿐 아니라 플로우의 정의도 포함됩니다. 이 정의는 비즈니스 프로세스를 지원하는 기능성을 제공하는 기능적 컴포넌트의 협업입니다. 앞서 본 것처럼 이 비즈니스 관련 컴포넌트의 기능성은 정의된 서비스(컴포넌트의 더 나은 레벨 오브젝트 또는 레거시 시스템 구조에서 구현)를 통해 사용 가능합니다.

이 단계에는 일반 OOAD 활동이 포함되어야 합니다. 초점을 맞춘 파티션된 범위는 오브젝트 디자인을 가리킵니다. 일반 객체 지향 디자인의 경우, 보다 더 큰 종속 오브젝트 그래프를 작성하는 반면 서브시스템 분석은 비즈니스의 기능 영역 식별로 이루어집니다. 범위에 초점을 맞추고 디자인 에너지를 돌리도록 정의합니다. 이렇게 하면 보다 더 느슨하게 결합된 오브젝트 모델 세트(시스템 유스 케이스에서 트리거된 클래스 다이어그램 및 시퀀스 다이어그램)가 만들어집니다.

기술적 컴포넌트

기능적 컴포넌트와 같은 방법으로 기술적 컴포넌트가 세분화되지 않은 서비스 컴포넌트로 구성됩니다. 기술적 컴포넌트(예: 인증, 로깅 및 보고)는 비즈니스 프로세스 전반에 사용 가능합니다.  이 공통 컴포넌트는 기능적 컴포넌트를 지원하는 하부 구조를 만드는 데 필요합니다.  비즈니스 프로세스의 주요 변형 중 하나는 아래의 그림 "엔터프라이즈 컴포넌트 패턴"에 표시된 대로 비즈니스 규칙 때문입니다. 이러한 변형은 일반적으로 변형 지향 디자인에서 캡처됩니다.

서비스 컴포넌트 패턴

서비스 컴포넌트가 서비스 스펙을 실현한다고 해서 구현자가 덜 세분화된 서비스 정의에서 서비스 동작을 제공하는 데 필요한 세분화된 구현 클래스 및 아티팩트 세트로 이동할 수 있도록 지원함을 의미하지는 않습니다. 이와 관련해서는 일반적으로 결과 서비스 컴포넌트에 특정 정책 요구사항을 처리하는 시작 프레임워크 또는 특정 패턴으로서 구조를 제공하는 패턴에 의존합니다.

NFR에 의한 패턴 선택사항, 아키텍처 [계속]

여기서 소개하는 추가 스테레오타입은 아티팩트: 서비스 컴포넌트에서 설명합니다.

기본 서비스 컴포넌트 패턴

서비스의 초기 구조를 정의하는 데 있어, 사용자 정의 및 완료의 시작점으로 다음 패턴을 제공합니다.

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

패턴 요소는 다음과 같습니다.

  • Facade 컴포넌트: Facade는 서비스 컴포넌트 자체와 동일한 인터페이스를 실현하며 실행할 오퍼레이션당 컴포넌트로 요청을 전달하기 전에 메시지 유효성 검증을 위한 기본 기능을 제공합니다. 이러한 경우 해당 컴포넌트를 구분하기 위해 <<Facade>> 스테레오타입을 지정합니다.
  • 오퍼레이션당 컴포넌트: 서비스의 세분성을 고려할 때, 대부분의 경우 서비스에서 제공하는 각 오퍼레이션의 구현에 별도 컴포넌트/클래스를 사용하는 것이 좋습니다.

다음은 이 패턴의 컴포지트 구조 보기를 보여줍니다. 이 경우, Facade는 서비스 컴포넌트에 의해 위임됩니다. 또한 서비스 컴포넌트에 대한 오퍼레이션을 호출하는 이용자는 실제로 Facade 컴포넌트가 지원합니다. UML 2.0 포트를 사용하고 인터페이스를 제공할 수 있으며 커넥터를 사용하여 이 위임을 명시적으로 작성할 수 있습니다.

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

단일 오퍼레이션 서비스 컴포넌트 패턴

오퍼레이션이 여러 개인 서비스 모델에서 서비스가 식별되는 경우, 논리 서비스 및 실제 서비스 보기를 구분하는 독립형 서비스로서 오퍼레이션을 개별적으로 구현하는 것이 보다 적절한 방법입니다. 이러한 패턴은 소스 제공, 고가용성, 버전화 및 전개 관점에서 장점이 있지만 관련 오퍼레이션 세트로서의 서비스 인터페이스 개념을 상실하게 됩니다.

이 패턴에 따라 서비스 컴포넌트를 모델링하는 작업에는 단일 오퍼레이션과의 단일 인터페이스를 실현하는 단일 <<서비스 컴포넌트>>가 포함됩니다. 모든 이름은 공통 규약에 따라 지정되며 다음과 같습니다.

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

이 경우, 앞에서 언급한 대로 위의 패턴에서 한 요소가 원래 서비스 스펙을 직접 실현하지 않습니다. 따라서 서비스 스펙으로 다시 추적성을 제공할 수 있는 요소를 모델에 도입할 수 있습니다. 아래 예제에서는 <<subsystem>>으로 스테레오타입이 지정되는 컴포넌트를 도입했습니다. 이 컴포넌트는 서비스 스펙을 구현하며 위에서 설명한 요소를 소유합니다.

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

이 패턴은 또한 <<facade>> 컴포넌트를 도입하지 않습니다. 서비스 이용자가 사용하는 서비스를 직접 식별하기 때문입니다.

중개된 오퍼레이션 패턴

서비스 이용자의 요청을 실행할 오퍼레이션 컴포넌트로 선택한 컴포넌트 중 하나로 라우팅할 수 있는 경우 아래와 같이 중개자를 사용하여 패턴을 확장함으로써 메시지를 라우팅할 수 있습니다. 컴포넌트/클래스는 명확성을 위해 <<mediator>> 스테레오타입으로 지정합니다. 중개에 사용되는 정확한 메커니즘은 정의되지 않습니다. 정적인 구현 세트를 미리 확인할 수 있으며 또한 특정 유형의 레지스트리를 사용하여 이용자, 요청 메시지 컨텐츠 등을 기반으로 특정 구현으로 맵핑할 수 있습니다. 이 패턴은 위의 단일 오퍼레이션 패턴에는 사용되지 않습니다.

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

이는 또한 서비스 컴포넌트의 컴포지트 구조 보기에 영향을 줍니다. 즉, 중개자 연결은 아래와 같이 오퍼레이션 컴포넌트를 직접 호출하기 위해 해당 연결을 사용하는 Facade에서 표시됩니다.

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

중개자 외부 레지스트리를 사용하는 경우, 중개자에서 오퍼레이션 컴포넌트 또는 컴포지트 구조 다이어그램 파트 간의 커넥터로의 정적 사용법 종속성을 항상 표시할 수는 없습니다. 따라서 중개자에서 중개된 오퍼레이션 컴포넌트로의 종속성을 모델링하는 방법을 이해해야 합니다. 다음 다이어그램에서는 각 오퍼레이션 컴포넌트가 구현할 인터페이스를 보여줍니다. 이제 아래와 같이 중개자에서 인터페이스로의 사용법을 모델링할 수 있습니다.

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

또한 아래와 같이, 인터페이스에서 입력한 새 파트를 포함하여 컴포지트 구조 다이어그램의 관계를 변경하고 커넥터의 중개자와 오퍼레이션 컴포넌트 간 다양성을 표시합니다.

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

데이터 액세스 컴포넌트

또한 서비스 오퍼레이션이 공통 데이터 요구사항을 공유하는 경우, 데이터 관리 기능을 구현에 제공하는 특정 컴포넌트를 강조표시하는 것이 좋습니다. 컴포넌트/클래스는 명확성을 위해 <<데이터 액세스>> 스테레오타입으로 지정합니다.

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

엔터프라이즈 컴포넌트 패턴

아래의 엔터프라이즈 컴포넌트 패턴에서는 서비스 컴포넌트 활동을 기본적인 기능적 및 기술적 컴포넌트의 Facade로 표시합니다. 서비스는 컴포넌트 Facade에서 서비스 컴포넌트의 에지에 공개됩니다. Facade의 서비스 요청이 중개자로 전달된 후 이 중개자는 메시지를 해당 기능적 또는 기술적 컴포넌트에 라우트합니다.

연관된 텍스트에 설명된 다이어그램

엔터프라이즈 컴포넌트 패턴

기술적 컴포넌트에 대한 기능적 컴포넌트의 종속성 및 요구는 아래에서 설명됩니다(렌트카 예제).

연관된 텍스트에 설명된 다이어그램

렌트카 엔터프라이즈 컴포넌트 패턴을 사용한 예약 서비스 컴포넌트

서브시스템 컴포넌트 모델 콜렉션은 기능적 컴포넌트 모델로 수집됩니다. 이 기능적 컴포넌트 모델에서는 기술적 컴포넌트에 대한 기능적 컴포넌트의 의존도 및 기능적 컴포넌트 간의 내부 관계를 표시합니다. 서브시스템 Facade에 지정된 리프 레벨의 서브프로세스는 서브시스템이 제공할 서비스로 지정해야 합니다. 이 서브프로세스는 서브시스템 구조 내에 캡슐화된 시스템 유스 케이스의 세분화된 세트를 통해 지원 및 구현됩니다. 유스 케이스의 실현(realization)의 경우 기능적 컴포넌트에 의존합니다. 기능적 컴포넌트는 해당 하부 구조가 필요로 하는 기술적 컴포넌트 및 유틸리티에 따라 다릅니다.