SoaML - ServiceContract

• A ServiceContract defines:
  • terms, conditions
  • interfaces
  • choreography

• A ServiceContract is binding on all participating parties
• A Participant plays a role as the provider or user of services specified by ServiceContracts
• Each role is defined by an Interface or ServiceInterface

• It defines the relationships between a set of roles defined by Interfaces and/or ServiceInterfaces.

• It is the expectation of SoaML that:
  • services may have bi-directional interactions
  • communications may be long-lived and asynchronous

The simpler concept of a request-response function call or invocation 
is a degenerate case of a service, and can be expressed easily by UML 

• Participants can engage in a variety of contracts

• Each time a ServiceContract is used in a ServicesArchitecture; there must also be a compliant port on a participant

Example

Instructions

Service Contract

• A service contract is represented as a UML Collaboration and defines specific roles each participant plays in the service contract
• These roles have a name, an interface type that may be stereotyped as the «Provider» or «Consumer»
• The consumer is expected to start the service, calling on the provider to provide something of value to the consumer

Choreography

• The interaction diagram, above, illustrates the choreography of a service contract
• The interactions are synchronous but they can be be defined using signals, which makes this service contract asynchronous and document oriented, a mainstream SOA best practice

provider : CourseOutlineTarget

• Defines the role of the provider in the CourseOutlinePush service
• The type “CourseOutlineTarget” is the interface that a provider will implement on a port to provide this service (also could be a «ServiceInterface»).

consumer: CourseOutlineSource

• The type of is “CourseOutlineSource” is the interface that a consumer will implement on a port to consume this service (may be empty, indicating a one-way service)

«Provider» CourseOutlineTarget

• Indicates all the operations and signals a providing participant may receive when enacting this service
• CourseOutlineSource uses the CourseOutlineTarget (the dashed line) – this shows that the CourseOutlineSource calls the CourseOutlineTarget (using signals or operations)
• In any bi-directional service the provider will respond to the consumers requests using the CourseOutlineTarget interface

«Consumer» CourseOutlineSource

• Indicates all of the operations and signals a consuming participant will receive when enacting the service with the provider
• In simple unidirectional services, the consumer interface may be missing or empty.

Use of the service contract to define participants

• the case described is marked red in the diagram
• nobleprog.co.uk participant has CourseOutlineSource, it provides this interface
• nobleprog.us participant has CourseOutlineTarget, it provides this interface

• The interfaces are described by the “CourseOutlinePush” behavior and so must abide by that choreography when offering that service

• These ports have “conjugate” provided and required interfaces and are therefore compatible and these ports can be connected to enact the service

• Showing the port name, type and interfaces is a bit overkill, so we usually only show the port type on diagrams

The service contract is a binding contract with respect to the participants.
By using the interfaces of a service contract (CourseOutlineSource and CourseOutlineTarget)
the participants are bound to that contract when interacting via that port.
The interfaces represent the type of each bound party.

This is an extension to the UML concept of a collaboration which is not binding 
without an explicit collaboration use.

Use of «Service» and «Request» (Alternative)

• The case described here is marked green in the diagram above
• An alternative way of using the same interfaces involves the use of «Service» and «Request» ports
• When using this style of modeling the participant’s ports only the Provider interface is used
• The provider interface is used as the type of a «ServicePoint» and also as the type of a RequestPoint.
• Request is a “conjugate” port, that is it inverts the required and provided interfaces.
• Use of Request and «Service» is useful when there is a simple one-way interface (that is the consumer does not have an interface) or for a binary service contract (as shown).
• Note that in the above diagram the type of the nobleprog.co.uk service port is “~CourseOutlineTarget” – this is the CourseOutlineTarget interface, the same as is used in the nobleprog.us port
• The tilde (“~”) indicates that this is the conjugate type
• Since the conjugated type has been used (as indicated by the Request stereotype) the interfaces that are provided and required by a port are exactly the same
• The use of the consumer’s interface or Request yields exactly the same result – it is the modeler’s option which way to use the service contract
• For service contracts with more than two participants the Request method does not work as well.

Exercises

1. Design the same as in the previous exercise (ServiceInterface), but using ServiceContract