In the current Eclipse tools, that use the pi4soa Scenario and Choreography based models for defining requirements and architectural models, this phase would be achieved by defining the Participants and Roles within the choreography model.
When a choreography description is initially created, using the New->Other->Choreography->Choreography Description menu item, the roles and relationships can be defined on the first tab.
Default participant types are automatically created, one per role, and can be found on the Base Types tab. For example,
Only these components need to be specified in the choreography model. This enables them to be referenced in the subsequently defined scenarios. Otherwise it would be necessary to return to the scenarios, once the choreography model had been defined in the Architecture phase.
When designing a system, it is necessary to capture requirements. Various approaches can be used for this, but currently there are no mechanisms that enable the requirements to be documented in such a way to enable an implementation to be validated back against the requirements.
The pi4soa tools provide a means of describing requirements, representing specific use cases for the interactions between a set of cooperating services, using scenarios - which can be considered similar to UML sequence diagrams that have been enhanced to include example messages.
In the purchasing Eclipse project, the
SuccessfulPurchase.scn scenario looks like this:
The business requirements can therefore defined as a set of scenarios, each demonstrating a specific use-case, or path through the business process being enacted.
The next step is to create the example messages required by the scenarios.
Some previously defined examples can be found in the purchasing
Eclipse project. For example, the Buy request is defined as:
<tns:BuyRequest xmlns:tns="http://www.jboss.org/examples/store"
id="1" />
Although a schema may not have been defined at this stage, unless one previously existed that is being reused, it is a good idea to define a namespace for the message type. This is because it will be used within the scenarios and architectural models defined in the following stage. If the namespace was not specified at this stage, then the example messages, scenarios and architectural models would need to be updated at a later stage.
Although this phase has been defined following the definition of the scenarios, in practice these phases are iterative. So scenarios and example messages would be defined concurrently. Similarly, new participants may be added in an evolutionary manner, as scenarios are created that require them.