서비스 포트폴리오(분류된)에서 후보 서비스를 선택하고 문서화하면 서비스로 공개해야 하는 후보 서비스를 결정해야 합니다. 이론적으로는 서비스 설명으로서 해당 인터페이스를 내보내기하여 모든 후보 서비스를 공개할 수
있지만 모든 후보 서비스가 그런 것은 아닙니다. 이는 경제적으로 그리고 실용적으로(비기능적 요구사항이 공개될 수 있음) 실현 가능하지 않을 수도 있습니다. 특히 "모든 클래스에서 모든 메소드"를
공개하는 결정의 결과로 압도적이고 때로 관리 불가능한 수의 서비스에서 "서비스 포트폴리오 신드롬"이 발생합니다. 이렇게 되면 회사의 지적 자본을 제공할 수 있다는 사실 뿐 아니라 엄청난 성능과 서비스 관리 문제점을
작성합니다. 게다가 공개할 모든 서비스와 연관된 비용을 생각해야 합니다. 즉, 서비스의 자금 지원, 관리 및 기본 하부 구조(해당 보안, 성능, 관리)와 서비스를 구현할 컴포넌트를 고려해야 합니다.
따라서 특정 기준으로 서비스를 공개할지, 특히 서비스의 기능성을(서비스의 유지보수, 모니터링, 보안, 성능 및 기타 서비스 레벨 계약을 포함해) 제공할 서비스 컴포넌트 작성에 자금을 지원할지의 여부를 결정합니다.
서비스 리트머스 테스트
프로젝트 경험으로 서비스 리트머스 테스트의 양식으로 기준 세트를 표시하고, 후보 서비스의 콜렉션을 필터하는 데 사용해야 합니다. 이 메타포는 테스트 세트를 나타내는 데 사용하고 ,적용되면 제공된
서비스가 서비스 설명 사용 시 공개에 적합한지 여부를 결정합니다. 이 테스트는 모두 채택되며 다음과 같은 질문에 응답을 하는 데 도움을 줍니다. 후보 서비스 목록에서 어떤 것이 공개되어야 합니까? 그러면 어떤 후보
서비스에 자금을 지원합니까? 어떤 것에 비즈니스 가치가 있습니까?
모든 비즈니스 유스 케이스는 후보 서비스로 간주될 수 있습니다. 반면에 소수의 서비스는 공개를 위해 선택되었습니다. 서비스 리트머스 테스트를 적용하면 관리 가능한 서비스 세트를 적용하는데, 비즈니스에서 공개될 수
있고 나중에 컴포지션에서 사용될 수 있습니다.
모든 서비스 리트머스 테스트를 전달하는 후보 서비스는 SOA의 서비스로서 공개되어야 합니다. 서비스 리트머스 테스트를 전달하지 않은 후보 서비스가 있지만 여전히 서비스로서 구현됩니다. 서비스 리트머스 테스트는
공개할 서비스를 결정하는 데 도움이 됩니다. 비즈니스에서 서비스 리트머스 테스트를 전달하지 않는 후보 서비스를 공개하도록 선택한 경우, 실현할 SOA 관련 이점을 나타냅니다.
서비스 리트머스 테스트를 충족하지 않는 후보 서비스는 비즈니스 요구를 충족시키는 데 필요한 특정 방법으로 구현해야 합니다. 이 후보 서비스는 서비스 컴포넌트의 메소드로서 구현할 수 있고 WSDL의 생성 또는 기타
양식의 서비스 정의를 필요로 하지 않습니다. 또는 공개 불가능한 엔티티로서 사용할 수 있습니다.
고려사항
서비스 리트머스 테스트를 적용하면 반복 프로세스가 됩니다. 정제(Elaboration)의 첫 단계에서는 현재 지식을 기반으로 결정을 해야 합니다. 그 다음 자세한 정보는 디자인 프로세스 전체에서 얻게 되므로 서비스
리트머스 테스트를 재검토해야 합니다.
각 후보 서비스에 대한 서비스 리트머스 테스트를 적용하고 해당 주제 전문가 또는 이해 당사자가 검토해야 합니다.
서비스 리트머스 테스트의 결과를 검토하는 것은 기준 및 서비스 세분성의 적합성을 따르는 유용한 방법입니다. 예를 들어, 너무 많은 후보 서비스가 특정 테스트를 전달하는 경우, 테스트 정의가 지나치게 넓거나 서비스
레벨 세분성이 적합하지 않습니다.
서비스가 하나 이상의 서비스 리트머스 테스트에 실패할 수 있지만 일부 프로젝트용 결정(비즈니스 또는 IT) 때문에 공개할 수 있습니다. 이렇게 되어도 괜찮습니다. 서비스 리트머스 테스트에도 불구하고 서비스를
공개하도록 아키텍처 또는 비즈니스 결정을 내릴 수 있습니다.
|