중간 산출물: 서비스 모델
서비스 모델은 서비스 지향 아키텍처(SOA)의 핵심 요소 모델입니다. 서비스 모델은 구현 및 테스트 타스크에 대한 필수 입력으로 사용됩니다.
목적

서비스 모델은 엔터프라이즈 내부에서 구현되고 하나 이상의 서비스 지향 솔루션 개발을 지원하는 IT 서비스의 추상입니다. 이 모델은 소프트웨어 서비스의 디자인을 구상하고 문서화하는 데 사용됩니다. 이 모델은 또한 모든 서비스, 제공자, 스펙, 파티션, 메시지, 협업 및 해당 관계를 포함하는 포괄적인 컴포지트 중간 산출물입니다. 다음과 같은 내용에 필요합니다.

  • 후보 서비스 식별 및 실제로 공개할 서비스 종류에 대한 결정 캡처
  • 서비스 제공자와 서비스 이용자 간의 계약 지정
  • 서비스를 이 서비스를 실현하는 데 필요한 컴포넌트와 연결
관계
역할책임이 있음: 수정자:
입력 대상필수: 선택사항:
  • 없음
외부:
  • 없음
설명
간략한 아웃라인

서비스 모델은 실제 자산(UML 모델, 문서 및 요구사항 관리 도구 항목 포함)의 다른 콜렉션 유형입니다. 하지만 서비스 모델에는 다음 논리 요소가 있어야 합니다(기본 설명 참조).

  • 서비스 포트폴리오
  • 서비스 계층 구조
  • 서비스 공개
  • 서비스 종속성
  • 서비스 컴포지션 및 플로우
  • 서비스 비기능적 요구사항
  • 서비스 메시지
  • 상태 관리 결정
  • 실현(realization) 결정
기본 설명

서비스 모델에서는 다중 반복으로 서비스 세트의 세부사항을 캡처하여 세부사항을 더욱 세부화합니다. 서비스 모델은 다음과 같은 여러 범위 레벨에 사용할 수 있습니다.

  • 서비스 범위 개발 프로젝트 범위는 서비스를 가능한 한 다른 서비스에 관계 없이 독립적으로 개발하는 것입니다. 따라서 이 모델링은 유스 케이스, 아키텍처, 디자인 및 구현 모델을 특정 서비스의 수직 단면으로 포함합니다.
  • 프로젝트 범위 개발 프로젝트에 여러 서비스의 스펙이 포함되며 응용프로그램 요구사항 세트를 지원합니다. 이러한 경우, 해당 범위는 응용프로그램 레벨에 맞게 확장되어 여러 서비스를 포함할 수 있습니다. 결과적으로 유스 케이스 및 아키텍처에 대한 응용프로그램 레벨 모델 세트와, 서비스 특정 디자인 및 구현 모델 세트가 존재합니다.
  • 엔터프라이즈 범위 개발 또는 서비스 포트폴리오 관리에서는 해당 범위가 엔터프라이즈 전체 범위가 아닌 서비스 스펙 및 논리 파티션만 캡처하는 것입니다. 이러한 경우 디자이너 및 설계자는 전체 포트폴리오에 대한 광범위한 결정을 내릴 수 있지만 식별된 서비스(및 클라이언트 응용프로그램)에 대한 디자인 및 구현 모델을 개발하기 위한 별도 프로젝트가 필요합니다.

다음 다이어그램에서는 서비스 모델의 핵심 양상 및 이 양상 간 관계와 식별, 스펙 및 활동 실현(realization)을 추상적으로 보여줍니다.

 

요소 식별

첫 번째 정제는 분해와 같은 기법을 사용하여 활동: 기존 자산 분석 중에 작성된 서비스 포트폴리오에 있는 후보 서비스의 목록부터 시작합니다(개념: 비즈니스 프로세스 분해 참조). 이 서비스는 기능 영역 및 서비스를 식별하는 데 사용된 기법에 따라 카테고리화됩니다. 여기서 설명한 서비스 포트폴리오는 프로젝트용 포트폴리오이며 활성: 기존 자산 분석에 설명된 여러 분석 기법을 사용하여 식별된 후보 서비스를 포함합니다. 이 단계에서 식별된 서비스는 이름 및 가능한 기능 설명으로만 제공되며 서비스 목록을 포함한 간단한 문서로 충분하지만 UML 접근 방식이 사용되는 경우에는, 포트폴리오가 아티팩트: 서비스 스펙의 콜렉션으로 유지보수되며 보고서: 서비스 포트폴리오를 사용하여 생성 가능합니다.

가능한 한 빨리 목록의 서비스를 기능 분류 구성(일반적으로 도메인 분해 중에 식별된 기능 영역을 기반으로 함)을 사용하여 계층 구조로 구성합니다. 이와 같은 계층 구조에서는 프로세스 호출 종속성에 대한 서비스의 기본 분류 구성을 볼 수 있으며 따라서 분해 활동 중에 식별된 서비스 간의 관계를 이해하는 데 큰 도움이 됩니다. 또한 계층 구조는 문서, 스프레드시트 또는 UML 모델로 표시합니다. 이 경우, 기능 영역을 모델링하는 데 아티팩트: 서비스 파티션을 사용합니다.

또한 서비스 포트폴리오 용어는 프로젝트용 포트폴리오의 라이프사이클 이상인 엔터프라이즈 전체 서비스 포트폴리오를 나타낼 수 있습니다(개념: 서비스 포트폴리오에서 설명). 실제 엔터프라이즈와 프로젝트 포트폴리오 간의 관계는 아래 그림에 표시되어 있습니다.

스펙 요소

활동: 서비스 스펙 수행 의 첫 단계 중 하나는 서비스의 공개를 결정하고 문서화하는 것, 즉 진정한 서비스로서 개발하고 공개할 후보 서비스를 문서화하는 것입니다. 핵심 기법 중 하나는 타스크: 서비스 리트머스 테스트 적용으로서, 공개를 위해 서비스를 평가하는 방법에 대한 특정 안내를 제공합니다. 서비스 모델의 UML 표시에 대해서, 상태 특성을 사용하여 식별 중에 개발된 서비스 스펙을 모델에 표시 및 공개한 후 세부화합니다. 공개를 위한 서비스 분석에서 서비스를 논리 제품으로 그룹화할 수 있으며 아티팩트: 서비스 제공자를 사용하여 UML에 모델링할 수 있습니다.

서비스 스펙 문서화의 경우, 다양한 목적을 위한 서비스 종속성 모두를 캡처하는 것이 중요합니다. 예를 들어, 종속성이 많은 서비스는 여러 환경에서 재사용하기가 더 어려운 반면 많은 종속자를 가진 서비스는 코어 기능을 나타냅니다. 서비스 종속성은 텍스트로, 혹은 종종 테이블 형식으로도 캡처할 수 있으며(보고서: 서비스 종속성 참조) 또는 서비스 모델의 UML 표시로 모델링할 수 있습니다. 일부 종속성의 원인은 내부 서비스 통신 때문이며 UML 모델 및 특히 협업 모델의 아티팩트: 서비스 채널을 사용하여 이 종속성과 연관된 특정 세부사항(관련된 통신 프로토콜, 보안 등)을 문서화할 수 있음을 인식해야 합니다.

서비스 정의 시 일반적으로 컴포지트 서비스가 좀 더 세분화된 서비스 세트를 구성(Choreography)하는 데만 사용됨을 인지하며, 이 컴포지션 및 플로우에서는 컴포지트와 작성된 서비스 간의 관계 및 서비스에 대한 플로우로 표현된 서비스 간 종속성에 대해 설명합니다. UML 표시로 이 컴포지션 및 플로우(활동, 상호작용)를 잘 설명할 수 있으며(컴포지트 클래스), 기법은 개념: 서비스 컴포지션 및 Choreography에서 설명됩니다.

또한 서비스의 비기능적 요구사항을 캡처하고(위의 많은 주제가 기능적 요구사항에 더 초점을 맞춘 경우), 서비스 품질, 정책 등에 대한 가능한 한 많은 세부사항을 캡처해야 합니다. 이 영역에서는 요구사항을 텍스트 문서로 표시할 수 있지만(UML로 직접 표시하기는 더 어려움), 요구사항 관리 제품을 사용하면 더 쉽게 표시할 수 있습니다. 서비스 모델의 UML 표시 사용 시 기존 RUP 아티팩트: 소프트웨어 아키텍처 문서 및 아티팩트: 보충 스펙을  모두 사용하여 비기능적 요구사항을 캡처하는 것이 좋습니다. 비기능적 솔루션의 한 가지 양상은 서비스의 분배 및 가용성과 관계가 있으며 UML 모델과 특히 아티팩트: 서비스 파티션 및 아티팩트: 서비스 게이트웨이를 사용해 이를 문서화할 수 있습니다.

서비스 메시지의 세부화는 사용 가능한 서비스 스펙의 개발에 중요합니다. 이 메시지는 상위 레벨 모델에서 파생 가능하거나 일부 기술용 양식(예: XML 스키마)으로 직접 표시할 수 있습니다. 메시지가 스키마 언어에서든 UML 모델에서든 텍스트로 설명되면 이 메시지 정의에서는 타스크: 메시지 디자인 및 해당 가이드라인: 메시지 첨부에 문서화된 핵심 사항을 고려해야 합니다.

SOA에서 실제로 서비스를 Stateless로 만드는 경우 이를 언제나 고정된 목적으로 만들 수 있는 것은 아닙니다. 상태 관리 결정 주제를 제공하면 디자이너 시간을 절충사항, 비용 및 서비스 상태 관리의 이점에 반영할 수 있습니다. 이러한 결정을 지원하는 경우 가이드라인: 서비스 상태 관리 주제에서 서비스로 자주 유지보수해야 하는 상태 유형의 예제를 제공합니다.

요소 실현(realization)

서비스 실현(realization)은 본래 세 영역과 관계가 있는데, 이 세 영역은 각각 서비스의 실제 실현(realization)에 대한 결정, 서비스 스펙을 실현할 서브시스템 및 컴포넌트 식별, 마지막으로 이러한 컴포넌트의 개발입니다.

실현(realization) 결정 문서화의 경우, 타스크: 서비스 실현(realization) 결정 문서화의 설명대로 소싱 및 개발 접근 방식 선택에 대한 합리적이고 세부적인 이유가 있어야 합니다. 또한 위의 비기능적 요구사항과 유사한 방법에서는 이 결정을 UML로 표시하기(특히 자세하게) 어려우므로 문서화할 서비스를 각각 독립적으로 선택해야 합니다.

특성
선택사항
계획됨Yes
예시
사용자 조정
부재에 따른 영향이 제품이 없으면 서비스를 올바르게 정의하고 서비스를 실현하는 데 필요한 컴포넌트을 지정하는 일이 어렵게 됩니다.  그러면 서비스 포트폴리오의 공백, 불필요한 서비스의 확산, 서비스 공개 방법의 불일치 및 서비스 실현에 필요한 컴포넌트의 디자인 불일치가 발생하게 됩니다.
필요 없는 이유중요한 조직 경계의 에지(예: 엔터프라이즈의 비즈니스 주요 행의 에지) 또는 엔터프라이즈의 에지에서 서비스 설명을 구체화할 필요가 없는 경우에는, 이 제품이 필요하지 않습니다.
표시 옵션

서비스 모델은 큰 중간 산출물이며 대개 많은 기법을 사용하여 개발됩니다. 예를 들어 UML 모델은 서비스 요소를 설명하는 데 사용되지만 중간 산출물의 프리젠테이션은 UML 모델의 다이어그램을 포함한 문서가 될 수 있습니다. UML 모델에 따르는 특정 프로젝트의 레벨은 연관된 스태프의 스킬 및 배경과 프로젝트 이해 당사자의 기대에 영향을 받습니다. 일반적으로 UML 표시로 가능한 한 많은 모델을 개발하고 이 모델을 추가 컨텐츠(특히 설명 텍스트)와 통합하며 문서로 마지막 해당 양식에 표시하는 것이 좋습니다.

UML 표시는 템플리트: UML의 서비스 모델을 참조하십시오.

문서화 실현은 템플리트: 워드의 서비스 모델을 참조하십시오.

자세한 정보