타스크: 서비스 스펙
이 타스크는 포함된 디자인 요소 및 외부 서브시스템/인터페이스의 협업 관점에서 서비스 지향 솔루션의 서비스 및 구조를 정의하고 지정합니다.
원칙: 분석 및 디자인
목적
  • 포함된 디자인 요소 및 외부 서브시스템/인터페이스의 협업 관점에서 서비스 지향 솔루션의 서비스 및 구조를 정의합니다.
  • 공통성 및 변동에 대해 서비스를 분석합니다(가이드라인: 변동 분석 참조).
  • 서비스 스펙을 문서화합니다.
  • 종속성과, 서비스 간 통신을 결정합니다.
관계
기본 설명
이 타스크에서는 활동: 서비스 식별 에서 식별하고 규정한 아티팩트: 서비스 스펙 세트를 정제하고 추가 구조 및 세부사항을 제공합니다. 이 디자인 레벨 세부사항에는 인터페이스, 메시지 및 서비스 컴포지션과 제공자에 대한 서비스 할당이 포함됩니다.
단계
엔터프라이즈 서비스 포트폴리오 재사용

서비스 지향 아키텍처(SOA) 사용에 있어 자주 언급되는 장점 중 하나는 단일 응용프로그램 범위에서만 컴포넌트를 개발하지 않고 서비스로 엔터프라이즈에서 재사용 가능한 자산을 나타낼 수 있는 기능입니다. 이 엔터프라이즈 보기는 진정한 IT용 서비스 지향 아키텍처(SOA)가 모든 하부 구조 및 비즈니스 기능을 서비스로 제공하고 엔터프라이즈에서 개발한 응용프로그램이 서비스 포트폴리오의 기능을 재사용할 수 있다는 개념을 채택한다는 점에서 중요합니다.

따라서 프로젝트 시작 시 서비스를 포트폴리오의 일부로 개발하는지 또는 해당 서비스를 사용하는 응용프로그램 기능성을 개발하는지 여부를 확인해야 합니다. 예를 들어, 고객이 계정 정보에 액세스하는 포털 사이트를 개발하는 것은 고객 정보, 계정 정보, 제안 등에 대한 포트폴리오의 서비스를 사용하는 응용프로그램 개발 프로젝트입니다. 각각의 경우 포트폴리오 사용은 다른 의미를 갖습니다. 서비스 디자이너는 해당 서비스 스펙을 설명하고 포트폴리오의 일부로 공개합니다. 응용프로그램 개발자는 이 스펙을 통해 서비스에 대한 상호작용 요구사항을 이해할 수 있습니다. 서비스 구현자는 이제 동일한 서비스 스펙을 사용하여 하나 이상의 서비스 구현을 개발할 수 있으며 구현이 스펙을 준수하는지 확인합니다.   다음 다이어그램에서는 엔터프라이즈 전체의 서비스 포트폴리오와 프로젝트의 포트폴리오 간의 관계를 보여줍니다.

자세한 정보는 서비스 포트폴리오 개념을 참조하십시오.

디자인 패턴 및 메커니즘 사용

디자인할 서비스에 맞게 또한 프로젝트 디자인 가이드라인에 따라 디자인 패턴 및 메커니즘을 사용합니다. 패턴 또는 메커니즘을 통합함으로써 패턴 또는 메커니즘으로 정의한 규칙에 따라, 이 타스크의 많은 후속 단계를 효과적으로 수행할 수 있습니다.

패턴 및 메커니즘은 일반적으로 이 타스크의 첫 번째 단계가 아닌 디자인 전개에 따라 통합됩니다. 또한 단일 요소보다는 모델 요소 세트에 자주 적용됩니다.

실현(realization)으로의 서비스 변환에는 패턴 세트, 가이드라인: 서비스 컴포넌트 패턴에 설명된 일부 패턴이 필요합니다.

솔루션의 논리 구조 설명

일반적으로 시스템에 대한 다른 보기와 개발 대상 서비스를 해당 보기에 일치시키는 방법의 관점에서 사고를 구성하는 것이 유용합니다. 논리 조직 보기를 정의하는 경우, 보기에 대한 서비스 지정은 UML(Unified Modeling Language)의 소유권을 의미하지는 않습니다(UML 의미 또는 포함). 즉, 동일한 서비스가 여러 논리 보기에 참여할 수 있습니다. 조직 보기는 서비스 개발 전에 또는 최소한 해당 보기의 첫 번째 반복 전에 모델에 배치하는 것이 좋습니다. 이러한 경우 서비스를 식별된 상태로 보기에 지정할 수 있습니다. 서비스 모델의 경우, 모델 요소 서비스 파티션을 사용하여 보기의 한 측면을 나타냅니다. 이 파티션은 솔루션의 다양한 여러 Perspective를 나타내는 데 사용할 수 있지만 지정된 서비스의 소유권을 의미하지는 않습니다. 자세한 정보는 솔루션 파티션 개념을 참조하십시오.

또한 이러한 파티션(최소한 핵심 시점을 나타내는 파티션)은 서비스와 별도 모델에 상주할 수 있으며 이러한 경우 파티션 모델이 독립적으로 전개됩니다.

서비스 요소 설명

다른 소프트웨어 시스템 모델링의 경우와 같이, 모델의 여러 시작점이 존재하며 원하는 수의 표시를 사용할 수 있으며 방법론 또한 다양하게 적용할 수 있습니다. 대부분의 경우, 이러한 시작점은 해당 기술 또는 비즈니스 도메인의 특정 관심사항에 따른 것입니다. 성공을 위해서는 이러한 관심사항과 해당 상호작용에 대한 이해가 반드시 필요하므로 해당 관심사항이 시작점 역할을 수행합니다.

관찰에 따르면 서비스 지향 솔루션을 개발하는 데 있어 이러한 관심사항은 그리 많지 않습니다. 다음 다이어그램은 이러한 기본 관심사항을 특정 디자인 타스크로 나타냅니다. 이러한 관심사항 각각은 서비스 디자인의 시작점 역할을 수행하며 각 접근 방식은 특정 서비스 클래스에 맞게 최적화된다는 점에서 볼 때 대규모 프로젝트에서는 서비스 식별 및 디자인을 위해 여러 접근 방식을 조합하여 사용합니다.

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

자세한 정보는 이러한 접근 방식을 지원하는 세부 기법 세트를 나타내는 활동: 기존 자산 분석을 참조하십시오.

메시지 디자인

이 접근 방식에서는 서비스 도메인에 초점을 맞춥니다. 도메인 엔지니어링 또는 객체 지향 분석 및 디자인과 같은 기법은 추상 도메인 모델 개발에 대한 통찰력을 제공합니다. 이러한 경우 일반적으로 메시지 스키마에 재사용할 수 있는 모델이 생성됩니다. 서비스 디자인은 일반적으로 보조 활동이지만 때때로 동시에 수행되기도 합니다. 예를 들어, 전자 데이터 교환(EDI)의 경우 해당 시스템에는 일반적으로 메시지에 대한 단일 글로벌 받은 편집함과 보낼 편지함이 포함되므로 서비스 인터페이스에 대한 실제 개념이 없습니다.

해당 접근 방식의 한 예는 EDI 표준화로 대표되는 전통적인 B2B 영역에 속합니다. 이러한 경우, 디자인 활동은 특정 업계 또는 기타 범위에서 동의한 메시지 스키마 개발에 초점을 맞추며, 예를 들어 메시지 클래스의 스키마 및 업계 표준(예: ACORD, SWIFT 및 RosettaNet)을 대표하는 것으로 간주됩니다(타스크: 메시지 디자인 참조).

서비스 디자인

이 접근 방식의 경우, 디자이너는 비즈니스 또는 응용프로그램의 예상 기능을 서비스 또는 서비스 세트로 나타낼 수 있습니다. 이러한 경우, 해당 서비스로 수행할 서비스 클라이언트를 알지 못해도 해당 클라이언트가 예상하는 상호작용 유형은 확인할 수 있습니다. 따라서 메시지는 보조적 특성을 가지며 오퍼레이션 요구사항에 대한 응답으로 개발됩니다.

이러한 접근 방식의 한 예는 AmazoneBay와 같은 회사가 제공하는 웹 서비스 API입니다. 이러한 서비스 인터페이스는 클라이언트에게 비즈니스 프로세스를 부과하지 않습니다. 대부분의 경우, 클라이언트에 필수 인터페이스도 부과하지 않습니다. 그러나 각 서비스 제공자의 오퍼레이션을 써드파티 개발자가 명확하고 쉽게 이해할 수 있는 방식으로 표시합니다.

위에서 언급한 대로, 서비스 중심 모델링은 종종 액터 요구, 서비스의 외부 클라이언트를 이해하고, 이러한 요구와 오퍼레이션(예: 카탈로그 찾아보기, 장바구니에 항목 추가, 체크아웃 등)을 지원하는 오퍼레이션을 제공하여 유스 케이스 구동 접근 방식을 사용합니다.

협업 디자인

협업 디자인에서는 두 개 이상의 서비스의 협업에 초점을 맞춥니다. 이는 서비스의 프로세스 보기와 매우 유사하며 소프트웨어 개발 활동의 경우보다 더 전통적인 비즈니스 모델링과 관련됩니다. 이 접근 방식의 경우, 서비스는 협업의 이행 역할로 간주되므로 서비스 스펙은 하나 이상의 협업에서 역할에 대해 정의된 책임의 세트입니다.

해당 접근 방식은 RosettaNet PIP(Partner Interchange Processes) 개발 또는 OAGIS 표준 개발에 관여한 사람이 이해할 수 있지만 이러한 경우 협업은 완성되지 않았습니다. 이러한 접근 방식은 비즈니스 프로세스 디자인 관점에서 또는 모든 IT 시스템 컴포넌트가 서비스로 표시되는 비즈니스 통합 활동에서 일반적입니다.

이러한 경우, 일반적으로 서비스 스펙은 협업에서 직접 파생될 수 있지만 이 접근 방식은 완전성에 대한 혼성 접근 방식 요구사항으로 연결되는 메시지 컨텐츠에 많은 초점을 두지 않습니다.

정책 식별 및 캡처

정책은 비기능적 요구사항으로 간주할 수 있는 설명 또는 제한조건을 나타내기 위해 사용하는 광범위한 의미의 단어입니다. 이 모델 레벨에서는 기술 정보에 대한 세부 설명으로 모델을 채우지 않으며 실제 의도는 이러한 요구사항과 관련한 시스템의 의도를 캡처하는 것입니다. 예를 들어, 고객의 개인 신상 정보를 포함하는 경우 특정 메시지를 전송하고 외부에 공개해서는 안됩니다. 즉, 중요한 점은 공용 키 암호화를 위한 X.509 인증서가 있는 정규 XML 데이터 세트에 대한 AES 128비트 암호화를 사용하는 데이터 암호화가 필요하다는 것이 아닌 메시지를 외부에 공개해서는 안된다는 것입니다. 이는 이 추상 레벨에서 모델에 지정할 수 있다는 것의 의미를 이해하는 사람이 거의 없기 때문입니다(타스크: 보안 패턴 식별).

다음 다이어그램은 정책과 서비스 모델 요소와의 연관을 보여줍니다. 정책 정보는 아래 식별된 스펙 컴포넌트 이외의 정보에도 첨부할 수 있지만 이는 주요 관심 영역은 아닙니다.

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

보안 정책 모델링에 대한 자세한 정보는 백서, 서비스 지향 아키텍처(SOA)의 보안 관심사항 모델링을 참조하십시오.

모델 서비스 종속성

스펙에서 개발되어야 하는 아티팩트: 서비스 모델의 또다른 주요 양상은 서비스 간의 종속성 캡처입니다. 서비스 모델의 일부로 여러 종속성이 기본적으로 캡처됩니다. 이러한 종속성은 서비스와 해당 스펙 또는 보다 복잡한 두 독립 서비스와의 논리 관계만큼 명확합니다. 두 관계는 모두 동일한 스펙을 구현하기 때문입니다. 이 종속성(아티팩트: 서비스 모델 및 보고서: 서비스 종속성에서 설명)은 서비스를 자치 단위로 배치하는 기능을 이해하는 데 필요하며 종속성이 변경할 서비스 기능에 대한 조건이 되므로 지속적으로 그 발전에 영향을 줍니다.

서비스 종속성에서는 사용 방법에 대한 큰 컨텍스트에서 발생하는 서비스 간의 관계를 설명합니다. 서비스가 기타 서비스의 컴포지션에서 만들어지는 경우, 작성 중인 서비스는 작성된 서비스에 따라 다릅니다. 비즈니스 프로세스에서 서비스를 사용하는 경우 프로세스 관련 종속성이 서비스 사용 순서 지정을 나타내는 비즈니스 프로세스의 고유 시퀀스 단계에서 발생합니다.

  • 기능 종속성/서비스 구성은 여러 서비스의 컴포지션에서 생깁니다.
    • 예제: 챠량 예약은 그 기능성에 대한 요금 및 예약에 따라 다릅니다.
  • 임시 종속성 여기에서는 일부 사전 또는 사후 조건이나 요구사항 처리가 컴포지션 또는 Choreography에서 설명되어야 합니다.
    • 전제 조건 종속성 - 예: 현재 호출이 실행되기 전에 또다른 서비스 호출이 실행되어야 합니다.
    • 종속성 처리 - 예: 현재 서비스 실행을 완료하는 데 또다른 서비스 호출이 필요합니다.
    • 사후 조건 - 이 조건은 실행 후 서비스에 다른 서비스 호출이 필요한 경우에 나타납니다.

이러한 종속성은 특히 선택할 수 있는 구현이 여러 가지인 경우 종종 서비스 클라이언트가 서비스 재사용 여부를 선택할 때 수행해야 하는 결정 프로세스에 포함됩니다.

서비스 모델에서 중요한 종속성/연관 유형은 다음과 같습니다.

  • 서비스와 서비스를 구현하는 서비스 제공자의 관계
  • 서비스와 서비스가 구현하는 서비스 스펙의 관계
  • 서비스와 서비스에 필요한 서비스 스펙의 관계
  • 서비스와 해당 서비스를 다른 서비스와 연결하는 서비스 채널 간의 관계와, 채널 반대편의 서비스와의 관계
  • 서비스와 서비스가 나타나는 서비스 파티션의 관계

따라서 모든 서비스 스펙은 해당 스펙이 제공하는 오퍼레이션 및 메시지뿐만 아니라 콜백 오퍼레이션의 필수 인터페이스와 같은 종속성에 있어서도 완전해야 합니다. 보고서 서비스 종속성은 서비스 모델의 중요한 종속성에 대한 개요를 제공합니다.

모델 서비스 컴포지션 및 플로우

서비스는 기존의 기타 서비스로 구성되어 있으며 경우에 따라 기존 서비스의 구성과 같은 명시적 코드 없이 Choreography와 같은 기술로 서비스 개발이 가능합니다. 스펙에서 서비스는 엔터프라이즈 포트폴리오의 요소를 이미 재사용 중이며 이 서비스에 대한 종속성을 문서화하고 기능성이 작성된 서비스 기능에 따르고 컴포지트를 작성된 서비스에 대한 액세스로 배치해야 하는 경우, 컴포지트 서비스로 간주할 수 있습니다.

일부 SOA 프레임워크에서 복합 프로세스가 좀 더 세분화된 서비스의 Choreography 관리용인 경우 비즈니스 프로세스 계층은 Choreography화된 컴포지트 서비스만 관리할 수 있습니다. 이 경우 웹 서비스용 비즈니스 프로세스 실행 언어(BPEL4WS)는 컴포지트 서비스 개발, 서비스 플로우 및 비즈니스 프로세스 계층을 위한 도구로 사용할 수 있습니다.

따라서, 두 가지 정도의 컴포지트 서비스 유형을 다음과 같이 식별할 수 있습니다.

  • 하드 와이어 컴포지트 서비스 - 이 서비스의 특징은 낮은 유연성인데, 이는 플로우 및 제어가 구체화되지는 않았지만 서비스의 플로우 및 제어가 사전 정의되었기 때문입니다. 이러한 유형의 서비스는 성능 같은 좋은 서비스 품질 속성을 가집니다.
  • 루즈 와이어 컴포지트 서비스 - 이 서비스의 특징은 높은 유연성으로 비즈니스 프로세스에 작성 중인 서비스가 플로우 및 제어를 구체화하여 완성됩니다. 컴포지션의 플로우 설명이 구체화됩니다. 이 유형의 컴포지션을 사용하여 모델링 도구, 규칙을 통한 동적 변동 및 모델링을 통한 정적 변동을 개발합니다. BPEL을 사용한 컴포지션은 예제입니다.

자세한 정보는 프로젝트용 예제를 위한 개념: 서비스 컴포지션과 Choreography가이드라인: 서비스 실현(realization) - SOA 응용프로그램의 BPEL 서비스를 참조하십시오.

비기능적 요구사항 문서화

서비스 지향 아키텍처(SOA)를 이용하면 기능성 제공 및 서비스 품질(QoS) 보장을 기반으로 한 아티팩트: 서비스 제공자를 선택할 기회가 주어집니다. 서비스 제공자를 변경하는 이유 중 한 가지는 기존 제공자가 현재 지원하지 않는 새로운 레벨의 QoS를 필요로 하여 비기능적 요구사항이 변경되었기 때문입니다. 또한 이는 서비스 이용자가 필요로 하는 QoS의 저하로 발생합니다. 서비스 지향 아키텍처(SOA)에서는 일반적으로 기타 아키텍처 스타일보다 낮은 비용으로 이 성능을 사용합니다.

QoS는 두 가지 Perspective, 즉 제공자와 이용자의 Perspective에서 볼 수 있습니다. 서비스 제공자는 해당 서비스에 대한 각각의 서비스 또는 그룹의 서비스 품질을 제공하고 유지보수하도록 보장합니다. 반면에 서비스 이용자는 원하는 QoS를 "살펴보고" QoS 기반의 제공자를 선택합니다. 또한 이용자 및 제공자가 서비스 사용에 대한 법적 계약을 맺는 상업적 설정에서는 이러한 서비스의 품질이 서비스 레벨 계약에서 구체화되며, 제공자가 이와 같은 계약을 지키지 못하면 불이익을 받게 됩니다.

따라서 서비스 또는 서비스 세트에 대해 이용자에게 필요한 비기능적 요구사항(예: 트랜잭션, 성능, 가용성, 보안 등에 대한 비용)을 분명하게 지정해야 합니다. 이러한 서비스 스펙의 타스크에서 원하는 QoS에 대한 비기능적 요구사항을 식별합니다. 비기능적 요구사항으로 서비스를 제공하는 서비스 컴포넌트의 자원을 커밋하고 지속적으로 QoS를 전달하는 서비스 컴포넌트의 실현(realization) 및 유지보수에 투자합니다. 핵심 아키텍처 결정으로 비기능적 요구사항을 기반으로 한 서비스의 약속된 품질을 달성해야 합니다.

비기능적 요구사항을 아티팩트: 서비스 스펙에 첨부하는 방법은 이 안내에서 정의되지 않습니다. 이와 같은 요구사항의 구성 요소, 즉 QoS에 대한 경계가 설정되어 있지 않으며 보안에 대해서는 위에서 언급되었습니다. 예제에는 다음의 내용이 포함됩니다.

  • 가용성(예: 평균 실패 시간 간격(MTBF))
  • 작업 창(서비스를 사용하지 않을 시간이 있습니까?)
  • 응답 시간(서비스가 요청 수 응답하는 시간 간격)
  • 최대 처리량(서비스 요청이 시간 단위 당(초당, 분당, 시간당) 도달하는 수)
상태 관리 요구사항 문서화

개별 서비스가 Stateless로 간주되지만 컴포지션에는 구성된 서비스 호출을 통한 상태 정보를 유지보수하는 요구사항이 있습니다. 서비스의 Choreographer는 종종 상태 관리를 해야 합니다. 또는 관련된 다중 서비스나 서비스에 대한 오퍼레이션을 구현 및 실현하는 컴포넌트에서는 성능 이유로 호출 간 상태를 유지해야 합니다.

SOA 환경에서의 상태 관리는 세 가지 기본 카테고리로 나눌 수 있습니다.

  • 트랜잭션 상태 - 클라이언트와 대화 중에 서비스의 트랜잭션이 열려 있습니다.
  • 보안 상태 - 클라이언트와 대화 중에 보안 컨텍스트가 열려 있습니다.
  • 기능적 상태 - 클라이언트와의 대화가 많은 관련 오퍼레이션에 영향을 줍니다.

자세한 정보는 가이드라인: 서비스 상태 관리를 참조하십시오.

자세한 정보