SOA Reference Ontology, published by OASIS last month, is an extension of OASIS Reference Model for Service Oriented Architecture (SOA-RM) combining it with the key concepts of semantics that are relevant for Semantically-enabling Service Oriented Architectures.
As defined by the standard:
A key limitation of a "classical SOA"... is that the standards used for describing Web services provide very little detail about the service, beyond a simple description of the external interface they provide. With these descriptions it is impossible to provide further meaning about a service, such that reasonable inferences can be drawn regarding the functionality offered by the service, or the behavior of its outwardly facing interfaces.
SOA Reference Ontology standards provides means for overcoming this limitation through usage of ontologies:
By extending ontologies to describe services in a SOA, a machine can reason about the functionality they provide, the mechanism to invoke them, and the data they expect as input and return as output. In other words each service that currently has a syntactic description (i.e., a WSDL document) will also have a semantic description in some formalism. Thus services within a Semantic SOA are not a reinvention of services, but an enhancement of them. In order to effectively describe services semantically we need to have an understanding of what elements need to be modeled within our semantic description. Within this document you will find the Reference Ontology for Service Oriented Architectures, which provides such a description of what elements need to be modeled in order to effectively provide semantic description for services and build a SOA that is semantically-enabled, referred to as a Semantic SOA (SSOA).
The two fundamental principles of the semantics-based approach, introduced by the standard, are:
- all descriptions of service-oriented concepts should be made in an ontology-based formalism;
- all ontology-based descriptions should be capable of being connected via mediation.
The first principle is implemented in standard by associating semantic descriptions with all SOA resources. These descriptions allows for both functional, including behavioral, and non-functional descriptions of the service and are grounded to concrete service realizations, such that once the semantic description is known, the implementation of the service can be found as well.
Introduction of service descriptions allows to formalize selection of the appropriate service, based on the goals of the service requester. In order to facilitate the matchmaking process between requester goals and provider services
... the Reference Ontology defines a GoalDescription as being formed from the same elements as a ServiceDescription: namely a CapabilityDescription and a set of Interfaces. The CapabilityDescription of a GoalDescription represents the requested capability, i.e. the capability the requester desires to find and consume. The Interface of a GoalDescription describes the interfaces the requester intends to use during the communication with the matching service.
A standard describes Capability in terms of state of the world’s conditions that must exist so the execution of the service to be possible and state of the world’s conditions to be guaranteed to hold after service’s execution. It further distinguishes between the state of the information and the state of the real world. As a result, Capability can be broken down into two groups: preconditions and post-conditions, describing the state of the information space and assumptions and effects, defining the state of the real-world. By providing these 4 elements, the Reference Ontology allows the state change that occurs in both the information space and in the real world to be effectively described.
Following SOA-RM, which specifies "the service interface as the means for interacting with a service" and consists of two parts, Information Model and Behavioral Model, SOA Reference Ontology defines semantic definitions for both Information and Behavioral models:
...information model is based on an ontological description, and needs to be considered both by the capability and the interface, so this is attached directly to the service (or goal) description... for Semantic SOA this [model] is provided by the domain ontology of the service; this ontology specifies all the information needed for the service execution and for its communication with other services or with the requestors.
...behavioral model is specialized into two different concepts, representing different perspectives:
- Service requester perspective - the information that is needed for service execution by the service requester, specified as Choreography;
- Communication with other services - information on how the service can coordinate the cooperation between other services in order to fulfill its functionality, specified as the Orchestration.
For Semantic SOA this [model] is encapsulated by the definition of what information needs to be exchanged during the communication, the concepts and relations of an ontology being marked to support a particular role (or mode). Furthermore, the order in which the messages are exchanged needs to be unambiguously specified
The mediation principle is based on SOA RM definitions of Visibility - "the relationship between service consumers and providers that is satisfied when they are able to interact with each other" and a mediator, which is described in terms of the entities it is able to connect with each other and states how it will resolve mismatches.
The standard defines the following types of mediators:
- Ontology to Ontology mediators (OO-Mediators) connect ontologies and resolve terminological and representational mismatches;
- Service Description to Service Description mediators (SS-Mediators) connect service descriptions resolving mismatches between the representation of their functionality and/or in the means by which they are accessed (i.e., between their capabilities and/or interfaces);
- Goal Description to Goal Description mediators (GG-Mediators) connect Goal descriptions resolving mismatches in the requirements of the service requestor, again either in capability or interface terms;
- Service Description to Goal Description (SG-Mediators) connect Service descriptions and goal descriptions, mediating between the consumer’s and provider’s viewpoint of the functionality and/or its access.
Different mediators can be grouped together in a mediation service:
This mechanism allows Mediators to be used to describe pieces of functionality offered by complex services that are able to perform concrete mediation scenarios. A mediation service can either be a Goal or a Service Description. The former links to a Goal that is to be used in the discovery process to find a Service offering the functionality described by the Mediator, while the latter directly links to a Service that is able to offer the functionality described by the Mediator.
By publishing the description of the Mediator and all its needed Ontologies, Goal and Service Descriptions, the requirements for Visibility are met, thus allowing a Goal to interact with the Service.
Current working draft will be updated as necessary to bring it up to public review draft status in the coming weeks/months.
