Semantic Execution Environment (SEE)
Background and Related Work
To be Approved, 10 October 2007
Artifact Identifier:
SEE-background-and-related-work_11
Location:
Current: http://www.oasis-open.org/apps/org/workgroup/semanticex/document.php?document_id=20914
This Version: http://www.oasis-open.org/apps/org/workgroup/semanticex/download.php/20914/SEE-background-and-related-work_10.doc
Previous Version: http://www.oasis-open.org/apps/org/workgroup/semanticex/download.php/20914/SEE-background-and-related-work_09.doc
Artifact Type:
TBC – Background and Related Work
Technical Committee:
OASIS SEE TC
Chairs:
John Domingue, Open University, < [email protected] >
Michal Zaremba, DERI Innsbruck, < [email protected] >
Editors:
Zhixian Yan, DERI < [email protected] >
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] >
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 1 of 26
Michal Zaremba, DERI Innsbruck, < [email protected] >
OASIS Conceptual Model topic area:
SOA (Service-Oriented Architecture), Semantic Web,
(Semantically-Enabled Service-Oriented Architecture)
Semantic
Web
Service,
SESA
Related work:
This specification replaces or supersedes:

This document provides the background and related work (supersedes) for the other
documents of OASIS SEE TC, especially the two specific documents, namely “Reference
Model for Semantic Service Oriented Architecture” and “Reference Architecture for
Semantic Service-Oriented Architecture”.
This specification is related to:


The reference model is specified in the separate OASIS SEE TC document titled
“Reference Model for Semantic Service Oriented Architecture”.
The reference architecture is specified in the separate OASIS SEE TC document titled
“Reference Architecture for Semantic Service Oriented Architecture”.
Abstract:
This document collects background information and related work of interest of OASIS SEE TC.
Status:
This document is already in the FINAL status, but maybe further updated and improved
periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical
Committee’s email list. Others should send comments to the Technical Committee by using the
“Send A Comment” button on the Technical Committee’s web page at www.oasisopen.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.oasisopen.org/committees/ex-semantics/ipr.php.
The non-normative errata page
open.org/committees/ex-semantics.
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
for
this
specification
is
located
at
www.oasis-
"01 October 2007"
Page 2 of 26
Notices
Copyright © OASIS Open 2007. 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.
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 3 of 26
Table of Contents
1
2
Introduction ........................................................................................................................................... 5
SOA Related work ................................................................................................................................ 6
2.1 OASIS SOA Reference Model ............................................................................................................ 6
2.2 OASIS SOA Adoption Blueprints ........................................................................................................ 6
2.3 W3C XML Protocol Working Group .................................................................................................... 7
2.4 W3C WS Description Working Group ................................................................................................. 8
2.5 OASIS UDDI TC ................................................................................................................................. 8
2.6 WS-BPEL ............................................................................................................................................ 9
3
Related work in adding semantics to SOA ......................................................................................... 10
3.1 Web Services Modeling Ontology (WSMO) ..................................................................................... 10
3.2 Web Services Modeling Language (WSML)..................................................................................... 11
3.3 Web Services Execution Environment (WSMX) ............................................................................... 12
3.4 IRS-III ................................................................................................................................................ 14
3.5 Semantically-Enabled Service-oriented Architecture (SESA) .......................................................... 14
3.6 WSDL-S, SAWSDL........................................................................................................................... 16
3.7 Semantic Web Services Initiative – Semantic Web Services Architecture Committee .................... 17
3.8 Glue .................................................................................................................................................. 18
4
Relationships to Other Specifications................................................................................................. 19
4.1 W3C WS Choreography Working Group .......................................................................................... 19
4.2 OASIS ebSOA TC ............................................................................................................................ 19
4.3 OASIS ebXML Registry TC .............................................................................................................. 19
4.4 OASIS ebXML BP TC ....................................................................................................................... 20
4.5 OASIS Web Services Resource Framework (WSRF) TC ................................................................ 20
4.6 OASIS FWSI TC ............................................................................................................................... 21
5
References ......................................................................................................................................... 22
6
Summary ............................................................................................................................................ 24
A. Acknowledgements ............................................................................................................................ 25
B. Revision History.................................................................................................................................. 26
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 4 of 26
1
1 Introduction
2
3
4
5
6
7
8
This document is intended to provide the audience of SEE TC documents with a minimum set of back
ground information. It is organized as a list of short sections that describe research and development
activities at the basis of SEE TC work (section 2 and 3). Section 2 is mainly centered with SOA concepts
and current implementations 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 concludes a list
of references to relevant literatures cited in the previous chapters.
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 5 of 26
9
2 SOA Related work
10
2.1 OASIS SOA Reference Model
11
12
13
14
15
The OASIS SOA Reference Mode (SOA-RM) is a product of the OASIS SOA Reference Model (SOA-RM)
Technical Committee (TC)1. Prior to this initiative, no standard definition of SOA had existed. The SOARM TC was charted in February 2005 to develop a core Reference Model for Service Oriented
Architecture. The Reference Model is being developed to encourage the continued growth of different
and specialized SOA implementations whilst preserving a common layer of understanding what SOA is.
16
17
18
19
20
21
22
23
24
The motivation and main goal of OASIS SOA-RM is providing a core Reference Model to be used to
guide and forster the creation of specific Service-Oriented Architecture. This is primarily to address SOA
being used as a term in an increasing number of contexts and specific technology implementations.
According to the SOA-RM specification, SOA is a paradigm for organizing and utilizing distributed
capabilities that may be under the control of different ownership domains. It provides a uniform means to
offer, discover, interact with and use capabilities to produce desired effects consistent with measurable
preconditions and expectations. The SOA-RM specification bases its definition of SOA around the
concept of “needs and capabilities”, where SOA provides a mechanism for matching needs of service
consumers with capabilities provided by service providers.
25
26
27
28
29
30
31
The reference model was approved as an OASIS standard by OASIS Members in October 2006.
Furthermore, the OASIS SOA-RA (Reference Architecture) subcommittee 2 has developed a SOA
reference architecture based on the SOA-RM specification. Basically, SEE TC aims to use concepts laid
by SOA RM and RA 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.
32
33
34
More detailed information and resources can be further referred to the two standardized documents
(OASIS SOA Reference Model [OASIS SOA-RM] and Reference Architecture [OASIS SOA-RA]), other
relevant literatures and the two OASIS TC websites mentioned previously.
35
2.2 OASIS SOA Adoption Blueprints
36
37
38
The OASIS SOA Adoption Blueprints TC3 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
1
OASIS SOA-RM TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
2
OASIS SOA-RA TC, http://wiki.oasis-open.org/soa-rm/ReferenceArchitecture
3
OASIS SOA Adoption Blueprints TC, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-blueprints
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 6 of 26
39
40
blueprints". The TC does not develop any new Web services standards, but recommends instead certain
standards as suitable for specific functional requirements.
41
42
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



43
44
45
business problem statement,
a set of business requirements, and
a normative set of functions to be fulfilled.
46
47
48
49
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.
50
51
52
There isn’t too much new status or supporting documents can be available publicly. For more details
information on "adoption blueprints" can be further referred to the SOA Adoption Blueprint “Generico”
Working Draft in March 2006 [AdoptionBlueprint].
53
2.3 W3C XML Protocol Working Group
54
55
56
57
58
59
60
The W3C XML Protocol Working Group4, founded in September 2000, is the first working group of XML
protocol activity, which is a part of the Web Service Activity5. The initial focus of the XML Protocol WG is
to develop a framework for XML-based messaging systems, which includes specifying a message
envelope format and a method for data serialization, directly mainly, but not exclusively, to RPC
application. Quite a number of relevant working documents and drafts have been realized, such as: XML
Protocol (XMLP) Requirement Document, XML Protocol Abstract Model, XML Protocol Usage Scenarios,
SOAP Primer, SOAP Messaging Framework, and SOAP Adjuncts ect.
61
62
63
64
65
66
67
68
69
The goal of XML Protocol is to develop technologies which allow two or more peers to communicate in a
distributed environment using XML as its encapsulation language. Solutions developed by this activity
allow a layered architecture on top of an extensible and simple messaging format, which provides
robustness, simplicity, reusability and interoperability. The representative outcome of this working group is
the SOAP standardization, a protocol for exchanging XML-based messages over computer networks,
normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a
basic messaging framework which more abstract layers can build on. Now, SOAP has moved to the
version 1.2. More details can be referred to the three core deliverables, namely SOAP Primer [SOAP1.2Primer], SOAP Messaging Framework [SOAP1.2-Messaging], and SOAP Adjuncts [SOAP1.2- Adjuncts].
70
71
In addition to XML formats for messaging, SEE TC further focuses on semantically-enabled web service
descriptions with WSML, which offers a human readable syntax as well as XML and RDF for exchanging
4
XML Protocol Working Group, http://www.w3.org/2000/xp/Group/
5
W3C Web Service Activity, http://www.w3.org/2002/ws/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 7 of 26
72
73
data between machines. WSML provides a formal syntax and semantics for WSMO (Web Service
Modeling Ontology).
74
2.4 W3C WS Description Working Group
75
76
77
The W3C Web Service Description Working Group 6, which is another important part of the Web Services
Activity 7 , currently consists of 34 members from 23 different organizations, with both industrial and
academic profiles.
78
79
80
81
82
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).
83
84
85
86
87
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/CRwsdl20-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/).
88
89
90
91
92
93
94
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.
95
2.5 OASIS UDDI TC
96
97
98
99
The Universal Description, Discovery and Integration (UDDI) protocol8 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:
100
101
102
103


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.
6
http://www.w3.org/2002/ws/desc/
7
http://www.w3.org/2002/ws/Activity
8
http://www.uddi.org/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 8 of 26
104
105
106
107
108
109
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 Pages9.
110
111
2.6 WS-BPEL
112
113
114
115
116
WS-BPEL is concerned with creating a language to specify business processes using Web services. The
acronym stands for Web Service-Business Process Execution Language. In 2003 OASIS was invited to
continue the work of the BPEL4WS v1.110 specification whose contributing members included IBM, BEA
Systems, Microsoft, SAP AG and Siebel Systems and the WS-BPEL technical committee 11 was
established.
117
118
119
120
121
122
123
124
In that context, WS-BPEL considers the following challenges: how to handle (i) data-dependent behavior,
(ii) exceptional conditions and (iii) long-running interactions including multiple nested processes. WSBPEL 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.
125
126
127
128
129
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.
130
131
132
133
134
135
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.
9
http://xml.coverpages.org/uddi.html
10
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
11
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 9 of 26
136
3 Related work in adding semantics to SOA
137
3.1 Web Services Modeling Ontology (WSMO)
138
139
140
141
142
Web Service Modeling Ontology (WSMO)12 is a conceptual model that describes the aspects related to
Semantic Web Services, providing ontological specifications. 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 [Roman et al., 2006].
The following figure provides a sketch map for the WSMO four main core elements.
143
144
Figure 1. WSMO Top Level Elements
145
146
147
148
149
150
151
152
153
As a fundamental description framework for such future generation Web, WSMO is designed with
following principles: (1) Web Compliance, (2) Ontology-based, (3) Strict Decoupling, (4) Centrality of
Mediation, (5) Ontological Role Separation, (6) Description versus Implementation, (7), Execution
Semantics, (8) Service versus Web Service. The elements of the WSMO ontology are defined in a metameta-model language based on the Meta Object Facility (MOF) (OMG, 2002). Based on those principles
and the MOF meta-model, 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.
154
155
A lot of supporting deliverables about WSMO can be found in the WSMO working group website, and
some of them have been submitted to the relevant W3C standard organization.
12
http://www.wsmo.org
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 10 of 26
156
3.2 Web Services Modeling Language (WSML)
157
158
159
160
161
162
163
The focus of WSML working group 13 is to define and develop the Web Service Modeling Language
(WSML) [de Bruijn, 2005], a language that offers a formal syntax and semantics for WSMO. WSML
provides 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.
164
165
166
167
168
169
170
171
172
173
174
175
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  WSMLFull and the path that follows WSML-Core  WSML-Flight  WSML-Rule WSML-Full. The sketch
figure about those different WSML variants can be shown in the following figure.
176
177
Figure 2. WSML Variants
178
179
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. There are some
13
http://www.wsmo.org/wsml
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 11 of 26
180
181
182
supporting tools, such as OWL-WSML Translator 14 . Similar with the WSMO further resources, more
detailed information about the WSML relevant working drafts and deliverables can be found in the
working group website.
183
3.3 Web Services Execution Environment (WSMX)
184
185
186
187
188
189
190
191
192
193
194
195
196
197
The Web Service Execution Environment (WSMX) 15 [Haller et al. 2005] is a research prototype
implementation for discovering, selecting, mediating and invoking Semantic Web services. It can be
installed at the service requester side, provider side or both or at an independent location. WSMX was
designed and created to provide a software environment capable of interpreting and acting on the
semantic descriptions provided by the Web Services Modeling Ontology (WSMO). Interpreting means that
WSMX accepts WSMO descriptions represented using the Web Services Modeling Language (WSML)
and parses the descriptions into an internal format provided by a Java object model. Depending on the
type of the WSMO element description received, WSMX initiates a defined behavior. 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.
198
199
200
201
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.
202
203
Discovery. Service requesters need to be able to locate a service description or aggregation of
descriptions that fits their needs.
204
205
206
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.
207
208
209
210
211
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.
212
213
214
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
14
http://tools.deri.org/wsml/owl2wsml-translator/v0.1/
15
http://www.wsmx.org
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 12 of 26
215
216
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.
217
218
219
220
221
222
223
224
225
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. Analogously, 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 transition 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.
226
Registry. WSMX maintains a registry of service descriptions that it uses during the discovery activity.
227
228
229
230
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.
231
232
233
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] The WSMX architecture can be drawn as the following figure.
234
235
Figure 3. WSMX Architecture
236
237
238
239
240
241
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
been used as the basis to establish the OASIS SEE Technical Committee. DERI16 has contributed all
WSMX conceptual work and its reference implementation to the open source community as a platform for
16
http://www.deri.org/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 13 of 26
242
243
research and development. As the work of the SEE TC progresses, it is intended that WSMX becomes an
early reference implementation.
244
3.4 IRS-III
245
246
247
248
249
IRS-III17 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.
250
251
252
253
254
255
256
257
258
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.
259
The three key differences between IRS-III and WSMX are:

260
261
262
263
264
265
266
267
268
269
270
271


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.
272
3.5 Semantically-Enabled Service-oriented Architecture (SESA)
273
274
275
276
277
Based on the SWSF framework, and its building block WSMX in particular, DERI Innsbruck has further
proposed and implemented the architecture for semantic web service execution environment, named
SESA (Semantically-Enabled Service-oriented Architecture) [Vitvar, 2007]. The goal of SESA is to place
semantics at the core of computer science in order to realize the potential of the next generation of
computing. There are four main grounding principles for SESA, namely (1) Service Oriented Principle, (2)
17
IRS, http://kmi.open.ac.uk/projects/irs/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 14 of 26
278
279
Semantic Principle, (3) Problem Solving Principle and (4) Distributed Principle. The following figure gives
a global view for the whole SESA architecture.
User 1
Domain
System
Administrator Expert
User 2
Stakeholders
Layer
Problem
Formulation Layer
Back-end
System X
Applications
(user tools, access portals, ...)
Business
Service S1
Service Requesters
Layer
Domain Ontologies
Software
Engineer
Developer Tools
(ontology management,
monitoring, ...)
Network
(internet, intranet, extranet)
Semantic Execution Environment (Machine A)
broker
Security
Execution
Management
vertical
Discovery
Adaptation
Fault Handling
Monitoring
Orchestration
Mediation
Composition
Grounding
Reasoning
Storage
Communication
base
Formal Languages
Business
Service S3
Back-end
System Z
Shared Message Space
SEE
(Machine D)
Business
Service S4
SEE
(Machine C)
SEE
(Machine B)
Middleware Layer
280
Service Providers Layer
281
Figure 4. Global View on SESA Architecture
282
283
284
285
286
The global view on the architecture comprises of several layers, namely (1) Stakeholders forming several
groups of users of the architecture, (2) Problem Solving Layer building the environment for stakeholders
access to the architecture, (3) Service Requesters as client systems of the architecture, (4) Middleware
providing the intelligence for the integration and interoperation of business services, and (5) Service
Providers exposing the functionality of back-end systems as Business Services.
287
288
289
290
291
292
293
294
295
296
297
298
WSMX is a reference implementation of an SESA that is compliant with the semantic specifications of
WSMO. WSMX supports semantically enabled change functions such as dynamic discovery, selection,
and mediation. WSMX also implements semantically enabled control and connection functions such as
service invocation and interoperation. WSMX is an execution environment for the dynamic discovery,
selection, mediation, invocation and interoperation of the Semantic Web Services in a reference
implementation for WSMO. The development process for WSMX includes defining its conceptual model,
defining the execution semantics for the environment, describing architecture and a software design and
building a working implementation. The OASIS Semantic Execution Environment Technical Committee
(SEE TC18 ) has focused on standardization and the WSMX working group on building a prototypical
execution infrastructure for Semantic Web Services (SWS) based on the Services Oriented Architecture
(SOA) paradigm of loosely coupled components. There are some detailed implementations according to
certain B2B integration scenarios, such as some challenge tasks in the Semantic Web Service
18
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=semantic-ex
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 15 of 26
299
Challenge19 [Haselwanter, 2006].
300
301
302
Realizing SESA principles and providing a platform incorporating them is the major necessity to
implement Service Web 3.0. There are following four types of business services of an infrastructure which
are a must for Service Web 3.0 to deliver its promisses:
303
304
305

The stakeholders layer which consists of Ontologies, Applications (e.g. e-tourism, e-government)
and Developer tools (GUI tools such as those for engineering ontology/web service descriptions;
generic developer tools such as language APIs, parsers/serializers, converters, etc.).
306
307
308
309
310

The broker layer which consists of Discovery, Adaptation (including selection and negotiation),
Composition (web service composition techniques such as planning), Choreography, Mediation ((a)
Ontology mediation: techniques for combining Ontologies and for overcoming differences between
Ontologies; (b) Process mediation: overcoming differences in message ordering, etc.), Grounding,
Fault Handling (Transactionality, Compensation, etc.), and Monitoring.
311
312
313
314
315

The base layer that is providing the exchange formalism used by the architecture, i.e., Formal
languages (static ontology and behavioral, i.e., capability/choreography/orchestration languages,
connection between higher-level descriptions, e.g., WSML), (13) Reasoning (techniques for
reasoning over formal descriptions; LP, DL, FOL, behavioral languages, etc.) and Storage and
Communication.
316
317

Finally, vertical services such as Execution management and Security (authentication/
authorization, encryption, trust/certification).
318
3.6 WSDL-S, SAWSDL
319
320
321
322
323
324
325
WSDL-S [Akkiraju et al. 2005] is a joint proposal between LSDIS Lab and IBM representing a lightweight
approach to adding semantics to Web services by providing a simple extension to the meta-model for the
WSDL 2.0 specification. It is also a W3C member submission 20and a foundational input to the W3C
Semantic Annotations for Web Service Description Language (SAWSDL) working group 21. The extension
takes advantage of WSDL support for multiple type-systems (e.g. XML Schema, WSMO and OWL-S) and
provides a mechanism to specify preconditions and effects on the operation child elements of WSDL
interfaces.
326
327
328
329
330
331
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.
332
19
http://sws-challenge.org/
20
http://www.w3.org/Submission/WSDL-S/
21
http://www.w3.org/2002/ws/sawsdl/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 16 of 26
333
334
Figure 1: Associating semantics to WSDL elements [Akkiraju et al. 2005].
335
336
337
338
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.
340
3.7 Semantic Web Services Initiative – Semantic Web Services
Architecture Committee
341
342
343
344
345
Mission of the Semantic Web Services Initiative Architecture (SWSA) committee 22, part of Semantic Web
Services Initiative23, 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.
346
347
348
349
350
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.
339
22
Semantic Web Services Architecture Committee, http://www.daml.org/services/swsa/
23
Semantic Web Services Initiative, http://www.swsi.org/
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 17 of 26
351
352
353
354
355
356
357
358
OWL-S Web Ontology Language for Web Services (OWL-S)24, part of the DAML Program, specifies a
set of ontologies based on OWL to describe different aspects of a semantic Web service [OWL-S, 2004].
There are three core ontologies, i.e. service profile, service model and grounding. Service profile presents
“what a service does”; service model describes “how a service works”; service grounding supports “how
to access it” via detailed specifications of message formats, protocols and so forth (normally expressed in
WSDL). All the three ontologies are linked to the top-level concept Service, which serves as an
organization point of reference for declaring Web services; the properties presents, describedBy, and
supports of Service link to the above three core ontologies respectively.
359
360
361
362
363
364
365
366
SWSF Semantic Web Services Framework (SWSF) 25 is a specification produced by the SWSL
Committee of the Semantic Web Service Initiative (SWSI). SWSF has its own conceptual model Semantic
Web Service Ontology (SWSO) and relevant language Semantic Web Service Language (SWSL). SWSO
has been influenced by OWL-S and adopts its three ontologies, i.e. service profile, model and grounding.
The difference and the key contribution of SWSO are its rich behavioral process model, based on PSL.
With such extensions, SWSO can support more powerful descriptions and reasoning on Web services.
SWSL has two sub-sets, SWSL-FOL and SWSL-Rules, supporting first-order-logic and logic
programming respectively [SWSF, 2005].
367
3.8 Glue
368
369
370
Glue [DellaValle et al, 2005] is a WSMO compliant discovery engine that provides the basis for
introducing discovery in a variety of applications in an easy-to-use way for requesters, and providing
efficient pre-filtering and accurate discovery of relevant services that fulfill a given requester goal.
371
372
In conceiving Glue, the model for WSMO Web Service discovery introduced was refined explicating the
central role of mediation:


373
374
375
376
377
378
379
380
381
382
383
384


by making the notion of class of goals and class of Web Service descriptions explicit;
by using ggMediators to automatically generate a set of goals that are semantically equivalent to
the one expressed by the requester but are expressed with a different form or using different
ontologies;
by making wgMediators the conceptual element responsible for evaluating the matching;
by using ooMediators to solve any terminological mismatch that can appear when dealing with
different polarized ontologies for the domain, and \item by redefining the discovery mechanism as
a composite procedure where the discovery of the appropriate mediators and the discovery of the
appropriate services is combined.
Glue implementation26 uses internally F-Logic and it is built aroung an open source F Logic interference
engine called Flora227 that runs over XSB28, an open source implementation of tabled prolog and
deductive database system.
24
OWL-S, http://www.daml.org/services/owl-s/
25
Semantic Web Service Framework, http://www.w3.org/Submission/SWSF/
26
Glue implementation is available open source at http://sourceforge.net/projects/sws-glue
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 18 of 26
385
4 Relationships to Other Specifications
386
387
388
All Web Services and Service Oriented Architecture groups are the primary target of this work. It is
anticipated that liaisons may be needed for many SOA-related Technical Committees such as the
following:
389
4.1 W3C WS Choreography Working Group
390
391
392
393
394
395
396
W3C Chorographpy and WSMO Choreography are partly orthogonal to each other and have different
views on the same problems in other areas. A fundamental difference is that WSMO choreographies are
natively based on semantics by choosing ontologies as the datamodel it operates on, while W3C
choreography works primarily on syntactical construct. In addition to that it takes a global viewpoint on the
behavior aspects of web service while WSMO model behavior strictly local to a Web Service. The models
are not compatible per se, but there is enough orthogonality to reasonably expect usefull results that each
address aspects of the problem.
397
4.2 OASIS ebSOA TC
398
399
400
OASIS ebSOA TC continues the work in ebXML Technical Architecture taking in consideration the latest
releases in ebXML specifications and based on the latest developments in Web Services and Service
oriented Architecture.
401
402
403
404
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.
405
406
407
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.
408
4.3 OASIS ebXML Registry TC
409
410
411
412
413
414
OASIS ebXML Registry is chartered to develop specifications to achieve interoperable registries and
repositories, with an interface that enables submission, query and retrieval on the contents of the registry
and repository. The Registry TC seeks to develop specifications that serve a wide range of uses, covering
the spectrum from general purpose document registries to real-time business-to-business registries.
Additionally, as part of its specification development work, this TC explores and promotes various
emerging models for distributed and cooperating registries.
27
http://flora.sourceforge.net
28
http://xsb.sourceforge.net
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 19 of 26
415
416
417
418
419
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.
420
4.4 OASIS ebXML BP TC
421
422
423
424
425
426
427
428
OASIS ebXML Business Process (ebBP) TC defines a standard language to configure business systems
for business collaboration execution between collaborating parties or business partners. Business
processes are key components to enable and drive collaborating partner relationships for electronic
business (eBusiness). The ebBP provides capabilities to drive those eBusiness collaborative processes.
As a part of the original eBusiness XML framework of specifications, the ebBP is targeted for monitoring
of collaborative business processes among parties or business partners. Today, ebBP has evolved to
integrate use of other specifications and emerging technologies as part of eBusiness solutions focused on
Service-Oriented Architecture.
429
4.5 OASIS Web Services Resource Framework (WSRF) TC
430
431
432
433
434
435
436
437
438
The Web Services Resource Framework (WSRF) [WSRF 2005] is a standard for Web services that takes
into account features involved in the implementation of Grid computing, such as statefulness, notification
mechanisms and transient resources or services (in contrast to standard Web services which are
stateless and persistent). WSRF is an open framework that allows the implementation of both Grid
applications and Grid middleware services (job submission, file transfer, information service, etc.).One of
the key ideas of WSRF is the virtualization of resources through WS-Resource (i.e. a Web service with
properties describing a state). The WSRF is a specification of the mandatory and optional interfaces a
Web service must support for it to be considered a Grid service based on the definitions of Grid service
and Open Service Grid Architecture (OGSA) provided in [OGSA 2002].
439
440
441
442
443
444
445
446
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 lifetimemanagement 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.
447
448
449
450
451
452
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
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 20 of 26
453
454
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.
455
4.6 OASIS FWSI TC
456
457
458
459
The Framework for Web Services Implementation (FWSI) TC29 aims to enable robust implementations of Web
Services by defining a practical and extensible methodology consisting of implementation processes and
common functional elements that practitioners can adopt to create high quality Web Services systems without
reinventing them for each implementation.
460
The goals of the FWSI TC are30 to:
461
462
463
464
465
466
1.
2.
3.
4.
accelerate implementation of Web Services-based systems
improve the performance and robustness of such systems
improve understanding of Web Services implementations
reduce the complexity of such systems and hence reduce the developmental and maintenance
efforts; and to
5. reduce the risk of implementation.
467
468
469
470
A key outcome of the FWSI TC is the specification of a set of Functional Elements that need to be instantiated
into a technical architecture. The purpose of this specification to define the right level of abstraction for these
Functional Elements and to specify the purpose and scope of each Functional Element so as to facilitate
efficient and effective implementation of Web Services.
471
472
473
474
475
476
477
Since the main focus of the FWSI TC is the implementation of Web services and the identification of
necessary functional elements, its objectives clearly differ from the objectives of the SEE TC, which is
mainly concerned with using existing Semantic Web Services. However, it would be interesting to
examine the functional elements proposed by the FWSI TC in the context of Semantic Web Services
environment. This may help to identify and describe additional functional elements that are necessary in a
semantic execution environment. These additional functional elements could be suggested to the FWSI to
extend their framework for Web services implementation to also work with Semantic Web Services.
29
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=fwsi
30
Taken from the FWSI TC’s charter, http://www.oasis-open.org/committees/fwsi/charter.php
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 21 of 26
478
5 References
479
480
481
[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.
482
483
484
485
[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.
486
487
488
489
[DellaValle et al., 2005] E. Della Valle and D. Cerizza. The mediators centric approach to automatic
Web Service discovery of Glue. In M. Hepp, A. Polleres, F. van Harmelen, and
M. R. Genesereth, editors, Proc. of the 1st Int’l Workshop on Mediation in
Semantic Web Services (MEDIATE’05). CEUR-WS.org, December 2005.
490
491
492
493
494
[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.
495
496
497
498
[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.
499
500
501
502
[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.
503
504
[de Bruijn, 2005]
505
506
507
508
509
[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://swschallenge.org/2006/paper/DERI_WSMX_SWSChallenge_II.pdf" presented at
SWS Challenge Phase II Workshop, Budva, Montenegro, 2006.
510
511
512
[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.
513
514
[Roman et al., 2006]D. Roman, H. Lausen, and U. Keller. D2v1.3. Web Service Modelling Ontology
(WSMO). Deliverable, http://www.wsmo.org/TR/d2/v1.3/, October 2006.
515
516
517
[Preist 2004]
J. de Bruijn. D16 the wsml specification. WSMO Deliverable available from
http://www.wsmo.org/TR/d16/, February 2005.
Chris Preist, A Conceptual Architecture for Semantic Web Services. in Third
International Semantic Web Services Conference (ISWC), Hiroshima, Japan,
2004, Springer, pp395-409
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 22 of 26
518
519
520
521
[Vitvar et al., 2007] T. Vitvar, A. Mocan, M. Kerrigan, M. Zaremba, M. Zaremba, M. Moran, E.
Cimpian, T. Haselwanter, and D. Fensel. Semantically-enabled service oriented
architecture: Concepts, technology and application. Service Oriented Computing
and Applications, 2007.
522
523
[OWL-S, 2004]
OWL-S (Web Ontology Language for Web Service) 1.2 Release. Available from
http://www.daml.org/services/owl-s/1.0/. 2004
524
525
[SWSF, 2005]
Semantic Web Service Framework, SWSF version 1.0. SWSF Available from
http://www.daml.org/services/swsf/1.0/ , 2005.
526
527
528
[OASIS RM-SOA] OASIS Reference Model for Service Oriented Architecture (SOA-RM) 1.0, 2006,
Available from http://www.oasis-open.org/committees/download.php/19679/soarm-cs.pdf
529
530
[OASIS RA-SOA]
531
532
533
[SOA AdoptionBlueprint] SOA Adoption Blueprint “Generico” Working Draft 0.2, 2006,
http://www.oasis-open.org/committees/documents.php?wg_abbrev=soablueprints
534
535
[SOAP1.2-Primer] SOAP Version 1.2 Part 0: Primer (Second Edition), W3C Recommendation 27
April 2007, http://www.w3.org/TR/2007/REC-soap12-part0-20070427/
536
537
538
[SOAP1.2-Messaging] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) W3C
Recommendation 27 April 2007, http://www.w3.org/TR/2007/REC-soap12-part120070427/
539
540
[SOAP1.2-Adjuncts] SOAP Version 1.2 Part 2: Adjuncts (Second Edition), W3C Recommendation
27 April 2007, http://www.w3.org/TR/2007/REC-soap12-part2-20070427/
541
542
[WSDL]
Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001,
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
543
544
[UDDI]
UDDI specifications, http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm
545
546
[IBM BPEL4WS]
Business Process Execution Language for Web Services version 1.1,
http://www.ibm.com/developerworks/library/specification/ws-bpel/
547
548
[OASIS BPEL]
OASIS Web Services Business Process Execution Language (WSBPEL)
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
549
550
[SAWSDL]
Semantic Annotations for WSDL and XML Schema, W3C Recommendation 28
August 2007, http://www.w3.org/TR/sawsdl/
OASIS Reference Architecture for Service Oriented Architecture (SOA-RA),
http://wiki.oasis-open.org/soa-rm/What_Is_A_Reference_Architecture%3F
551
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 23 of 26
552
6 Summary
553
554
555
556
557
558
The document provides the background and related work to SEE (Semantic Execution Environment) TC.
In addition to some basic conceptual ideas about Service-Oriented Architecture, the document has
summarized both traditional non-semantic activities and existing semantic approaches towards SOA.
SEE TC provide semantic execution environment, including semantic service-oriented architecture
reference model and reference architecture. Furthermore, SEE TC puts in relationships with other related
OASIS and W3C standards.
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 24 of 26
559
A. Acknowledgements
560
561
The following individuals have participated in the creation of this specification and are gratefully
acknowledged:
562
Participants:
563
564
565
Barry Norton, Open University
Omair Shafiq, DERI
Maciej Zaremba, DERI
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 25 of 26
566
B. Revision History
567
[optional; should not be included in OASIS Standards]
Rev
wd-01
Date
2006-04-25
By Whom
Emanuele Della Valle
Wd-02
2006-06-22
John Domingue
What
Initial version created by merging
common background and related
work sections of other WDs
Included IRS-III
Wd-03
2006-06-22
Matthew Moran
Included WSDL-S
Wd-05
2006-07-09
Matthew Moran
Updated WSMX description
Wd-06
2006-09-30
Emanuele Della Valle
Refactoring of the document
Wd-07
2006-10-31
Emanuele Della Valle
Refactoring of section structure and
responsibility assignment
Wd-09
2006-11-11
Emanuele Della Valle
Wd-10
2007-09-26
Zhixian Yan
Wd-11
2007-10-10
Zhixian Yan
Revision in FWSI section by Marc
Haines
Section Reorganization, more details
and references
Finalizing the document
568
[Document Identifier]
Copyright © OASIS Open 2007. All Rights Reserved.
"01 October 2007"
Page 26 of 26