SOA-RM Wiki
1. Service Description
<describe service description> It is beneficial if service descriptions are based on widely adopted standards within the industry. Illustration 1 depicts the SOA elements for description. Note: The open diamonds are for aggregation and the closed diamonds are for composition. In UML, composition is a stronger form of aggregation. In composition, the object lives and dies with its parent. In aggregation, the object could live as part of another object. A car has an aggregation of wheels while the body has a composition of hands.
Illustration 1 - Service Description
- Service Reachability - The ability for service participants to locate and interact with one another. Reachability includes communication protocols.
- Service Functionality - An unambiguous expression of service function(s) and the real world effects of invoking the function.
- Interaction Policies - Information for prospective consumers pertaining to constraints of the usage of a service.
- Information Model - A definition of the data model required to invoke service actions.
- Behavior Model - The characterization of (and responses to, and temporal dependencies between) the actions on a service.
- Action Model - The description of actions that may be invoked against a service.
- Process Model - The temporal relationships between service actions and events.
<from interacting w/services> It should be noted that a service description is actually an artifact, usually a document-based artifact, that references not only the information and behavior models associated with a service but also provides data associated with service reachability, service functionality?, describes the service interface, and specifies the policies and contracts associated with a service.</from interacting w/services>
1.1. Service Description Versioning
Describe support for service description versioning.
1.2. Consumer Description
Illustration - Consumer Description
1.3. Projecting the RA Service Description into a Fully Automated Reference Implementation - Temporary, To Be Removed
Standard and technology descriptions are for example purposes only.
The entire service description could be a meta model that can be used for automated generation of service description artifacts stored in a registry/repository. The meta model provides flexibility for different implementation technologies and standards.
Service Reachability could become the wsdl address bindings for UDDI or ebXML. The RM also suggests communication protocols be part of Service Reachability.
Service Functionality describes real world effects and constraints of the functions of a service. This could be easily confused with the Action Model, however, service functionality can relate to more than the individual service actions. The Service Functionality Model could define measurability mechanisms that verify the service satisfies the expected capability. Additional constraints on the service can be imposed by Service Functionality.
Interaction Policies could be XACML policies processed by PDPs.
For Web Services, the combination of the Information model and the Action Model could become the WSDL.
The Process Model could be translated into a machine processable artifact that could be used like a schema for message flow validation of the single service. The Process Model contains the Message Exchange Patterns (MEPS) for the service. The Process Model could also be used by Service Orchestration for the automation of higher order service interactions.
What's not listed in the SOA RM but has to be done for an implementation is Service Description versioning and version compatibility.