서비스는 서비스 지향 아키텍처(SOA)의 핵심 아티팩트이므로 서비스의 개념을 이해해야 합니다. 다음은 RUP(Rational Unified Process)
용어집의 내용을 발췌한 것입니다.
서비스는 구체화된 서비스 스펙으로 발견할 수 있는 소프트웨어 자원입니다. 이 서비스 스펙은 서비스 이용자가 검색, 바인딩 및 호출하는 데 사용할 수 있습니다. 서비스 제공자는 서비스 스펙 구현을 실현하고 또한
서비스 요구사항 품질을 서비스 이용자에게 전달합니다. 서비스는 선언 정책으로 관리하므로 동적으로 재구성 가능한 아키텍처 스타일을 지원합니다.
다음 섹션은 위의 내용 중 중요 개념에 대해 설명합니다. 해당 개념과 이전 기술의 디자인 요소를 실질적으로 구분짓는 추가 서비스 측면을 이해해야 합니다. 서비스는 비즈니스 레벨에서 식별할 수 있는 세분성 레벨을
나타냅니다. 따라서 다음은 서비스의 비즈니스 측면 특성을 설명합니다.
서비스는 단일 응용프로그램 아키텍처의 일부가 아닙니다. 즉, 런타임에서 해당 솔루션의 임의 또는 모든 다른 서비스와 독립적으로 존재합니다. 이는 서비스가 실현하는 아티팩트: 서비스 스펙과 같은 기준, 해당 아티팩트: 서비스 제공자와 기타 비즈니스 및 기술 분류를 기반으로 하는 서비스 등록 및 발견 메소드가 필요함을 의미합니다.
이러한 발견 프로세스는 개발 시 지원 서비스와 해당 서비스를 일치시키기 위해 수행되거나 런타임에서 서비스를 동적으로 제공(중개된 호출)하기 위해 수행됩니다. 발견 가능한 서비스는 분류할 수 있는 메타데이터 세트를
제공해야 합니다. 이 메타데이터는 외부 스펙의 일부입니다.
자세한 정보는 개념:
서비스 포트폴리오 및 가이드라인: 서비스 중개를 참조하십시오.
외부 스펙을 이용하면 클라이언트가 서비스에 직접 액세스하지 않고도 인터페이스, 위치, 정책, 분류 등과 같은 해당 세부사항을 서비스가 공개할 수 있습니다. 이러한 정보는 일반적으로 알려진 위치 또는 메타데이터
조회를 지원하는 특별 서비스 레지스트리에 저장됩니다. 현재 웹 서비스 환경에서 서비스 인터페이스 설명에 대해 허용되는 표준은 월드 와이드 웹(WWW) 콘소시엄의 WSDL(Web Services Description Language)입니다.
서비스 스펙 중간 산출물은 실제로 인터페이스, 동작 및 정책 스펙의 조합입니다. 따라서 이러한 다른 측면을 실현하려면 단순히 WSDL에서 제공하는 인터페이스 정의 이외의 것이 필요합니다.
서비스 레지스트리에 대한 자세한 정보는 개념:
서비스 포트폴리오를 참조하십시오.
위의 용어 정의에서, 서비스 스펙이 서비스 제공자 및 서비스 이용자 모두에 대한 보기를 제공함을 확인했습니다. 이러한 보기는 구현과 스펙을 명확하게 구분할 수 있는 계약의 전반부와 후반부에 해당합니다.
다음 표는 서비스 스펙의 여러 측면과 스펙의 제공자 및 이용자 모두에 대한 영향 관계를 설명합니다.
역할
|
인터페이스 스펙
|
동작 스펙
|
정책 스펙
|
제공자
|
서비스가 응답해야 하는 오퍼레이션 및 메시지 세트를 알려줍니다. 모든 오퍼레이션은 올바른 메시지에 대응 및 응답해야 합니다.
|
이 서비스가 지원해야 하는 동작에 대해 알려줍니다. 해당 동작 스펙이 완전한 정규 스펙인 경우 구현의 스펙 준수 여부를 테스트할 수 있습니다.
|
서비스 구현에 적용되는 제한조건 세트와 실행해야 하는 서비스 품질 세트에 대해 알려줍니다.
|
이용자
|
호출될 수 있는 오퍼레이션 세트를 알려줍니다.
|
고객이 실현해야 하는 프로토콜 요구사항(오퍼레이션 순서 지정, 데이터 플로우 등)에 대해 알려줍니다. 또한 이용자가 협업을 지원하기 위해 구현해야 하는 오퍼레이션을 표시합니다.
|
이 서비스와의 통신에 있어 이용자가 인식해야 하는 제한조건(예: 보안 요구사항)에 대해 알려줍니다. 또한 이용자가 해당 제공자에게서 가져올 수 있는 서비스 품질을 식별합니다.
|
이러한 서비스 스펙은 계약에 의한 디자인의 적용으로 볼 수 있지만 발견 가능하고 동적으로 재구성 가능한 서비스를 달성하는 데 있어 필요한 단계입니다.
일반적으로, 비즈니스 오퍼레이션을 나타내는 비즈니스 모델과 IT 응용프로그램을 지원하는 디자인 모델은 연관성이 크지 않습니다. 대부분의 경우 전혀 연관성이 없습니다. RUP는 비즈니스 모델에서 시스템 유스 케이스
모델로의 전이에 대한 안내를 제공하지만(가이드라인 비즈니스 모델에서 시스템으로 이동 참조) 연결을 위해서는 세분성 및 추상 레벨 변경에 따른 비즈니스에서 IT Perspective로의 여러 변환이
필요합니다.
일반적으로, 서비스는 비즈니스 또는 하부 구조 서비스로 분류될 수 있습니다. 서비스 분류에 대한 설명은 개념:
서비스 포트폴리오를 참조하십시오.
SOA의 중요 측면 중 하나는 서비스 지향 솔루션에서 설명하는 서비스 세분성 레벨이 서비스가 제공하는 오퍼레이션을 비즈니스 레벨에서 식별할 수 있는 레벨이라는 것입니다. IT 지원에 있어 이러한 세분성 레벨 증가는
많은 경우에 있어 비즈니스 프로세스 모델에서 식별된 타스크를 서비스에 대한 오퍼레이션으로 직접 실현할 수 있음을 의미합니다. 따라서 IT 솔루션의 비즈니스 사용자는 분석 및 디자인 프로세스에 보다 밀접한 관계를
갖게 됩니다. 또한 서비스는 이처럼 비즈니스 프로세스 모델과의 밀접한 관계로 인해 IT 중간 산출물로서 RUP 비즈니스 모델링 원칙에서 모델링되는 비즈니스 목적과도 보다 밀접하게 연관됩니다.
비즈니스와 서비스 모델 간 연결에 대한 자세한 정보는 활동: 기존 자산 분석을 참조하십시오.
서비스를 모델링하는 경우, 소프트웨어 서비스용 UML(Unified Modeling Language) 프로파일과 프로파일의 각 요소에 제공되는 안내를 사용합니다. 일반적으로
서비스 모델에서 서비스 및 서비스 스펙의 정적 보기를 구성하는 요소가 아래 다이어그램에 표시됩니다.
-
"UpdateCustomerAddressLegacyProvider" 서비스 제공자는 "UpdateCustomerAddress" 서비스를 제공합니다.
-
"UpdateCustomerAddress" 서비스는 "IUpdateCustomerAddress" 서비스 스펙을 구현합니다.
-
"IUpdateCustomerAddress" 서비스 스펙은 단일 오퍼레이션 "execUpdateCustomerAddress"를 갖습니다.
-
"execUpdateCustomerAddress" 오퍼레이션은 단일 입력 메시지, "UpdateCustomerRequest"를 가져옵니다.
-
"execUpdateCustomerAddress" 오퍼레이션은 단일 출력 메시지, "UpdateCustomerResponse"를 리턴합니다.
모델의 구조 및 컴포지션 보기는 서비스 간 통신과 솔루션 파티션을 캡처합니다. 이 내용은 개념: 서비스 컴포지션 및 Choreography 및 개념: 솔루션 파티션에서 다룹니다.
대체 메소드
대개 모델링에는 동일한 논리 구조를 모델링하는 대체 메소드가 있으며 어떤 경우에는 기술을 추가 기술 세부사항을 나타내는 데 사용할 수 있습니다. 예를 들어 제공되거나 필요한 서비스 기능 모두의 개념을 모델링하는
경우, 이러한 기능을 설명하는 인터페이스를 서비스 스펙으로 스테레오타입화하는 것 또는 결합된 유형을 나타내는 스테레오타입화되지 않은 클래스를 사용하는 것 중 택일하거나 인터페이스가 아닌 클래스 자체를
스테레오타입화하도록 선택할 수 있습니다. 이 옵션 모두가 아래 그림에 표시됩니다.
일반적으로 인터페이스를 여러 컨텍스트의 기타 서비스에서 사용할 경우 이 인터페이스를 스테레오타입화해야 합니다. 그러므로 경험에 의한 규칙으로 보면 어떤 요소이든 재사용가능한 설명을 스테레오타입화해야 하는 것으로
간주해야 합니다. 서비스 제공자에서 서비스 작성 시(UML 용어로 된 클래스 또는 컴포넌트의 포트) 아래에 표시된 대로 ServiceType 또는 MyService 클래스를 스테레오타입화된 포트 유형으로
선택합니다.
결과 구조는 ServiceType 또는 MyService에서 동일하며 포트는 필수 인터페이스 및 제공된 인터페이스(클라이언트가 제공하는 콜백 인터페이스)를 표시합니다. 하지만 경우에 따라 필수 및 제공된 기능을
개별 서비스 설명으로 분리하는 데 사용합니다. 이 경우 위에서 소개된 서비스 스펙을 실현하는 데 두 개의 클래스가 필요합니다. 아래 그림은 이 클래스를 보여줍니다.
서비스 제공자 작성 시 아래에 표시된 대로 두 개의 스테레오타입화된 포트가 필요합니다. 포트 하나는 콜인 기능을, 다른 하나는 콜백 기능을 합니다.
이 추가적인 유연성이 필요한 경우 타스크 및 모델에 포함해야 하는 형식성 레벨의 영향을 받습니다. 마지막 예제에서는 콜인과 콜백의 독립된 개념을 분명하게 보여줍니다. 하지만 동일한 제공자가 많은 서비스
종료점을 구현할 경우에 대해서는 알 수 없습니다. 포트의 증가로 최종 결과를 읽고 이해하기가 어려울 수 있습니다.
서비스의 디자인 및 구현에 대한 자세한 정보는 타스크: 서비스
실현(realization) 결정 문서화를 참조하십시오.
|