Concept: ServiceInterface (SoaML)
Defines the interface to a Service Point or Request Point and is the type of a role in a service contract.
Relationships
Main Description

Usage:  "ServiceInterface" stereotypes UML Class, Interface

A ServiceInterface defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a ServicePoint or RequestPoint. A ServiceInterface is the means for specifying how a participant is to interact to provide or consume a Service. A ServiceInterface can 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 can address the concepts associated with ownership, ownership domains, actions communicated between legal peers, trust, business transactions, authority, delegation, etc.

A ServicePoint or RequestPoint or role can 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 can also specify various protocols for using the functional capabilities defined by the service interface. This provides reusable protocol definitions in different Participants providing or consuming the same Service.

A ServiceInterface can 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.  They 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 can be used to match needs and capabilities.

A service interface might itself have service points or request points 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. Internal to a participant, connections can be made for the entire service or any one of the subservices, allowing delegation of responsibility for specific parts of the service contract.

A ServiceInterface can fulfill zero or one ServiceContracts by binding the parts of the service contract to the ServiceInterface. Fulfilled contracts can define the functional and nonfunctional requirements for the service interface, the objectives that are intended to be fulfilled by providers of the service, and the value to consumers. In all cases, the specifications of the ServiceContract and the ServiceInterface must not be in conflict.

There is 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, such as composite services, and where a service architecture is being defined.  "Standalone" service interfaces with locally-defined behaviors can be used for context independent services. However, there is some overlap in specification capability, and either or both can be used in some cases.

Semantics

A ServiceInterface defines a semantic interface to a Service or Request. It defines the structural and behavioral semantics of the service necessary for consumers to determine if a service typed by a ServiceInterface meets their needs.  It also defines what consumers and providers must do to carry out the service. A ServiceInterface defines the information shown in the following table.  All the information listed below is not required for every ServiceInterface.



Function Metadata

An indication of what the service does or is about

The ServiceInterface name

The service defined by the ServiceInterface that will be provided by any Participant having a Service typed by the ServiceInterface, or used by a Participant having a Request typed by the ServiceInterface.

The provided Interfaces containing Operations modeling the capabilities. As in UML2, provided interfaces are designated using an InterfaceRealization between the ServiceInterface and other Interfaces.

Any service interaction consumers are expected to provide or consume in order to use or interact with a Service typed by this ServiceInterface.

Required Interfaces containing Operations modeling the needs. As in UML2, required interfaces are designated using a Usage between the ServiceInterface and other Interfaces.

The detailed specification of an interaction providing value as part of a service including:

  1. Its name, often a verb phrase indicating what it does.
  2. Any required or optional service data inputs and outputs.
  3. Any preconditions consumers are expected to meet before using the capability.
  4. Any post conditions consumers participants can expect, and other providers must provide upon successful use of the service.
  5. Any exceptions or fault conditions that might be raised if the capability cannot be provided for some reason even though the preconditions have been met.

Each atomic interaction of a ServiceInterface is modeled as an Operation or event reception in its provided or required Interfaces. From UML2, an Operation has Parameters defining its inputs and outputs, preconditions and post-conditions, and can raise Exceptions. Operation Parameters also can be typed by a MessageType.

Any communication protocol or rules that determine when a consumer can use the capabilities or in what order.

An ownedBehavior of the ServiceInterface. This behavior expresses the expected interaction between the consumers and providers of services typed by this ServiceInterface. The ownedBehavior could be any Behavior including Activity, Interaction, StateMachine, ProtocolStateMachine, or OpaqueBehavior.

Requirements any implementer must meet when providing the service.

This is the same ownedBehavior that defines the consumer protocol just viewed from an implementation rather than a usage perspective.

Constraints that reflect what successful use of the service is intended to accomplish and how it would be evaluated.

UML2 Constraints in ownedRules of the ServiceInterface.

Policies for using the service such as security and transaction scopes for maintaining integrity or recovering from the inability to successfully perform the service or any required service.

Policies also can be expressed as constraints.

Qualities of service consumers can expect and providers are expected to provide such as: cost, availability, performance, footprint, suitability to the task, competitive information, etc.

The OMG QoS specification can be used to model qualities of service constraints for a ServiceInterface.

A service composed of other services as a composite service.

Service point or request point ports on the service interface.


A ServiceInterface specifies its provided capabilities through InterfaceRealizations. A ServiceInterface can realize any number of Interfaces. Some platform specific models might restrict the number of realized interfaces to at most one. A ServiceInterface specifies its required needs through Usage dependences to Interfaces. These realizations and usages are used to derive the provided and required interfaces of Request and Service ports typed by the ServiceInterface.

The parts of a ServiceInterface are typed by the interfaces realized or used by the ServiceInterface. These parts (or roles) can be used in the ownedBehaviors to indicate how potential consumers and providers of the service are expected to interact. A ServiceInterface can specify communication protocols or behavioral rules describing how its capabilities and needs must be used. These protocols can be specified using any UML2 Behavior.

A ServiceInterface can have ownedRules which determine the successful accomplishment of its service goals. An ownedRule is a UML constraint within any namespace, such as a ServiceInterface. 
 

More Information