서비스 지향 아키텍처(SOA)의 중요 측면 중 하나는 서비스를 작성할 수 있다는 것입니다. 즉, 종종 새 서비스가 기존 서비스 세트 간의 협업으로 작성됩니다. 이는 많은 측면에 있어 기존 컴포넌트 기반 및 객체
지향 기법에 해당되는 내용입니다. 그러나 서비스 지향 솔루션을 개발하는 데 사용되는 미들웨어의 특정 기능을 사용하면 웹 서비스용 비즈니스 프로세스 실행 언어(BPEL4WS, WS-BPEL 또는
BPEL)와 같은 표준을 통해 이러한 협업을 직접 실행할 수 있습니다. 또한 서비스를 구조적으로 작성할 수 있고, 서비스 간 사용법 종속성을 정의할 수 있으며, 서비스를 동작식으로 작성하여 많은 조직에게 매력적인
서비스 기반 아키텍처 및 IT 전략을 작성할 수 있습니다.
점점 더 많은 조직이 국제화에 따른 압력, 신규 시장 및 채널 또는 기술을 보다 효율적으로 사용하는 새로운 경쟁자로 인해 변화하는 비즈니스 환경에 대한 민첩한 대응력의 필요성을 인식하고 있습니다. 이러한 조직은
현재 요구사항을 처리하고 미래 요구사항을 효율적이고 효과적으로 재사용, 재구성 및 재결합할 수 있는 비즈니스 관련 기능의 하부 구조를 제공할 수 있도록 조직의 IT 자산을 구성하기 위한 방법으로 서비스 지향 개발
및 서비스 지향 솔루션을 추구하고 있습니다.
이 방식으로 서비스를 작성하는 기능의 또 다른 측면은 신규 자산과 동일한 방식으로 기존 IT 자산을 새 솔루션에 통합할 수 있는 유연한 방법을 제공한다는 것입니다. 예를 들어, 미들웨어 제품을 사용하여 기존
자산(메인프레임 플랫폼 또는 유사한 플랫폼용으로 개발된 자산 포함)을 서비스로 제공할 수 있으며 해당 자산을 J2EE, IBM WebSphere 또는 Microsoft .NET을 사용하여 개발한 새 서비스와 동일한
방식으로 통합할 수 있습니다. 그러나 대부분의 기존 자산은 새 서비스에 사용하려는 안내의 상당 부분을 준수하는 인터페이스를 사용하여 개발되지 않는 경향이 있습니다. 따라서 이러한 기존 서비스를 단순히 랩핑하지 않고
서비스를 집계하고 구성함으로써 기존 기능을 이용하여 상위 레벨 기능을 제공하며 비즈니스 측면이 보다 반영된 다른 인터페이스를 제공하는 컴포지트 서비스를 작성하는 것이 유용한 방법입니다.
서비스 구성(choreography)
먼저 구성(choreography)이라는 용어에 대해 간략히 설명합니다. 이 용어는 참가자가 서비스이고 타스크가 메시지 교환인 프로세스 플로우를 나타내는 스크립트의 관리 실행을 나타내기 위해 여러
미들웨어 제품에서 사용되는 용어입니다. 일부 제품에서는 구성(orchestration)이라는 용어를 사용합니다. 일부 업계 분석가와 기술자는 특정 단어와 해당 단어가 표준으로 사용되는 방법의 차이점에
대해 설명하지만 대부분의 사용자에게 있어 이러한 차이는 해당 유사성만큼 관심을 끌지 못합니다.
대부분의 선두 미들웨어 벤더가 자체 솔루션을 도입했으므로 웹 서비스의 구성(choreography)을 나타내는 일반적인 방법을 표준으로 사용하기에는 시점이 늦은 상태입니다. 현재 업계 표준은 웹 서비스용 비즈니스
프로세스 실행 언어(BPEL4WS 또는 BPEL)입니다. BPEL4WS에 대한 자세한 정보는 OASIS WSBPEL 사이트 또는 IBM BPEL 사이트를 참조하십시오.
아래 다이어그램과 같이, 다른 서비스에서 제공하는 기능에 대한 서비스를 반복 방식으로 쉽게 개발할 수 있습니다. 이 경우 서비스가 신뢰할 수 있는 서비스를 식별할 수 있습니다. 또한 이 경우 컴포지트 서비스가 주문
입력 및 전자 데이터 교환(EDI) 게이트웨이 서비스를 사용합니다. 컴포지트 서비스는 서비스 기능의 일반 팩토링이 여러 상황에서 제공될 수 있는 공통 기능을 식별하는 경우 자주 사용됩니다. 하부 구조 기능을
제공하는 것 이상의 역할을 수행하는 일부 서비스의 경우(예를 들어, 아래 EDI 서비스), 이를 상대적으로 쉽게 식별할 수 있습니다. 다른 경우, 세부 서비스 협업이 후보 서비스를 여러 실제 서비스로 분할해야 하는
요구를 식별합니다.
컴포지트 서비스의 중요한 용도 중 하나는 기존(레거시) 자산이 실현하는 기능의 제공입니다. 대부분의 경우 이러한 기능은 자산에서 자체적으로 제공하는 API 또는 커넥터를 통해 액세스하며 일부 로직에 대해 이러한
자산에 의존하는 새 서비스가 개발됩니다. 반면에, 집계 컴포넌트가 보다 유연하게 전개되고 기존 자산이 향후에 다른 구현을 위해 교환될 수 있도록 하려면 대체 전략을 사용할 수 있습니다. 이러한 경우, 각 기존
기능은 독립 서비스로 제공되며 이러한 서비스는 기존 자산 및 컴포지트 서비스가 모두 독립적으로 전개될 수 있도록 허용하는 컴포지트 서비스에서 사용합니다.
컴포지트 서비스의 또 다른 용도는 컴포지트 서비스에서 이용하는 실제 서비스 세트를 미리 알 수 없는 경우입니다. 예를 들어, 주문 관리 서비스의 경우 주문 유효성 검증을 별도의 독립 비즈니스 규칙 서비스 세트로
분리함으로써 나중에 새 규칙을 추가할 수 있도록 해야하는 요구를 식별할 수 있습니다. 이것은 서비스 중개의 주제와 관련이 있습니다(가이드라인: 서비스 중개 참조).
이러한 접근 방식은 명확한 이점을 갖고 있는 반면 단점도 있습니다. 예를 들어, SOAP/HTTP와 같은 인터넷 프로토콜을 통해서만 하위 레벨 서비스를 제공하는 경우 기본 API 또는 커넥터를 통해 액세스하는
경우보다 일반적으로 성능과 신뢰성이 더 낮습니다. 이러한 절충은 결정한 후 서비스 디자인의 일부로 문서화한 아키텍처 사항의 일반 세트에 포함되어야 합니다.
기존 자산 액세스 및 후보와 실제 서비스 간의 관계에 대한 자세한 정보를 보려면 활동: 기존 자산 분석을 참조하십시오.
컴포지트 서비스의 동작을 모델링하는 경우, 식별 및 디자인 단계에서 아티팩트: 서비스 계약의 개념을 사용합니다.
-
활동: 기존 자산 분석에서는 협업을 도구로 사용하여 후보 서비스의 역할 및 책임을 설명합니다. 예를 들어, 별도의 주문 유효성 검증 및 주문
관리 서비스에 대한 요구를 식별할 수 있지만 통신 방법과 책임 정보를 결정해야 합니다. 서비스 협업은 이러한 통신을 설명하는 도구로 사용되며 결과 모델에서 필요한 메시지 교환을 식별할 수 있습니다.
-
타스크: 서비스 스펙에서는 협업을 사용하여 해당 서비스 또는 서비스에 대한 오퍼레이션의 구체적인 동작을 설명합니다.
예를 들어, 위의 주문 유효성 검증 예제는 유효성 검증 규칙 서비스 세트로 송신되는 메시지 세트로서 구체적으로 설명할 수 있습니다.
이러한 방식을 통해, 서비스 디자인 타스크의 서비스 협업이 웹 서비스 관점에서 구성(choreography) 개념과 직접적인 관련이 있음을 알 수 있습니다. 이는 서비스 간 메시지 교환 세트의 시퀀스를 지정하는
구성 가능하고 구체화된 플로우 설명을 나타냅니다. 구성(choreography)을 구현하는 대부분의 미들웨어의 경우, 이 플로우는 BPEL과 같은 XML 언어로 설명됩니다. 이러한 언어는 아티팩트: 서비스 모델에서 설명하는 서비스 협업에서 생성될 수 있습니다(해당 플로우를 UML 2.0 활동 또는 상호작용으로
설명하는 경우).
협업은 협업자 및 해당 연결의 보기를 제공하는 컴포지트 구조와 교환된 메시지 및 해당 시퀀스를 표시하는 동작으로 구성됩니다. CompositeProvider를 표시하는 위의 다이어그램은 아래 주문 유효성 검증
그림과 같이 컴포지트 구조를 보여줍니다.
이는 아래 다이어그램과 같이 유효성 검증 제공자의 구조가 아닌 서비스 협업의 구조입니다.
서비스 동작 지정
위에서 설명한 대로 협업의 서비스 간 메시지 플로우를 설명하기 위한 일반적인 방법은 UML 2.0 활동 또는 상호작용, 특히 시퀀스 다이어그램을 사용하는 것입니다. 아래 다이어그램은 주문 유효성 검증 서비스의
동작을 보여주는 UML 2.0 활동 다이어그램입니다. 특정 주문마다, 호출할 실제 유효성 검증 오퍼레이션의 목록을 유효성 검증 레지스트리 서비스가 제공합니다.
이러한 동작은 서비스 요구에 따라 전체 서비스에 대해 또는 오퍼레이션 기반으로 식별할 수 있습니다. 이러한 경우, 협업 내 활동은 Validate() 오퍼레이션과 관련이 있습니다(UML 2.0의 스펙/메소드 연관을
통해).
서비스 바인딩 지정
위와 같이, 서비스 간 통신에 사용된 바인딩(실제 물리적 프로토콜 및 메시지 인코딩)은 컴포지션 보기에서 아티팩트: 서비스 채널의 특성으로 식별됩니다. 서비스 간에 사용된 실제 바인딩은 성능, 신뢰성 및 보안과 같은 비기능적
요구사항에 큰 영향을 줍니다. 따라서 사용 가능한 선택사항은 전체 시스템 아키텍처 내에서 식별되는 각 결과와 함께 문서화되어야 합니다. 예를 들어, 아티팩트: 서비스 파티션을 사용하여 파티션 내 서비스 간에 허용되거나 필요한 바인딩을 나타낼 수 있습니다. 공통 요구사항은
특정 논리 영역 내 서비스가 고성능 자체 바인딩을 사용하여 통신하는 반면 해당 영역 밖의 서비스와의 통신에서는 저성능 표준 바인딩을 사용하는 것입니다.
웹 서비스 성능, 신뢰성 및 확장성에 필요한 기능을 HTTP 및 SOAP(기본적으로 속도가 느리고 신뢰할 수 없음) 기반의 아키텍처로 제공할 수 있는지에 대한 의문이 종종 제기됩니다. 먼저, "속도가 느리고 신뢰할
수 없음"을 정의한 후 신뢰할 수 있는 전송 수단도 신뢰할 수 없는 수단에 의존함을 인식해야 합니다. 예를 들어, HTTP를 통한 SOAP를 사용하는 경우 메시지 수신 확인 및 보안에 대한 추가 기능을 제공하는
응용프로그램 레벨 프로토콜 및 상호작용을 항상 빌드할 수 있습니다. 그러나 특정 서비스가 동일한 보안 또는 응용프로그램 컨텍스트에서 통신하는 것으로 간주하는 경우 HTTP 이외의 다른 수단 사용을 고려할 수
있습니다.
웹 서비스가 단순 모델 및 단순하고 유연한 프로토콜 세트를 제시하는 경우라도 해당 사항만 선택해야 하는 것은 아닙니다. WSDL은 이미 SOAP 및 HTTP GET/PUT 모두에 대한 바인딩을 갖고 있으므로
요청자에게 추가 선택사항을 제공해야 합니다. 예를 들어, 단일 서비스가 메시지 대기열 바인딩 및 SOAP 바인딩을 사용하여 메시지를 표시하는 경우 요청자가 사용하기에 보다 적절한 바인딩을 선택할 수 있습니다.
이러한 경우, 제공자는 또한 보증 서비스 레벨과 같은 인센티브를 제공할 수 있습니다(메시지 대기열을 사용하되 서비스가 HTTP 대화를 보증하지 않는 경우).
위의 주문 유효성 검증 예제에서는 아티팩트: 서비스 채널 스테레오타입과 바인딩의 연관 관계 및 아래 다이어그램에서의 시각화를 확인할 수 있습니다.
엔터프라이즈 규모 솔루션을 구성하고 디자인하는 경우, 항상 기능 및 비기능적 요구사항에 유의해야 하며 비즈니스 목적을 지원하기 위한 올바른 절충 및 결정을 내려야 합니다.
|