[rfc2119]

Semantic Web Services Architecture and Information Model

Working Draft v0.1-r1, 8 September 2006

Artifact Identifier:wd-see-arch-v0.1-r1

Location:Current: docs.oasis-open.org/ex-semantics/architecture/latestThis Version: docs.oasis-open.org/ex-semantics/architecture/0.1Previous Version: docs.oasis-open.org/ex-semantics/architecture/0.1

Artifact Type:architecture

Technical Committee:OASIS SEE TC

Chair(s):John Domingue, Open University, <[email protected]>Michal Zaremba, DERI, <[email protected]>

Editor(s):Michal Zaremba, DERI Innsbruck, <[email protected]>Matthew Moran, DERI Galway, <[email protected]>Thomas Haselwanter, DERI Innsbruck, <[email protected]>Barry Norton, Open University, <[email protected]>

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:[Summary of the technical purpose of the document]

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

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at 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

OASIS SEE TC Architecture and Information Model 08 September 2006Copyright © OASIS Open 2006. All Rights Reserved. of 30

1

2

3

4

56

78910

1112

1314

151617

1819202122

2324

2526

2728

29

3031

3233

343536

37383940

4142

12

3

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.


4344

4546

45

6

Notices

Copyright © OASIS Open 2005. 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.


47

48

4950

5152535455565758

5960

6162636465

6667686970

7172737475

7677787980818283848586

78

9

Table of Contents

1 Introduction......................................................................................................................................... 6

1.1 What is a Semantic Execution Environment......................................................................................6

1.2 Audience........................................................................................................................................... 7

1.3 Relationships to Other Specifications................................................................................................7

1.4 Terminology....................................................................................................................................... 7

1.5 Organization of the document...........................................................................................................7

1.6 Normative References....................................................................................................................... 7

1.7 Non-Normative References...............................................................................................................7

2 Motivation for SEE.............................................................................................................................. 9

2.1 Service Oriented Architectures..........................................................................................................9

2.2 Dynamic SOA.................................................................................................................................... 9

2.3 Nature of Existing Service Execution Environments........................................................................10

2.4 Benefits of adding Semantics to SOA..............................................................................................10

2.5 Scope of SEE.................................................................................................................................. 11

3 Architecture Overview....................................................................................................................... 12

3.1 Overview of SEE Infrastructure.......................................................................................................12

3.2 Distribution of SEE.......................................................................................................................... 14

3.3 Overview of a Single Node..............................................................................................................15

4 Structural View.................................................................................................................................. 17

4.1 Problem Solving Layer....................................................................................................................17

4.1.1 Ontologies................................................................................................................................ 17

4.1.2 Applications.............................................................................................................................. 17

4.1.3 Developer Tools....................................................................................................................... 17

4.2 Application Layer............................................................................................................................. 17

4.2.1 Discovery................................................................................................................................. 17

4.2.2 Adaptation................................................................................................................................ 18

4.2.3 Composition............................................................................................................................. 19

4.2.4 Choreography.......................................................................................................................... 19

4.2.5 Data Mediation......................................................................................................................... 20

4.2.6 Process Mediation....................................................................................................................20

4.2.7 Communication External (Grounding)......................................................................................20

4.2.8 Fault Handling.......................................................................................................................... 21

4.2.9 Monitoring................................................................................................................................ 21

4.3 Base Layer...................................................................................................................................... 21

4.3.1 Formal Languages...................................................................................................................21

4.3.2 Reasoning................................................................................................................................ 22

4.3.3 Storage..................................................................................................................................... 22

4.4 Vertical Services.............................................................................................................................. 23

4.4.1 Execution Management...........................................................................................................23

4.4.2 Security.................................................................................................................................... 23

5 Summary........................................................................................................................................... 24

A. Acknowledgements........................................................................................................................... 25


87

88

89

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

123

124

125

126

127

128

129

1011

12

B. Appendix A – SEE API (Operations).................................................................................................26

Discovery.......................................................................................................................................... 26

C. Revision History................................................................................................................................ 28


130

131

132

133

134

1314

15

1 Introduction

1.1 What is a Semantic Execution EnvironmentA Semantic Execution Environment is a service oriented architecture that uses the semantic descriptions of Web services, goals, and supporting concepts such as ontologies and mediators to create software applications where the services required to achieve a particular goal are determined at runtime. We adopt the OASIS SOA RM TC definition of Service Oriented Architecture (SOA) as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains”. In the context of SEE, SOA is a software architectural style where the capabilities are provided by Web services. We define Semantic Web services to mean the semantic description of various aspects of Web services using a language with well-defined semantics such as WSML or OWL-S. For this document we choose to use the WSMO conceptual model for describing Semantic Web services along with its associated language WSML. Goals are the descriptions of the intent that service requester’s have when seeking to carry out their tasks and use the WSMO conceptual description for goals.

The absence of common understanding (semantics) of data and process descriptions between service requesters and providers remains a substantial problem in the design and implementation of SOA. Solutions for service discovery, composition, invocation, data translation and monitoring exist but are usually based exclusively on the syntactic level with XML as the common representation language. Components for handling differences in semantics between requester and provider during service discovery or service invocation are notably absent in most software application designs.

The purpose of SEE Semantic Web Services Architecture and Information Model is to define a software architecture with functionality that aims for the automation of service discovery, negotiation, adaptation, composition, invocation, and monitoring based on semantic descriptions of the various aspects of Web services. The SEE architecture will enable goal-based invocation of Web services. In the service-oriented world of the future, services will need to be discovered, composed, adapted and invoked on the fly based on various requirements. The contribution of the SEE specification is to describe the fixed component services of an infrastructure that MUST be provided to enable dynamic discovery, selection, mediation, invocation and inter-operation of services to facilitate the SOA evolution to towards flexible applications.

Taking a supply chain management scenario as an example. One step may require that a shipping service be located for shipment from the UK to the USA. A goal is created that formally describes that a specific volume of goods needs to be shipped on a particular date. The SEE architecture will enable a service to be discovered that matches this goal. Conceptual differences between the data definitions used by the requester and provider will be resolved. The architecture will act as a broker coordinating the message exchange between the two parties and will monitor the status of the conversation. The advantage of the approach is that, if the next week, the same shipment is required again and the service provider is no longer available, no change on the service requester side is required, the architecture will discover a new provider if possible and, as before, resolve any semantic differences.

As the volume of data published on the Web is grows exponentially, so too do the number of services, albeit at a slower rate. However this rate is increasing and will eventually lead to vast amount of available services. However the availability of services will be volatile as the complete connection between service requesters and providers will not be guaranteed over the Web. Machine-processable semantic descriptions of these services are critical to enable location of services and the interaction between them to be established automatically. As in the example above, when one service disappears, mechanisms will be required to establish communication with an alternative service provider. While the SEE Architecture specification identifies components that must be provided by the infrastructure, it remains agnostic about their internal design and implementation. Many research efforts and working groups already investigate specific topics such as service composition, discovery etc. We refer to this work in the related work deliverable referenced in section 1.3.


135

136

137138139140141142143144145146147

148149150151152153

154155156157158159160161

162163164165166167168169170

171

172173174175176177178179180181182

1831617

18

1.2 AudienceThe anticipated audience for this work includes all OASIS Web Service and ebXML TCs, non-OASIS Web Service standards groups, Semantic Web Services research and interest groups, SOA architects and programmers, vendors and users. The work should be of interest to anyone involved with Semantic Web Services and more generally also in Service Oriented Architectures (SOAs).

1.3 Relationships to Other SpecificationsThis is specified in the SEE TC deliverable – SEE-background-and-related-work_01.doc.

1.4 TerminologyThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.5 Organization of the documentThe specification is structured as following. Section 2 provides the motivation for SEE. In section 3 the architecture overview is presented. Section 4 discusses structural view and section 5 provides behavioral view. Section 6 presents related work (does it differ from the section 1.3?) and finally section 7 summarizes this specification.

1.6 Normative References[Cimpian 2005] E. Cimpian, T. Vitvar, M. Zaremba (editors): Overview and Scope of WSMX.

WSMX Deliverable D13.0, WSMX Final Draft v0.2, 2005, http://www.wsmo.org/TR/d13/d13.0/v0.2/

[OGSA 2002] Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke: Grid Services for Distributed System Integration, Computer, vol 35, no. 6, pp 37-46, June 2002.

[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

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[Roman et al 2005] Dumitru Roman, Uwe Keller, Holger Lausen, Jos de Bruijn, Rubén Lara, MichaelStollberg, Axel Polleres, Cristina Feier, Christoph Bussler, and Dieter Fensel: Web Service Modeling Ontology, Applied Ontology, 1(1): 77 - 106, 2005.

[WSRF 2005] Steve Graham, Anish Karmarker, Jeff Mischkinsky, Ian Robinson, Igor Sedukhin (editors): The WS-Resource Framework, Version 1.2, draft 0.2, available at http://www.oasis-open.org/committees/wsrf (2005)

[W3C Glossary 2004] Hugo Haas, and Allen Brown (editors): Web Services Glossary, W3C Working Group Note 11 February 2004, available at http://www.w3.org/TR/ws-gloss/

1.7 Non-Normative References

[Mocan et al 2005] Adrian Mocan, Emilia Cimpian: Mapping Creation Using a View Based Approach, 1st International Workshop on Mediation in Semantic Web Services (Mediate 2005), December 2005, Amsterdam, Netherlands


184

185186187188

189

190

191

192193194

195

196197198199

200

201

202203204205206207208209210211212213214215216217218219

220

221

222

223224225

1920

21

http://www.w3.org/TR/ws-gloss/

http://www.ietf.org/rfc/rfc2119.txt

http://www.wsmo.org/TR/d13/d13.0/v0.2/

[Cimpian et al 2005] Emilia Cimpian, Adrian Mocan: WSMX Process Mediation Based on Choreographies, 1st International Workshop on Web Service Choreography and Orchestration for Business Process Management (BPM 2005), September 2005, Nancy, France


226227228229

230

2223

24

2 Motivation for SEESection 2.1 provides an overview of Service Oriented Architecture. Section 2.2 looks at SOA in the situation where the services are distributed in the open environment provided by the Web. Section 2.3 looks at what is understood by the term Service Execution Environment. In section 2.4, the advantages of applying semantics to SOA are introduced. Finally section 2.5 describes the scope and requirements for SEE.

2.1 Service Oriented ArchitecturesThe hot topic in today’s design of software architectures is to satisfy increasing software complexity as well as new IT needs, such as the need to respond quickly to new requirements of businesses, the need to continually reduce the cost of IT or the ability to integrate legacy and new emerging business information systems. In the current IT enterprise settings, introducing a new product or service, integrating multiple services and systems present unpredicted costs, delays and difficulty. Existing IT systems consist of a patchwork of legacy products, monolithic off-shelf applications and proprietary integration. It is even today’s reality that in many cases users on the “spinning chairs” manually re-enter data from one system to another within the same organization. The past and existing efforts in the Enterprise Application Integration (EAI) don’t represent successful and flexible solutions so far. Several studies showed that the EAI projects are lengthy, majority of these efforts are late and over budget. It is mainly costs, proprietary solutions and tightly-coupled interfaces that make EAI expensive and inflexible.

Service Oriented Architecture (SOA) solutions are the next evolutionary step in software architectures. SOA is an IT architecture in which functions are defined as independent services with well-defined, invocable interfaces. SOA will enable cost-effective integration as well as bring flexibility to business processes. In line with SOA principles, several standards have been developed and are currently emerging in IT environments. In particular, Web Services technology provides means to publish services in a UDDI registry, describing their interfaces using Web Service Description Language (WSDL) and exchanging requests and messages over a network using SOAP protocol. Business Process Execution Language (BPEL) allows composition of services into complex processes as well as their execution. Although Web services technologies around UDDI, SOAP and WSDL have added a new value to the current IT environments in regards to the integration of distributed software components using web standards, they cover mainly characteristics of syntactic interoperability. With respect to a big number of services which will exist in IT environments in the inter and intra enterprise integration settings based on SOA, the problems with service discovery or selection of the best services conforming user’s needs, as well as resolving heterogeneity in services capabilities and interfaces will be again lengthy and costly process. From this reason, machine processable semantics should be used for description of services in order to allow total or partial automation of tasks such as discovery, selection, composition, mediation, invocation and monitoring of services. Along with this approach, Semantic Web Services defining concepts, language and execution environment is the next evolutionary step towards Semantic-empowered Service Oriented Architectures.

2.2 Dynamic SOASEE is a an Execution Environment represented as a SOA. That is, almost all of its services can offer their functionality as Web Services, deployed by one or more providers. Additionally, each time a request passes the system boundaries it becomes a broker, an infrastructure, on which a new, ad-hoc, SOA will be created. This ad-hoc SOA is specialized in solving a precise task: the task formulated by the requester's goal.We recognize the dual dimensions of SEE SOA: the SOA based SWS Execution Environment and the “on-demand” SOA built by using SEE. There are two triggers for dynamicity of SEE: (1) its own execution semantics, which formally specifies how system behaves; (2) user’s goals, which causes different services to be composed together to achieve functionality expected by the requester.


231

232233234235236

237

238239240241242243244245246247248

249250251252253254255256257258259260261262263264265266267

268

269270271272273274275276277278

2526

27

SEE comes with four predefined branches of execution semantics, its expected functionality being described in terms of its entry points. Depending on the requestor’s requirements one of this branches gets trigged and several components are called to achieve the expected functionality (e.g. to find a Web Service we require discovery, choreography and process mediator, while to call a known Web Service we do not need discovery but additionally need the invoker). Additionally to these build-in branches, dynamicexecution semantics can be defined. To achieve dynamic execution semantics we SEE extends SOA by allowing for model-driven execution of system components. We call dynamic execution semantics, a run-time deployable formal definition of a system behavior, which can be executed against components that are part of the system. Such execution semantics must not only be applicable at the design or startup time of the system, but must be executable in a running instance of the system as well. Due to the fact that WSMX system services are assembled on the fly, user services provided by external systems (such as enterprise systems) are also assembled on demand (unless service requestor specify in his/her goal which services should be used).

2.3 Nature of Existing Service Execution EnvironmentsServices by themselves do not go very far, even if they are semantically annotated. They need an environment that provides certain base functions for managing the interaction between services. This environment then acts to link the semantic descriptions of goals that service requesters wish to achieve with services that can solve these problems. Functionally this environment provides services for discovery, data and process mediation, composition, selection and invocation. Equally importantly, the environment must provide facilities to monitor service execution, support service level agreements, and react to unexpected failures.

It is the function of the execution environment to make all this happen transparently to the requestor of the service. Taking an example from eBanking, an online credit card applicant may not necessarily need to know that for the application to be made an external check on her credit rating needs to be run. There may be a number of state-approved credit rating agencies available that the bank could use. Further, the details of how the messages that are sent to and from the selected credit rating agency may need to be encrypted and transformed into a specific data format. For the card-applicant, this would probably not be interesting; it is enough to make the card application. In other words, from a customer’s perspective, it is sufficient to express the wish that she would like to apply for a credit card through her bank.

2.4 Benefits of adding Semantics to SOAService Oriented Architectures represent a huge step towards providing simpler, more dynamic and cheaper integration solutions. By having services to encapsulate discrete piece of functionality that can be later discovered and consumed is without a doubt the critical step in moving from a patchwork of legacy products, monolithic off-shelf applications and proprietary integration to a strongly decoupled, robust yet flexible software architecture.

But SOA cannot (and it is not meant to) solve all the heterogeneity problems inherent to enterprises integration tasks. Such heterogeneity problems could be induced for example by the services (the key players of SOA) themselves or by the environment the enterprises are acting in. In the former case it is natural that services deployed by different providers to have specific requirements regarding data formats or communication protocols. Further more, the invocation of such services can be part of complex business process that most probably differs from one vendor to another. Regarding the second case, the World Wide Web proves to be a more and more appealing (and suited) environment for businesses and Web Services could successfully fulfill the roll of services in SOA. Such a context allows for ad-hoc cooperation and on-the-fly business provision, but also pushes the interoperability problems to extreme, beyond the boundaries of the enterprises to be integrated.

Semantics is coming to offer the tools to enable scalable, efficient and cost-effective solutions to these problems. Using ontologies and semantics, services can be un-ambiguous described, from data, functionality and behavior point of view. These semantics descriptions can be used in operations like discovery, selection, composition or aggregation of services to provide meaningful functionality through a


279280281282283284285286287288289290291292293

294

295296297298299300301

302303304305306307308309

310

311312313314315

316317318319320321322323324325

326327328329

2829

30

truly Service Oriented Architecture. SOA can provide domain independent solutions for these operations that highly rely on semantics, formal specifications and reasoning.

It is important to note that providing semantics descriptions for SOA it is not a trivial task and involves significant efforts: additionally to the actual implementation and technical interfaces an extra layer, the semantic layer, has to be added by each of the service providers. Only after this extra step is accomplished the real benefits of semantics can be exploited: old hard-coded, domain-specific solutions for service operations can be replaced by general, semantic-based ones and used in inter-enterprise (or even intra-enterprise) business scenarios.

As such, bringing semantics to SOA means adding semantics to the services part of SOA and then augmenting SOA with semantic-aware mechanisms to support the elementary operations on services (e.g. discovery, selection, composition, invocation etc).

2.5 Scope of SEEThe scope of the SEE Technical Committee is defined in the committee’s charter.

Initial requirements have indicated that Semantic Web services systems should enable automatic or semi-automatic discovery, negotiation, selection, composition, mediation, invocation and interoperation of multiple services. The SEE TC will assess the subsequent and related works and implementation experience of existing efforts in a variety of sectors (financial, telecommunication, e-health and e-government) to define and implement these functions related with Semantic Web Services. Based on those experiences, the detailed analysis of requirements for Semantic Web services Architecture will be provided.

The SEE TC will provide a test bed for the Web Services Modeling Ontology (WSMO), which is anticipated as a contribution for use by the TC on a non-exclusive basis, and will seek to demonstrate the viability of using WSMO concepts, relationships and definitions as a means to achieve successful dynamic interoperation of multiple ambient services, whether or not they share a common design or source.

The TC anticipates contribution of the draft WSMX specifications and WSMO ontology on a non-exclusive basis. Other contributions will be accepted for consideration without any prejudice or restrictions, and evaluated on their technical merit, as long as the contributions conform to this charter.

Following a top-down, component based development approach, the TC will provide a whole framework capable of carrying out the dynamic discovery, mediation, selection, invocation and inter-operation of Web Services and any other functionality which will be revealed during the requirements analysis phase. While the focus of this group will remain on a high level semantic description of components interfaces, the TC will seek tight cooperation with any group working on semantics-enabled functional components that fulfill the requirements of such system.

The SEE TC will not implement actual software products or solutions based on the specifications developed along the course of work of this group.


330331

332333334335336337

338339340

341

342

343

344345346347348349350

351352353354355

356357358

359360361362363364

365366

3132

33

3 Architecture OverviewThe following section provides an overview of the SEE infrastructure. It starts with a high level overview of the architecture, types of services it hosts, and it justifies division of platform services into vertical and horizontal layers.

3.1 Overview of SEE InfrastructureThe key aim for SEE is to define functional mandatory services, decouple their functionality one from the other and to describe components’ interfaces in terms of offered functionality. One of the design principles of SOA (and Web Services in general) is the separation of the implementation of the service from its externally visible description. Such design allows replacement of one service with another as long as the new service supports the stable interface. Similarly, the SEE does not define services in terms of their design or implementation details, but only it terms of expected functionality and their externally visible behavior. The infrastructure of SEE is been presented in Figure 2.

Figure 2: SEE Infrastructure and its services

We distinguish four different types of elements of an overall SEE where each element type is composed by some sub functionalities:

The problem-solving layer which consists of (1) Ontologies, (2) Applications (e.g., e-tourism, e-government) and (3) Developer tools (GUI tools such as ontology/web service description engineering tools; generic developer tools such as language APIs, parsers/serializers, converters, etc.).

The broker layer which consists of (4) Discovery, (5) Adaptation (including selection and negotiation), (6) Composition (web service composition techniques such as planning), (7) Choreography, (8) Mediation ((a) Ontology mediation: techniques for combining Ontologies and for overcoming differences between Ontologies; (b) Process mediation: overcoming differences in message ordering, etc.), (9) Grounding (Communication – external), (10) Fault Handling (Transactionality, Compensation, etc.), and (11) Monitoring.

The base layer that is providing the exchange formalism used by the architecture, i.e., (12) 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 (14) Storage and Communication.


367

368369370

371

372373374375376377378

379380

381382

383384385386387388389390391392393394395396397

3435

36

Finally, vertical services such as (15) Execution management and (16) Security (authentication/authorization, encryption, trust/certification).

While some of these functionalities are provided as services, the others remain the entities required to let the overall system to function, but they are not services in terms of the Service Oriented Architectures. This causes that SEE is called an infrastructure, not just an architecture. While the Broker and Base layers (without Formal Languages) builds SEE architecture in terms of services, the Problem Solving layer adds the set of tools and entities, which causes that SEE becomes the complete Semantic Web Services oriented infrastructure.

SOAs typically consist of a set of services, and a coordinator that combines the services and puts them to use. Talking about SOA in the context of SEE can sometimes be misleading since SEE is a SOA and at the same time it is the coordinator of another, larger SOA. The SEE differentiates two types of services: platform services (such as Discovery, Choreography, Data and Process mediation etc.) and user services (e.g. back-end applications services). Platform services are mandatory to enable the infrastructure to deliver its functionality as defined by its execution semantics. User services are exposed by information system external to SEE infrastructure, but they are still coordinated using SEE platform services. The SEE recommendation defines the scope for particular platform services in terms of their functionality, while it remains silent about the scope and the functionality of user services. In the diagram 3 kappa is the SOA that SEE uses to enable the External SOA. SEE services are complementary pieces of functionality that directly enable aspects of External SOA.

Figure 3: Platform Services versus User Services

The SEE infrastructure consists of several decoupled services. This enables independent refinement of these services, so each of them can have its own architecture, without hindering the overall SEE infrastructure. Following the SOA design principles, the SEE infrastructure separates concerns of the components thereby separating the service descriptions and their interfaces from the implementation. This adds flexibility and scalability for upgrading or replacing the implementation of the services provided by the components that adhere to the required interfaces.

The SEE recognizes vertical and horizontal services. Vertical services remain invisible to horizontal services, and during its execution, the horizontal services remain unaware that vertical services are executed together with them. This type of vertical service is provided through the inversion of control.


398399

400

401402403404405406

407

408409410411412413414415416417418

419420

421422423424425426

427428429

3738

39

With this principle the vertical services invoke horizontal services, coordinating overall workflow, rather than horizontal service invoking the vertical. The following mandatory vertical platform services have been identified: Discovery, Adaptation, Composition, Choreography, Data Mediation, Process Mediation, Communication, Fault Handling, Monitoring, Storage and Reasoning. Additionally to it, the SEE specifies End User and Developer Tools services enabling end users and developers to interact with platform services. The SEE recognizes two vertical services, namely: Execution Management and Security.

The existing Web Service technology describes and publishes the services interfaces as a WSDL document providing a good starting point for SOA. The architecture of the SEE TC infrastructure builds on the cornerstone technologies of the current web service technology and extends them towards the semantically enriched architecture. The service interfaces are provided to emphasize the reuse of components, where possible. WSML has been identified to describe platform services.

3.2 Distribution of SEEFundamentally, in a Peer-to-Peer (P2P) network each node is entitled to have equal control. The network is controlled and maintained through the cooperation between participating nodes. Thus, there is no central control of operations but it is distributed over the network. Nodes in the network may cooperate with each other while performing some task(s). Figure 4 is a high level overview derived from the Web Services architecture. In the original diagram - kept in light blue – illustrated the internal and external facets of the web service architecture. The added red parts are logical extensions of the architecture to carter for the needs of semantics.

Company C (provider)

Company A (provider)

WS interfaceAccess to internal systems

middleware

Internal WS architecture

Internal service

Company B (provider)

Company D (client)

client

SWS interfaceAccess to internal systems

Internal SWS architecture

Internal serviceS WS S WS

S WS

S WS

S WSExternal

SWSarchitecture

Figure 4: Extension of Web Services Architecture with Semantic Layer

A large bulk of the architecture concerns itself with the internal workings of the external architecture, decomposing its overall functionality in components like Discovery, Choreography, Data and Process Mediation, and specifying the relations between them. It is however worthwhile not forgetting about the internal architecture, for without it some envisioned aspects, like automatic negotiation, will not be achievable.

In particular an application of SEE to grid environments makes a provider-side tier necessary. However, it is not strictly required and a business service with lesser requirements may choose to expose a standard WS interface plus a semantic description of it. Having an internal SWS architecture poses additional requirements for service providers, but given that service providers are willing to set up an additional WS tier, on top of their internal services to provide machine accessibility, the odds are in the favor that they are willing to set up an SWS tier to gain the benefits of machine processability.

The requirement of a provider-side SWS tier does not contradict |anytoany|, it rather extends the architecture to the upper tier of the service providers, as illustrated by the Figure 5.


430431432433434435

436437438439440

441

442443444445446447448

449450

451452453454455

456457458459460461

462463

464

465

4041

42

ServiceService

ANY ANY

SEE

InternalSWS

Architecture

InternalSWS

Architecture

External SWS

Architecture

Figure 5: Distribution of SEE

SEE’s SOA enables anarchic growth. Anarchic growth is characterized by a low or non-existent barrier of entry, and the limitation of resources and effort spent, to the node that is crossing the barrier, as opposed to load-balancing it over a set of common nodes. If somebody wants to set up a website then all he has to do is set up a web server and make sure it is listed on the major search engines. The economic burden of running the server lies with the one that wants to offers a web page. It is a self-regulating system in the sense that more traffic enables that particular node to grow in its computational and bandwidth capacity, because of the economic implications of increased traffic.

Similarly the architecture of SEE may make use of provider-side hosted services to achieve the functionality that is required to interact with this service. This shifts the economic burden to a large extent from the broker to the endpoints, the actual service providers (see figure 5).

It also allows business services which speak exotic protocols and that have developed custom adapters and mediation rules for themselves, to simply register their mediators with the broker like a website registers itself with (or is being crawled by) a search engine, instead of the economic-transaction implying, high-barrier task of asking the broker to host the mediation rules and use its resources for mediation.

Figure 6: Anarchic growth of SEE


466467

468

469470471472473474475

476477478

479

480481482483

484

485486

4344

45

3.3 Overview of a Single NodeSEE the Service Oriented Architectural style where a software system is a set of collaborating components with well defined interfaces. Each component provides a specific service, exchange message with other component collectively performing a set of tasks. The components may reside in the same machine or may be distributed over the network as long as they can be accessed through a communication channel(s). Thus adopting SOA architectural style, SEE components are loosely coupled and provide a service that consists of a service layer, communication layer, persistency layers and a public interface to access the service. The service layer consists of application services (e.g., discovery, mediation, selection, etc.), a base service (e.g., reasoner, storage.), and a vertical service (e.g., security, monitoring, etc). Services are often characterized by exactly these operations, which they provide to other components. Preferably these services have machine processable meta-data descriptions. The component decoupling improves optimization allowing component clustering and load balancing among them.

The internal communication model for a SEE node is based on an event-based messaging mechanism. The event-based messaging mechanism has is increased flexibility, better extensibility and improved reusability compared to other messaging mechanisms.

The SEE architecture is decomposed to a set of functional (or service) layers where each layer corresponds to an abstraction of some aspect of the system. In most cases services provided by the upper layers are transparent to the lower layer. Software systems have progressed from initial one layer systems (e.g. mainframes) through two layer systems (e.g. simple client server), through three tiered application servers, through to n-layer systems, a generalization of three layer architectures, where multi-layer subarchitecture may be present in a top-level-layer. An example of a layered architecture is shown in figure 7.

Figure 7: SEE Node Layered Structure

In figure 4 the user interface provides functionality for registering service descriptions with the SEE node and for displaying information on the execution of the system. The service layer includes the functional components providing application services, base services and common (or vertical) services and the communication layer is responsible for handling message exchange between SEE nodes, the requesters and providers of Web services. Finally the persistence layer consists of repositories for storing and retrieving data.


487

488489490491492493494495496497498499

500501502

503504505506507508509

510511

512513514515516517

4647

48

4 Structural ViewAs presented in section 3, We distinguish four different types of elements of an overall SEE where each element type is composed by some sub functionalities:

The problem-solving layer The broker layer The base layer The vertical services

This chapter identifies functional components that play a role in the SEE architecture. Section 4.1 describes the set of compulsory services for the Base and Application layers from figure 2. Section 4.2 details the vertical services that are required across different layers of the architecture such as security and reliability. Section 4.3 describes interfaces to SEE for different categories of end-users and component developers.

4.1 Problem Solving LayerProblem solving layer rather than offering services itself, is utilizing services from the other layers

4.1.1 Ontologies

Ontologies are community contracts about a representation of a domain of discourse. Representation in here includes (1) formal parts that can be used for machine reasoning, and (2) informal parts like natural language descriptions and multimedia elements that help humans establish, maintain, and renew consensus about the meaning of concepts.

4.1.2 Applications

This component/service is concerned with (1) use case scenarios that help validate the real-world fitness of SEE services and (2) domain-specific implementations which will be used for testing of SEE services.

4.1.3 Developer Tools

The developer tools are any kind of tools related to Semantic Web Services that can be used by users of all competency levels. These can be editors for ontologies, web services, goals and mediators. Any kind of tools for creating mappings between ontologies for runtime mediation, for executing WSDL web services and managing SEE execution environments itself.

4.2 Application Layer

4.2.1 Discovery

Following the specification in the Web Service glossary, the Service Discovery component is responsible for “locating a machine-processable description of a Web service-related resource that may have been previously unknown and that meets certain functional criteria". WSMO Discovery provides a complete conceptual solution for the discovery problem in SWS settings, defining the border line between the different steps involved in the process of locating services, namely: goal discovery, goal refinement, service discovery and service contracting. Assuming that the users are expressing their requests using natural language or any other means, Goal discovery is about abstracting goals from these user requests. These goals are intended to be generic and reusable, thus the second step, Goal refinement, will refine the pre-defined goal discovered in the previous step to the actual user desire.

For the next steps, a clear distinction between services and Web services must be made: a service is a concrete instance of a Web service having all the inputs specified, while a Web service is an abstract


518

519520

521522523524

525526527528529

530

531

532

533534535536

537

538539

540

541542543544

545

546

547548549550551552553554555

556557

4950

51

entity, a class of concrete services. The third step becomes thus Web service discovery and implies matching formalized goals with formalized Web service descriptions, selecting Web services that can potentially be used to get the desired service. The last step becomes Service discovery and is about finding concrete services based on the abstract descriptions discovered in the previous step.

In the case of SEE, the focus is on the Web service discovery step from the WSMO framework. Three different approaches, delivering discovery results of different accuracy, have been distinguished: Keyword-based discovery, Discovery based on simple descriptions of services (also known as Lightweight semantic discovery) and Discovery based on rich semantic descriptions of services (Heavyweight semantic discovery).

In the Keyword-based discovery approach, a query engine matches the keywords from an input query against the keywords used to describe the service. Such an approach has the advantage that a huge amount of available services can be filtered or ranked rather quickly.

In the Discovery based on simple descriptions of services, Web services and goals are modeled as sets of objects. More precisely, a Web service is represented as a set of objects that it delivers, while a goal is represented as a set of elements which are relevant to the client as the outcome of a service execution. The descriptions of these sets refer to ontologies that capture general knowledge about the problem domain under consideration. Logics based on set theory (e.g. Description Logics) are used to determine whether a goal description matches service descriptions.

In the Discovery based on rich semantic descriptions of services approach, relations between inputs and outputs of the services and the goal as well as transition states, are considered during the matching process. More expressive logics that provide rule support (e.g. F-Logic) can be used to determine whether a goal description matches services descriptions.

The Discovery interface provides two operations by which Web services matching a specific Goal description can be obtained. The first operation returns a possibly empty list of WG-mediators, linking to Goal description to Web Service descriptions. These are returned in descending order of how well the Web Services match the supplied Goal. The algorithm that determines the matching is part of the implementation of the method itself. This is shown in the model and choreography in Figures 8 and 9 respectively.

Figure 8: Discovery communications Figure 9: Discovery choreography

The second operation allows a ranking mechanism described as an ontology to be used in the discovery process. The ordering of results is in descending order as in the first method.

4.2.2 Adaptation

After discovering a set of potentially useful services, the Semantic Execution Environment (SEE) needs to check whether the services can actually fulfill the user's concrete goal and under what conditions. Those that cannot fulfill the goal are removed from the list of discovered services. This step is required as it is not feasible for a service to provide an exhaustive semantic description. Giving the Amazon bookstore service as an example, it is not feasible for Amazon to update the semantic description of their Web


558559560561

562563564565566

567568569

570571572573574575

576577578579

580581582583584585

586

587

588589

590

591592593594595

5253

54

Barry Norotn, 09/14/06,

Didn’t we agree at the Symposium not to include this here?

service every time a new book is available or an existing book is changed, therefore we must check that Amazon actually currently has a copy of the book requested by the user. The process of checking whether and under what conditions a service can fulfill a concrete Goal is called negotiation in SEE.

Once a list of Web services than can fulfil the user's concrete goal is prepared, the SEE must then choose one of the services to invoke. It is important that this selection is tailored to the user's needs, as for example while one user may require high quality another may prefer low price. This process is called selection.

Negotiation and selection are tasks of the Adaptation component in SEE.

The Adaptation component provides the following functionalities:

checking which of the discovered Web services can fulfill the user's concrete goal finding out the non-functional properties related to the concrete goal, e.g. the currently applicable

price of the service

o potentially also dynamic negotiation of such properties, e.g. the best trade-off between quality of service and the respective price

selecting the most suitable Web service (or ordering them according to suitability) with respect to the preferences of the user

Figure 10: Adaptation communications Figure 11: Adaptation choreography

4.2.3 Composition

The orchestration part of a service interface describes how the service makes use of other services to achieve its functionality. This definition is in accordance to the following definition given by the W3C Glossary [W3C Glossary, 2004]: An orchestration defines the sequence and conditions in which one Web Service invokes other Web Services in order to realize some useful function. That is, an orchestration is the pattern of interactions that a Web Service agent must follow in order to achieve its goal.

Not only does this allow service provides to compose new services out of existing ones, reusing them as component parts at design time, it also gives the means to achieve composing functionality of services at runtime.

Orchestrations and choreography are related concepts but orthogonal to each other. Every component service of an orchestrated service has a choreography and the choreography of the orchestrated service itself is an abstraction of the details of the orchestration where only communication with external entities is taken into account.


596597598

599600601602

603

604

605606607

608609

610611

612

613

614

615616617618619

620621622

623624625626

627

5556

57

4.2.4 Choreography

The Choreography part of a service interface describes the behavior of the service from a client point of view; this definition is in accordance to the following definition given by the W3C Glossary [W3C Glossary, 2004]: Web Services Choreography concerns the interactions of services with their users. Any user of a Web service, automated or otherwise, is a client of that service. These users may, in turn, may be other Web Services, applications or human beings.

After discovering a Web service description, one has to know the observable behavior of the Web service in order to achieve the desired functionality. The Choreography Engine is responsible for using the choreography descriptions of both the service requester and provider to drive the conversation between them. It is the responsibility of the Choreography Engine to maintain the state of a conversation and to take the correct action when that state is updated. For example, the update of the state of a choreography instance may be the result of a message received from a service provider. The consequent action, as described in the choreography instance, could be to forward the unchanged message to the service requester.

The Choreography Engine in the SEE architecture has three main responsibilities:

1. Evaluating the transition rules defined in the Choreography Interface descriptions in WSMO Web Service descriptions

2. Determines the legal instances for the last choreography step3. Appropriately managing invocation requests to and from the Communication Manager

During the first step, the interface descriptions are either fetched from the Resource Manager Service or appropriately parsed from the description (this depending on whether the requester sends her/his own descriptions). Once the choreographies of both parties are initialized, the start of the conversation is triggered by the instance data sent by the requester. This leads to the second step where the conversation is handled. During the interaction between the two choreographies, the data being exchanged is appropriately checked for conformance with respect to the choreography description and is always sent through the Process Mediation which determines which kind of data should be sent (if any) to the other party. Furthermore, during the evaluation of the rules, the choreography engine sets up the data required for invocation from the choreography description. The Choreography Engine does not perform the invocation itself but it rather forwards the invocation data to the Communication Manager which then processes this information appropriately and performs the invocation. The interaction between the two parties stops when either a choreography fails or all the required input data from the requester is consumed.

4.2.5 Data Mediation

SEE implements two levels of mediation, data and process level mediation, as distinct components.

The Data Mediation component in SEE deals with heterogeneity problems that can appear at the data level. All messages in SEE are semantically described in WSML, meaning that data to be mediated is described in terms of ontologies, i.e. data consists of ontology instances.

In this context, the heterogeneity problems at the data level appear when the requester and the provider of a service use different ontologies to conceptualize their domain. As a consequence, data has to be transformed from terms of one ontology (e.g. requester’s ontology) into terms of the other ontology (e.g. provider’s ontology). Due to the fact that these transformations are taking place during run-time the whole process has to be completely automatic. The data mediator component in SEE achieves this by relying on a set of mappings (semantic relationships) between the source and target ontology identified during design-time and stored in a persistent storage .


628

629630631632633

634635636637638639640641

642

643

644645646647

648

649650651652653654655656657658659660661

662

663

664

665666667

668

669670671672673674675

676

5859

60

The mappings are in fact logical rules that are executed during run-time by a reasoner component against the incoming data, to output data as required by the target party. There are several ways (languages) of representing these rules, depending of the reasoning support available. In order to encourage interoperability between various mediation systems and to allow a flexible and an easy management of these mappings, a language independent format (called the Abstract Mapping Language) is used. As a consequence, each time a set of such mappings have to be used in a concrete scenario (as the instance transformation in SEE) the mappings have to be “grounded” to a concrete ontology representation language (in our case WSML). The grounding not only transforms the mappings in an executable form, but also associate them a formal semantics, a meaning in respect with the concrete representation language and the mediation scenario to be used in.

4.2.6 Process Mediation

Process level mediation deals with solving the interaction mismatches. Every semantic Web service has a specific choreography that describes they way in which the user should interact with it. Similarly, every requester of a service describes the way he wants to interact with a Web service by defining its own choreography. These choreographies describe semantically the control and data flow of messages that every partner can exchange. In cases where the choreography of the requestor (goal choreography) and the choreography of the Web Service do not match, process mediation is required. The Process Mediation component in SEE operates based on the two choreographies, and it is responsible for resolving mismatches between the choreographies (often referred to as public processes). These mismatches can appear not only when the requestor and the provider of a service use different conceptualizations of a domain (in which case data mediation is required), but also if they have different requirements for the message exchange pattern to be followed. Essentially this means that one of them expects to receive/send messages in a particular order while the other one has a different messages or a different message order that doesn’t match. The role of the process mediator is to retain, postpone, rebuild or create messages that would allow the communication process to continue .

4.2.7 Communication External (Grounding)

Apart from discovering Web services and composing them, the Semantic Execution Environment (SEE) also needs to communicate with the services — send the necessary request messages and receive the responses. All such external communication will be taken care of by this component.

Because internal communication within the SEE uses semantic data and practically all currently deployed Web services use their specific XML formats, the External Communication component needs to translate between the involved data forms. This translation is also known as data grounding. Above that, this component also needs to support concrete network protocols (HTTP, SOAP, other bindings) to be able to exchange messages with the Web service.

The External Communication component provides the following functionalities (only to be used where applicable):

data grounding — two-way transformations between semantic data within SEE and the XML data used in external communication

network protocol binding — based on the WSDL description of the target Web service, the best supported protocol binding will be selected for communication

potentially also triple-space grounding for communication using TripleSpace

The External Communication component provides the following functionalities (only to be used where applicable):

data grounding — two-way transformations between semantic data within SEE and the XML data used in external communication


677678679680681682683684685686

687

688689690691692693694695696697698699700701

702

703704705

706707708709710

711712

713714715716

717

718719

720721

6162

63

network protocol binding — based on the WSDL description of the target Web service, the best supported protocol binding will be selected for communication

potentially also triple-space grounding for communication using TripleS

4.2.8 Fault Handling

4.2.9 Monitoring

SEE expects to send and receive semantically enriched messages at its boundaries. A semantically enriched message is one where the content data of the message is described exclusively in terms of concepts from one or more ontologies. Other components of the framework may use the validator to check a document for consistency and correctness before continuing to process it. Correct data descriptions are then parsed by the individuals components into an internal representation .This guarantees that clients of SEE get consistent exceptions and faults for ill-defined WSML documents, giving more freedom to the components parser choice.

4.3 Base Layer

4.3.1 Formal Languages

Descriptions in SEE need different formal languages for the specification of different aspects of knowledge and services. The descriptions in a SEE can be decomposed into four dimensions:

Static knowledge (ontologies)

Ontologies are the core of the Semantic Web and of any Semantic Service Oriented Architecture. They can be used to formally describe any kind of knowledge on the Semantic Web and they form the vocabulary for the other dimensions for description in a SEE.

Functional description (capabilities)

With capabilities, services are viewed as functions which provide a certain output, given a particular input. This simplified view of services is useful for such tasks as discovery and composition.

Behavioural description (choreography/orchestration)

Choreographies describe the interface of a service in terms of possible interactions with a service. Orchestrations describe compositions of services. Choreographies and Orchestrations can both be viewed as decompositions of capabilities.

Non-functional Properties

Besides a functional description, services also have a non-functional description, with things as author, natural language description, QoS, pricing, service-level agreements, etc.

4.3.2 Reasoning

The semantic markup of Web services using specific ontologies provides the knowledge required by computer systems to help them automate tasks that otherwise require human intervention at run-time. Combining ontology-based markup with logic and reasoning provides very powerful instruments. Knowledge represented formally, using logical languages, can be interpreted and reasoned about by machines. Reasoning allows implicit knowledge to be inferred from existing knowledge and form an extremely powerful tool when combined with ontologies.

In the context of SEE, the Reasoner component is required for discovery as well as both process and data mediation. As a starting input, the current release of the WSMX Reasoner component allows for


722723

724

725

726

727728729730731732733

734

735

736737

738

739

740741742

743

744

745

746747

748

749750751

752

753

754755

756

757758759760761762

763764

6465

66

hierarchical queries on concepts, such as requests for subconcepts or superconcepts, entailment and, some support for queries against the knowledge base available to the reasoner.

The Semantic Execution Environment (SEE) needs the reasoning component for service discovery as well as both process and data mediation. To enable processing of these tasks in an automated manner, machines need to have access to structured knowledge. Knowledge described formally using logical languages can be interpreted and reasoned about by machines.

The Reasoning component in the SEE architecture provides an infrastructure for defining, managing and reasoning about formally represented knowledge. Mission critical features of this component are: hybrid reasoning based on DLs and logic programming, reasoning with very large instance bases, reasoning with heterogeneous and conflicting information, and reasoning in distributed environments.

The Reasoning component provides a reasoner with the following functionalities:

Hybrid reasoning with DLs and rules

Implementation of novel efficient deductive database algorithms and optimization techniques

Implementation of the RIF specification in order to handle rules from diverse rule systems and allow WSML rules to be interchangeable with other rule languages supported by RIF

Reasoning with very large instance databases

Reasoning with heterogeneous formats of data possibly containing conflicting information

Reasoning in a distributed environment - knowledge that is not necessarily present in one location

Common reasoning tasks - query answering, checking logical entailment, consistency checking etc.

4.3.3 Storage

The Storage service in SEE is required to provide support based on two major aspects. Firstly, for storing information in distributed and scalable storage repositories and secondly to carryout communication according to Web principles, based on the model of persistent publish and read.

The storage space is based on Web and semantics, i.e. it can be accessed over Web and have Resource Description Framework (RDF) triples as fundamental storage element. It supports storing information both at run time and at design time. It allows storing formal descriptions of Ontologies, Semantic Web Service descriptions, Mediation mappings, user Goals along with any contextual information about their use, any intermediary data during inter-platform services communication. The storage space can be composed on a single repository or widely distributed on multiple Web accessible storage repositories and visible as single virtual storage.

The Storage service in SEE is not only about semantic data storage but also about scalable communication and coordination of Semantic Web Services based on emerging Triple Space Computing [1]. It has been achieved by extending Tuple Space Computing to support RDF and carding out communication and coordination based on persistent publish and read to enable decoupling based on time, reference and location. It supports intra SEE communication (i.e. inter Platform services communication), hence enables the decoupling of Platform services of Kappa SOA. It also supports communication between different SEE systems to form SEE cluster, hence enables the decoupling of different Semantic Web Services.


765766

767

768769770771

772

773774775776

777

778

779

780781

782

783

784785

786787

788

789790791

792

793794795796797798799

800

801802803804805806807808

6768

69

4.4 Vertical Services

4.4.1 Execution Management

The execution management service is responsible for the coordination of the overall operational semantics of SEE that let the system achieve the promised functional semantics of its client-side interface. It takes the functionality offered by the individual services of the framework and orchestrates these atomic pieces into a coherent whole in an orderly, logical, and consistent fashion.

These properties are guaranteed by the execution semantics, which are the topic of another specification developed in the SEE TC. The execution management service executes the execution semantics over the set of services that are available to it.

The borders of one instance of SEE are defined by the services that are registered with the execution management service and may vary over time. By managing the control flow as well as the dataflow between the components it serves as a layer of indirection between the individual services, that are neither aware of each other nor of the context in which they are being invoked.

Much of the perceived reliability of a SEE instance is rooted in this service, as it is the place where unavailability of individual services can be compensated for. It monitors its own execution as well as registered service, for a range of data relevant to the manageability of the overall system.

4.4.2 Security


809

810

811812813814

815

816817818

819

820821822823

824

825826827

828

7071

72

5 SummaryThis document outlined a comprehensive framework that integrates two complimentary and revolutionary technical advances, Service-Oriented Architectures (SOA) and Semantic Web, into a single computing architecture, that we call Semantically Execution Environment. While SOA is widely acknowledged for its potential to revolutionize the world of computing, that success depends on resolving two fundamental challenges that SOA does not address, integration, and search or mediation. In a services-oriented world, billions of services must be discovered and selected based on requirements, then orchestrated and adapted or integrated. SOA depends on but does not address either search or integration. The contribution of this document is to provide the semantics-based solution to search and integration that will enable the SOA revolution. The document provided a vision of the future enabled by SEE framework that places computing and programming at the services layer and places the real goal of computing, problem solving, in the hands of end users.


829

830831832833834835836837838839840

7374

75

A. Acknowledgements


841

7677

78

B. Appendix A – SEE API (Operations)

Presentation of operations in pseudo syntactical syntax

Discovery

Operation A:

Searches the repository for those Web services that match the goal of the requester. The operation receives a goal as input and return a number of web services leading to the following signature.

discover(Goal goal): WebService[]

Operation B:

Searches the repository for those Web services that match the goal of the requester, according to a specific matching function.

discover(Goal goal, Matchtype type): WebService[]

<WSML Supportive Ontologies>http://www.oasis-open.org/ex-semantics/ontologies/discovery

http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess

http://www.wsmo.org/2004/d2

<WSML service description>

wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-rule"

namespace { _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#",

dc _"http://purl.org/dc/elements/11#",

xsd _"http://www.w3c.org/2001/XMLSchema#",

wsml _"http://www.wsmo.org/2004/wsml#",

d _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#",

dp _"http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess#",

dc _"http://www.oasis-open.org/ex-semantics/ontologies/discoverychoreography#",

oasm _"http://www.wsmo.org/ontologies/choreography/oasm#",

d2 _"http://www.wsmo.org/2004/d2#"

}

webService _"http://www.oasis-open.org/ex-semantics/services/discovery"

nonFunctionalProperties

dc#title hasValue "Discovery"

dc#type hasValue d2#Webservice

wsml#version hasValue "0.01"

endNonFunctionalProperties

importsOntology _"http://www.oasis-open.org/ex-semantics/ontologies/discovery"


842

843

844

845

846847

848

849

850

851

852853

854

855

856

857858

859

860

861

862

863864

865

866

867

868

869

870

871

872

873

874

875

876

877

878

879

880

881

882883

884

7980

81

capability _"http://www.oasis-open.org/ex-semantics/services/discovery#capability"

importsOntology { _"http://www.oasis-open.org/ex-semantics/ontologies/discovery"}

precondition discoveryPrecondition

postcondition discoveryPostcondition

interface DiscoveryInterface

choreography DiscoveryChoreography

stateSignature _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#statesignature"

importsOntology {

_"http://www.oasis-open.org/ex-semantics/ontologies/discovery",

_"http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess",

_"http://www.oasis-open.org/ex-semantics/ontologies/discoverychoreography"

}

in d2#Goal withGrounding { _"http://www.example.org/services/discovery/a" }

out dp#DiscoveryResult

controlled oasm#ControlState

transitionRules _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#transitionRules"

/*

* Request-reply style MEP

*/

forall {?controlstate, ?request} with (

?controlstate[oasm#value hasValue oasm#InitialState] memberOf oasm#ControlState and

?request memberOf d2#Goal

) do

add(?controlstate[oasm#value hasValue dc#EntreatyReceived])

delete(?controlstate[oasm#value hasValue oasm#InitialState])

add(_# memberOf dp#DiscoveryResult)

endForall

/*

* If the request specifies a match type the response will be

* matches from this type.

*

* Binds to a goal even though it's not used in the conclusion

* of the rule to make sure that we never fire without a request.

*/

forall {?controlstate, ?request} with (

?controlstate[oasm#value hasValue oasm#InitialState] memberOf oasm#ControlState and

?request memberOf d2#Goal and

?matchtype memberOf d#Match

) do

add(_#[d#matchtype hasValue ?matchtype] memberOf dp#DiscoveryResult)

endForall


885

886

887888

889

890891

892893

894

895

896

897

898

899

900

901

902

903

904

905

906907

908

909

910

911912

913

914

915

916

917

918

919920

921

922

923

924

925

926

927

928929

930

931

932

933

934

8283

84

C. Revision History

[optional; should not be included in OASIS Standards]

Revision Date Editor Changes Made

1 30/11/2005 [email protected] Document created. Initial document structure proposed

2 14/12/2005 [email protected] Explained what is SEE in section 1.1

Initial relationships to others groups and committees recognized in section 1.3

3 16/12/2005 [email protected] Added updates for section 2.3 and 2.5

4 16/12/2005 [email protected] Added updates for section 2.1

5 12/1/2006 [email protected] Added updates to section 4.1

6 4/2/2006 [email protected] Added updates to section 3.2, 3.4, 4.1.1, 4.1.2, 4.1.3, 4.1.9, 4.1.10

7 17/2/2006 [email protected] Architecture diagram updated based on research seminar in Innsbruck. Introduced concepts of user services and platform services. Introduced concepts of vertical and horizontal services.

8 18/02/2006 [email protected] Added paragraphs on relationship to WSRF in section 1.3

9 24/03/2006 [email protected] Added section 2.6 – Conceptual model for SEE, first rough draft

10 24/03/2006 [email protected] Description for most of the components provided

11 17/04/2006 [email protected] Structural updates to streamline the deliverable. Removed section on Conceptual Model for SEE (may be introduced in a separate deliverable). Removed shaded sections on distribution model for SEE (redundant). Removed section on Related Work (this goes to new SEE TC deliverable).

12 29/04/2006 [email protected] Minor structural updates to document

13 1/05/2006 [email protected] Added section 2.4 Benefits of adding Semantics to SOA and section 2.2 on Dynamic SOA.

Complete description of discovery with Informal Description of Functionality and


935

936

937

8586

87

mailto:[email protected]












Informal Interface

Discovery Operations added in SEE API Appendix

End User Tools changed to Applications

Data and Process Mediation merged on diagram just to Mediation.

Short description provided for Ontologies, Formal Languages, Developer Tools and Applications

Short Summary Provided

Introduction to Section 4 provided

Updated figure 3 and figure 6 – removed Kappa and Lambda

Diagram from figure 2 updated – numbers added

14 8/05/2006 [email protected] Rename application layer to broker layer,

Move beginning of section 4, which introduces SEE services to section 3.

15 8/05/2006 [email protected] Add explanation of what is the difference between architecture and infrastructure

16 8/09/2006 [email protected] Revised section 1.

17 14/09/2006 [email protected] Added choreography UML diagrams.


938

8889

90





[rfc2119]

Documents

oasis technical

oasis intellectual

oasis website

oasis ipr policy

open university

technical committee

technical purpose

technical committee