• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Background and Related Work
 

Background and Related Work

on

  • 842 views

 

Statistics

Views

Total Views
842
Views on SlideShare
842
Embed Views
0

Actions

Likes
0
Downloads
1
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

    Background and Related Work Background and Related Work Document Transcript

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