타스크: 서비스 실현(realization) 결정 문서화
이 타스크는 기존 미들웨어 환경에서 실행할 소프트웨어 컴포넌트에 대한 서비스 모델의 실현(realization)에 초점을 맞추고 있습니다.
원칙: 구현
목적

이 타스크의 목적은 개발자가 필수 서비스를 제공하는 서비스 컴포넌트를 구현하는 데 사용할 구현에 필요한 디자인 모델을 제공하는 것입니다.

관계
기본 설명

서비스 모델의 목적은 주로 서비스, 해당 조직, 협업과, 세부화되고 완료된 스펙을 식별하는 것입니다. 구현 역할은 기존 RUP(Rational Unified Process) 디자인 모델, 특히 서비스 컴포넌트 모델 요소로 위임됩니다. 일반적으로 서비스 모델은 디자인 모델로 실현됩니다. 그러나 스펙만 필요한 경우 서비스 모델에서 직접 아티팩트를 생성할 수 있습니다. 또한 구현/구축(Construction) 이전에 서비스를 보다 자세하게 설명할 수 있는 유스 케이스 모델을 서비스 모델에서 작성하는 방법도 유용합니다.

단계
소싱 접근 방식 결정

서비스 실현 방법 결정에 대해 고려될 많은 대안이 있습니다(아래 그림 참조). 이는 구매 결정에 대한 직접적인 빌드가 아닙니다. 기타 흥미로운 옵션은 그림에 있습니다. "변환"에서는 비즈니스 규칙 추출을 포함한 기술 조합을 사용하여 기능성의 일부분을 가져온 후 컴포넌트 서비스의 실현(realization)에 독자적으로 사용할 수 있습니다. "통합"은 기능성을 완성할 레거시 기능성의 "랩퍼링"입니다. 통합은 호출을 기반으로 합니다. 가입은 고객이 제공자가 제공한 서비스를 가입하는 공용 가입 모델(메시지 지향 미들웨어 컨텍스트에 있음)의 가용성을 기반으로 합니다. 옵션 중 하나는 기능성을 기타 비즈니스로 아웃소싱하는 것입니다. 웹 서비스 및 비즈니스 간 통합이 늘어날수록 이 옵션 사용도 보다 더 폭넓은 기초에서 이루어진다고 간주할 수 있습니다.

  • 빌드 - 여러 이유로 결정은 조직 내 서비스를 우선 개발하는 것입니다.
  • 구매 - 내부적으로 배치 및 호스트할 서비스를 구매합니다.
  • 변환 - 비즈니스 규칙 추출을 포함한 기술 조합을 사용하여 기능성의 일부분을 가져온 후 컴포넌트 서비스의 실현(realization)에 독자적으로 사용합니다.
  • 가입 - 고객이 제공자가 제공한 서비스를 가입하는 공용 가입 모델(메시지 지향 미들웨어 컨텍스트에 있음)의 가용성을 기반으로 합니다.
  • 통합 - 기능성을 완성할 레거시 기능성의 랩퍼링입니다. 통합은 호출을 기반으로 합니다.
  • 아웃소싱 - 웹 서비스 및 비즈니스 간 통합이 늘어날수록 이 옵션 사용도 보다 더 폭넓은 기초에서 이루어진다고 간주할 수 있습니다.

서비스 실현(realization) 결정은 서비스 컴포넌트와 연관되어 있습니다. 각 서비스 컴포넌트는 서비스를 실현하는 데 필요한 기능성 컨테이너로 간주할 수 있습니다. 이 서비스 컴포넌트에서는 기능적 및 기술적 컴포넌트 모두를 사용합니다. 또한 이 서비스 컴포넌트를 실현하는 방법을 결정해야 합니다. 이는 단순히 결정을 "구매 또는 빌드"하는 것이 아닙니다. 기타 고려해야 할 사항은 다음과 같습니다.

  • 규칙 추출 또는 기존 코드의 복제본 작성 및 정의된 인터페이스가 있는 컴포넌트로 수행하도록 재작성하는 것과 연관된 변환
  • 메시지 전달 또는 랩퍼로 통합

예제

렌트카 예제에 대한 실현(realization) 결정을 캡처하려 하지만 많은 예제에서 사용한 UML 모델에서 캡처하기는 어렵습니다. 이 프로세스에 도움이 되도록 아래 그림의 표시대로 실현(realization) 메트릭스 템플리트를 이 결정의 결과를 문서화하는 데 사용할 수 있습니다.

개발 접근 방식 결정

선택사항의 이점은 어떤 방법을 선택해도 유스 케이스 모델에서 디자인 모델, 또한 구현으로의 추적성 관점에서 각 방법 간의 연관성이 존재한다는 것입니다.

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

서비스 모델은 디자인 모델을 사용하여 실현하도록 권장합니다. 이 모델을 사용하는 경우 디자이너구현자는 디자인 모델에 패턴을 적용하고, 구현 아티팩트를 생성하기 전에 추가 기능 및 구조를 모델링할 수 있습니다.

기존 자산의 세부화된 맵핑

일반적으로 솔루션 지원 기능성을 제공하거나 솔루션이 상호작용해야 하는 기존 응용프로그램을 고려하지 않고 솔루션을 빌드해서는 안됩니다. 따라서 솔루션의 일부로 재사용될 기존 레거시 응용프로그램을 카탈로그화하고 해당 기능성을 식별해야 합니다. 서비스 지향 솔루션을 사용하면 여러 루트를 통해 새 서비스와 기존 기능성을 통합할 수 있습니다. 해당 방법은 다음 그림을 참조하십시오.

  • 기존 기능을 서비스로 랩핑. 이 경우 현재 기능을 유지하되, 기존 기능을 서비스로 제공하는 도구 또는 미들웨어를 사용합니다. 예를 들어, IBM은 레거시 CICS 트랜잭션을 SOAP 웹 서비스로 제공하는 기능을 제공합니다.
  • 기존 기능을 랩핑하고 서비스로 바꾸기. 이 경우 위와 같이 기능을 랩핑하되, 결과 서비스 스펙을 사용하여 나중에 원래 서비스를 바꾸고 클라이언트를 새 구현으로 다시 지정하여 서비스를 재개발합니다.
  • 서비스 호출에 보다 적합한 어댑터 사용. 기능을 랩핑하고 서비스로서 제공할 수 없는 경우도 있지만 메시지 대기열 지정 인터페이스 또는 JCA(Java Connector Architecture)와 같이 통합이 보다 용이한 상태로 기능을 랩핑할 수 있습니다. 이 방법을 사용하면 새 서비스로 해당 기능에 액세스할 수 있습니다.
  • 기능을 서비스로 통합. 경우에 따라, 서비스 구현 내 논리 컴포넌트로서 기능을 사용하여 새 서비스로 해당 레거시 기능에 액세스할 수 있습니다.

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

세 번째, 네 번째 옵션의 경우 기존 기능을 사용하되, 현재 기능을 클라이언트에게 지속적으로 제공하지 않으므로 보다 유연한 방법입니다. 반대로, 첫 번째, 두 번째 옵션의 경우 기존 기능의 서비스 랩핑과 관련된 문제가 발생할 수 있습니다. 웹 서비스 프로토콜의 성능으로 인해 또한 기본 데이터 형식과 XML이 일치하지 않아 성능 문제가 발생할 수 있기 때문입니다.

기존 소프트웨어 자산 및 해당 종속성과 인터페이스를 분석하여 비즈니스 기능성 지원을 변경해야 할 지 여부를 결정해야 합니다. 예를 들어, 비즈니스 기능의 레거시 구현을 위해 웹 서비스 인터페이스를 작성하려면 분석 시 온라인 트랜잭션이나 일괄처리 작업 또는 지속적인 데이터 스토어(기능 수행에 도움이 됨)의 컴포지션 및 플로우를 검토해야 합니다.  이 기존 응용프로그램의 현재 디자인은 기능성을 지원할 수 있도록 변경해야 합니다.  또한 웹 서비스 인터페이스를 원하는 품질의 서비스로 작성하는 데 있어서의 잠재적인 장벽을 모두 식별해야 합니다.  예를 들어, 비즈니스 기능의 모놀리식 일괄처리 구현에는 서비스로 호출되는 초 단위 이하 응답 시간이 필요합니다.  

기존 자산을 서비스 패턴으로 랩핑

그러나 경우에 따라서는 하위 레벨 레거시 기능 세트가 개별 서비스로 제공되는 레거시 서비스 파티션을 개발하는 것이 효과적입니다. 이 파티션은 보다 세분화된 비즈니스 관련 스펙을 이용자에게 제공하는 데 해당 기능을 활용하는 상위 레벨 서비스만 액세스할 수 있습니다. 이러한 레거시 기능 캡슐화는 일시적인 솔루션이므로 랩핑 기술의 성능 특성을 잘 이해하는 경우에만 실행해야 합니다. 자세한 정보는 솔루션 파티션 개념을 참조하십시오.

레거시 기능 랩핑에 대한 또 다른 평가는 매우 단순화된 서비스 제공자 모델 요소 양식이라는 점입니다. 즉, 단일 서비스가 단일 오퍼레이션으로 단일 스펙을 실현합니다. 다음 다이어그램은 레거시 기능 "UpdateCustomerAddress"에 대한 이 패턴을 보여줍니다.

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

이 패턴을 사용자 조정할 때는 다음 작업을 수행할 수 있습니다.

  • 기존 기능 세트를 동일한 컴포넌트가 제공하므로 동일한 서비스 제공자를 사용해야 합니다.
  • 위의 패턴은 자동으로 생성되었으므로 "exec${service}"에서 기본 오퍼레이션 이름을 바꾸는 것이 좋습니다.
  • 마찬가지로, 기본적으로 생성된 메시지의 이름도 바꾸는 것이 좋습니다. 또한 이 시점에서 메시지 구조를 모델링해야 합니다.
  • 기본 패턴에서는 오퍼레이션이 메시지 입력을 가져와 메시지를 리턴하는 것으로 가정합니다. 레거시 기능은 메시지를 리턴하지 않거나 알림 전용이므로 생성된 오퍼레이션의 서명을 수정해야 합니다.
  • 설계자/디자이너는 서비스 제공자의 "allowedBindings" 특성에 올바른 값이 지정되었는지 확인해야 합니다.
자세한 정보