• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction
 

Introduction

on

  • 788 views

 

Statistics

Views

Total Views
788
Views on SlideShare
788
Embed Views
0

Actions

Likes
1
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduction Introduction Document Transcript

    • 1 2Semantic Execution Environment (SEE) 3Background and Related Work 4Working Draft 09, 11 November 2006 5Artifact Identifier: 6 SEE-background-and-related-work_09 7Location: 8 Current: http://www.oasis-open.org/apps/org/workgroup/semantic-ex/document.php? 9 document_id=20914 10 This Version: http://www.oasis-open.org/apps/org/workgroup/semantic- 11 ex/download.php/20914/SEE-background-and-related-work_09.doc 12 Previous Version: http://www.oasis-open.org/apps/org/workgroup/semantic- 13 ex/download.php/20914/SEE-background-and-related-work_07.doc 14Artifact Type: 15 TBC 16Technical Committee: 17 OASIS SEE TC 18Editor: 19 Emanuele Della Valle, CEFRIEL < dellavalle@cefriel.it > 20Contributors: 21 Adrian Mocan, DERI < adrian.mocan@deri.org > 22 Emilia Cimpian, DERI < emilia.cimpian@deri.org > 23 Matthew Moran, DERI < matthew.moran@deri.org > 24 Emanuele Della Valle, CEFRIEL < dellavalle@cefriel.it > 25 Dario Cerizza, CEFRIEL < cerizza@cefriel.it > 26 John Domingue, The Open University < j.b.domingue@open.ac.uk > 27 Brahmananda Sapkota, DERI < brahmananda.sapkota@deri.org > 28 TBC more from the former documents? 29OASIS Conceptual Model topic area: 30 SOA 31Related work: 32 This specification replaces or supersedes: 33 • [specifications replaced by this standard] 34 • [specifications replaced by this standard] 35 This specification is related to: 36 • [related specifications] 37 • [related specifications] 38Abstract: 39 This document collects background information and related work of interest of OASIS SEE TC. 1[Document Identifier] [DD Month YYYY] 2Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 21
    • 40Status: 41 This document is in DRAFT status. This document is updated periodically on no particular 42 schedule. 43 Technical Committee members should send comments on this specification to the Technical 44 Committee’s email list. Others should send comments to the Technical Committee by using the 45 “Send A Comment” button on the Technical Committee’s web page at www.oasis- 46 open.org/committees/ex-semantics. 47 For information on whether any patents have been disclosed that may be essential to 48 implementing this specification, and any offers of patent licensing terms, please refer to the 49 Intellectual Property Rights section of the Technical Committee web page (www.oasis- 50 open.org/committees/ex-semantics/ipr.php. 51 The non-normative errata page for this specification is located at www.oasis- 52 open.org/committees/ex-semantics. 4[Document Identifier] [DD Month YYYY] 5Copyright © OASIS Open 2006. All Rights Reserved. Page 2 of 21
    • 53Notices 54Copyright © OASIS Open 2006. All Rights Reserved. 55All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 56Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 57This document and translations of it may be copied and furnished to others, and derivative works that 58comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 59and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 60and this section are included on all such copies and derivative works. However, this document itself may 61not be modified in any way, including by removing the copyright notice or references to OASIS, except as 62needed for the purpose of developing any document or deliverable produced by an OASIS Technical 63Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 64be followed) or as required to translate it into languages other than English. 65The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 66or assigns. 67This document and the information contained herein is provided on an "AS IS" basis and OASIS 68DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 69WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 70OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 71PARTICULAR PURPOSE. 72OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 73necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 74to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 75such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 76produced this specification. 77OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 78any patent claims that would necessarily be infringed by implementations of this specification by a patent 79holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 80Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 81claims on its website, but disclaims any obligation to do so. 82OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 83might be claimed to pertain to the implementation or use of the technology described in this document or 84the extent to which any license under such rights might or might not be available; neither does it represent 85that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 86rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 87OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 88to be made available, or the result of an attempt made to obtain a general license or permission for the 89use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 90Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 91information or list of intellectual property rights will at any time be complete, or that any claims in such list 92are, in fact, Essential Claims. 7[Document Identifier] [DD Month YYYY] 8Copyright © OASIS Open 2006. All Rights Reserved. Page 3 of 21
    • 93Table of Contents 941 Introduction..............................................................................................................................................5 95 1.1 Methodology.....................................................................................................................................5 962 SOA Related work...................................................................................................................................6 97 2.1 OASIS SOA Reference Model TC....................................................................................................6 98 2.2 OASIS SOA Adoption Blueprints TC................................................................................................6 99 2.3 W3C XML Protocol Working Group..................................................................................................6 100 2.4 W3C WS Description Working Group...............................................................................................7 101 2.5 OASIS UDDI TC...............................................................................................................................7 102 2.6 WS-BPEL.........................................................................................................................................8 1033 Related work in adding semantics to SOA...............................................................................................9 104 3.1 Web Services Modelling Ontology (WSMO) Working Group............................................................9 105 3.2 Web Services Modelling Language (WSML) Working Group...........................................................9 106 3.3 Web Services Execution Environment (WSMX) Working Group......................................................9 107 3.4 IRS-III.............................................................................................................................................11 108 3.5 WSDL-S..........................................................................................................................................11 109 3.6 Semantic Web Services Initiative – Semantic Web Services Architecture Committee...................12 110 3.7 Glue................................................................................................................................................13 1114 Relationships to Other Specifications....................................................................................................14 112 4.1 W3C WS Choreography Working Group........................................................................................14 113 4.2 OASIS ebSOA TC..........................................................................................................................14 114 4.3 OASIS ebXML Registry TC............................................................................................................14 115 4.4 OASIS ebXML BP TC.....................................................................................................................15 116 4.5 OASIS Web Services Resource Framework (WSRF) TC...............................................................15 117 4.6 OASIS FWSI TC.............................................................................................................................16 118 4.7 Biztalk.............................................................................................................................................16 1195 References............................................................................................................................................18 120 5.1 Normative References....................................................................................................................18 121 5.2 Non-Normative References............................................................................................................18 1226 Summary...............................................................................................................................................19 123A. Acknowledgements..............................................................................................................................20 124B. Revision History....................................................................................................................................21 125 126 10[Document Identifier] [DD Month YYYY] 11Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 21
    • 1271 Introduction 128This document is intended to provide the audience of SEE TC documents with a minimum set of back 129ground information. It is organized as a list of short sections that describe research and development 130activities at the basis of SEE TC work (section 2 and 3). Section 2 is mainly centered on SOA concepts 131and current implementation of SOA based on Web Services technologies. Section 3, on the other hand, 132contains sections related to efforts that are tying to add semantics to SOA. In Section 4 SEE TC work is 133put in relationship with other OASIS and W3C standardization activities. Finally, Section 5 includes a list 134of references to relevant literature cited in the previous chapters. 1351.1 Methodology 136In order to make the document as readable as possible we decided to organized the information in each 137subsection as follows: 138 - short description of the activity: 50-100 words describing the activity. Detailed information not 139 accessible to people outside the described activity should be avoided. 140 - motivation of the activity: 50-100 words describing the main goals of the activities avoiding the 141 use of concepts specific of the activities. 142 - relationships with other activities: 50-100 words describing the relationships of this activity with 143 others either present in the document (internal pointers are welcome) or not listed (in this case 144 references are welcome). 145 - detailed description of the activity (optional): max 500 words describing the activities in more 146 details. Concepts related to the activity itself can be referenced and used, 147 - achievements and roadmap: max 200 words describing the current achievements of the activity 148 and the roadmap towards goal achievement. 149 - participants (optional): list the key organizations or individuals promoting the activity 150 - to learn more: references and links to external resources 13[Document Identifier] [DD Month YYYY] 14Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 21
    • 1512 SOA Related work 1522.1 OASIS SOA Reference Model TC 153SOA RM OASIS TC is chartered to develop a Reference Model for Service Oriented Architecture. This is 154primarily to address SOA being used as a term in an increasing number of contexts and specific 155technology implementations. The Reference Model is being developed to encourage the continued 156growth of different and specialized SOA implementations whilst preserving a common layer of 157understanding about what SOA is. 158SEE TC aims to use concepts laid by SOA RM to describe Service Oriented Architecture of SEE. We 159recognized that both committees can benefit out of this symbiosis. While SEE benefits out of foundational 160concepts provided by SOA RM, the SOA RM will receive a feedback on how their specification can be 161applied to implementable SOA such as SEE. 162 163Editor: 164 1652.2 OASIS SOA Adoption Blueprints TC 166The OASIS SOA Adoption Blueprints TC aims at illustrating the practical deployment of services using 167SOA methods by developing and maintaining a set of concrete examples. The TC collects business 168requirements and functions and it shows how they can be fulfilled by SOA methods in a set of "adoption 169blueprints". 170All the blueprints generalize a basic Generico blueprint that serves as a basic Adoption Blueprint. Each 171adoption blueprint provides (on a vendor- and specification-neutral basis) a 172 • business problem statement, 173 • a set of business requirements, and 174 • a normative set of functions to be fulfilled. 175The community of SOA is invited to develop software implementations of the blueprints, as a way of 176demonstrating capability to meet those business needs. The TC collects and reviews the 177implementations. The result is a set of solutions to well-defined SOA problems from which implementers 178can gain insight into the best (and worst) practices associated with them. 179The TC does not develop any new Web services standards, it recommends instead certain standards as 180suitable for specific functional requirements. 181 182Editor: Emanuele Della Valle 183 1842.3 W3C XML Protocol Working Group 185 186Editor: Matthew Moran 187 16[Document Identifier] [DD Month YYYY] 17Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 21
    • 1882.4 W3C WS Description Working Group 189The W3C Web Service Description Working Group1, which is part of the Web Services Activity2, currently 190consists of 34 members from 23 different organizations, with both industrial and academic profile. 191The main objective of this working group is the design of several components of a Web Service Interface: 192the message (definition for the types and structures of the data being exchanged), the message 193exchange patterns (the descriptions of the sequence of operations supported by a Web service) and the 194protocol binding (a mechanism for binding a protocol used by a Web service, independently of its 195message exchange patterns and its messages). 196Out of 8 deliverables developed by this working group 3 are W3C Candidate Recommendations: Web 197Services Description Language (WSDL) Version 2.0 Part 0: Primer (http://www.w3.org/TR/2006/CR- 198wsdl20-primer-20060327/), Web Services Description Language (WSDL) Version 2.0 Part 1: Core 199Language (http://www.w3.org/TR/wsdl20/), and Web Services Description Language (WSDL) Version 2.0 200Part 2: Adjuncts (http://www.w3.org/TR/wsdl20-bindings/). 201The Web Service Descriptions working group’s activity and results can be compared with the work of 202WSMO and WSML working groups, the difference being that WSMO is addressing all aspects related to 203Semantic Web Services, not only interface related aspects, while WSML develops a language for 204representing all the concepts identified by WSMO. Considering this, we may identify Web Service 205Description working group’s activity as being a subset of the work carried on in WSMO and WSML, and 206as a consequence, any implementation based on WSDL would be a subset (or several components) of 207the SEE architecture. 208 209Editor: Emilia Cimpian 210 2112.5 OASIS UDDI TC 212The Universal Description, Discovery and Integration (UDDI) protocol3 is an industry standard fostered, 213among others, by IBM, Microsoft, Ariba and Sun Microsystems within the OASIS consortium. UDDI 214provides the key publication and discovery capabilities of Service-Oriented Architectures by specifying an 215interoperable platform that enables: 216• a Web Service provider to register as Business Entity and to publish its Web Services by registering 217 each Web Service as a Business Services, bind to a standard interface (i.e. tModel); and 218• a Web Service requesters to discover and use Web Services using approaches similar to white, 219 yellow and green pages. 220UDDI v3.0 was ratified as OASIS Standard February the 3rd 2005 and with the approval of such version 221IBM, Microsoft and SAP have determined that the goals for the project have been achieved. The market 222adoption of UDDI is gaining momentum and a significant number of vendor supplied UDDI products. 223Registries based on UDDI have been established within enterprises and organizations and have an 224important role in Web services business applications. 225For a good overview of the past activities around UDDI see the UDDI Cover Pages4 . 226 227Editor: Emanuele Della Valle 228 191 http://www.w3.org/2002/ws/desc/ 202 http://www.w3.org/2002/ws/Activity 213 http://www.uddi.org/ 224 http://xml.coverpages.org/uddi.html 23[Document Identifier] [DD Month YYYY] 24Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 21
    • 2292.6 WS-BPEL 230WS-BPEL is concerned with creating a language to specify business processes using Web services. The 231acronym stands for Web Service-Business Process Execution Language. In 2003 OASIS was invited to 232continue the work of the BPEL4WS v1.15 specification whose contributing members included IBM, BEA 233Systems, Microsoft, SAP AG and Siebel Systems and the WS-BPEL technical committee was 234established. In that context, WS-BPEL considers the following challenges: how to handle (i) data- 235dependent behaviour, (ii) exceptional conditions and (iii) long-running interactions including multiple 236nested processes. 237WS-BPEL distinguishes two different types of business processes which it can describe – executable and 238abstract. An executable process is one that is fully specified and that can be executed by an appropriate 239engine. An abstract process is one that is only partially specified and which, consequently, can not be 240directly executed. The reason for the distinction is that there are some processes, all the operational 241details of which, a business may not want to divulge. Abstract processes can in some ways be thought of 242as templates that show process functionality that is required but that is not fully specified. 243There is a tight relationship between WS-BPEL and the XML specifications of WSDL 1.1, XML Schema 2441.0, XSLT 1.0 and XPATH 1.0. In particular, WS-BPEL layers on top of WSDL portTypes and operations 245when defining endpoints in conversations between partners. Any Web service can be defined as a partner 246adopting a specific role. The concept of partnerLinks allows two partners to be linked together in their 247respective roles for a message exchange. 248The difference between SEE and WS-BPEL lie in addressing the Semantic Gap in terms of data and 249processes between any two partners. The Semantic Gap alludes to the fact that agility to react to 250changing conditions is very important for any process management software. The aim of the SEE is to 251link decoupled heterogeneous at run-time services based on their semantic descriptions. This requires 252solutions for semantic service discovery, as well as data and process mediation at the ontological level 253rather than at a point-to-point level. 254 255Editor: Matthew Moran 256 257 265 http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ 27[Document Identifier] [DD Month YYYY] 28Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 21
    • 2583 Related work in adding semantics to SOA 2593.1 Web Services Modelling Ontology (WSMO) Working Group 260Web Service Modeling Ontology (WSMO) is an ontology that describes the aspects related to Semantic 261Web Services. In this respect, it identifies four fundamental entities: Ontologies, Goals, Web Services and 262Mediators, and provides ontological specification for these entities that aims to integrate the Semantic 263Web and Web Services Technologies. 264SEE can fully benefit from adopting these specifications, since it offers all the necessary means to 265augment a Service Oriented Architecture with semantics. Using WSMO, all the concepts handled inside 266the Semantic Execution Environment can be semantically described in terms of ontologies – a 267compulsory step towards a truly semantic execution environment. 268 269Editor: John Domingue 2703.2 Web Services Modelling Language (WSML) Working Group 271The focus of this working group is to define and develop the Web Service Modeling Language (WSML), a 272language that offers a formal syntax and semantics for WSMO. WSML offers a human readable syntax, 273as well as XML and RDF syntaxes for exchanging data between machines. WSML clearly separates 274between conceptual and logical expression syntaxes. The conceptual syntax is used for distinctly model 275different conceptual aspects of WSMO such as Web services, Ontologies, Goal and Mediators where as 276the logical expression syntax is used for describing additional constraints and axioms. 277This language is based on different logical formalisms, namely Description Logics, First-Order Logic and 278Logic Programming in order to support different level of logical expressivity and computational complexity. 279It provides a framework of different language variants to describe semantic Web services. These variants 280are WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. WSML-Core is the least 281expressive variant but poses the most preferable computational characteristics among the WSML 282variants. It is defined by the intersection of Description Logic and Horn Logic. The WSML-DL, WSML- 283Flight and WSML-Rule variants extend WSML-Core to provide increasing expressiveness in the direction 284of Description Logics and Logic Programming where as WSML-Full is the union of these two directions 285which makes it the most expressive WSML variant. The WSML-Full variant can be reached through two 286different paths of WSML-Core extensions i.e. the path that follows WSML-Core → WSML-DL → WSML- 287Full and the path that follows WSML-Core → WSML-Flight → WSML-Rule →WSML-Full. 288Additionally, WSML Working Group has provided a mapping between WSML ontologies and OWL to 289enable basic inter-operation through a common semantic subset of OWL and WSML. 290 291Editor: Brahmananda Sapkota 292 2933.3 Web Services Execution Environment (WSMX) Working Group 294The Web Service Execution Environment (WSMX) [Haller et al. 2005] is a research prototype 295implementation for discovering, selecting, mediating and invoking Semantic Web services. It can be 296installed at the service requester side, provider side or both or at an independent location. WSMX was 297designed and created to provide a software environment capable of interpreting and acting on the 298semantic descriptions provided by the Web Services Modeling Ontology (WSMO). Interpreting means that 30[Document Identifier] [DD Month YYYY] 31Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 21
    • 299WSMX accepts WSMO descriptions represented using the Web Services Modeling Language (WSML) 300and parses the descriptions into an internal format provided by a Java object model. Depending on the 301type of the WSMO element description received, WSMX initiates a defined behaviour. The phrase, acting 302on, means that this behaviour is defined as specific sets of activities that correspond to the type of WSMO 303element received. For example, when a goal description is received, there is currently a set of two 304possible activities. The first is that WSMX will attempt to discover Web service descriptions that match the 305goal and return these to the client. The second is that in addition to the discovery phase, service 306selection, mediation and invocation will take place – a full round trip between service requester and 307provider. 308 309WSMX aims to provide a coherent set of services to enable the use of Semantic Web services as the 310basis for designing and implementing service oriented architectures (SOA). The following minimal set of 311service components have been identified and implemented based on using WSMO semantic descriptions. 312Discovery. Service requesters need to be able to locate a service description or aggregation of 313descriptions that fits their needs. 314Data mediation. Mismatches are likely between the date definition used by the service requester and 315provider. Data mediation provides a description-based approach to defining and implementing mappings 316between heterogeneous ontological data definitions. 317Process mediation. Service requesters and providers define the interfaces they use to send and receive 318messages over the Web. Mismatches can occur. For example in a supply-chain scenario, a requester 319may define the public process they wish to follow based on the EDI message exchange protocol. A 320service provider may define the public process they support in terms of the RosettaNet protocol. This 321mismatch is resolved by process mediation. 322Communication manager. Once a goal and service have been matched, communication needs to be 323established between them so that messages can be exchanged. WSMX acts as a broker in this sense, 324receiving messages from either party, mediating where necessary and then passing the (possibly 325transformed) message on. The choreography description of goals and services is used by WSMX to 326manage the state of interaction between any goal-service pair. 327Choreography engine. In WSMO the choreography of a service is defined to be the description of the 328public interface of the service. In WSDL the interface of a service is defined in terms of operations that 329have input and output messages. The messages are typed using primitive types and XML Schema 330definitions. Analagously, WSMO uses a choreography description defines the input and output messages 331that a service expects using ontological concepts. These concepts are then grounded to WSDL message 332types. The order in which messages are sent or received is described using an abstract state machine 333with transistion rules. The choreography engine service in WSMX implements an engine that can execute 334the abstract state machine based descriptions of WSMO choreographies maintaining the state of each 335conversation between service requesters and providers. 336Registry. WSMX maintains a registry of service descriptions that it uses during the discovery activity. 337Core. The core component implements an event-driven architecture for communication between the 338WSMX component services. For example, when a goal is received by the communication manager, an 339event is raised so that the discovery service will pick up the goal description and try to match it to a 340service description from the registry. 341Other component services defined for WSMX not described here include a WSML reasoner, a WSML 342parser, orchestration and service selection components. These are described in more detail at [Haller 343et al. 2005 & Haselwanter et al. 2006] 344 345WSMX is an open source project with source code available at http://sourceforge.net/projects/wsmx/ 346under an LGPL license. A number of EU research projects use WSMX as the basis for their prototype 347implementations and additionally it is an active participant in the Semantic Web Services challenge http:// 348sws-challenge.org/wiki/index.php/Main_Page. The work of WSMX working group and its ideas have been 33[Document Identifier] [DD Month YYYY] 34Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 21
    • 349used as the basis to establish the OASIS SEE Technical Committee. DERI 6 has contributed all WSMX 350conceptual work and its reference implementation to the open source community as a platform for 351research and development. As the work of the SEE TC progresses, it is intended that WSMX becomes an 352early reference implementation. 353 354Editor: Matthew Moran 355 3563.4 IRS-III 357IRS-III is a platform and broker for developing and executing semantic Web services (Domingue et al., 3582004; Domingue et al., 2005a; Domingue et al., 2005b; Tanasescu et al. 2006). By definition, a broker is 359an entity which mediates between two parties and IRS-III mediates between a service requester and one 360or more service providers. To achieve this, IRS-III incorporates and extends WSMO as the core IRS-III 361epistemological framework. 362A core design principle for IRS-III is to support capability-based invocation. A client sends a request which 363captures a desired outcome or goal and, using a set of semantic Web service descriptions, IRS-III will: a) 364discover potentially relevant Web services; b) select the set of Web services which best fit the incoming 365request; c) mediate any mismatches at the data, ontological or business process level; and d) invoke the 366selected Web services whilst adhering to any data, control flow and Web service invocation constraints. 367Additionally, the IRS supports the SWS developer at design time by providing a set of tools for defining, 368editing and managing a library of semantic descriptions, and also for grounding the descriptions to either 369a standard Web service with a WSDL description, a Web application available through an HTTP GET 370request, or stand-alone Java or Lisp code. 371The three key differences between IRS-III and WSMX are: 372 • An explicit ontological WSMO meta-model – within IRS-III, specific goals, mediators and Web 373 services are defined as classes. Individual goal requests and Web service invocations lead to the 374 creation of goal and Web service instances (i.e. an instance represents a particular goal or Web 375 service invocation). A set of relations within an explicit WSMO meta-model support inference over 376 WSMO definitions. For example, the can-solve relation links a WSMO goal to Web services which 377 can potentially satisfy the goal. 378 • Explicit input and output role declaration – IRS-III requires that goals and Web services have 379 input and output roles, which include a name and a semantic type. The declared types are 380 imported from domain ontologies 381 • Client choreography – the provider of a Web service must describe the choreography from the 382 viewpoint of the client. This means IRS-III can interpret the choreography in order to 383 communicate with the deployed Web service. 384 385Editor: John Domingue 386 3873.5 WSDL-S 388WSDL-S [Akkiraju et al. 2005] is a joint proposal between LSDIS Lab and IBM representing a lightweight 389approach to adding semantics to Web services by providing a simple extension to the meta-model for the 390WSDL 2.0 specification. It is also a W3C member submission 7and a foundational input to the W3C 391Semantic Annotations for Web Service Description Language (SAWSDL) working group8. The extension 366 http://www.deri.org/ 377 http://www.w3.org/Submission/WSDL-S/ 388 http://www.w3.org/2002/ws/sawsdl/ 39[Document Identifier] [DD Month YYYY] 40Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 21
    • 392takes advantage of WSDL support for multiple type-systems (e.g. XML Schema, WSMO and OWL-S) and 393provides a mechanism to specify preconditions and effects on the operation child elements of WSDL 394interfaces. 395In [Brodie et al. 2005] the authors describe how starting with the assumption that a semantic model of the 396Web service exists, WSDL-S describes a mechanism to link this semantic model with the syntactic 397functional description captured by WSDL. Using the extensibility elements of WSDL, a set of annotations 398can be created to semantically describe the inputs, outputs and operations of a Web service. This method 399keeps the semantic model outside WSDL, making the approach agnostic to any ontology representation 400language as illustrated in Figure 1. 401 402 403 Figure 1: Associating semantics to WSDL elements [Akkiraju et al. 2005]. 404 405The key advantages of the approach are that it (i) builds on WSDL using its extensibility mechanism (ii) is 406agnostic to the ontological language used for semantic annotations and (iii) supports annotating XML 407Schema data types, the most common data-definition mechanism used in Web service descriptions. 408 409Editor: Matthew Moran 410 4113.6 Semantic Web Services Initiative – Semantic Web Services 412 Architecture Committee 413Mission of the Semantic Web Services Initiative Architecture (SWSA) committee, part of Semantic Web 414Services Initiative, was to develop the necessary abstractions for an architecture that supports Semantic 415Web Services. The resultant framework builds on the W3C Web Services Architecture working group 416report. Other groups developing Semantic Web services frameworks contributed to the discussions, 417including the OWL-S consortium, WSMO and METEOR-S working groups. 418At this stage the SWSA group has suspended its activity, but the major outcomes of their work have been 419input for work of WSMX working group and some of its ideas have been already partially applied to 420WSMX infrastructure. Work of SEE TC can be treated as a continuation of SWSA work to further 421elaborate on the protocols exchanged between the interacting components/services. Several contributors 422of SWSA group were supporters of establishing SEE TC. 423 424Editor: ??? 42[Document Identifier] [DD Month YYYY] 43Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 21
    • 425 4263.7 Glue 427Glue [DellaValle et al, 2005] is a WSMO compliant discovery engine that provides the basis for 428introducing discovery in a variety of applications in an easy-to-use way for requesters, and providing 429efficient pre-filtering and accurate discovery of relevant services that fulfill a given requester goal. 430In conceiving Glue, the model for WSMO Web Service discovery introduced was refined explicating the 431central role of mediation: 432 • by making the notion of class of goals and class of Web Service descriptions explicit; 433 • by using ggMediators to automatically generate a set of goals that are semantically equivalent to 434 the one expressed by the requester but are expressed with a different form or using different 435 ontologies; 436 • by making wgMediators the conceptual element responsible for evaluating the matching; 437 • by using ooMediators to solve any terminological mismatch that can appear when dealing with 438 different polarized ontologies for the domain, and item by redefining the discovery mechanism as 439 a composite procedure where the discovery of the appropriate mediators and the discovery of the 440 appropriate services is combined. 441Glue implementation9 uses internally F-Logic and it is built aroung an open source F Logic interference 442engine called Flora210 that runs over XSB11, an open source implementation of tabled prolog and 443deductive database system. 444 445Editor: Dario Cerizza 459 The latest release of Glue implementation is available open source at 46http://sourceforge.net/projects/sws-glue 4710 http://flora.sourceforge.net 4811 http://xsb.sourceforge.net 49[Document Identifier] [DD Month YYYY] 50Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 21
    • 4464 Relationships to Other Specifications 447All Web Services and Service Oriented Architecture groups are the primary target of this work. It is 448anticipated that liaisons may be needed for many SOA-related Technical Committees such as the 449following: 4504.1 W3C WS Choreography Working Group 451W3C Chorographpy and WSMO Choreography are partly orthogonal to each other and have different 452views on the same problems in other areas. A fundamental difference is that WSMO choreographies are 453natively based on semantics by choosing ontologies as the datamodel it operates on, while W3C 454choreography works primarily on syntactical construct. In addition to that it takes a global viewpoint on the 455behavior aspects of web service while WSMO model behavior strictly local to a Web Service. The models 456are not compatible per se, but there is enough orthogonality to reasonably expect usefull results that each 457address aspects of the problem. 458 459Editor: Thomas Haselwanter 460 4614.2 OASIS ebSOA TC 462OASIS ebSOA TC continues the work in ebXML Technical Architecture taking in consideration the latest 463releases in ebXML specifications and based on the latest developments in Web Services and Service 464oriented Architecture. 465The focus of this committee is to develop a set of patterns defining the architectural elements end the 466relationship between them, in order to enable electronic business on global basis. Examples of such 467patterns are: Service Description Pattern, Search and Discovery Pattern, Business Process Description 468Pattern, Data Transformation Pattern, etc. 469As SEE is a Service Oriented Architecture meant to enable business scenarios between various business 470entities (through Semantic Web Service), such patterns could be valuable in identifying meaningful 471execution semantics or in pointing to best practices as a reference point for SEE development. 472 473Editor: 474 4754.3 OASIS ebXML Registry TC 476OASIS ebXML Registry is chartered to develop specifications to achieve interoperable registries and 477repositories, with an interface that enables submission, query and retrieval on the contents of the registry 478and repository. The Registry TC seeks to develop specifications that serve a wide range of uses, covering 479the spectrum from general purpose document registries to real-time business-to-business registries. 480Additionally, as part of its specification development work, this TC explores and promotes various 481emerging models for distributed and cooperating registries. 482SEE TC recognized discovery as a critical element of its infrastructure. ebXML registry/repository is en 483example of specification, which capture functionality expected from the particular components/services of 484the SEE infrastructure. Work of SEE infrastructure aim to answer question if infrastructure provided by 485existing business registries such as ebXML would be sufficient to serve for scenarios as described by use 486cases of SEE TC. 487 52[Document Identifier] [DD Month YYYY] 53Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 21
    • 488Editor: 489 4904.4 OASIS ebXML BP TC 491OASIS ebXML Business Process (ebBP) TC defines a standard language to configure business systems 492for business collaboration execution between collaborating parties or business partners. Business 493processes are key components to enable and drive collaborating partner relationships for electronic 494business (eBusiness). The ebBP provides capabilities to drive those eBusiness collaborative processes. 495As a part of the original eBusiness XML framework of specifications, the ebBP is targeted for monitoring 496of collaborative business processes among parties or business partners. Today, ebBP has evolved to 497integrate use of other specifications and emerging technologies as part of eBusiness solutions focused on 498Service-Oriented Architecture. 499 500Editor: Michal Zaremba 501 5024.5 OASIS Web Services Resource Framework (WSRF) TC 503The Web Services Resource Framework (WSRF) [WSRF 2005] is a standard for Web services that takes 504into account features involved in the implementation of Grid computing, such as statefulness, notification 505mechanisms and transient resources or services (in contrast to standard Web services which are 506stateless and persistent). WSRF is an open framework that allows the implementation of both Grid 507applications and Grid middleware services (job submission, file transfer, information service, etc.).One of 508the key ideas of WSRF is the virtualization of resources through WS-Resource (i.e. a Web service with 509properties describing a state). The WSRF is a specification of the mandatory and optional interfaces a 510Web service must support for it to be considered a Grid service based on the definitions of Grid service 511and Open Service Grid Architecture (OGSA) provided in [OGSA 2002]. 512There relationship between Web services and Grids has been established by the OGSA definition of a 513service oriented architecture for Grids based on standard Web service technology. Both the WSRF and 514SEE aim at seamless integration and ad-hoc cooperation between various resources on the Web. SEE 515focuses on the solving the problems of data and process mediation as well as service discovery and 516composition based on semantic annotation of services. The WSRF complements SEE by providing 517specifications to cater for aspects such as stateful Web resources, notification mechanisms and lifetime- 518management of services. The application of semantics to the WSRF suggests a logical step to enable 519WSRF fulfill the requirements for the resource management in the SEE architecture. 520This would require the development of a “WSRF-S” a combination of WSRF and the semantic framework 521used by the rest of SEE. The advantage of enhancing WSRF with semantics and the use of ontologies 522will be twofold: first, it facilitates the unambiguous description of various resources and their relationships. 523This is currently missing and is an important issue, because WSRF is a significant building block for the 524Grid and is used at different levels. Because of the lack of clear semantics, currently the creation of new 525Grid services and applications require somewhat arbitrary conventions to be followed, and is relatively 526tedious and error prone. Secondly, the use of semantic-based discovery and composition techniques will 527greatly aid in the task of finding and using Grid resources. 528 529Editor: 530 55[Document Identifier] [DD Month YYYY] 56Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 21
    • 5314.6 OASIS FWSI TC 532The Framework for Web Services Implementation (FWSI) TC12 aims to enable robust implementations of Web 533Services by defining a practical and extensible methodology consisting of implementation processes and 534common functional elements that practitioners can adopt to create high quality Web Services systems without 535reinventing them for each implementation. 536The goals of the FWSI TC are13 to: 537 1. accelerate implementation of Web Services-based systems 538 2. improve the performance and robustness of such systems 539 3. improve understanding of Web Services implementations 540 4. reduce the complexity of such systems and hence reduce the developmental and maintenance 541 efforts; and to 542 5. reduce the risk of implementation. 543 544A key outcome of the FWSI TC is the specification of a set of Functional Elements that need to be instantiated 545into a technical architecture. The purpose of this specification to define the right level of abstraction for these 546Functional Elements and to specify the purpose and scope of each Functional Element so as to facilitate 547efficient and effective implementation of Web Services. 548Since the main focus of the FWSI TC is the implementation of Web services and the identification of 549necessary functional elements, its objectives clearly differ from the objectives of the SEE TC, which is 550mainly concerned with using existing Semantic Web Services. However, it would be interesting to 551examine the functional elements proposed by the FWSI TC in the context of Semantic Web Services 552environment. This may help to identify and describe additional functional elements that are necessary in a 553semantic execution environment. These additional functional elements could be suggested to the FWSI to 554extend their framework for Web services implementation to also work with Semantic Web Services. 555 556Editor: Marc Haines, Adrian Mocan 557 5584.7 Biztalk 559Microsoft Biztalk 14is a software integration product built around XML messaging. First released in 2000, 560the current version of Biztalk requires Microsoft .Net version 2.0 and uses Microsoft SQL Server as the 561underlying database system. The focus of Biztalk is XML-based integration even where the applications 562or systems being integrated do not directly support XML. In such cases, adapters are used and a wide 563range of adapters for various commercial systems are provided. From the developer point of view there 564are a number of artifacts that can be created as part of an integration deployment. These include software 565applications (usually but not exclusively built on .Net), XML Schema, XSLT documents for data 566transformation between differing XML Schema and orchestrations incorporating business rules. 567Orchestrations are definitions of business processes in terms of applications and services linked together 568by XML messages. Message routing is based on a publish/subscribe model and rules can be defined to 569determine or constrain the flow of messages. One of the strengths of Biztalk is the integrated visual 570environment provided by Microsoft for the creation of the various artifacts required by Biztalk. Microsoft 571Visual Studio has tools for creation of XML Schema, business rules, applications and orchestrations. 572The challenges faced by Biztalk are common to all application integration platforms – how to handle the 573combination of autonomous heterogeneous applications where the heterogeneity stretches across data, 574process models and communication models. Mismatch handling is carried out using a combination of 575adapters and XSLT. Many popular communication and business protocols are handled. This includes 5812 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=fwsi 5913 Taken from the FWSI TC’s charter, http://www.oasis-open.org/committees/fwsi/charter.php 6014 http://www.microsoft.com/biztalk/ 61[Document Identifier] [DD Month YYYY] 62Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 21
    • 576being able to import and export BPEL process descriptions. Process mismatches are usually addressed 577by bespoke application development. 578A significant drawback associated with Biztalk is licensing cost for smaller organizations as the product is 579dependent on a larger suite of Microsoft products such as SQL Server, and Visual Studio. In comparison 580with SEE, Biztalk, being based exclusively on XML assumes that XSLT and design time graphical tools 581are sufficient to cover data and process mediation problems. The absence of support for semantics 582means that process designs are more brittle and changes to individual XML schema can have significant 583redesign knock-on effects. 584 585Editor: Matthew Moran 586 64[Document Identifier] [DD Month YYYY] 65Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 21
    • 5875 References 5885.1 Normative References 589 [Akkiraju et al. 2005] R. Akkiraju, J. Farrell, J.Miller, M. Nagarajan, M. Schmidt, A. Sheth, and K. 590 Verma, "Web Service Semantics - WSDL-S, available at 591 http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/," 2005. 592 [Brodie et al. 2005] M. Brodie, C. Bussler, J. d. Bruijn, T. Fahringer, D. Fensel, M. Hepp, H. Lausen, 593 D. Roman, T. Strang, H. Werthner, and M. Zaremba, "Semantically Enabled 594 Service-Oriented Architectures: A Manifesto and a Paradigm Shift in Computer 595 Science," DERI 2005. 596 [DellaValle et al., 2005] E. Della Valle and D. Cerizza. The mediators centric approach to automatic 597 Web Service discovery of Glue. In M. Hepp, A. Polleres, F. van Harmelen, and 598 M. R. Genesereth, editors, Proc. of the 1st Int’l Workshop on Mediation in 599 Semantic Web Services (MEDIATE’05). CEUR-WS.org, December 2005. 600 [DOMINGUE et al., 2004] John Domingue, Liliana Cabral, Fashard Hakimpour, Denilson Sell and 601 Enrico Motta. IRS-III: A Platform and Infrastructure for Creating WSMO-based 602 Semantic Web Services. In Proceedings of the Workshop on WSMO 603 Implementations (WIW 2004), Frankfurt, Germany, September 29-30, 2004, 604 CEUR Workshop Proceedings, ISSN 1613-0073. http://sunsite.informatik.rwth- 605 aachen.de/Publications/CEUR-WS//Vol-113/paper3.pdf. 606 [DOMINGUE et al., 2005a] John Domingue, Liliana Cabral, Stefania Galizia and Enrico Motta. A 607 Comprehensive Approach to Creating and Using Semantic Web Services, In 608 Proceedings of the W3C Workshop on Frameworks for Semantics in Web 609 Service, Innsbruck, Austria, June 9-10, 2005. 610 [DOMINGUE et al., 2005b] John Domingue, Stefania Galizia, and Liliana Cabral. Choreography in 611 IRS-III- Coping with Heterogeneous Interaction Patterns in Web Services, In 612 Proceedings of the 4th International Semantic Web Conference (ISWC 2005), 613 November 6-10, 2005, Galway, Ireland. 614 [Haller et al., 2005] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler, WSMX – A Semantic 615 Service-Oriented Architecture. In Proc. Of the 3rd Int. Conf. on Web Services, pp. 616 321 – 328. IEEE Computer Society, 2005. 617 [Haselwanter et al., 2006] T. Haselwanter, P. Kotinurmi, M. Moran, T. Vitvar, and M. Zaremba, 618 "Dynamic B2B Integration using Semantic Web Services: SWS Challenge Phase 619 2, available at http://sws- 620 challenge.org/2006/paper/DERI_WSMX_SWSChallenge_II.pdf" presented at 621 SWS Challenge Phase II Workshop, Budva, Montenegro, 2006. 622 [Preist 2004] Chris Preist, A Conceptual Architecture for Semantic Web Services. in Third 623 International Semantic Web Services Conference (ISWC), Hiroshima, Japan, 624 2004, Springer, pp395-409 6255.2 Non-Normative References 67[Document Identifier] [DD Month YYYY] 68Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 21
    • 6266 Summary 70[Document Identifier] [DD Month YYYY] 71Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 21
    • 627A. Acknowledgements 628The following individuals have participated in the creation of this specification and are gratefully 629acknowledged: 630Participants: 631 Barry Norton, The Open University 632 Omair Shafiq, DERI 633 Maciej Zaremba, DERI 73[Document Identifier] [DD Month YYYY] 74Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 21
    • 634B. Revision History 635[optional; should not be included in OASIS Standards] 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 Wd-07 2006-10-31 Emanuele Della Valle Refactoring of section structure and responsibility assignment Wd-09 2006-11-11 Emanuele Della Valle Revision in FWSI section by Marc Haines 636 76[Document Identifier] [DD Month YYYY] 77Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 21