다른 소프트웨어 시스템 모델링의 경우와 같이, 모델의 여러 시작점이 존재하며 원하는 수의 표시를 사용할 수 있으며 방법론 또한 다양하게 적용할 수 있습니다. 대부분의 경우, 이러한 시작점은 해당 기술 또는 비즈니스
도메인의 특정 관심사항에 따른 것입니다. 성공을 위해서는 이러한 관심사항과 해당 상호작용에 대한 이해가 반드시 필요하므로 해당 관심사항이 시작점 역할을 수행합니다.
관찰에 따르면 서비스 지향 솔루션을 개발하는 데 있어 이러한 관심사항은 그리 많지 않습니다. 다음 다이어그램은 이러한 기본 관심사항을 특정 디자인 타스크로 나타냅니다. 이러한 관심사항 각각은 서비스 디자인의 시작점
역할을 수행하며 각 접근 방식은 특정 서비스 클래스에 맞게 최적화된다는 점에서 볼 때 대규모 프로젝트에서는 서비스 식별 및 디자인을 위해 여러 접근 방식을 조합하여 사용합니다.
자세한 정보는 이러한 접근 방식을 지원하는 세부 기법 세트를 나타내는 활동: 기존 자산 분석을 참조하십시오.
이 접근 방식에서는 서비스 도메인에 초점을 맞춥니다. 도메인 엔지니어링 또는 객체 지향 분석 및 디자인과 같은 기법은 추상 도메인 모델 개발에 대한 통찰력을 제공합니다. 이러한 경우 일반적으로 메시지 스키마에
재사용할 수 있는 모델이 생성됩니다. 서비스 디자인은 일반적으로 보조 활동이지만 때때로 동시에 수행되기도 합니다. 예를 들어, 전자 데이터 교환(EDI)의 경우 해당 시스템에는 일반적으로 메시지에 대한 단일 글로벌
받은 편집함과 보낼 편지함이 포함되므로 서비스 인터페이스에 대한 실제 개념이 없습니다.
해당 접근 방식의 한 예는 EDI 표준화로 대표되는 전통적인 B2B 영역에 속합니다. 이러한 경우, 디자인 활동은 특정 업계 또는 기타 범위에서 동의한 메시지 스키마 개발에 초점을 맞추며, 예를 들어 메시지
클래스의 스키마 및 업계 표준(예: ACORD, SWIFT 및 RosettaNet)을 대표하는 것으로 간주됩니다(타스크: 메시지
디자인 참조).
이 접근 방식의 경우, 디자이너는 비즈니스 또는 응용프로그램의 예상 기능을 서비스 또는 서비스 세트로 나타낼 수 있습니다. 이러한 경우, 해당 서비스로 수행할 서비스 클라이언트를 알지 못해도 해당 클라이언트가
예상하는 상호작용 유형은 확인할 수 있습니다. 따라서 메시지는 보조적 특성을 가지며 오퍼레이션 요구사항에 대한 응답으로 개발됩니다.
이러한 접근 방식의 한 예는 Amazon과 eBay와 같은 회사가 제공하는 웹 서비스 API입니다. 이러한 서비스 인터페이스는 클라이언트에게 비즈니스 프로세스를 부과하지 않습니다. 대부분의
경우, 클라이언트에 필수 인터페이스도 부과하지 않습니다. 그러나 각 서비스 제공자의 오퍼레이션을 써드파티 개발자가 명확하고 쉽게 이해할 수 있는 방식으로 표시합니다.
위에서 언급한 대로, 서비스 중심 모델링은 종종 액터 요구, 서비스의 외부 클라이언트를 이해하고, 이러한 요구와 오퍼레이션(예: 카탈로그 찾아보기, 장바구니에 항목 추가, 체크아웃 등)을 지원하는 오퍼레이션을
제공하여 유스 케이스 구동 접근 방식을 사용합니다.
협업 디자인에서는 두 개 이상의 서비스의 협업에 초점을 맞춥니다. 이는 서비스의 프로세스 보기와 매우 유사하며 소프트웨어 개발 활동의 경우보다 더 전통적인 비즈니스 모델링과 관련됩니다. 이 접근 방식의 경우,
서비스는 협업의 이행 역할로 간주되므로 서비스 스펙은 하나 이상의 협업에서 역할에 대해 정의된 책임의 세트입니다.
해당 접근 방식은 RosettaNet PIP(Partner Interchange Processes) 개발 또는 OAGIS 표준 개발에 관여한 사람이 이해할 수 있지만 이러한 경우 협업은 완성되지 않았습니다. 이러한
접근 방식은 비즈니스 프로세스 디자인 관점에서 또는 모든 IT 시스템 컴포넌트가 서비스로 표시되는 비즈니스 통합 활동에서 일반적입니다.
이러한 경우, 일반적으로 서비스 스펙은 협업에서 직접 파생될 수 있지만 이 접근 방식은 완전성에 대한 혼성 접근 방식 요구사항으로 연결되는 메시지 컨텐츠에 많은 초점을 두지 않습니다.
정책은 비기능적 요구사항으로 간주할 수 있는 설명 또는 제한조건을 나타내기 위해 사용하는 광범위한 의미의 단어입니다. 이 모델 레벨에서는 기술 정보에 대한 세부 설명으로 모델을 채우지 않으며 실제 의도는 이러한
요구사항과 관련한 시스템의 의도를 캡처하는 것입니다. 예를 들어, 고객의 개인 신상 정보를 포함하는 경우 특정 메시지를 전송하고 외부에 공개해서는 안됩니다. 즉, 중요한 점은 공용 키 암호화를 위한 X.509
인증서가 있는 정규 XML 데이터 세트에 대한 AES 128비트 암호화를 사용하는 데이터 암호화가 필요하다는 것이 아닌 메시지를 외부에 공개해서는 안된다는 것입니다. 이는 이 추상 레벨에서 모델에 지정할 수 있다는
것의 의미를 이해하는 사람이 거의 없기 때문입니다(타스크: 보안
패턴 식별).
다음 다이어그램은 정책과 서비스 모델 요소와의 연관을 보여줍니다. 정책 정보는 아래 식별된 스펙 컴포넌트 이외의 정보에도 첨부할 수 있지만
이는 주요 관심 영역은 아닙니다.
보안 정책 모델링에 대한 자세한 정보는 백서, 서비스 지향 아키텍처(SOA)의 보안 관심사항 모델링을 참조하십시오.
|