OASIS Specification Template



[pic]

Semantic Execution Environment (SEE) Background and Related Work

Working Draft 06, 30 September 2006

Artifact Identifier:

SEE-background-and-related-work_05

Location:

Current: TBC

This Version: TBC

Previous Version: TBC

Artifact Type:

TBC

Technical Committee:

OASIS SEE TC

Editor:

Emanuele Della Valle, CEFRIEL < dellavalle@cefriel.it >

Contributors:

Adrian Mocan, DERI < adrian.mocan@ >

Emilia Cimpian, DERI < emilia.cimpian@ >

Matthew Moran, DERI < matthew.moran@ >

Emanuele Della Valle, CEFRIEL < dellavalle@cefriel.it >

Dario Cerizza, CEFRIEL < cerizza@cefriel.it >

John Domingue, The Open University < j.b.domingue@open.ac.uk >

Brahmananda Sapkota, DERI < brahmananda.sapkota@ >

TBC more from the former documents?

OASIS Conceptual Model topic area:

SOA

Related work:

This specification replaces or supersedes:

•

•

This specification is related to:

•

•

Abstract:

This document collects background information and related work of interest of OASIS SEE TC.

Status:

This document is in DRAFT status. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at mittees/ex-semantics.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (mittees/ex-semantics/ipr.php.

The non-normative errata page for this specification is located at mittees/ex-semantics.

Notices

Copyright © OASIS Open 2006. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

Table of Contents

1 Introduction 5

2 Related work 6

2.1 Web Services Modelling Ontology (WSMO) Working Group 6

2.2 Web Services Modelling Language (WSML) Working Group 6

2.3 Web Services Execution Environment (WSMX) Working Group 6

2.4 IRS-III 8

2.5 WSDL-S 8

2.6 Semantic Web Services Initiative – Semantic Web Services Architecture Committee 9

2.7 Glue 10

2.8 Biztalk 10

3 Relationships to Other Specifications 11

3.1 OASIS SOA Reference Model TC 11

3.2 OASIS ebSOA TC 11

3.3 OASIS Web Services Resource Framework (WSRF) TC 11

3.4 OASIS ebXML Registry TC 12

3.5 OASIS UDDI TC 12

3.6 OASIS FWSI TC 12

3.7 OASIS SOA Adoption Blueprints TC 13

3.8 OASIS ebXML BP TC 13

3.9 W3C WS Description Working Group 14

3.10 W3C WS Choreography Working Group 14

3.11 WS-BPEL 14

4 References 16

4.1 Normative References 16

4.2 Non-Normative References 16

5 Summary 17

A. Acknowledgements 18

B. Revision History 19

Introduction

This document is intended to provide the audience of SEE TC documents with a minimum set of back ground information. It is organized as a list of short sections that describe research and development activities at the basis of SEE TC work (section 2) and put SEE TC work in relationship with other OASIS and W3C standardization activities (section 3). Section 4 include a list of references to relevant literature cited in the previous chapters.

Related work

The following research and development activities are at the basis of SEE TC work.

1 Web Services Modelling Ontology (WSMO) Working Group

Web Service Modeling Ontology (WSMO) is an ontology that describes the aspects related to Semantic Web Services. In this respect, it identifies four fundamental entities: Ontologies, Goals, Web Services and Mediators, and provides ontological specification for these entities that aims to integrate the Semantic Web and Web Services Technologies.

SEE can fully benefit from adopting these specifications, since it offers all the necessary means to augment a Service Oriented Architecture with semantics. Using WSMO, all the concepts handled inside the Semantic Execution Environment can be semantically described in terms of ontologies – a compulsory step towards a truly semantic execution environment.

TBC possible extensions

2 Web Services Modelling Language (WSML) Working Group

The focus of this working group is to define and develop the Web Service Modeling Language (WSML), a language that offers a formal syntax and semantics for WSMO. WSML offers a human readable syntax, as well as XML and RDF syntaxes for exchanging data between machines. WSML clearly separates between conceptual and logical expression syntaxes. The conceptual syntax is used for distinctly model different conceptual aspects of WSMO such as Web services, Ontologies, Goal and Mediators where as the logical expression syntax is used for describing additional constraints and axioms.

This language is based on different logical formalisms, namely Description Logics, First-Order Logic and Logic Programming in order to support different level of logical expressivity and computational complexity. It provides a framework of different language variants to describe semantic Web services. These variants are WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. WSML-Core is the least expressive variant but poses the most preferable computational characteristics among the WSML variants. It is defined by the intersection of Description Logic and Horn Logic. The WSML-DL, WSML-Flight and WSML-Rule variants extend WSML-Core to provide increasing expressiveness in the direction of Description Logics and Logic Programming where as WSML-Full is the union of these two directions which makes it the most expressive WSML variant. The WSML-Full variant can be reached through two different paths of WSML-Core extensions i.e. the path that follows WSML-Core ( WSML-DL ( WSML-Full and the path that follows WSML-Core ( WSML-Flight ( WSML-Rule (WSML-Full.

Additionally, WSML Working Group has provided a mapping between WSML ontologies and OWL to enable basic inter-operation through a common semantic subset of OWL and WSML.

3 Web Services Execution Environment (WSMX) Working Group

The Web Service Execution Environment (WSMX) [Haller et al. 2005] is a research prototype implementation for discovering, selecting, mediating and invoking Semantic Web services. It can be installed at the service requester side, provider side or both or at an independent location. WSMX was designed and created to provide a software environment capable of interpreting and acting on the semantic descriptions provided by the Web Services Modeling Ontology (WSMO). Interpreting means that WSMX accepts WSMO descriptions represented using the Web Services Modeling Language (WSML) and parses the descriptions into an internal format provided by a Java object model. Depending on the type of the WSMO element description received, WSMX initiates a defined behaviour. The phrase, acting on, means that this behaviour is defined as specific sets of activities that correspond to the type of WSMO element received. For example, when a goal description is received, there is currently a set of two possible activities. The first is that WSMX will attempt to discover Web service descriptions that match the goal and return these to the client. The second is that in addition to the discovery phase, service selection, mediation and invocation will take place – a full round trip between service requester and provider.

WSMX aims to provide a coherent set of services to enable the use of Semantic Web services as the basis for designing and implementing service oriented architectures (SOA). The following minimal set of service components have been identified and implemented based on using WSMO semantic descriptions.

Discovery. Service requesters need to be able to locate a service description or aggregation of descriptions that fits their needs.

Data mediation. Mismatches are likely between the date definition used by the service requester and provider. Data mediation provides a description-based approach to defining and implementing mappings between heterogeneous ontological data definitions.

Process mediation. Service requesters and providers define the interfaces they use to send and receive messages over the Web. Mismatches can occur. For example in a supply-chain scenario, a requester may define the public process they wish to follow based on the EDI message exchange protocol. A service provider may define the public process they support in terms of the RosettaNet protocol. This mismatch is resolved by process mediation.

Communication manager. Once a goal and service have been matched, communication needs to be established between them so that messages can be exchanged. WSMX acts as a broker in this sense, receiving messages from either party, mediating where necessary and then passing the (possibly transformed) message on. The choreography description of goals and services is used by WSMX to manage the state of interaction between any goal-service pair.

Choreography engine. In WSMO the choreography of a service is defined to be the description of the public interface of the service. In WSDL the interface of a service is defined in terms of operations that have input and output messages. The messages are typed using primitive types and XML Schema definitions. Analagously, WSMO uses a choreography description defines the input and output messages that a service expects using ontological concepts. These concepts are then grounded to WSDL message types. The order in which messages are sent or received is described using an abstract state machine with transistion rules. The choreography engine service in WSMX implements an engine that can execute the abstract state machine based descriptions of WSMO choreographies maintaining the state of each conversation between service requesters and providers.

Registry. WSMX maintains a registry of service descriptions that it uses during the discovery activity.

Core. The core component implements an event-driven architecture for communication between the WSMX component services. For example, when a goal is received by the communication manager, an event is raised so that the discovery service will pick up the goal description and try to match it to a service description from the registry.

Other component services defined for WSMX not described here include a WSML reasoner, a WSML parser, orchestration and service selection components. These are described in more detail at [Haller et al. 2005 & Haselwanter et al. 2006]

WSMX is an open source project with source code available at under an LGPL license. A number of EU research projects use WSMX as the basis for their prototype implementations and additionally it is an active participant in the Semantic Web Services challenge . The work of WSMX working group and its ideas have been used as the basis to establish the OASIS SEE Technical Committee. DERI[1] has contributed all WSMX conceptual work and its reference implementation to the open source community as a platform for research and development. As the work of the SEE TC progresses, it is intended that WSMX becomes an early reference implementation.

4 IRS-III

IRS-III is a platform and broker for developing and executing semantic Web services (Domingue et al., 2004; Domingue et al., 2005a; Domingue et al., 2005b; Tanasescu et al. 2006). By definition, a broker is an entity which mediates between two parties and IRS-III mediates between a service requester and one or more service providers. To achieve this, IRS-III incorporates and extends WSMO as the core IRS-III epistemological framework.

A core design principle for IRS-III is to support capability-based invocation. A client sends a request which captures a desired outcome or goal and, using a set of semantic Web service descriptions, IRS-III will: a) discover potentially relevant Web services; b) select the set of Web services which best fit the incoming request; c) mediate any mismatches at the data, ontological or business process level; and d) invoke the selected Web services whilst adhering to any data, control flow and Web service invocation constraints. Additionally, the IRS supports the SWS developer at design time by providing a set of tools for defining, editing and managing a library of semantic descriptions, and also for grounding the descriptions to either a standard Web service with a WSDL description, a Web application available through an HTTP GET request, or stand-alone Java or Lisp code.

The three key differences between IRS-III and WSMX are:

• An explicit ontological WSMO meta-model – within IRS-III, specific goals, mediators and Web services are defined as classes. Individual goal requests and Web service invocations lead to the creation of goal and Web service instances (i.e. an instance represents a particular goal or Web service invocation). A set of relations within an explicit WSMO meta-model support inference over WSMO definitions. For example, the can-solve relation links a WSMO goal to Web services which can potentially satisfy the goal.

• Explicit input and output role declaration – IRS-III requires that goals and Web services have input and output roles, which include a name and a semantic type. The declared types are imported from domain ontologies

• Client choreography – the provider of a Web service must describe the choreography from the viewpoint of the client. This means IRS-III can interpret the choreography in order to communicate with the deployed Web service.

5 WSDL-S

WSDL-S [Akkiraju et al. 2005] is a joint proposal between LSDIS Lab and IBM representing a lightweight approach to adding semantics to Web services by providing a simple extension to the meta-model for the WSDL 2.0 specification. It is also a W3C member submission [2]and a foundational input to the W3C Semantic Annotations for Web Service Description Language (SAWSDL) working group[3]. The extension takes advantage of WSDL support for multiple type-systems (e.g. XML Schema, WSMO and OWL-S) and provides a mechanism to specify preconditions and effects on the operation child elements of WSDL interfaces.

In [Brodie et al. 2005] the authors describe how starting with the assumption that a semantic model of the Web service exists, WSDL-S describes a mechanism to link this semantic model with the syntactic functional description captured by WSDL. Using the extensibility elements of WSDL, a set of annotations can be created to semantically describe the inputs, outputs and operations of a Web service. This method keeps the semantic model outside WSDL, making the approach agnostic to any ontology representation language as illustrated in Figure 1.

[pic]

Figure 1: Associating semantics to WSDL elements [Akkiraju et al. 2005].

The key advantages of the approach are that it (i) builds on WSDL using its extensibility mechanism (ii) is agnostic to the ontological language used for semantic annotations and (iii) supports annotating XML Schema data types, the most common data-definition mechanism used in Web service descriptions.

6 Semantic Web Services Initiative – Semantic Web Services Architecture Committee

Mission of the Semantic Web Services Initiative Architecture (SWSA) committee, part of Semantic Web Services Initiative, was to develop the necessary abstractions for an architecture that supports Semantic Web Services. The resultant framework builds on the W3C Web Services Architecture working group report. Other groups developing Semantic Web services frameworks contributed to the discussions, including the OWL-S consortium, WSMO and METEOR-S working groups.

At this stage the SWSA group has suspended its activity, but the major outcomes of their work have been input for work of WSMX working group and some of its ideas have been already partially applied to WSMX infrastructure. Work of SEE TC can be treated as a continuation of SWSA work to further elaborate on the protocols exchanged between the interacting components/services. Several contributors of SWSA group were supporters of establishing SEE TC.

7 Glue

8 Biztalk

Microsoft Biztalk [4]is a software integration product built around XML messaging. First released in 2000, the current version of Biztalk requires Microsoft .Net version 2.0 and uses Microsoft SQL Server as the underlying database system. The focus of Biztalk is XML-based integration even where the applications or systems being integrated do not directly support XML. In such cases, adapters are used and a wide range of adapters for various commercial systems are provided. From the developer point of view there are a number of artifacts that can be created as part of an integration deployment. These include software applications (usually but not exclusively built on .Net), XML Schema, XSLT documents for data transformation between differing XML Schema and orchestrations incorporating business rules.

Orchestrations are definitions of business processes in terms of applications and services linked together by XML messages. Message routing is based on a publish/subscribe model and rules can be defined to determine or constrain the flow of messages. One of the strengths of Biztalk is the integrated visual environment provided by Microsoft for the creation of the various artifacts required by Biztalk. Microsoft Visual Studio has tools for creation of XML Schema, business rules, applications and orchestrations.

The challenges faced by Biztalk are common to all application integration platforms – how to handle the combination of autonomous heterogeneous applications where the heterogeneity stretches across data, process models and communication models. Mismatch handling is carried out using a combination of adapters and XSLT. Many popular communication and business protocols are handled. This includes being able to import and export BPEL process descriptions. Process mismatches are usually addressed by bespoke application development.

A significant drawback associated with Biztalk is licensing cost for smaller organizations as the product is dependent on a larger suite of Microsoft products such as SQL Server, and Visual Studio. In comparison with SEE, Biztalk, being based exclusively on XML assumes that XSLT and design time graphical tools are sufficient to cover data and process mediation problems. The absence of support for semantics means that process designs are more brittle and changes to individual XML schema can have significant redesign knock-on effects.

Relationships to Other Specifications

All Web Services and Service Oriented Architecture groups are the primary target of this work. It is anticipated that liaisons may be needed for many SOA-related Technical Committees such as the following:

1 OASIS SOA Reference Model TC

SOA RM OASIS TC is chartered to develop a Reference Model for Service Oriented Architecture. This is primarily to address SOA being used as a term in an increasing number of contexts and specific technology implementations. The Reference Model is being developed to encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA is.

SEE TC aims to use concepts laid by SOA RM to describe Service Oriented Architecture of SEE. We recognized that both committees can benefit out of this symbiosis. While SEE benefits out of foundational concepts provided by SOA RM, the SOA RM will receive a feedback on how their specification can be applied to implementable SOA such as SEE.

2 OASIS ebSOA TC

OASIS ebSOA TC continues the work in ebXML Technical Architecture taking in consideration the latest releases in ebXML specifications and based on the latest developments in Web Services and Service oriented Architecture.

The focus of this committee is to develop a set of patterns defining the architectural elements end the relationship between them, in order to enable electronic business on global basis. Examples of such patterns are: Service Description Pattern, Search and Discovery Pattern, Business Process Description Pattern, Data Transformation Pattern, etc.

As SEE is a Service Oriented Architecture meant to enable business scenarios between various business entities (through Semantic Web Service), such patterns could be valuable in identifying meaningful execution semantics or in pointing to best practices as a reference point for SEE development.

3 OASIS Web Services Resource Framework (WSRF) TC

The Web Services Resource Framework (WSRF) [WSRF 2005] is a standard for Web services that takes into account features involved in the implementation of Grid computing, such as statefulness, notification mechanisms and transient resources or services (in contrast to standard Web services which are stateless and persistent). WSRF is an open framework that allows the implementation of both Grid applications and Grid middleware services (job submission, file transfer, information service, etc.).One of the key ideas of WSRF is the virtualization of resources through WS-Resource (i.e. a Web service with properties describing a state). The WSRF is a specification of the mandatory and optional interfaces a Web service must support for it to be considered a Grid service based on the definitions of Grid service and Open Service Grid Architecture (OGSA) provided in [OGSA 2002].

There relationship between Web services and Grids has been established by the OGSA definition of a service oriented architecture for Grids based on standard Web service technology. Both the WSRF and SEE aim at seamless integration and ad-hoc cooperation between various resources on the Web. SEE focuses on the solving the problems of data and process mediation as well as service discovery and composition based on semantic annotation of services. The WSRF complements SEE by providing specifications to cater for aspects such as stateful Web resources, notification mechanisms and lifetime-management of services. The application of semantics to the WSRF suggests a logical step to enable WSRF fulfill the requirements for the resource management in the SEE architecture.

This would require the development of a “WSRF-S” a combination of WSRF and the semantic framework used by the rest of SEE. The advantage of enhancing WSRF with semantics and the use of ontologies will be twofold: first, it facilitates the unambiguous description of various resources and their relationships. This is currently missing and is an important issue, because WSRF is a significant building block for the Grid and is used at different levels. Because of the lack of clear semantics, currently the creation of new Grid services and applications require somewhat arbitrary conventions to be followed, and is relatively tedious and error prone. Secondly, the use of semantic-based discovery and composition techniques will greatly aid in the task of finding and using Grid resources.

4 OASIS ebXML Registry TC

OASIS ebXML Registry is chartered to develop specifications to achieve interoperable registries and repositories, with an interface that enables submission, query and retrieval on the contents of the registry and repository. The Registry TC seeks to develop specifications that serve a wide range of uses, covering the spectrum from general purpose document registries to real-time business-to-business registries. Additionally, as part of its specification development work, this TC explores and promotes various emerging models for distributed and cooperating registries.

SEE TC recognized discovery as a critical element of its infrastructure. ebXML registry/repository is en example of specification, which capture functionality expected from the particular components/services of the SEE infrastructure. Work of SEE infrastructure aim to answer question if infrastructure provided by existing business registries such as ebXML would be sufficient to serve for scenarios as described by use cases of SEE TC.

5 OASIS UDDI TC

The Universal Description, Discovery and Integration (UDDI) protocol[5] is an industry standard fostered, among others, by IBM, Microsoft, Ariba and Sun Microsystems within the OASIS consortium. UDDI provides the key publication and discovery capabilities of Service-Oriented Architectures by specifying an interoperable platform that enables:

• a Web Service provider to register as Business Entity and to publish its Web Services by registering each Web Service as a Business Services, bind to a standard interface (i.e. tModel); and

• a Web Service requesters to discover and use Web Services using approaches similar to white, yellow and green pages.

UDDI v3.0 was ratified as OASIS Standard February the 3rd 2005 and with the approval of such version IBM, Microsoft and SAP have determined that the goals for the project have been achieved. The market adoption of UDDI is gaining momentum and a significant number of vendor supplied UDDI products. Registries based on UDDI have been established within enterprises and organizations and have an important role in Web services business applications.

For a good overview of the past activities around UDDI see the UDDI Cover Pages[6] .

6 OASIS FWSI TC

The purpose of OASIS Framework for Web Services Implementation (FWSI) TC[7] is to facilitate the implementation Web Services. For this, they define practical and extensible methodology consisting of implementation processes and common functional elements that practitioners can adopt to create high quality Web Services systems without re-inventing them for each implementation.

The efforts of this TC are[8] to:

1. accelerate implementation of Web Services-based systems

2. improve the performance and robustness of such systems

3. improve understanding of Web Services implementations

4. reduce the complexity of such systems and hence reduce the developmental and maintenance efforts; and to

5. reduce the risk of implementation.

Although the objectives of this TC are out of the scope of SEE TC, since we are more concerned with how Semantic Web Services can be used, and not with how they can be created, it would be interesting to see if services developed using the methodologies developed by the FWSI could be automatically invoked and executed by the Semantic Execution Environment, if semantically enhanced descriptions are provided.

7 OASIS SOA Adoption Blueprints TC

The OASIS SOA Adoption Blueprints TC aims at illustrating the practical deployment of services using SOA methods by developing and maintaining a set of concrete examples. The TC collects business requirements and functions and it shows how they can be fulfilled by SOA methods in a set of "adoption blueprints".

All the blueprints generalize a basic Generico blueprint that serves as a basic Adoption Blueprint. Each adoption blueprint provides (on a vendor- and specification-neutral basis) a

• business problem statement,

• a set of business requirements, and

• a normative set of functions to be fulfilled.

The community of SOA is invited to develop software implementations of the blueprints, as a way of demonstrating capability to meet those business needs. The TC collects and reviews the implementations. The result is a set of solutions to well-defined SOA problems from which implementers can gain insight into the best (and worst) practices associated with them.

The TC does not develop any new Web services standards, it recommends instead certain standards as suitable for specific functional requirements.

8 OASIS ebXML BP TC

OASIS ebXML Business Process (ebBP) TC defines a standard language to configure business systems for business collaboration execution between collaborating parties or business partners. Business processes are key components to enable and drive collaborating partner relationships for electronic business (eBusiness). The ebBP provides capabilities to drive those eBusiness collaborative processes. As a part of the original eBusiness XML framework of specifications, the ebBP is targeted for monitoring of collaborative business processes among parties or business partners. Today, ebBP has evolved to integrate use of other specifications and emerging technologies as part of eBusiness solutions focused on Service-Oriented Architecture.

9 W3C WS Description Working Group

The W3C Web Service Description Working Group[9], which is part of the Web Services Activity[10], currently consists of 34 members from 23 different organizations, with both industrial and academic profile.

The main objective of this working group is the design of several components of a Web Service Interface: the message (definition for the types and structures of the data being exchanged), the message exchange patterns (the descriptions of the sequence of operations supported by a Web service) and the protocol binding (a mechanism for binding a protocol used by a Web service, independently of its message exchange patterns and its messages).

Out of 8 deliverables developed by this working group 3 are W3C Candidate Recommendations: Web Services Description Language (WSDL) Version 2.0 Part 0: Primer (), Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language (), and Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts ().

The Web Service Descriptions working group’s activity and results can be compared with the work of WSMO and WSML working groups, the difference being that WSMO is addressing all aspects related to Semantic Web Services, not only interface related aspects, while WSML develops a language for representing all the concepts identified by WSMO. Considering this, we may identify Web Service Description working group’s activity as being a subset of the work carried on in WSMO and WSML, and as a consequence, any implementation based on WSDL would be a subset (or several components) of the SEE architecture.

10 W3C WS Choreography Working Group

W3C Chorographpy and WSMO Choreography are partly orthogonal to each other and have different views on the same problems in other areas. A fundamental difference is that WSMO choreographies are natively based on semantics by choosing ontologies as the datamodel it operates on, while W3C choreography works primarily on syntactical construct. In addition to that it takes a global viewpoint on the behavior aspects of web service while WSMO model behavior strictly local to a Web Service. The models are not compatible per se, but there is enough orthogonality to reasonably expect usefull results that each address aspects of the problem.

11 WS-BPEL

WS-BPEL is concerned with creating a language to specify business processes using Web services. The acronym stands for Web Service-Business Process Execution Language. In 2003 OASIS was invited to continue the work of the BPEL4WS v1.1[11] specification whose contributing members included IBM, BEA Systems, Microsoft, SAP AG and Siebel Systems and the WS-BPEL technical committee was established. In that context, WS-BPEL considers the following challenges: how to handle (i) data-dependent behaviour, (ii) exceptional conditions and (iii) long-running interactions including multiple nested processes.

WS-BPEL distinguishes two different types of business processes which it can describe – executable and abstract. An executable process is one that is fully specified and that can be executed by an appropriate engine. An abstract process is one that is only partially specified and which, consequently, can not be directly executed. The reason for the distinction is that there are some processes, all the operational details of which, a business may not want to divulge. Abstract processes can in some ways be thought of as templates that show process functionality that is required but that is not fully specified.

There is a tight relationship between WS-BPEL and the XML specifications of WSDL 1.1, XML Schema 1.0, XSLT 1.0 and XPATH 1.0. In particular, WS-BPEL layers on top of WSDL portTypes and operations when defining endpoints in conversations between partners. Any Web service can be defined as a partner adopting a specific role. The concept of partnerLinks allows two partners to be linked together in their respective roles for a message exchange.

The difference between SEE and WS-BPEL lie in addressing the Semantic Gap in terms of data and processes between any two partners. The Semantic Gap alludes to the fact that agility to react to changing conditions is very important for any process management software. The aim of the SEE is to link decoupled heterogeneous at run-time services based on their semantic descriptions. This requires solutions for semantic service discovery, as well as data and process mediation at the ontological level rather than at a point-to-point level.

References

1 Normative References

[Akkiraju et al. 2005] R. Akkiraju, J. Farrell, J.Miller, M. Nagarajan, M. Schmidt, A. Sheth, and K. Verma, "Web Service Semantics - WSDL-S, available at ," 2005.

[Brodie et al. 2005] M. Brodie, C. Bussler, J. d. Bruijn, T. Fahringer, D. Fensel, M. Hepp, H. Lausen, D. Roman, T. Strang, H. Werthner, and M. Zaremba, "Semantically Enabled Service-Oriented Architectures: A Manifesto and a Paradigm Shift in Computer Science," DERI 2005.

[DOMINGUE et al., 2004] John Domingue, Liliana Cabral, Fashard Hakimpour, Denilson Sell and Enrico Motta. IRS-III: A Platform and Infrastructure for Creating WSMO-based Semantic Web Services. In Proceedings of the Workshop on WSMO Implementations (WIW 2004), Frankfurt, Germany, September 29-30, 2004, CEUR Workshop Proceedings, ISSN 1613-0073. .

[DOMINGUE et al., 2005a] John Domingue, Liliana Cabral, Stefania Galizia and Enrico Motta. A Comprehensive Approach to Creating and Using Semantic Web Services, In Proceedings of the W3C Workshop on Frameworks for Semantics in Web Service, Innsbruck, Austria, June 9-10, 2005.

[DOMINGUE et al., 2005b] John Domingue, Stefania Galizia, and Liliana Cabral. Choreography in IRS-III- Coping with Heterogeneous Interaction Patterns in Web Services, In Proceedings of the 4th International Semantic Web Conference (ISWC 2005), November 6-10, 2005, Galway, Ireland.

[Haller et al., 2005] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler, WSMX – A Semantic Service-Oriented Architecture. In Proc. Of the 3rd Int. Conf. on Web Services, pp. 321 – 328. IEEE Computer Society, 2005.

[Haselwanter et al., 2006] T. Haselwanter, P. Kotinurmi, M. Moran, T. Vitvar, and M. Zaremba, "Dynamic B2B Integration using Semantic Web Services: SWS Challenge Phase 2, available at " presented at SWS Challenge Phase II Workshop, Budva, Montenegro, 2006.

[Preist 2004] Chris Preist, A Conceptual Architecture for Semantic Web Services. in Third International Semantic Web Services Conference (ISWC), Hiroshima, Japan, 2004, Springer, pp395-409

2 Non-Normative References

Summary

A. Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Barry Norton, The Open University

Omair Shafiq, DERI

Maciej Zaremba, DERI

B. Revision History

|Rev |Date |By Whom |What |

|wd-01 |2006-04-25 |Emanuele Della Valle |Initial version created by merging common background|

| | | |and related work sections of other WDs |

|Wd-02 |2006-06-22 |John Domingue |Included IRS-III |

|Wd-03 |2006-06-22 |Matthew Moran |Included WSDL-S |

| | | | |

|Wd-05 |2006-07-09 |Matthew Moran |Updated WSMX description |

|Wd-06 |2006-09-30 |Emanuele Della Valle |Refactoring of the document |

| | | | |

-----------------------

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8] Taken from the FWSI TC’s charter,

[9]

[10]

[11]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download