Background and Related Work

Semantic Execution Environment (SEE) Background and Related Work

Working Draft 07, 31 October 2006

Artifact Identifier:SEE-background-and-related-work_07

Location:Current: SEE-background-and-related-workThis Version: SEE-background-and-related-work_06Previous Version: SEE-background-and-related-work_05

Artifact Type:TBC

Technical Committee:OASIS SEE TC

Editor:Emanuele Della Valle, CEFRIEL < [email protected] >

Contributors:Adrian Mocan, DERI < [email protected] >Emilia Cimpian, DERI < [email protected] >Matthew Moran, DERI < [email protected] >Emanuele Della Valle, CEFRIEL < [email protected] >Dario Cerizza, CEFRIEL < [email protected] >John Domingue, The Open University < [email protected] >Brahmananda Sapkota, DERI < [email protected] >TBC more from the former documents?

OASIS Conceptual Model topic area:SOA

Related work:This specification replaces or supersedes:

[specifications replaced by this standard] [specifications replaced by this standard]

This specification is related to:

[related specifications] [related specifications]

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

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

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the

[Document Identifier] [DD Month YYYY]Copyright © OASIS Open 2006. All Rights Reserved. of 21

1

2

3

4

56

78910

1112

1314

1516

171819202122232425

2627

2829

3031

32

3334

3536

373839

4041

12

3

mailto:[email protected]








“Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/ex-semantics.

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

The non-normative errata page for this specification is located at www.oasis-open.org/committees/ex-semantics.


4243

44454647

4849

45

6

Notices

Copyright © OASIS Open 2006. All Rights Reserved.

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

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

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

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

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

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

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


50

51

5253

5455565758596061

6263

6465666768

6970717273

7475767778

7980818283848586878889

78

9

Table of Contents

1 Introduction......................................................................................................................................... 5

2 SOA Related work............................................................................................................................... 6

2.1 OASIS SOA Reference Model TC.....................................................................................................6

2.2 OASIS SOA Adoption Blueprints TC.................................................................................................6

2.3 W3C XML Protocol Working Group...................................................................................................6

2.4 W3C WS Description Working Group................................................................................................7

2.5 OASIS UDDI TC................................................................................................................................ 7

2.6 WS-BPEL.......................................................................................................................................... 8

3 Related work in adding semantics to SOA..........................................................................................9

3.1 Web Services Modelling Ontology (WSMO) Working Group.............................................................9

3.2 Web Services Modelling Language (WSML) Working Group............................................................9

3.3 Web Services Execution Environment (WSMX) Working Group.......................................................9

3.4 IRS-III.............................................................................................................................................. 11

3.5 WSDL-S.......................................................................................................................................... 12

3.6 Semantic Web Services Initiative – Semantic Web Services Architecture Committee....................13

3.7 Glue................................................................................................................................................. 13

4 Relationships to Other Specifications................................................................................................14

4.1 W3C WS Choreography Working Group.........................................................................................14

4.2 OASIS ebSOA TC........................................................................................................................... 14

4.3 OASIS ebXML Registry TC.............................................................................................................14

4.4 OASIS ebXML BP TC...................................................................................................................... 15

4.5 OASIS Web Services Resource Framework (WSRF) TC................................................................15

4.6 OASIS FWSI TC.............................................................................................................................. 16

4.7 Biztalk.............................................................................................................................................. 16

5 References........................................................................................................................................ 18

5.1 Normative References.....................................................................................................................18

5.2 Non-Normative References.............................................................................................................18

6 Summary........................................................................................................................................... 19

A. Acknowledgements........................................................................................................................... 20

B. Revision History................................................................................................................................ 21


90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

1011

12

1 IntroductionThis document is intended to provide the audience of SEE TC documents with a minimum set of back ground information. It is organized as a list of short sections that describe research and development activities at the basis of SEE TC work (section 2 and 3). Section 2 is mainly centered on SOA concepts and current implementation of SOA based on Web Services technologies. Section 3, on the other hand, contains sections related to efforts that are tying to add semantics to SOA. In Section 4 SEE TC work is put in relationship with other OASIS and W3C standardization activities. Finally, Section 5 includes a list of references to relevant literature cited in the previous chapters.

1.1 MethodologyIn order to make the document as readable as possible we decided to organized the information in each subsection as follows:

- short description of the activity: 50-100 words describing the activity. Detailed information not accessible to people outside the described activity should be avoided.

- motivation of the activity: 50-100 words describing the main goals of the activities avoiding the use of concepts specific of the activities.

- relationships with other activities: 50-100 words describing the relationships of this activity with others either present in the document (internal pointers are welcome) or not listed (in this case references are welcome).

- detailed description of the activity (optional): max 500 words describing the activities in more details. Concepts related to the activity itself can be referenced and used,

- achievements and roadmap: max 200 words describing the current achievements of the activity and the roadmap towards goal achievement.

- participants (optional): list the key organizations or individuals promoting the activity

- to learn more: references and links to external resources


123

124125126127128129130

131

132133

134135

136137

138139140

141142

143144

145

146

1314

15

2 SOA Related work

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

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

Editor:

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

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

business problem statement,

a set of business requirements, and

a normative set of functions to be fulfilled.

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

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

Editor: Emanuele Della Valle

2.3 W3C XML Protocol Working Group

Editor: Matthew Moran


147

148

149150151152153

154155156157

158

159

160

161

162163164165

166167

168

169

170

171172173174

175176

177

178

179

180

181

182

183

1617

18

Emanuele Della Valle, 10/30/06,

Shall we add a SOAP related section?

2.4 W3C WS Description Working GroupThe W3C Web Service Description Working Group1, which is part of the Web Services Activity2, currently consists of 34 members from 23 different organizations, with both industrial and academic profile.

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

Out of 8 deliverables developed by this working group 3 are W3C Candidate Recommendations: Web Services Description Language (WSDL) Version 2.0 Part 0: Primer (http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/), Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language (http://www.w3.org/TR/wsdl20/), and Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts (http://www.w3.org/TR/wsdl20-bindings/).

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

Editor: Emilia Cimpian

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

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

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

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

For a good overview of the past activities around UDDI see the UDDI Cover Pages4 .

Editor: Emanuele Della Valle

1 http://www.w3.org/2002/ws/desc/ 2 http://www.w3.org/2002/ws/Activity 3 http://www.uddi.org/ 4 http://xml.coverpages.org/uddi.html[Document Identifier] [DD Month YYYY]Copyright © OASIS Open 2006. All Rights Reserved. of 21

184

185186

187188189190191

192193194195196

197198199200201202203

204

205

206

207

208209210211

212213

214215

216217218219220

221

222

223

224

19

20

21

22

2324

25

http://xml.coverpages.org/uddi.html

http://www.uddi.org/

http://www.w3.org/TR/wsdl20-bindings/

http://www.w3.org/TR/wsdl20/

http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/

http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/

http://www.w3.org/2002/ws/Activity

http://www.w3.org/2002/ws/desc/

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

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

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

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


5 http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ [Document Identifier] [DD Month YYYY]Copyright © OASIS Open 2006. All Rights Reserved. of 21

225

226227228229230231232

233234235236237238

239240241242243

244245246247248249

250

251

252

253

26

2728

29

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

3 Related work in adding semantics to SOA

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

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

Editor: John Domingue

3.2 Web Services Modelling Language (WSML) Working Group

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

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

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

Editor: Brahmananda Sapkota

3.3 Web Services Execution Environment (WSMX) Working GroupThe Web Service Execution Environment (WSMX) [Haller et al. 2005] is a research prototype implementation for discovering, selecting, mediating and invoking Semantic Web services. It can be installed at the service requester side, provider side or both or at an independent location. WSMX was designed and created to provide a software environment capable of interpreting and acting on the semantic descriptions provided by the Web Services Modeling Ontology (WSMO). Interpreting means that


254

255

256257258259

260261262263

264

265

266

267268269270271272

273274275276277278279280281282283

284285

286

287

288

289

290291292293294

3031

32

WSMX accepts WSMO descriptions represented using the Web Services Modeling Language (WSML) and parses the descriptions into an internal format provided by a Java object model. Depending on the type of the WSMO element description received, WSMX initiates a defined behaviour. The phrase, acting on, means that this behaviour is defined as specific sets of activities that correspond to the type of WSMO element received. For example, when a goal description is received, there is currently a set of two possible activities. The first is that WSMX will attempt to discover Web service descriptions that match the goal and return these to the client. The second is that in addition to the discovery phase, service selection, mediation and invocation will take place – a full round trip between service requester and provider.

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

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

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

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

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

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

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

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

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

WSMX is an open source project with source code available at http://sourceforge.net/projects/wsmx/ under an LGPL license. A number of EU research projects use WSMX as the basis for their prototype implementations and additionally it is an active participant in the Semantic Web Services challenge http://sws-challenge.org/wiki/index.php/Main_Page. The work of WSMX working group and its ideas have


295296297298299300301302303

304

305306307

308309

310311312

313314315316317

318319320321322

323324325326327328329330331

332

333334335336

337338339

340

341342343344

3334

35

http://sws-challenge.org/wiki/index.php/Main_Page

http://sourceforge.net/projects/wsmx/

been used as the basis to establish the OASIS SEE Technical Committee. DERI6 has contributed all WSMX conceptual work and its reference implementation to the open source community as a platform for research and development. As the work of the SEE TC progresses, it is intended that WSMX becomes an early reference implementation.


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

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

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

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

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

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

Editor: John Domingue

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

6 http://www.deri.org/7 http://www.w3.org/Submission/WSDL-S/8 http://www.w3.org/2002/ws/sawsdl/[Document Identifier] [DD Month YYYY]Copyright © OASIS Open 2006. All Rights Reserved. of 21

345346347348

349

350

351

352

353354355356357

358359360361362363364365366

367

368369370371372373

374375376

377378379

380

381

382

383

384385386387388

36

37

38

3940

41

http://www.w3.org/2002/ws/sawsdl/

http://www.w3.org/Submission/WSDL-S/

provides a mechanism to specify preconditions and effects on the operation child elements of WSDL interfaces.

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

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

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


3.6 Semantic Web Services Initiative – Semantic Web Services Architecture Committee

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

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

Editor:


389390

391392393394395396

397

398399

400

401402403

404

405

406

407408

409410411412413

414415416417418

419

420

421

4243

44

3.7 Glue

Editor: Dario Cerizza


422

423

424

425

4546

47


CEFRIEL would like to add this section

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

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

Editor: Thomas Haselwanter

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

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

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

Editor:

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

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


426

427428429

430

431432433434435436437

438

439

440

441

442443444

445446447448

449450451

452

453

454

455

456457458459460461

462463464465466

467

4849

50

Editor:

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

Editor: Michal Zaremba

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

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

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

Editor:


468

469

470

471472473474475476477478

479

480

481

482

483484485486487488489490491

492493494495496497498499

500501502503504505506507

508

509

510

5152

53

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

The efforts of this TC are10 to:

1. accelerate implementation of Web Services-based systems

2. improve the performance and robustness of such systems

3. improve understanding of Web Services implementations

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

5. reduce the risk of implementation.

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

Editor: Adrian Mocan

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

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

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

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

9 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=fwsi 10 Taken from the FWSI TC’s charter, http://www.oasis-open.org/committees/fwsi/charter.php11 http://www.microsoft.com/biztalk/ [Document Identifier] [DD Month YYYY]Copyright © OASIS Open 2006. All Rights Reserved. of 21

511

512513514515

516

517

518

519

520521

522

523524525526527

528

529

530

531

532533534535536537538539

540541542543544

545546547548549550

551552553554

54

55

56

5758

59

http://www.microsoft.com/biztalk/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=fwsi

means that process designs are more brittle and changes to individual XML schema can have significant redesign knock-on effects.



555556

557

558

559

6061

62

5 References

5.1 Normative References[Akkiraju et al. 2005] R. Akkiraju, J. Farrell, J.Miller, M. Nagarajan, M. Schmidt, A. Sheth, and K.

Verma, "Web Service Semantics - WSDL-S, available at http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/," 2005.

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

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

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

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

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

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

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

5.2 Non-Normative References


560

561

562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593

594

595

6364

65


Should be extended to include all relevant pointer to literature related to SEE TC

6 Summary


596

6667

68

A. Acknowledgements

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

Participants:Barry Norton, The Open UniversityOmair Shafiq, DERIMaciej Zaremba, DERI


597

598599

600601602603

6970

71

B. Revision History

[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


604

605

606

7273

74

Background and Related Work

Documents

Transcript of Background and Related Work