타스크: 서비스 리트머스 테스트 적용
이 타스크에서는 후보 서비스에 권한을 부여하여 실제로 비즈니스 요구를 충족하도록 개발되었는지 확인할 요구사항을 설명합니다.
원칙: 분석 및 디자인
관계
기본 설명

서비스 포트폴리오(분류된)에서 후보 서비스를 선택하고 문서화하면 서비스로 공개해야 하는 후보 서비스를 결정해야 합니다. 이론적으로는 서비스 설명으로서 해당 인터페이스를 내보내기하여 모든 후보 서비스를 공개할 수 있지만 모든 후보 서비스가 그런 것은 아닙니다. 이는 경제적으로 그리고 실용적으로(비기능적 요구사항이 공개될 수 있음) 실현 가능하지 않을 수도 있습니다. 특히 "모든 클래스에서 모든 메소드"를 공개하는 결정의 결과로 압도적이고 때로 관리 불가능한 수의 서비스에서 "서비스 포트폴리오 신드롬"이 발생합니다. 이렇게 되면 회사의 지적 자본을 제공할 수 있다는 사실 뿐 아니라 엄청난 성능과 서비스 관리 문제점을 작성합니다. 게다가 공개할 모든 서비스와 연관된 비용을 생각해야 합니다. 즉, 서비스의 자금 지원, 관리 및 기본 하부 구조(해당 보안, 성능, 관리)와 서비스를 구현할 컴포넌트를 고려해야 합니다.

따라서 특정 기준으로 서비스를 공개할지, 특히 서비스의 기능성을(서비스의 유지보수, 모니터링, 보안, 성능 및 기타 서비스 레벨 계약을 포함해) 제공할 서비스 컴포넌트 작성에 자금을 지원할지의 여부를 결정합니다.  

서비스 리트머스 테스트

프로젝트 경험으로 서비스 리트머스 테스트의 양식으로 기준 세트를 표시하고, 후보 서비스의 콜렉션을 필터하는 데 사용해야 합니다. 이 메타포는 테스트 세트를 나타내는 데 사용하고 ,적용되면 제공된 서비스가 서비스 설명 사용 시 공개에 적합한지 여부를 결정합니다. 이 테스트는 모두 채택되며 다음과 같은 질문에 응답을 하는 데 도움을 줍니다. 후보 서비스 목록에서 어떤 것이 공개되어야 합니까? 그러면 어떤 후보 서비스에 자금을 지원합니까? 어떤 것에 비즈니스 가치가 있습니까?

모든 비즈니스 유스 케이스는 후보 서비스로 간주될 수 있습니다. 반면에 소수의 서비스는 공개를 위해 선택되었습니다. 서비스 리트머스 테스트를 적용하면 관리 가능한 서비스 세트를 적용하는데, 비즈니스에서 공개될 수 있고 나중에 컴포지션에서 사용될 수 있습니다.

모든 서비스 리트머스 테스트를 전달하는 후보 서비스는 SOA의 서비스로서 공개되어야 합니다. 서비스 리트머스 테스트를 전달하지 않은 후보 서비스가 있지만 여전히 서비스로서 구현됩니다. 서비스 리트머스 테스트는 공개할 서비스를 결정하는 데 도움이 됩니다. 비즈니스에서 서비스 리트머스 테스트를 전달하지 않는 후보 서비스를 공개하도록 선택한 경우, 실현할 SOA 관련 이점을 나타냅니다.

서비스 리트머스 테스트를 충족하지 않는 후보 서비스는 비즈니스 요구를 충족시키는 데 필요한 특정 방법으로 구현해야 합니다. 이 후보 서비스는 서비스 컴포넌트의 메소드로서 구현할 수 있고 WSDL의 생성 또는 기타 양식의 서비스 정의를 필요로 하지 않습니다. 또는 공개 불가능한 엔티티로서 사용할 수 있습니다.

고려사항

서비스 리트머스 테스트를 적용하면 반복 프로세스가 됩니다. 정제(Elaboration)의 첫 단계에서는 현재 지식을 기반으로 결정을 해야 합니다. 그 다음 자세한 정보는 디자인 프로세스 전체에서 얻게 되므로 서비스 리트머스 테스트를 재검토해야 합니다.

각 후보 서비스에 대한 서비스 리트머스 테스트를 적용하고 해당 주제 전문가 또는 이해 당사자가 검토해야 합니다.

서비스 리트머스 테스트의 결과를 검토하는 것은 기준 및 서비스 세분성의 적합성을 따르는 유용한 방법입니다. 예를 들어, 너무 많은 후보 서비스가 특정 테스트를 전달하는 경우, 테스트 정의가 지나치게 넓거나 서비스 레벨 세분성이 적합하지 않습니다.

서비스가 하나 이상의 서비스 리트머스 테스트에 실패할 수 있지만 일부 프로젝트용 결정(비즈니스 또는 IT) 때문에 공개할 수 있습니다. 이렇게 되어도 괜찮습니다. 서비스 리트머스 테스트에도 불구하고 서비스를 공개하도록 아키텍처 또는 비즈니스 결정을 내릴 수 있습니다.

단계
서비스가 비즈니스 연계되는지 확인

서비스의 첫 번째 테스트는 비즈니스 연계에 대한 것입니다. 서비스가 비즈니스 타스크 또는 목적에 대해 추적 불가능한 경우, SOA 구현에 필요한 이점이 없게 됩니다. 모든 대답이 긍정인 경우, 다음 질문은 서비스가 비즈니스와 연계되어 있음을 의미합니다.

  • 서비스에서 비즈니스 프로세스 및 목적을 지원하는 필수 비즈니스 기능성을 제공합니까?(타스크: 비즈니스 프로세스 분석 참조)
  • 비즈니스는 해당 라이프사이클(제공, 관리 및 유지보수)을 통해 서비스에 자금을 지원합니까?
  • 비즈니스는 서비스를 내부적으로 또는 외부적으로 클라이언트 또는 비즈니스 파트너와 공유하려 합니까? 예를 들어, 추가 비용, 비즈니스 기밀, 보안 등을 의미할 수 있습니다.
  • 엔터프라이즈에 서비스를 재사용할 기존 또는 미래 기회가 있습니까?
서비스가 구성 가능한지 확인

구성 가능성은 서비스가 서비스 컴포지션에 관여할 수 있는 속성으로 정의됩니다. 응용프로그램은 두 가지 유형의 컴포지션을 사용하여 작성할 수 있습니다.

  • 서비스는 컴포지션의 비기능적 요구사항으로 정의된 서비스 속성의 필수 품질을 만족시킵니까?
  • 서비스는 Stateless합니까?(가이드라인: 서비스의 상태 관리 참조)
  • 서비스는 일체 완비형입니까? 서비스가 런타임 시 비즈니스 프로세스를 기타 서비스와 통합할 수 있지만 이 서비스를 독립적으로 배치해 비즈니스 목적을 충족시킬 수 있습니까? 기타 임베디드 기능성에 대한 서비스의 종속성 암시가 없습니다. 모든 종속적 서비스는 바꿀 수 있거나 일체 완비형입니다.
  • 서비스의 구현 기술이 중립적입니까? 중립적 기술은 서비스가 비표준(및 이용자에게 알려지지 않은) 프로토콜 또는 장치 지원을 요구하지 않음을 의미합니다. 예를 들어, 구성 컴포넌트에는 비표준 응용프로그램 인터페이스를 통한 개입이 필요합니다.
    이 테스트는 서비스가 이용자의 환경에 배치된 경우에만 적용됩니다. 예를 들어, 비즈니스는 해당 고객에 대한 이미지 검색 서비스를 제공합니다. 그리고 웹 서비스를 통해 해당 가입 고객에 대해 이 기능을 제공할 수 있습니다. 또는 비즈니스가 해당 고객에게 웹 서비스로 공개된 이미지 검색 기능 및 이미지 콜렉션을 제공할 수 있습니다. 여기서 고객은 기술 검색의 구현으로 인한 부담을 갖게 됩니다.
서비스에 외부 설명이 있는지 확인

대부분의 서비스 기본 특성은 구체화된 서비스 설명이 있다는 것입니다. 구체화된 서비스 설명은 도구를 통해 자동으로 또는 수동으로 생성될 수 있습니다.

  • 서비스에 실제 기본 구현과 다르고 독립적이라는 구체화된 서비스 설명이 있습니까? 이에 대한 현재 예제는 WSDL입니다.
  • 서비스 설명으로 서비스를 찾아 바인드할 수 있습니까?
  • 서비스 설명에는 그 자체에 대한 메타데이터가 있습니까? 즉, 서비스 설명은 자가 충족형이어야 하고 서비스의 이용자와 제공자 간의 메시지 교환을 이해하는 데 필요한 모든 정보를 포함하거나 참조해야 한다는 것입니다.
서비스 재사용가능 확인

이 서비스를 해당 기능이 필요한 모든 프로세스의 비즈니스 이해 당사자(stakeholder)가 사용할 수 있습니까?

서비스가 기술적으로 실현 가능한지 확인

기술적 실현 가능성으로, 사용 가능한 기술을 사용하여 기능적 및 비기능적 요구사항에 따라 실제로 서비스를 실현(구현 및 배치)할 수 있음을 확인합니다.

  • 구현의 요구사항 또는 하부 구조가 제공된 경우, 서비스의 구현 및 관리 노력은 합리적이며 쉽게 달성 가능합니까?
    이것은 실현(realization)의 기술적 실현 가능성 검사 후 이루어집니다.