Usage: "ServiceContract" stereotypes UML Collaboration
A ServiceContract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value, and obligations will flow
between the providers and consumers of that service. It specifies the service without regard for realization,
capabilities, or implementation. A ServiceContract does not require the specification of who, how, or why any party
will fulfill their obligations under that ServiceContract, thus providing for the loose coupling of the SOA paradigm.
In most cases a ServiceContract will specify two roles (provider and consumer), but other service roles might be
specified as well. The ServiceContract might also own a behavior that specifies the sequencing of the exchanges between
the parties, as well as the resulting state and delivery of the capability. The owned behavior is the choreography of
the service. It can use any of the standard UML behaviors, such as an interaction, timing, state, or activity
diagram.
Enterprise services frequently are complex and nested (for example, placing an order within
the context of a long-term contract). A ServiceContract can use other nested ServiceContracts, representing nested
services, as CollaborationUses. Such a nested service is performed and completed within the
context of the larger grained service that uses it. A ServiceContract using nested ServiceContracts is called a
compound service contract.
One ServiceContract can specialize another service contract using UML generalization. A specialized
contract must comply with the more general contract, but it can restrict the behavior and/or operations used. A
specialized contract can be used either as a general contract, or as a specific agreement between specific parties
for their use of that service.
A ServiceContract is used to model an agreement between two or more parties. It can constrain the
expected real world effects of a service. ServiceContracts can cover requirements, service interactions, quality of
service agreements, interface and choreography agreements, and commercial agreements.
Each service role in a service contract has a type, which must be a ServiceInterface or UML Interface, and which usually represents a provider or
consumer. The ServiceContract is a binding agreement on entities that implement the service types. That is, any party
that "plays a role" in a ServiceContract is bound by the service agreement, exchange patterns, behavior, and
MessageType formats. There are various ways to bind to or fulfill such an agreement, but compliance with the
agreement is ultimately required to participate in the service.
Semantics
ServiceContract shares all the semantics of UML2 Collaboration. It extends those
semantics by making the service contract binding on the types of the roles, without a collaboration use being required.
Any behavior specified as part of a ServiceContract is then a specification of how the parties that use that service
must interact. By typing a port with a ServiceContract that is the type of a role in a ServiceContract, the participant
agrees to abide by that contract.
Where a ServiceInterface has a behavior and is also used as a type in a ServiceContract,
the behavior of that ServiceInterface must comply with the service contract. However, common practice would be to
specify a behavior in the service contract or service interface, not both.
|