Figure 1

Reference Model for Semantic Service Oriented Architecture

Working Draft 0.1, 21 March 2007

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

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

Artifact Type:semanticsoarm

Technical Committee:OASIS SEE TC

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

Editor(s):Barry Norton, Open University, [email protected] Mocan, DERI, [email protected]

OASIS Conceptual Model topic area:SOA

Related work:This specification depends upon and extends:

Reference Model for Service Oriented Architecture, Public Review Draft 1.0, 10 Feb 2006This specification provides the basis for:

Semantic Web Services Architecture and Information Model SEE Execution Semantics

Abstract:This reference model extends the work done in the OASIS SOA-RM technical committee, defining a reference model for Service Oriented Architecture, by adding the concept of semantics. It should be noted that it is assumed that the reader has already read and is familiar with the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0”. The aim of this reference model is to provide justifications for the need for semantics in Service Oriented Architecture and to show where semantics can be applied in the SOA-RM and the benefits such an application gives.

Status:This document is currently a working draft and will be update as necessary to bring it up to public review draft status in the coming weeks/months. Please send all comments to the editors.

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/semantic-ex.

wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. of 26

1

2

3

4

56

789

10

1112

1314

151617

181920

2122

2324

25262728

2930313233343536

373839

40414243

12

3

mailto:[email protected]

mailto:[email protected]

Notices

Copyright © OASIS Open 2006. All Rights Reserved.

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

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

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

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

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

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

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


44

45

4647

4849505152535455

5657

5859606162

6364656667

6869707172

7374757677787980818283

45

6

Table of Contents

1 Introduction ......................................................................................................................................... 4

1.1 What is a Reference Model ...............................................................................................................4

1.2 Audience ........................................................................................................................................... 4

1.3 Guide to using the Reference Model .................................................................................................4

1.4 Notation Conventions ........................................................................................................................ 4

2 Semantic SOA ..................................................................................................................................... 5

2.1 Why Add Semantics to SOA? ............................................................................................................5

2.2 The Extra Benefits of SOA with Semantics .......................................................................................5

3 The Reference Model .......................................................................................................................... 7

3.1 Web Service ...................................................................................................................................... 7

3.2 Goal ................................................................................................................................................... 7

3.3 Mediator ............................................................................................................................................ 7

3.3.1 WG-Mediator .............................................................................................................................. 7

3.4 Capability ........................................................................................................................................... 8

3.5 Interface ............................................................................................................................................ 8

3.5.1 Choreography ............................................................................................................................ 8

3.5.2 Orchestration .............................................................................................................................. 8

3.6 … ....................................................................................................................................................... 8

4 Relationship between the Semantic SOA Reference Model and the SOA-RM specifications .............9

4.1 Service .............................................................................................................................................. 9

4.2 Dynamics of Services ...................................................................................................................... 10

4.2.1 Visibility .................................................................................................................................... 10

4.2.2 Interacting with services ...........................................................................................................10

4.3 About services ................................................................................................................................. 11

4.3.1 Service description ...................................................................................................................11

4.3.2 Policies and contracts ..............................................................................................................12

4.3.3 Execution contexts ................................................................................................................... 12

5 References ........................................................................................................................................ 13

5.1 Normative ........................................................................................................................................ 13

5.2 Non-Normative ................................................................................................................................ 13

A. Glossary ............................................................................................................................................ 14

B. Notations Used .................................................................................................................................. 15

Concepts ............................................................................................................................................... 15

Subsumption ......................................................................................................................................... 16

Attributes ............................................................................................................................................... 16

C. WSML Formalisation of Reference Model .........................................................................................18

D. Acknowledgements ........................................................................................................................... 19

E. Revision History ................................................................................................................................ 21

1 Introduction ......................................................................................................................................... 4

1.1 What is a reference model ................................................................................................................. 4

1.2 Audience ........................................................................................................................................... 4

1.3 Guide to using the reference model ..................................................................................................4


84

85

86

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

78

9

1.4 Notation Conventions ........................................................................................................................ 4

2 Semantic SOA ..................................................................................................................................... 5

2.1 Why Add Semantics to SOA? ............................................................................................................5

2.2 The Extra Benefits of SOA with Semantics .......................................................................................5

3 The Reference Model .......................................................................................................................... 7

3.1 Web Service ...................................................................................................................................... 7

3.2 Goal ................................................................................................................................................... 7

3.3 Mediator ............................................................................................................................................ 7

3.3.1 WG-Mediator .............................................................................................................................. 7

3.4 Capability ........................................................................................................................................... 8

3.5 Interface ............................................................................................................................................ 8

3.5.1 Choreography ............................................................................................................................ 8

3.5.2 Orchestration .............................................................................................................................. 8

3.6 … ....................................................................................................................................................... 8

4 Implementing the SOA-RM specifications – the SEE approach ..........................................................9

4.1 Service .............................................................................................................................................. 9

4.2 Dynamics of Services ...................................................................................................................... 10

4.2.1 Visibility .................................................................................................................................... 10

4.2.2 Interacting with services ...........................................................................................................10

4.3 About services ................................................................................................................................. 11

4.3.1 Service description ...................................................................................................................11

4.3.2 Policies and contracts ..............................................................................................................12

4.3.3 Execution contexts ................................................................................................................... 12

5 References ........................................................................................................................................ 13

5.1 Normative ........................................................................................................................................ 13

5.2 Non-Normative ................................................................................................................................ 13

A. Glossary ............................................................................................................................................ 14

B. Notations Used .................................................................................................................................. 15

Concepts ............................................................................................................................................... 15

Subsumption ......................................................................................................................................... 16

Attributes ............................................................................................................................................... 16

C. WSML Formalisation of Reference Model .........................................................................................18

D. Acknowledgements ........................................................................................................................... 19

E. Revision History ................................................................................................................................ 21


127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

1011

12

1 Introduction

1.1 What is a rReference mModelThe authors direct the reader to section 1.1 of “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” where a full description of the purpose of a reference model is described.

1.2 AudienceThe SOA-RM public review draft describes the audience as non-exhaustively including:

a Architects and developers designing, identifying or developing a system based on the service-oriented paradigm;.

s Standards architects and analysts developing specifications that rely on service oriented architecture concepts;.

d Decision makers seeking a "consistent and common" understanding of service oriented architectures;.

Uusers who need a better understanding of the concepts and benefits of service oriented architecture.

The audience of this reference model for Semantic SOA Service Oriented Architecture (SOA)_covers the same audience, especially in cases where the architect, developer, analyst, decision maker or user wishes to perform some form of automation within their SOA. As will be described later automation of parts of the SOA usage process is only possible if machines can ‘understand’ the services in the SOA and the addition of semantics is the proposed mechanism for achieving this.

1.3 Guide to using the rReference mModelWe encourage all readers to read this document in its entirety and make the assumption that the reader has already read the “Reference Model for Service Oriented Architecture, Public Review Committee Specification Draft 1.0” in its entirety.

This section of the current document introduces the documentcontent, its audience, notation conventions etc. Section 2 goes on to describe why semantics are needed in a SOA and the purpose of having a reference model. Section 3 goes on to describe the rReference mModel as an extension of the work done by the OASIS SOA-RM Technical Committee. Finally the document will provide some conformance guidelines and any references that may be interesting or useful to the reader.

1.4 Notation ConventionsFor ease of comparison we use the same notation conventions as the SOA-RM public review draft, namely those keywords from RFC2119: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL.

References are surrounded with [square brackets and are in bold text].


163

164

165166

167

168169170171172173174175176

177178179180181182

183

184185186

187188189190191

192

193194195196197

1314

15

2 Semantic SOAThis section provides an overview of the main benefits of adding semantics to SOA. In the first part, it outlines the “why bother” with respect to adding semantics to SOA’s while in the second part it elaborates the “benefits of SOA” section from the SOA-RM document with those added benefits received by adding semantics to the reference model.

2.1 Why Add Semantics to SOA?Service 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-ambiguously 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 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.2 The Extra Benefits of SOA with SemanticsThe semantically enhanced SOA inherits, and adds to, the general aims the ‘classical’ SOA is driven by. Some of these, as underlined by SOA-RM specification, are “to facilitate the manageable growth of large-scale enterprise systems”, “to facilitate Internet-scale provisioning and use of services” and “to reduce costs in organization to organization cooperation”. Semantics layers on top of SOA and provides a higher level of abstraction which allows the creation of intelligent, dynamic and flexible solutions to support the achievement of the above mentioned goals.

The main aspect where semantics can make the difference is the scalability. Whilst Wwe agree that definitely SOA undoubtedly scales much better than existing legacy systems but , soon this is going to be not enough. The current techniques in service provision, selection, composition, interoperability and


198

199200201202

203

204205206207208

209210211212213214215216217218

219220221222223224

225226227228229230

231232233

234

235236237238239240

241242243

1617

18

invocation may scale for thousands of services but it is envisioned that SOA solutions will extend over the enterprise boundaries to the Web scale. In the future, the World Wide Web could host billion of services and SOA will simply not scale without a significant degree of automation in all the operations regarding the services’ life cycle.

By semantically describing services, they can be far more easilyer discovered and integrated, to the degree that they can be used to achieve in ad-hoc collaborative scenarios. By semantically describing the information and behavioral model of these services the heterogeneity problems that may appear can be solved at a higher level of abstraction in a reusable and technology independent fashion.

Semantics- enabled SOA allows the integration of services in various execution scenarios that can be adjusted and updated without performing any changes on the constituent systems. Further more, such execution scenarios are independent of the underlying technologies and can be expressed in a higher level (semantic) description language. Bu In this way, the business logic is isolated from the technological details allowing better management and maintainability of the overall business solution.


244245246247

248249250251252

253254255256257258

259

260

1920

21

3 The Reference ModelThe basis of the Semantic SOA Reference Model is illustrated in Figure 1.


261

262

263

2223

24


264

2652526

27

Figure 1: Reference Model as UML Class Diagram

3.1 Web ServiceThis is comparable with the notion of service in the SOA-RM, but necessarily describes a service which is capable of programmatic invocation and access. This notion is common between OWL-S, METEOR-S and WSMO…

3.2 GoalA major difference between SOA-RM and the Semantic SOA Reference Model it that we explicitly model the intentions of the client to each service. We borrow this notion from WSMO, though it has appeared in primitive form in other SWS work, such as in ontologically representation of ‘service templates’ in METEOR-S-related work…This is represented ontologically as a Goal.

3.3 MediatorThe Semantic SOA Reference Model will adopt the WSMO principle that any connection made between two elements in the model should be represented by a Mmediator. These allow the specification of several types of mediation, which is to say bridging the gap between heterogeneous descriptions and/or expectations. Insofar as this requires difference in the representation of data, which we call data mediation, this is comparable with the OWL-S-related work on shims, but we aim to reproduce the full generality of mediators in WSMO which cover also e.g. protocol mediation.

3.3.1 WG-Mediator

An important class of Mediator used in the Semantic SOA Reference Architecture is named WG-Mediator since it fundamental mediator concerning description of SEE itself describes the mediation between goals and web services (and vice versa).…

3.4 CapabilityA capability is used both in the description of Goals and Web Services to semantically describe both the requirements for, and the results of, successful interaction from a global point of view. This is specified using logical expressions in the ontology language and consists in four parts, as follow:

Precondition: specifies

Assumption: specifies

Postcondition: specifies

Effect: specifies


266

267

268269270

271

272273274275

276

277278279280281282

283

284285286

287

288289290

291

292

293

294

2829

30

Barry Norton, 10/17/06,

I suppose?

3.5 Interface

3.5.1 Choreography

3.5.2 Orchestration

3.6 Behaviour Model…

3.7 Action Model

3.8 Process Model

3.9 CommunicableCommunicable is the means to specify semantically the actions involved in interaction between a requester and provider of a service. Ontologically it is a meta-class to concepts and relations ranging over the semantic representations of the values which can be passed, and allows an instance value to be added specifying the grounding to a syntactic representation (such as a WSDL 1.1 message or a XML Schema type).


295

296

297

298

299

300

301

302303304305306

307

3132

33

4 Implementing the Relationship between the Semantic SOA Reference Model and the SOA-RM specifications – the SEE approach

In this section we take each of the SOA-RM elements and discuss how are they covered by WSMO (the conceptual model of SEE) and by SEE itselfthe Reference Model. We start with the notion of service, continue with dynamics of services and finalized with the actual elements around the concept of service.

4.1 Service

SOA-RM defines the notion of service as follows: “A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” WSMO and SEE The main focus of the Semantic SOA Reference Model is on Web services, a type of services that obviously obey conform to the above description, albeit in a more restricted setting.

Additional to the classical Web services of WSDL description and SOAP-based invocations, WSMO the Semantic SOA Reference Model provides an extra layer: the semantic description of Web services. Further onIn this section , we want intend to prove show that exactly these semantic descriptions layered on top of a proper service execution environment, enable what we are calling the new generation of semantics-enabled SOA architecture, in accord compliance with the OASIS SOA-RM standard specifications.

SOA-RM identifies four main aspects regarding the service that have to be considered in SOA:

Enable access to one or more capabilities. In WSMO and SEE services are seen as well as computational entities that enable a requester to gain access and to consume certain functionality. WSMO prescribes that a service should have only one capability – a stronger condition that the one imposed by the SOA-RM.

Access through a prescribed interface. WSMO The Semantic SOA Reference Model makes a clear distinction between interface and the capability on one hand, and between the interface and the implementation of the service on the other hand. A WSMO service interface must contains all the necessary information one needs to access/invoke the service.

Opaque to the service consumer except from the information and behavioral models in the interface and the information required to asses if a service suits the requester needs. In WSMO the Semantic SOA Reference Model the above mentioned two-sided separations fully match this requirement. The separation between the implementation and the interface assures that none of the private business logics or the internal computational/technical details are revealed. By the separation between the interface and the capability, WSMO the Semantic SOA Reference Model makes sure that it is clearly stated what information needs to be used when finding the suited service (i.e. during the discovery service) and what information is needed after discovery when the service needs to be invoked. In WSMO the interfaces and the capability are semantically described (this description might include also the grounding to the actual implementation of the service, e.g. the WSDL web service).

Consequences of invoking a service should be either response information to the invocation or a change to the shared state of the defined interface. WSMO The Semantic SOA Reference Model goes one step further and as part of the capability, it formally describes the conditions to hold on the outputs after the invocation of the service (i.e. conditions) as well as the changes on the outside world (i.e. effects). SEE The Semantic SOA Reference Architecture has the role defines


308

309

310

311312313

314

315

316

317318319320321

322323324325326327

328

329

330331332333334335336337338339340341342343344345346347348349350351352353

3435

36

the functionality (during the discovery phase) to check if the post-conditions and the effects match the requester needs.

It is important to note that because the SEE Semantic SOA Reference Architecture defines operationses on services described using the Semantic SOA Reference ModelWSMO services theseis requirements are fully wholly fulfilled. Further more, by use of semantics, explicit information about service’s interface and capability is given; the semantic descriptions present offer a significant advantage on the WSDL description (or on the service descriptions in an UDDI repository) which are in general less expressive and in most of the cases rather ambiguous.

4.2 Dynamics of Services

SOA-RM also provides guidelines regarding the interactions of the requester with a service. As such, it identifies three fundamental concepts related with dynamics of the service: Visibility, Interaction and real world effect. In the following subsections we will analyze each of them from the perspectives of the WSMO and SEE Semantic SOA Reference Model and Architectureperspective.

4.2.1 Visibility

Visibility in terms of SOA-RM is characterized in terms of Awareness, Willingness and Reachability.

4.2.1.1 Awareness

Awareness is the state whereby the service requester is aware of the service provider or the other way around. It is normally achieved by having either the requester or the provider discovering the information the other party published in public directory for example.

WSMO The Semantic SOA Reference Model offers supports for creating the semantic description of services, and by using this the Semantic SOA Reference Architecture defines means for enables the creation provision of intelligent discovery mechanisms. It is the role of SEE concrete architectures, conforming to the Semantic SOA Reference Architecture to provide the actual discovery services that would make use of (semantics-enabled) service repositories.

WSMO The state of the art in the domain of Semantic Web Services, which the Semantic SOA Reference Model and Architecture aim to capture, has considered so far only one-way discovery: i.e. discovery of a from the requester to the provider from the point of view of a requester. Accordingly to WSMOthe Semantic SOA Reference Model provides for , a requester has to formalize its his needs in a Goal (i.e. a semantic description of its requirements) and to submit it to an intelligent discovery engine for resolutions. The SEE Semantic SOA Reference Architecture includes characterizes such a discovery services as able to resolve a Goal and to retrieve all matching services from a given repository (previously the semantic descriptions of the services have to be registered in the repository).

4.2.1.2 Willingness

Willingness is about concerns the intent to communicate. Even if the discovery process has been successful, without willingness to communicate from both requester and provider the interaction will fail.

WSMO The Semantic SOA Reference Architecture allow for the use of two aspects of the Semantic SOA Reference Model to judge willingness of each party to communicate: the capability, which we consider as part of the information model, provides a set of global conditions in the precondition and assumptions under which each party is willing in principal to communicate; the choreography, which is part of the behaviour model, provides a set of interactions in which each party is willing to engage at each stage of their interaction.does not directly prescribe any mechanisms dealing with this matter. But WMSO assumes that both partners would comply with the behaviors described in the interfaces of the Goal and Service, respectively, and that any special conditions that have to be fulfilled or actions to be taken in order to have a successful conversation are present in the capability’s preconditions.

Additionally, since one of SEE‘s role is to manage the conversation there could be compensatory measures and strategies implemented in case one of the partners is not willing to interact


354355

356357358359360361

362

363

364365366367

368

369

370

371372373

374375376377378

379380381382383384385386

387

388389

390391392393394395396397398

399400

3738

39

It is a task of the Semantic SOA Reference Architecture to ensure that these global conditions are met before a goal is mediated against a given service and then, as described later, to mediate between the behaviours.

4.2.1.3 Reachability

In WSMO The Semantic SOA Reference Architecture acts as a broker between client and services and therefore the reachability issue for the client is reduced to the reachability of the implementation of this architecture. The reachability of services brokered by the Semantic SOA broker means that, at the implementation level, the broker must act as a ‘semantic service bus’ supporting the transport mechanisms of all services to be brokered. Implementations of the architecture should also actively maintain a record of the status and dynamic reachability of services and include this in the discovery process, but this is currently seen as an implementation detail and not mandated by the architecture.this aspect is considered to be part of the infrastructure that supports the Semantic Web Services and their requesters.

SEE has the role of providing such an environment and even if the semantic technologies are used to enhance the main operations on services (e.g. discovery, invocation), standards are used as underlying, lower level technologies (e.g. SOAP, WSDL, etc.).

4.2.2 Interacting with services

The SOA Reference Model states: “Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission.” The action model of the Semantic SOA Reference Model allows not only for explicit messages, modeled as inputs and outputs, but also shared means of interaction that have been used in the state of the art for interaction via shared message spaces. It is important that these means of interaction are explicitly modeled and also given semantic descriptions.

4.2.2.1 Information model

Conform to Accordancing to SOA-RM, the information model of a service is a characterization of the information that may be exchanged with a service. The information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of the terms used. Additionally, an important fact is the semantics associated by the application to this information model, semantics which might vary from on system from another.

One of the strongest point of WSMO and SEE, and in general of semantic-based systems, which we intend to capture in the Semantic SOA Reference Model, is that they offer means to unambiguously describe such information models. In WMSO this model all the elements provided in the model are ontology-centric: everything is semantically describes byd using ontologies. In particular, the action model is described foremost in terms of ontological concepts and relations, and only secondly in terms of a grounding to syntactic representation. Secondly the inter-relationship and constraints over the semantic representation of the communication is given, in the precondition, by a logical expression in the ontology language.

By representing both the view of the client and the view of the service provider ontologically – though not necessarily coincidentally, nor even in the same ontology, a principal we call ‘ontological role separation’ – we allow for the Semantic SOA Reference Architecture to provide for mediation between requesters and providers with All the data exchanged between partners is structurally and semantically described by ontologies. SEE is a semantic environment as well and all the internal messages exchanged by its components and with the requester and/or receiver are ontology instances, i.e. semantically described data. In this way the semantic engagement is clear and it is the same for the requester and for the provider.

If, for whatever reason, this semantic engagement does not coincide for the partners that are communicating (i.e., they use different information models) mediation system can be used. Such systems


401402403

404

405406407408409410411412413

414415416

417

418419420421422423424

425

426427428429430

431432433434435436437438

439440441442443444445446

447448

4041

42


This first needs a sentence about what reachability is.

Implementations of these mediation components are able to resolve the heterogeneity problems between different models, using semantic techniques as well.

4.2.2.2 Behavioral model

The behavior model deals with “knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service”. It consists of two distinct aspects: the action model and the process model. The first one deals with the characterization of actions that can be invoked against the service, while the second deals with the temporal relationships of actions and events associated when interacting with a service.

The action model is captured explicitly modelled in semantic terms in WMSO by the capability of the service, in the assumptions, preconditions, post-conditions and the effects of the service. They specify exactly what conditions need to hold before invoking the service and what conditions need to hold after the invocation of the service (both in information space and in the real world). the Semantic SOA Reference Model, which are grounded

The process model is captured by the interface of a WSMO service described in the Semantic SOA Reference Model, especially in particular in the choreography. It describes in details the order in which interactions can be engaged in what re the expected messages and what is going to be delivered in a certain point of in the form of the a stateful conversation.

It is important to note that both the capability and interface of a service are augmented with semantics: all the notions and concepts used to define them are entities from the ontologies with a precise semantics.

4.2.2.3 Real world effect

WSMO allows to model in capability of the service (as described in the previous section) what are the effects of the service execution in the real world via the ‘effects’ property. This is modelled as an ontological logical expression.

4.3 About servicesFrom SOA RM: “In support of the dynamics of interacting with services are a set of concepts that are about services themselves. These are the service description, the execution context of the service and the contracts and policies that relate to services and service participants.”

4.3.1 Service description

SOA RM requires: “The service description represents the information needed in order to use a service.”

In WSMOthe Semantic SOA Reference Model, these core service descriptions represent a core element in defining Semantic Web Services, which we aim to support automated reasoning over by the use of semantic technologies. Therefore Ssemantic descriptions are associated to all resources, thus services as well. The semantic descriptions are grounded to concrete service realizations, such as once the semantic description is known the implementation of the service can be found as well.

It is important to know that WSMO point out that the Semantic SOA Reference Model allows for both functional, including behavioural, and non-functional descriptions of the service. While the functional descriptions are formal definitions expressed in terms of ontologies, the non-functional properties are extension of the Dublin Core, and might contain human-readable descriptions as well.

4.3.1.1 Service Reachability

From SOA RM: “…a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other.”


449450

451

452453454455456

457458459460461

462463464465

466467

468

469470471

472

473

474475476

477

478

479480481482483

484

485486487488

489

490491

4344

45

In WSMO the Semantic SOA Reference Model the reachability information is captured by grounding which has to role of bridging the semantic descriptions with the technical implementation of the service. SEE The Semantic SOA Reference Architecture then defines how implements such groundings, both for the data as well as for the behavior related descriptions, can used in implementation.

4.3.1.2 Service Functionality

As mentioned before, WSMO provides the means to describe the service’s functionality. Every WSMO Every service’s description in the Semantic SOA Reference Model has a capability definition, which consists of preconditions, assumptions, postconditions and effects. All this elements are formal definitions logical expressions referring to terms defined in ontologies.

4.3.1.3 Service Interface

As mentioned above, in WSMO the iInterface definitions in the Semantic SOA Reference Models have distinctive a first class place in the service description. WSMO sService interfaces has consist of up to two main parts: the choreography and orchestration. The first prescribes how a requester can interact with the service while the second describes how the service functionality is achieved by composing other services functionality.

4.3.2 Policies and contracts

WSMO The state of the art in Semantic Web Services technology has defined no standard for the latest specifications does not currently offer any support for of Policies and Contract. There is, Hhowever, there is ongoing work to align WSMO with existing Web service specifications. in this area and this will be included in the Semantic SOA Reference Model once some consensus has been reached on a standard.

4.3.3 Execution contexts

From SOA RM: “The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.”

WSMO, as conceptual model, The Semantic SOA Reference Model currently does not define how the path between the requester and the provider should be established, or what infrastructure elements should be used, since this is viewed as outside the scope of the Semantic SOA Reference Architecture and an implementation detail. It The Reference Model just creates the artifacts for the requestors and the providers to formalize their needs and to describe their capabilities (Goals and Services descriptions), respectively.

It is the role of SEE implementations of the Reference Architecture to tackle this aspect, to manage the requester-provider interactions. The conversation between the two parties takes place as specified in the interfaces (i.e. choreography and orchestration). Multiple conversations can be managed as well, as well as multiple interactions of the same service (several service instances). By grounding, the semantic-based methodologies are used in conjunction with the technological/infrastructural components.

Depending on each particular execution contexts, special operations, such as mediation can take place. Since for a particular conversation, a common semantics has to associated to the information and behaviors model, different mediation techniques might be employed (at data, process or protocol level).


492493494495

496

497498499500

501

502503504505506

507

508509510511

512

513514515

516517518519520521

522523524525526

527528529

530

4647

48


Is this true? Capabilities are optional in WMSL

5 References

5.1 NormativeNormative references go here

5.2 Non-NormativeNon-Normative references go here


531

532

533

534

535

4950

51

A. Glossary

This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” and introduces any new terms needed by the Semantic SOA Reference. The two glossaries are intended to be used together, therefore terms from the other glossary will not be repeated here.

A

A’s Definition

B

B’s Definition


536

537538539540

541

542

543

544

545

546

5253

54

B. Notations Used

Within the body text of this document we use UML Class Diagrams to illustrate the model. The formal definitions, however, are made in WSML. This is for two reasons: first, we must use a language with well-founded semantics, capable of machine reasoning – the general motivation of work in the Semantic Web, which has produced several ontology languages; secondly we need a language that allows us to attach elements of this model to SWS elements, including goals, and WSML is the only language that allows this.

Specifically, this document sticks to the ontology definition facilities of WSML. The Reference Architecture will attach Reference Model concepts to goal descriptions to allow the characterization of the components of a Semantic Execution Environment. The Execution Scenarios will attach Reference Model concepts, and Reference Architecture goals, to service descriptions to illustrate how the SEE components can work together to achieve common tasks. Finally, concrete architectures may be defined by linking concrete services to the goals from the Reference Architecture.

In the remainder of this section we sketch the relationship between UML Class Diagrams, as used within the text, to WSML descriptions. In the following section we reproduce these definitions.

ConceptsThe fundamental feature of Class Diagrams – and indeed Object-oriented design (OOD), which is the real target of UML – are classes, which are shown as square boxes with their identifier listed inside. We use UML classes to represent WSML concepts. Where the namespace into which concepts are defined is clear, we allow ourselves to omit this information in the Class Diagram. Where different namespaces are used, we use the notation for packages to make the namespace clear.

Figure 2 hence corresponds with Listing 1.

concept a

concept _”http://www.example.com/ontologies/ns1#b”

Listing 1: Example Concepts in WSML

Figure 2: Representation of WSML Example Concepts in UML Class Diagram

While UML Class Diagrams allow the definition of operations and attributes within classes, we choose not to use these and always show classes with an undivided box. Regarding the representation of attributes of WSML concepts, see below.


547

548549550551552553

554555556557558559

560561

562

563564565566567

568

569

570571572

573

574

575576

577

578579580

5556

57

SubsumptionThe fundamental relationship between concepts in WSML is subsumption. This is represented by inheritance in UML Class Diagrams. Since we declare no operations there are no unwanted side-effects due to UML/OOD semantics; in particular there are no complications to the use of multiple parents to a given concept.


concept a

concept b subConceptOf a

concept c

concept d subConceptOf {a, c}

Listing 2: Example of Subsumption between Concepts in WSML

Figure 3: Representation of Subsumption Example in UML Class Diagram

AttributesThe other explicit relationship between concepts in WSML is via attributes. These are represented by (directed) associations in UML Class Diagrams, which is to say associations with a one-way navigability, so that the innavigable side of the association (or, more correctly, the end of unspecified navigability) is the concept whose definition includes the attribute, and the other side the attribute range. The name of the association will be the name of the attribute; where the attribute name is the default ‘hasA’, where ‘a’ is the name of the concept that is the attribute range, we shall often omit this. Cardinality constraints are represented, where possible, by a constraint on the association.

The difficult case is where disjunctive attribute ranges are used; here we use two associations with the same name, which causes problems in the UML semantics, but this is due to the difference in expressivity between UML/OOD and ontology languages (in OOD it is assumed that these types of polymorphic references will be made using inclusion polymorphism, i.e. via a common superclass, which is not a requirement in most ontology languages). This also causes problems for the representation of cardinality


concept a

concept bhasA ofType (0, 1) a

concept c


581

582583584585

586

587

588589590591592593594

595

596

597598

599

600601602603604605606

607608609610611

612

613

614615616617618619620

5859

60

concept datt1 ofType {a, c}

Listing 3: Example of Attributes between WSML Concepts

Figure 4: Representation of Attributes Example in UML Class Diagram

Disjunctive attribute ranges also cause problems with cardinality constraints; consider the representation of ‘concept d att1 ofType(1) {a, c}’, which requires the use of a non-graphical constraint language, such as OCL, in UML.


621622

623

624

625626

627

628629630

6162

63

C. WSML Formalisation of Reference Model

wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight”

namespace {_”http:// http://www.oasis-open.org/apps/org/workgroup/www.semantic-exsoa.org/SemanticSOARMReferenceModel#”,

RM “http://www.semantic-soa.org/ReferenceModel#”}

ontology _http://www.semantic-soa.org/ReferenceModel#_”http:// http://www.oasis-open.org/apps/org/workgroup/semantic-ex/SemanticSOARM#”

concept wWebServicehasCapability ofType (0, 1) cCapability

hasInterface ofType iInterface

concept Ggoal hasCapability ofType (0, 1) cCapability hasInterface ofType iInterface

concept cCapability precondition ofType_”http://www.wsmo.org/wsml/wsml-syntax#logicalExpression” assumption ofType_”http://www.wsmo.org/wsml/wsml-syntax#logicalExpression” postcondition ofType_”http://www.wsmo.org/wsml/wsml-syntax#logicalExpression” effect ofType_”http://www.wsmo.org/wsml/wsml-syntax#logicalExpression”

concept IinterfacehasChoreography ofType (0, 1) cChoreographyhasOrchestration ofType (0, 1) oOrchestration

concept cChoreography subConceptOf BehaviourModel

concept oOrchestration subConceptOf BehaviourModel

concept BehaviourModel hasActionModel ofType (1) ActionModel hasProcessModel ofType (0, 1) ProcessModel

concept ActionModel in ofType (1) Communicable out ofType (1) Communicable shared ofType (1) Communicable

concept Communicable grounding ofType (0, 1) _iri

concept mMediatorhasMediationService ofType (0, 1) {wWebService, gGoal}


631

632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684

6465

66

http://www.semantic-soa.org/ReferenceModel#

concept wgWGMediator subConceptOf mediatorsource ofType (1) {wWebService, gGoal}target ofType (1) {WwebService, Ggoal}

Listing 4: Semantic SOA Reference Model in WSML


685686687

688

6768

69

D. Acknowledgements

The following individuals were members of the committee during the development of this specification and are gratefully acknowledged:

Participants:Marc Adlam, Oracle CorporationZachary Alexander, Individual MemberMichael Altenhofen, SAP AGAnuprlya Ankolekar, Institute of Applied Informatics and Formal Description Methods (AIFB)Tim Banks, IBMCharlton Barreto, Adobe SystemsDavid Brock, MW2 ConsultingDario Cerizza, CEFRIELJoseph Chiusano, Booz Allen HamiltonEmilia Cimpian, Digital Enterprise Research Institute (DERI)David Cunningham, Booz Allen HamiltonEmanuele Della Valle, CEFRIELPaul Denning, Mitre CorporationMarin Dimitrov, Ontotext Lab/Sirma GroupJohn Domingue (chair), The Open UniversityElmar Dorner, SAP AGMatthew Dovey, Oxford UniversityMike Evanoff, ManTech Enterprise Integration Center (e-IC)Dieter Fensel, Digital Enterprise Research Institute (DERI)Sri Gopalan, Booz Allen HamiltonPeter Gratzer, Sun MicrosystemsStephen Green, Individual MemberMarc Haines, Individual MemberThomas Haselwanter, Digital Enterprise Research Institute (DERI)Graham Hench, Digital Enterprise Research Institute (DERI)Hyun Jung, Korean National Computerization AgencyMick Kerrigan (secretary), Digital Enterprise Research Institute (DERI)Eunju Kim, Korean National Computerization AgencyHong-Gee Kim, Digital Enterprise Research Institute (DERI)Paavo Kotinurmi, Digital Enterprise Research Institute (DERI)Ho Kyoung Lee, Korean National Computerization AgencyJean-Luc LEVESQUE, EdiEyesSandeep Maripuri, Booz Allen HamiltonMonica Martin, Sun MicrosystemsTom Michaud, Software AG, Inc.Dugki Min, Individual MemberAdrian Mocan, Digital Enterprise Research Institute (DERI)Matthew Moran, Digital Enterprise Research Institute (DERI)Barry Norton, The Open UniversitySrinivas Padmanabhuni, Infosys TechnologiesYuanying Pan, Changfeng Open Standards Platform Software AllianceAsh Parikh, Raining Data CorporationKoustubh Pawar, CACarlos Pedrinaci, The Open UniversityJebastin Prabaharan, Infravio, Inc.Jiyong Pyon, Korean National Computerization AgencyBrahmananda Sapkota, Digital Enterprise Research Institute (DERI)Svante Schubert, Sun Microsystems


689

690691

692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740

7071

72

Ron Schuldt, Lockheed MartinOmair Shafiq, Digital Enterprise Research Institute (DERI)Clifford Thompson, Individual MemberWalt Truszkowski, NASALaurentiu Vasiliu, Digital Enterprise Research Institute (DERI)Tomas Vitvar, Digital Enterprise Research Institute (DERI)Alexander Wahler, NIWA-Web SolutionsMichal Zaremba (chair), Digital Enterprise Research Institute (DERI)Maciej Zaremba, Digital Enterprise Research Institute (DERI)


741742743744745746747748749

7374

75

E. Revision History

[optional; should not be included in OASIS Standards]

Rev Date By Whom What

wd-00 2006-05-24 Mick Kerrigan Initial version

wd-01 2005-10-17 Barry Norton Added initial UML content

wd-02 2005-10-17 Barry Norton Added initial WSML content

wd-03 2007-02-12 Adrian Mocan Added initial comparison between SOA-RM and WSMO/SEE

wd-05 2007-03-01 Adrian Mocan Editorial updates (fixing the data of the document, the revision history)

Section 4.3.1.3 “Policies related to Services” removed

wWd-06 2007-03-21 Adrian Mocan Adding content to sSection 2; removing Section 5.

wd-07 2007-03-22 Barry Norton Light editing of Section 2 (mainly for grammar), and re-write of Section 4 to align with the agreed view of positioning the Reference Model and Architecture.


750

751

752

7677

78

Figure 1

Documents

Transcript of Figure 1