Approaches to Service Description

LaTeX Version

Abbildung 1: Common Scenario of a Web Service

Abbildung 2: UDDI, SOAP and WSDL

Abbildung 3: Combining SOA and Semantic Web

• WS-* Standards for Web service description, focusing on WSDL services, 
• RESTful Web Services, follwing Web principles applied to service descriptions, and 
• Semantic Web Services approaches, connecting Semantic Web technologies to annotated Web services. 

WS-* Standards

• Abstract Interface: Via the abstract interface the service is defined. The kind of functionality it provides, the expected input, and the output is defined. 
• Protocol Binding: The binding defines how to access a service with a concrete protocol and data format specification for a particular port type. WSDL currently provides specific binding extensions to SOAP, HTTP GET /POST and MIME formats and protocols, but any other binding mechanisms can also be used. For example, when SOAP messages are exchanged over HTTP, the binding defines which parts of the input message go into the SOAP header and which parts go into the SOAP body. 
• Service Endpoints: The endpoint describes where to access a service and depends largely on the binding in use; for example, the endpoint may be a URL in an HTTP scheme, or an email address in an SMTP scheme. The endpoint tells the exact address where a service can be activated. 

Abbildung 4: WSDL 2.0 Infoset Diagram

RESTful Web Services

• Resource identification through URI, 
• Uniform interface,  
• Self-descriptive messages, 
• Stateful interactions through hyperlinks. 

Incorporating Semantic Web into SOA - Semantic Services Frameworks

Web Service Modeling Ontology (WSMO)

Abbildung 5: WSMO Top Level Notations

• Goals 
  Goals represent user desires, for which fulfilment could be sought by executing a Web service. Ontologies can be used for the domain terminology to describe the relevant aspects. Goals model the user view in the Web service usage process and are therefore a separate top-level entity in WSMO. 
   
• Ontologies 
  Ontologies provide the terminology used by other WSMO elements to describe the relevant aspects of the domains of discourse. According to [?] an ontology is a formal explicit specification of a shared conceptualization. Ontologies define an agreed common terminology by providing concepts, and relationships beween the concepts. In order to capture semantic properties of relations and concepts, an ontology generally also provides a set of axioms, which are expressions in some logical language. 
   
• Web Services 
  A Web service is a computational entity which is able (by invocation) to achieve a users goal. A service in contrast is the actual value provided by this invocation. WSMO provides service descriptions for describing services that are requested by service requesters, provided by service providers, and agreed between service providers and requesters. 
  WSMO Web services describes the computational entity providing access to services that provide some value in a domain. These descriptions comprise the capabilities (describing the Web service by means of its functionality) and interfaces (describing how the functionality of the Web service can be achieved). All these aspects of a Web Service are described using the terminology defined by the ontologies. 
   
• Mediators 
  Mediators describe elements that overcome interoperability problems between different WSMO elements. Mediators are the core concept to resolve incompatibilities on the data, process and protocol level, i.e. in order to resolve mismatches between different used terminologies (data level), in how to communicate between Web services (protocol level) and on the level of combining Web services (and goals) (process level). 
  WSMO distinguishes four different types of mediators [WSMO (2007)]: 
  • ggMediators: mediators that link two goals. This link represents the refinement of the source goal into the target goal or state equivalence if both goals are substitutable. 
  • ooMediators: mediators that import ontologies and resolve possible representation mismatches between ontologies. 
  • wgMediators: mediators that link Web services to goals, meaning that the Web service (totally or partially) fulfills the goal to which it is linked. wgMediators may explicitly state the difference between the two entities and map different vocabularies (through the use of ooMediators). 
  • wwMediators: mediators linking two Web services. 

Abbildung 6: WSMO Mediator Overview

Ontology Web Language for Services (OWL-S)

• a service profile for advertising and discovering services,  
• a process model, which gives a detailed description of a service's operation; and  
• a grounding, which provides details on how to interoperate with a service, via messages.  

Abbildung 7: Top level of the service ontology

• The Service concept serves as an organizational point of reference for declaring Web Services; every service is declared by creating an instance of the Service concept 
• The Service Profile is used to advertise the service. It captures the name of the service, its provider and a natural language description of the service, as well as a black-box description of the Service (specifying the input, output, preconditions and effects (short: IOPE). 
• The Service Model contains descriptive information on the functionality of a service and its composition out of other services, described as a process. Three type of processes, namely atomic, simple, and composite are distinguished. Each of these is described by IOPEs (input, output, preconditions and effects), with optional conditions over these. 
• The Service Grounding describes how an agent can access the service. A grounding can be thought of as a mapping from an abstract to a concrete specification for service usage. Although not restricted to one grounding technology, WSDL is favored for this [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)]. 

Abbildung 8: Mapping between OWL-S and WSDL

Semantic Web Services Framework (SWSF)

1. a conceptual model by which Web services can be described, called Semantic Web Services Ontology (SWSO) and  
2. a language for specifying formal characterizations of Web services concepts and descriptions of individual Web services called Semantic Web Services Language (SWSL). 

• SWSL-FOL based on First-Order Logic or SWSL-Rules based on Logic programming. The resulting ontologies are called: FLOWS—First-Order Logic Ontology for Web Services, which relies on First-Order Logic semantics, and 
• ROWS-Rule Ontology for Web Services, which relies on Logic Programming semantics.  
  Since both representations share the same conceptual model we will focus our overview on FLOWS, the derivation of ROWS from FLOWS being straightforward. 

• First-Order Logic, with the sublanguage SWSL-FOL and  
• Logic Programming, with the sublanguage SWSL-Rules.  

Internet Reasoning Service (IRS-III)

• Supporting Capability Based Invocation - a key feature to invoke services based on the client request by simply specifying a concrete desired capability. In this case the framework acts as a broker finding, composing, and invoking appropriate Web services in order to fulfill the request. 
• Ease of Use - The frameworks interfaces were designed so that much of the complexity surrounding the creation of SWS-based applications are hidden. 
• One Click Publishing - the IRS-III framework provides tools and processes to turn a stand-alone program into a Web service. Thus the framework supports 'one click' publishing of stand-alone code written in a standard programming language (currently Java and Lisp are supported). 
• Agnostic to Service Implementation Platform - This principle is in part a consequent of the one-click-publishing principle. Within the design of the IRS no srong assumptions about the underlying service implementation platform are made. However, the current dominance of the web services stack of standards and consequently program components which are published through the IRS also appear as standard web services with a SOAP based end-point. 
• Connected to the External Environment - When manipulating Web services (manually or automatically) it must be possible to reason about their status. To support this the framework allows functions and relations to be defined which make extra-logical calls to external systems – for example, invoking a Web service. 
• Open - IRS-III should be as open as possible. To support this principle the components of the framework are constracted as Semantic Web services. Hence users can replace the main parts of the IRS broker with their own Web services to suit their own particular needs. Furthermore the clients of the framework are based on Java APIs which are publicly accessible.  
• Inspectibility - This principle is concerned making the semantic descriptions accessible in a human readable form. In IRS-III, the service models are provided from libraries and are inspectable within a purpose built browsing and editing environment. Hence, the developers are able to understand the design and behavior of services being constructed. 

Abbildung 9: The Architecture of the IRS - III Framework

SAWSDL

• Build on existing Web services’ standards - Standards are regarded as key in creating integration solutions. Thus, an upwardly compatible mechanism for adding semantics to Web services is required. 
• Annotations agnostic to the semantics representation language - Web service providers should be able to use different to present their web services. One web service provider should be able to choose more than one representation form in order to enable its discovery by various engines. Hence it should not be prescribed what semantic representation language is to bt used. WSDL-S allows the association of various annotations written in different semantic representation languages. 
• Support annotation of XML Schema data type - SAWSDL supports the annotation of XML Schemas. Annotations are used for adding semantics to inputs and outputs of the Web service. Furthermore, the definition of mappings between the XML Schema complex types and the corresponding ontological concepts is of high relevance. In this context SAWSDL does not prescribe an ontology language. Instead the mapping techniques are directly dependent of the semantic representation language chosen. 
   
• Semantic Model: A semantic model represents a set of machine-interpretable representations used to model an area of knowledge or some part of the world, including software. According to [W3C (2007)] examples are ontologies that embody some community agreement and logic-based representations. Depending upon the framework or language used for modelling, different terminologies exist for denoting the building blocks of semantic models. 
• Concept: Concept represent elements of a semantic model. This specification makes no assumptions about the nature of concepts, except that they must be identifiable by URIs. Examples are classifiers in some language, predicate logic relations, values of the property of an ontology instance [W3C (2007)]. 
• Semantic Annotation: According to [W3C (2007)] a semantic annotation in a document is additional information that identifies or defines a concept in a semantic model in order to describe part of that document. In SAWSDL, semantic annotations are XML attributes added to a WSDL or associated XML Schema document, at the XML element they describe. Semantic annotations can be devided into: explicit identifiers of concepts, or identifiers of mappings from WSDL to concepts or vice versa. 

• modelReference: extension attribute that allows for a one-to-one mapping between XML or WSDL elements and concepts in some semantic model ; 
• schemaMapping: two extension attributes lifingSchemaMapping and loweringSchemaMapping that can be added to XSD elements or complex types to associate them with semantic data (used for one-to-many and many-to-one mappings);  
  schemaMapping attributes are used in the post-discovery issues of using a web services. Each of these elements can be used to create annotations.  

Abbildung 10: Technical Overview on SAWSDL

WSMO-Lite

• Definition of the minimal useful subset of WSMO-Standard  
• Establishment of the simplest subset of concepts that are useful for defining integration  
• Easing the implementation as a starting point for WSMO-Standard and WSMO-Full  

Abbildung 11: Releative Positioning of WSMO-Lite and MicroWSMO