Example: ServicesArchitecture (SoaML), Concept: Service Composition and Choreography, and Example: Sample SoaML Design Model illustrate the elements of a ServicesArchitecture,
which is a stereotyped UML collaboration:
- Collaboration parts, which interact to solve a business problem. In the
most general case, the parts will have only role names to illustrate the roles
that are involved in the collaboration. In a concrete ServicesArchitecture
-- one that shows which specific Participants in the solution space are being
used to address the problem -- the roles are typed with Participants.
-
CollaborationUses, which are used to bind the parts to the roles that they play
in the ServiceContracts or in the ServiceInterface protocols that govern the
interactions of the parts.
-
An ownedBehavior (such as an Activity or an Interaction), which is used to explicitly illustrate how the parts
interact to solve the problem.
-
A structure diagram, which is used to connect the parts to the roles they play in the Collaboration Uses.
Build each ServicesArchitecture by following these steps:
- Identify the services that need to be involved in the solution. This information
can be gleaned from the roles that were involved in the original Service
Collaborations. The required services will be the ones that were derived
previously from the Service Collaboration roles.
- Identify the Participants that provide the necessary services. Add them
to the ServicesArchitecture as parts.
- Identify the ServiceContracts or the ServiceInterface protocols that govern
the interactions of the Participants that are involved in the ServicesArchitecture.
Create a CollaborationUse for each such collaboration, and add it to the ServicesArchitecture.
- In the ServicesArchitecture's structure diagram, bind all of the parts
to the appropriate roles of the CollaborationUses.
- Check your work. Leverage the ServiceContract and protocol behaviors to create
a behavior for the ServicesArchitecture that shows how all of the involved
services interact to address the problem. The resulting behavior is expected
to be a concrete rendering of the role-based behavior that was created for
the original Service Collaboration.
|