서비스 지향 아키텍처(SOA)의 명확한 장점 중 하나는 IT 내 "저장" 사고에서 벗어나 여러 기능을 보유한 응용프로그램을 개발할 수 있다는 것입니다.
오늘날 응용프로그램은 이러한 단일 목적으로 빌드된 컴포넌트 세트의 수직 통합으로 이해됩니다. 즉, 개발 프로젝트는 응용프로그램의 개발 또는 유지보수에 중점을 두고 설정되며 심한 경우 개발 팀은 단일 응용프로그램만
담당하기도 합니다. 다음 그림은 공통 비즈니스 응용프로그램 구조를 나타내며 응용프로그램 간 유일한 재사용은 일반적으로 공통 데이터베이스를 공유하는 경우임을 보여줍니다.
서비스 지향 접근 방식을 통해 서비스 통합으로서의 응용프로그램을 보다 수평적으로 볼 수 있습니다. 따라서 실제로 모든 서비스는 응용프로그램을 개발할 수 있는 기능 포트폴리오에서 피어 상태로 존재하며 이제는 사용자와
상호작용하는 IT 솔루션의 해당 파트로 인식할 수 있습니다. 다음은 주문 관리 응용프로그램을 포털 서버로 통합하기 위한 사용자 대면 포틀렛 세트로 개발할 수 있는 방법과, 하부 구조 서비스 세트를 차례로 이용하는
서비스 세트에서 비즈니스 로직을 제공함을 보여줍니다.
서비스는 일반적으로 완전히 자체 포함될 수 있는 세분성으로 제공되는 독립 배치 컴포넌트를 제공하며 이러한 경우 데이터베이스 저장영역을 공유하는 것보다는 자체 데이터 스토어를 관리하고 보호하는 서비스가 제공됩니다.
이는 일부 회사가 오랜 기간에 걸쳐 공통 데이터 스토어 또는 최소한 모든 응용프로그램이 공유하는 공통 데이터 모델을 도입하는 활동과 대조적입니다. 반대로 서비스 지향 아키텍처(SOA)는 디자이너로 하여금 공통
데이터 저장영역 모델이 아닌 공통 메시지 모델을 개발함으로써 미들웨어 기술을 통한 서비스 통합을 용이하게 합니다.
앞에서 언급한 대로, 프로젝트 팀과 개발 팀은 모두 범위가 제한적이며, IT 서비스의 보다 광범위한 기능, 요구사항 및 목적과 보다 중요하게 서비스가 지원하는 비즈니스에 대한 가시성 또한 제한적입니다. 따라서
서비스 지향 솔루션 및 통합 솔루션의 수평 보기로 이동하면서 IT측 설계자는 비즈니스 운영에 필요한 비즈니스 솔루션을 지원하는 서비스 포트폴리오를 시각화할 수 있어야 합니다. 서비스 모델링에 따른 한 가지
장점은 추상 모델이 특정 세부사항을 생략할 수 있고 이에 따라 서비스 포트폴리오의 광범위한 보기를 확장 가능한 방식으로 나타낼 수 있다는 것입니다. 즉, 서비스가 여러 개인 경우 소프트웨어 설계자 및 디자이너의 결정을
지원하는 포트폴리오 보기를 모델이 제공할 수 있습니다.
조직이 서비스 지향 오브젝트(SOA)로 전이함에 따라 서비스가 증가하고 포트폴리오를 대규모 모델로 시작할 수 없지만 사용 가능한 서비스 및 계획된 서비스의 관점에서 전이 상태를 캡처할 수 있습니다. 서비스 파티션은 또한 포트폴리오 개발 시 모델을 구성하고 서비스를 분류하는 데 중요합니다.
서비스 식별(활동: 기존 자산 분석 참조) 초기 단계에서 후보 서비스는 일반적으로 이름 목록으로 캡처되며 계층 구조 목록으로 구성되거나 스프레드시트에 저장
가능합니다. 이와 같은 목록은 워크샵 환경에서 작업하거나 소스 자료에서 후보 서비스를 도출할 때 사용됩니다. 후보 서비스의 수가 증가하면 구성되지 않은 목록을 관리하기 힘들어집니다. 따라서 후보 서비스를 카테고리
계층 구조 내의 그룹에 구성 할 수 있도록 가능한 한 빨리 서비스 분류 구성표를 식별해야 합니다.
간단한 서비스 이름 목록이 빠른 시작점이 되면 각 서비스에 대한 추가 정보를 캡처하는 데 중요한 역할을 합니다. 이 정보는 두 가지 방법으로 나눌 수 있습니다. 하나는 서비스 식별을 지원하는 정보이고 다른 하나는
서비스 스펙을 지원하는 정보입니다. 서비스 식별로 서비스의 포트폴리오를 빌딩하는데, 이 포트폴리오는 비즈니스 기능, 비즈니스 목적, 자산(예: 기존 시스템) 및 서비스를 후보 서비스로 간주할지 또는 공개를 위해
선택할지의 여부 표시와 연관시킬 수 있습니다. 서비스 포트폴리오 템플리트는 서비스 포트폴리오에 필요한 세부사항의 레벨에서 서비스를 문서화하는 데 사용 가능합니다.
포트폴리오 서비스는 여러 가지 방법으로 분류할 수 있지만 일반적으로는 서비스의 목적, 소유권 또는 조직을 설명하는 용어를 사용합니다. 이러한 분류를 지원하기 위해 각 서비스 파티션에는 분류 유형을 표시하는 데
사용할 수 있는 분류 특성이 포함되며 파티션 이름은 해당 분류 구조의 값이 됩니다.
예를 들어, 여러 회사에서 포트폴리오의 서비스 "유형"을 시각화하기 위해 다음 다이어그램 또는 일부 변형을 개발했습니다. 이러한 분류는 일반적이지만 서비스 포트폴리오를 분류하기 위해 가능한 한 가지 방법입니다. 이
예제에서 각 파티션은 해당 분류 특성을 "영역"으로 설정하여 이름을 지정합니다.
-
사용자 상호작용 서비스는 사용자가 응용프로그램과 상호작용하는 방법을 설명하는 데 사용됩니다. 예를 들어, 서비스로 실제 사용자에게 작업을 지정해야 하는 경우, 해당 사용자에게 이 작업을
알린 후 원래 서비스에 작업 완료를 알리는 방법을 알고 있는 서비스가 필요합니다.
-
응용프로그램 특정 서비스는 재사용에 적합하지 않은 것으로 간주되어 개발 활동의 일부로 개발되는 서비스로서, 포트폴리오의 일부로 간주되지 않습니다. 또한 서비스는 작성 가능한 엔티티이므로 서비스가
포트폴리오의 일부로 포함되더라도 해당 중첩 서비스는 공개되지 않을 수 있습니다.
-
프로세스 통합 서비스는 일반적으로 상용 미들웨어가 제공하는 서비스로서, 서비스 구성(choreography)을 제공하여 미들웨어에서 프로세스를 규정할 수 있으며 포트폴리오의 서비스를 이용하여
프로세스를 구현할 수 있습니다.
-
정보 통합 서비스 역시 상용 미들웨어 서비스로서, 서비스 간 데이터 형식 및 메시지 컨텐츠를 중개하는 서비스를 제공합니다. 예를 들어, 포트폴리오의 다른 서비스에서 검색한 데이터의 집계인
서비스로 고객 메시지를 생성할 수 있습니다.
-
비즈니스 서비스는 비즈니스 특정 서비스로서, 비즈니스용으로 개발되었으며 비즈니스를 지원하기 위해 개발된 응용프로그램을 직접 지원합니다(예: CustomerMgmt, Inventory, HR
등).
-
하부 구조 서비스는 비즈니스 서비스뿐만 아니라 통합 서비스에서도 필요한 공통 IT 기능을 제공하는 서비스입니다(예: 메시지 전달, 디렉토리, 인증, 레거시 액세스 등).
분류 유형에 대한 추가 예제는 서비스 파티션 개념을 참조하십시오.
따라서 서비스 포트폴리오 모델과 관계 없이, 디자이너 및 개발자는 디자인 및 구현 시 서비스 스펙에 세부적인 방식으로 액세스할 수 있습니다. 또한 여러 서비스가 동일한 스펙을 구현할 수 있어 "IOrdering
스펙을 구현하는 모든 서비스" 양식의 조회를 허용하는 레지스트리에서는 개발자가 기존 서비스에서 솔루션을 작성할 수 있으며 통합 개발자는 비즈니스 또는 기술적 요구사항을 충족시키기 위해 사용하는 서비스를 식별할 수
있습니다.
서비스 저장소는 또한 위의 서비스 파티션을 사용하여 도입된 분류 값을 사용할 수 있습니다. 해당 값은 저장소에서 보관하는 서비스를 설명하는 메타데이터로 미리 채울 수 있습니다.
예를 들어, 솔루션은 운송 서비스를 요청하고 레지스트리는 운송을 제공하는 세 가지 서비스를 식별할 수 있습니다. 이 중 두 가지 서비스는 보안 메시지 교환을 제공할 수 있지만 하나는 JMS(Java Message
Service)에 대해서만 이를 수행하고 다른 하나는 HTTP를 통한 SOAP를 제공합니다. 비즈니스 요구사항은 고객 정보를 공개해서는 안되므로 보안 메시지 교환이 필요한 것만 지정합니다. IT 표준은 원격
서비스에 대해 JMS를 사용하지 않도록 권장하므로 선택의 폭이 줄었습니다.
다음은 현재 서비스 레지스트리에 사용할 수 있는 일부 기술 구현을 나타냅니다.
-
UDDI: 널리 채택되는 웹 서비스 표준 레지스트리로서, 개발 및 통합 시간 조회를 모두 지원합니다. 그러나 서비스 스펙과 연관된 모든 데이터를 추적하는 데 필요한 사용자 정의 레벨로 인해
오늘날과 같은 환경에서 UDDI가 이 문서에서 설명하는 엔터프라이즈 서비스 포트폴리오를 효과적으로 지원할 수 있는지에 대한 의문이 발생합니다.
-
RAS 저장소: 재사용가능한 자산 스펙은 재사용가능한 자산에 대해 사용자 정의 가능한 메타데이터 설명을 지원하며 웹 서비스에 대한 메타데이터 프로파일을 포함합니다. RAS의 목적이 서비스
포트폴리오를 제공하는 것은 아니지만 개발 시간 메타데이터의 경우 포트폴리오를 제공할 수 있습니다. 그러나 현재 통합 시간 조회에는 적합하지 않습니다.
-
사용자 정의: 이러한 선택에 직면한 많은 조직은 디자인 시간에 서비스에 대한 메타데이터 또는 디자인 문서 세트를 관리하고 구현 시간에는 연관 웹 서비스 아티팩트를 관리하여 사용자 정의 서비스
저장소를 구현하기로 선택했습니다. 대부분의 경우, 통합 시간 조회를 위한 프로덕션 서비스를 배치할 때 별도 UDDI 저장소를 사용합니다.
|