7.1.17 ServiceContract

A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service.

 

Extends Metaclass

• Collaboration

 

Description

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 may be specified as well. The ServiceContract may 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 and may use any of the standard UML behaviors such as an interaction, timing, state or activity diagram.

 

Enterprise services are frequently complex and nested (e.g., placing an order within the context of a long-term contract).  A ServiceContract may use other nested ServiceContracts representing nested services as a CollaborationUse.  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 may specialize another service contract using UML generalization.A specialized contract must comply with the more general contract but may restrict the behavior and/or operations used.  A specialized contract may be used as a general contract or as a specific agreement between specific parties for their use of that service.

 

A ServicesContract is used to model an agreement between two or more parties and may 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 or Class stereotyped as «Provider» or «Consumer».  The ServiceContract is a binding agreement on entities that implement the service type.  That is, any party that “plays a role” in a Service Contract is bound by the service agreement, exchange patterns, behavior and MessageType formats.  Note that 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.  Due to the binding agreement, where the types of a service contract are used in a Service or Request no collaboration use is required.

 

The Service contract is at the middle of the SoaML set of SOA architecture constructs. The highest level is described as a services architectures (at the community and participant levels) – were participants are working together using services.  These services are then described by a ServiceContract. The details of that contract, as it relates to each participant, uses an Interface which in tern has operations that use the message data types that flow between participants.  The service contract provides an explicit but high-level view of the service where the underlying details mat be hidden or exposed, based on the needs of stakeholders.

 

A ServiceContract can be used in support of multiple architectural goals, including:

 

1.  As part of the Service Oriented Architecture (SOA), including services architectures, participant architectures, information models and business processes.

 

2.   Multiple views of complex systems

 

o A way of abstracting different aspects of services solutions

o Convey information to stakeholders and users of those services

o Highlight different subject areas of interest or concern

3.   Formalizing requirements and requirement fulfillment

 

o Without constraining the architecture for how those requirements might be realized

 

o Allowing for separation of concerns.

4.   Bridge between business process models and SOA solutions

 

o Separates the what from the how

 

o Formal link between service implementation and the contracts it fulfills with more semantics than just traceability

 

5.   Defining and using patterns of services

 

6.   Modeling the requirements for a service

 

o Modeling the roles the consumers and providers play, the interfaces they must provide and/or require, and behavioral constraints on the protocol for using the service.

 

o The foundation for formal Service Level Agreements

7.   Modeling the requirements for a collection of services or service participants

 

o Specifying what roles other service participants are expected to play and their interaction choreography in order to achieve some desired result including the implementation of a composite service

 

8.   Defining the choreography for a business process

 

Attributes

 

No new attributes.

 

Associations

 

No new associations.

 

Constraints

 

If the CollaborationUse for a ServiceInterface in a services architecture has isStrict=true (the default), then the parts must be compatible with the roles they are bound to. For parts to be compatible with a role, one of the following must be true:

 

1.   The role and part have the same type,

 

2.   The part has a type that specializes the type of the role,

 

3.   The part has a type that realizes the type of the role, or

 

4.   The part has a type that contains at least the ownedAttributes and ownedOperations of the role. In general this is a special case of item 3 where the part has an Interface type that realizes another Interface.

 

5.   The type of each role in a service contract shall have a uses dependency to the type of all roles that role is connected to.

 

Semantics

 

Each ServiceContract role has a type that must be a UML Interface or (in the case of a composite service contract) a ServiceInteface or Class.  At least one such interface must be stereotyped as a «Provider» and one as a «Consumer».  The ServiceContract is a binding agreement on participants that implements the service type.  That is, any party that “plays a role” in a Service Contract is bound by the service agreement, interfaces, exchange patterns, behavior and Message formats.  Note that 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 as a provider or consumer.

 

ServiceContract shares all the semantics of UML2 Collaboration and 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 an interface or class 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.

 

Examples

 

In the context of services modeling, ServiceContracts may be used to model the specification for a specific service. A ServicesArchitecture or ParticipantArchitecture may then be used to model the requirements for a collection of participants that provide and consume services defined with service contracts.

 

When modeling the requirements for a particular service, a ServiceContract captures an agreement between the roles played by consumers and providers of the service, their capabilities and needs, and the rules for how the consumers and providers must interact. The roles in a ServiceContract are typed by Interfaces that specify Operations and events which comprise the choreographed interactions of the services.. A ServiceInterface may fulfill zero or more ServiceContracts to indicate the requirements it fulfills but they are usually one-one.

 

Figure 45 is an example of a ServiceContract. The orderer and order processor participate in the contract.

 

Figure 45: The Ordering Service Contract

 

The service contract diagram shows a high level “business view” of services but includes ServiceInterfaces as the types of the roles to ground the business view in the required details.  While two roles are shown in the example, a ServiceContract may have any number of roles.  Identification of the roles may then be augmented with a behavior. Real-world services are typically long-running, bi-directional and asynchronous.  This real-world behavior shows the information and resources that are transferred between the service provider and consumer.

 

 

Figure 46: Ordering Service communication protocol

 

The above behavior (a UML interaction diagram) shows when and what information is transferred between the parties in the service.  In this case a fulfillPurchaseOrder message is sent from the orderer to the order processor and the order processor eventually responds with a shipment schedule of an order rejected.

 

The service interfaces that correspond to the above types are:

 

Figure 47: Service interfaces that correspond to the above

 

Note that the above interfaces are the types of the roles in the ServiceContract shown in Figure 47.

 

The following example illustrates compound services:

 

Figure 48: Compound Services

 

Real-world services are often complex and made up of simpler services as “building blocks”.  Using services as building blocks is a good design pattern in that it can decouple finer grain serves and make them reusable across a number of service contracts.  Finer grain services may then be delegated to internal actors or components for implementation.  Above is an example of a compound ServiceContract composed of other, nested, ServiceContracts.   This pattern is common when defining enterprise level ServicesArchitectures – which tend to be more complex and span an extended process lifecycle.  The purchasing ServiceContract is composed of 2 more granular ServiceContracts: the “Ordering Service” and the “Invoicing Service”.  The buyer is the  “orderer” of the ordering service and the “invoice receiver” of the invoicing service.  The “Seller” is the “Order processor” of the ordering service and the “invoicer” of the invoicing service.  ServiceContracts may be nested to any level using this pattern.  The purchasing service defines a new ServiceContract by piecing together these other two services.  Note that it is common in a compound service for one role to initiate a sub service but then to be the client of the next – there is no expectation that all the services must go the same direction.  This allows for long-lived, rich and asynchronous interactions between participants in a service.

 

Note: A compound ServiceContract should not be confused with a service that is implemented by calling other services, such as may be specified with a Participant ServicesArchitecture and/or implemented with BPEL.  A compound ServiceContract defines a more granular ServiceContract based on other ServiceContracts.

 

Figure 49: Service Interfaces of a compound service

 

A compound service has service interfaces with ports, each port representing its role in the larger service contract.  The above example shows the Service Interfaces corresponding to the buyer and seller in the purchasing service, a compound service.  Note that the seller has two ports, each corresponding to the roles played in the ordering service and invoicing service.  Likewise, the buyer has two ports corresponding to the roles it plays in the same services.  These ports are typed by the Service Interfaces of the corresponding nested services.  The purchasing service specifies how these classes work together and defines the behavioral specification required for each.

 

When a compound service is used it looks no different than any other service in a

services architecture, thus hiding the detail of the more granular service in the high-level architecture yet providing traceability through all levels.

 

Notation

 

A ServiceContract is designated using the Collaboration notation stereotyped with «ServiceContract» or using the ServiceContract icon decoration: .

 

Additions to UML2

 

ServiceContract is a UML collaboration extended as a binding agreement between the parties, designed explicitly to show a service as a contract that is independent of but binding on the involved parties.

 

7.1.18     ServiceInterface

 

Provides the definition of a service. Defines the specification of a service interaction as the type of a «Service» or «Request» port.

 

Extends Metaclass

 

•    Class

 

Description

 

A ServiceInterface defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request Port. A ServiceInterface is the means for specifying how a participant is to interact to provide or consume a Service. A ServiceInterface may include specific protocols, commands and information exchange by which actions are initiated and the result of the real world effects are made available as specified through the functionality portion of a service. A ServiceInterface may address the concepts associated with ownership, ownership domains, actions communicated between legal peers, trust, business transactions, authority, delegation, etc.

 

A Service port or Request port or role may be typed by either a ServiceInterface or a simple UML2 Interface. In the latter case, there is no protocol associated with the Service. Consumers simply invoke the operations of the Interface. A ServiceInterface may also specify various protocols for using the functional capabilities defined by the servicer interface. This provides reusable protocol definitions in different Participants providing or consuming the same Service.

 

A ServiceInterface may specify “parts” and “owned behaviors” to further define the responsibilities of participants in the service.  The parts of a ServiceInterface are typed by the Interfaces realized (provided) and used (required) by the ServiceInterface and represent the potential consumers and providers of the functional capabilities defined in those interfaces. The owned behaviors of the ServiceInterface specify how the functional capabilities are to be used by consumers and implemented by providers. A ServiceInterface therefore represents a formal agreement between consumer Requests and providers that may be used to match needs and capabilities.

 

A service interface may it self have service ports or request ports that define more granular services that serve to make up a larger composite service.  This allows  “enterprise scale” services to be composed from multiple, smaller services between the same parties.  Internal to a participant connections can be made for the entire service or

any one of the sub-services, allowing delegation of responsibility for specific parts of the service contract.

 

One or more ServiceInterfaces may also be combined in a ServiceContract which can further specify and constrain related services provided and consumed by Participants.

 

 

Note: There is somewhat of a stylistic difference between specifying service roles and behavior inside of a service interface or in a service contract.  In general the service contract is used for more involved services and where a service architecture is being defined, while “standalone” service interfaces may be used