The results of service-oriented analysis are a set of candidate services. These candidate services should be described in the Service Repository along with descriptive information such as the type of service and its candidate tasks, the purpose of the service, architectural models (e.g. choreography model) and other documentation. A Service Repository could be accessible to a large audience, to promote the review of service candidates within an organization. A Service Repository could also understand the SOA development lifecycle, and help track a service through that lifecycle.

Details

A Service Candidate represents a potential service that may be required to achieve the business goals outlined in the requirements and architecture. A skeleton Service Model may be created as part of this step, to represent the service candidate during the analysis phase.

This step may also identify participants (service candidates) that need further decomposition, resulting in additional scenarios and choreographies. In this case, the service candidates from these further iterations will also be considered.

Repo: Create skeleton service models to represent the service candidates. Provide a description of the service. Set the lifecycle stage to Service-Oriented Analysis. At this point the service is a candidate. It is interesting enough to start gathering information about it, but may not be implemented.

Input: Choreographies

Output: Set of service candidates identified from the Choreography models. Each candidate service represented in service repository with descriptive info about the service types (e.g., Entity, Utility, Task, or Orchestrated) and candidate tasks. Associations with example messages and message schemas, choreographies and scenarios are also defined.