Usage: "ServicesArchitecture" stereotypes UML Collaboration
A ServicesArchitecture (a SOA) describes how Participants work together for a purpose by providing and using services expressed as service contracts. By expressing the use of services, the ServicesArchitecture
implies some degree of knowledge of the dependencies between the Participants in some context. Each use of a service in
a ServicesArchitecture is represented by the use of a ServiceContract bound to the roles of Participants in that
architecture.
Use of a ServicesArchitecture is optional but is recommended to show a high level view of how a set of
Participants work together for some purpose. Whereas simple services might not have any dependencies or links to a
business process, enterprise services can often only be understood in context. The services architecture provides that
context, and it might also contain a behavior, which is the business process. The Participants' roles in a services
architecture correspond to the swim lanes or pools in a business process.
A Participant can play a role in any number of services architectures. Each role that it
plays can impose additional requirements upon the Participant.
The internal behavior of each Participant that is involved in a ServicesArchitecture might itself be described using a
ServicesArchitecture. This situation arises, for example, when a Participant that is involved in a
ServicesArchitecture is, itself, a provider of a composite service. In this case the run-time relationships between, and the
behavior of, the Participant instances that drive the composite can be described using a ServicesArchitecture.
Semantics
Standard UML2 Collaboration semantics are augmented with the requirement that each
Participant used in a services architecture must have a port compliant with the ServiceContracts the Participant
provides or uses. Model the compliance by binding one of the roles of the ServiceContract usage (a
CollaborationUse) to the port.
|