At this stage it is appropriate to define the internal logic for the candidate services. The way in which this is achieved may be specific to the nature of the service, and the runtime technology selected to implement the service.

In the case of orchestrated services, a standard notation such as the BPMN2 Process Model should be used. This will provide a structured description of the service behavior that can be compared against the relevant choreography models. It can also be used to conformance check the implementations that are derived from the BPMN2 Process Model (assuming that a suitable implementation language is used).

However in the case of other service types, it may be more appropriate to select the design approach that is most suited to the implementation technology that has been selected. For example, entity services may best be designed using specific tools, such as Hibernate's entity schema design tools. Equally some task services may be implemented with rules, using Drools Guvnor to author and manage the rules and Drools Server to execute the rules via a Web service interface.

Where possible, standard design notations should be used, as this will make it easier to incorporate the artifacts into the “testable architecture” concept. However it is also important that the tools be productive, and therefore enable the service designer to use the most appropriate tool for the job. If design time validation of the artifacts is not possible due to using unsupported design artifact formats, then these services can be validated during the test and subsequent runtime monitoring phases.

An example of the BPMN that may be generated for the purchase example is:

When using runtime technology specific design tools, it may be the case that the 'service contracts' are defined 'bottom up'. Once the contract has been refined as part of the design stage, it may be necessary to return to the analysis scenarios, and architectural (choreography) models, to accommodate the actual service interface supported by the design/implementation. This is another case of the iterative nature of the methodology.

Details

Repo: Store detailed service design artifacts, with dependencies to service contract

Input: Public process model and/or service interface

Output: Detailed service design artifacts