• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Figure 1
 

Figure 1

on

  • 723 views

 

Statistics

Views

Total Views
723
Views on SlideShare
723
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Figure 1 Figure 1 Document Transcript

    • 1 2Reference Model for Semantic Service 3Oriented Architecture 4Working Draft 0.1, 21 March 2007 5Artifact Identifier: 6 wd-see-semanticsoarm-v0.1-r1 7Location: 8 Current: docs.oasis-open.org/ex-semantics/sematicsoarm/latest 9 This Version: docs.oasis-open.org/ex-semantics/sematicsoarm/0.1 10 Previous Version: docs.oasis-open.org/ex-semantics/sematicsoarm/0.1 11Artifact Type: 12 semanticsoarm 13Technical Committee: 14 OASIS SEE TC 15Chair(s): 16 John Domingue, Open University, <j.b.domingue@open.ac.uk> 17 Michal Zaremba, DERI, <michal.zaremba@deri.org> 18Editor(s): 19 Barry Norton, Open University, b.j.norton@open.ac.uk 20 Adrian Mocan, DERI, adrian.mocan@deri.org 21OASIS Conceptual Model topic area: 22 SOA 23Related work: 24 This specification depends upon and extends: 25 • Reference Model for Service Oriented Architecture, Public Review Draft 1.0, 10 Feb 2006 26 This specification provides the basis for: 27 • Semantic Web Services Architecture and Information Model 28 • SEE Execution Semantics 29Abstract: 30 This reference model extends the work done in the OASIS SOA-RM technical committee, 31 defining a reference model for Service Oriented Architecture, by adding the concept of semantics. 32 It should be noted that it is assumed that the reader has already read and is familiar with the 33 “Reference Model for Service Oriented Architecture, Public Review Draft 1.0”. The aim of this 34 reference model is to provide justifications for the need for semantics in Service Oriented 35 Architecture and to show where semantics can be applied in the SOA-RM and the benefits such 36 an application gives. 37Status: 38 This document is currently a working draft and will be update as necessary to bring it up to public 39 review draft status in the coming weeks/months. Please send all comments to the editors. 40 Technical Committee members should send comments on this specification to the Technical 41 Committee’s email list. Others should send comments to the Technical Committee by using the 1wd-see-semanticsoarm-v0.1-r1 22 May 2006 2Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 27
    • 42 “Send A Comment” button on the Technical Committee’s web page at www.oasis- 43 open.org/committees/semantic-ex. 4wd-see-semanticsoarm-v0.1-r1 22 May 2006 5Copyright © OASIS Open 2006. All Rights Reserved. Page 2 of 27
    • 44Notices 45Copyright © OASIS Open 2006. All Rights Reserved. 46All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 47Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 48This document and translations of it may be copied and furnished to others, and derivative works that 49comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 50and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 51and this section are included on all such copies and derivative works. However, this document itself may 52not be modified in any way, including by removing the copyright notice or references to OASIS, except as 53needed for the purpose of developing any document or deliverable produced by an OASIS Technical 54Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 55be followed) or as required to translate it into languages other than English. 56The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 57or assigns. 58This document and the information contained herein is provided on an "AS IS" basis and OASIS 59DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 60WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 61OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 62PARTICULAR PURPOSE. 63OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 64necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 65to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 66such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 67produced this specification. 68OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 69any patent claims that would necessarily be infringed by implementations of this specification by a patent 70holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 71Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 72claims on its website, but disclaims any obligation to do so. 73OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 74might be claimed to pertain to the implementation or use of the technology described in this document or 75the extent to which any license under such rights might or might not be available; neither does it represent 76that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 77rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 78OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 79to be made available, or the result of an attempt made to obtain a general license or permission for the 80use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 81Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 82information or list of intellectual property rights will at any time be complete, or that any claims in such list 83are, in fact, Essential Claims. 7wd-see-semanticsoarm-v0.1-r1 22 May 2006 8Copyright © OASIS Open 2006. All Rights Reserved. Page 3 of 27
    • 84Table of Contents 851 Introduction..............................................................................................................................................6 86 1.1 What is a rReference mModel..........................................................................................................6 87 1.2 Audience...........................................................................................................................................6 88 1.3 Guide to using the rReference mModel............................................................................................6 89 1.4 Notation Conventions.......................................................................................................................6 902 Semantic SOA.........................................................................................................................................7 91 2.1 Why Add Semantics to SOA?...........................................................................................................7 92 2.2 The Extra Benefits of SOA with Semantics.......................................................................................7 933 The Reference Model..............................................................................................................................9 94 3.1 Web Service...................................................................................................................................11 95 3.2 Goal................................................................................................................................................11 96 3.3 Mediator..........................................................................................................................................12 97 3.3.1 WG-Mediator...........................................................................................................................12 98 3.4 Capability........................................................................................................................................12 99 3.5 Interface..........................................................................................................................................12 100 3.5.1 Choreography..........................................................................................................................12 101 3.5.2 Orchestration...........................................................................................................................12 102 3.6 Behaviour Model….........................................................................................................................12 103 3.7 Action Model...................................................................................................................................12 104 3.8 Process Model................................................................................................................................12 105 3.9 Communicable................................................................................................................................12 1064 Implementing the Relationship between the Semantic SOA Reference Model and the SOA-RM 107specifications – the SEE approach............................................................................................................13 108 4.1 Service............................................................................................................................................13 109 4.2 Dynamics of Services.....................................................................................................................14 110 4.2.1 Visibility ..................................................................................................................................14 111 4.2.2 Interacting with services..........................................................................................................15 112 4.3 About services................................................................................................................................16 113 4.3.1 Service description .................................................................................................................16 114 4.3.2 Policies and contracts.............................................................................................................17 115 4.3.3 Execution contexts .................................................................................................................17 1165 References............................................................................................................................................18 117 5.1 Normative.......................................................................................................................................18 118 5.2 Non-Normative...............................................................................................................................18 119A. Glossary...............................................................................................................................................19 120B. Notations Used.....................................................................................................................................20 121 Concepts.............................................................................................................................................20 122 Subsumption........................................................................................................................................21 123 Attributes.............................................................................................................................................21 124C. WSML Formalisation of Reference Model............................................................................................23 125D. Acknowledgements..............................................................................................................................25 126E. Revision History....................................................................................................................................27 10wd-see-semanticsoarm-v0.1-r1 22 May 2006 11Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 27
    • 127 128 13wd-see-semanticsoarm-v0.1-r1 22 May 2006 14Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 27
    • 1291 Introduction 1301.1 What is a rReference mModel 131The authors direct the reader to section 1.1 of “Reference Model for Service Oriented Architecture, Public 132Review Draft 1.0” where a full description of the purpose of a reference model is described. 1331.2 Audience 134The SOA-RM public review draft describes the audience as non-exhaustively including: 135 • aArchitects and developers designing, identifying or developing a system based on the service- 136 oriented paradigm;. 137 • sStandards architects and analysts developing specifications that rely on service oriented 138 architecture concepts;. 139 • dDecision makers seeking a "consistent and common" understanding of service oriented 140 architectures;. 141 • Uusers who need a better understanding of the concepts and benefits of service oriented 142 architecture. 143 144The audience of this reference model for Semantic SOA Service Oriented Architecture (SOA)_covers the 145same audience, especially in cases where the architect, developer, analyst, decision maker or user 146wishes to perform some form of automation within their SOA. As will be described later automation of 147parts of the SOA usage process is only possible if machines can ‘understand’ the services in the SOA 148and the addition of semantics is the proposed mechanism for achieving this. 1491.3 Guide to using the rReference mModel 150We encourage all readers to read this document in its entirety and make the assumption that the reader 151has already read the “Reference Model for Service Oriented Architecture, Public Review Committee 152Specification Draft 1.0” in its entirety. 153This section of the current document introduces the documentcontent, its audience, notation conventions 154etc. Section 2 goes on to describe why semantics are needed in a SOA and the purpose of having a 155reference model. Section 3 goes on to describe the rReference mModel as an extension of the work done 156by the OASIS SOA-RM Technical Committee. Finally the document will provide some conformance 157guidelines and any references that may be interesting or useful to the reader. 1581.4 Notation Conventions 159For ease of comparison we use the same notation conventions as the SOA-RM public review draft, 160namely those keywords from RFC2119: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 161SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL. 162 163References are surrounded with [square brackets and are in bold text]. 16wd-see-semanticsoarm-v0.1-r1 22 May 2006 17Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 27
    • 1642 Semantic SOA 165This section provides an overview of the main benefits of adding semantics to SOA. In the first part, it 166outlines the “why bother” with respect to adding semantics to SOA’s while in the second part it elaborates 167the “benefits of SOA” section from the SOA-RM document with those added benefits received by adding 168semantics to the reference model. 1692.1 Why Add Semantics to SOA? 170Service Oriented Architectures represent a huge step towards providing simpler, more dynamic and 171cheaper integration solutions. By having services to encapsulate discrete piece of functionality that can be 172later discovered and consumed is without a doubt the critical step in moving from a patchwork of legacy 173products, monolithic off-shelf applications and proprietary integration to a strongly decoupled, robust yet 174flexible software architecture. 175But SOA cannot (and it is not meant to) solve all the heterogeneity problems inherent to enterprises 176integration tasks. Such heterogeneity problems could be induced for example by the services (the key 177players of SOA) themselves or by the environment the enterprises are acting in. In the former case it is 178natural that services deployed by different providers to have specific requirements regarding data formats 179or communication protocols. Further more, the invocation of such services can be part of complex 180business process that most probably differs from one vendor to another. Regarding the second case, the 181World Wide Web proves to be a more and more appealing (and suited) environment for businesses and 182Web Services could successfully fulfill the roll of services in SOA. Such a context allows for ad-hoc 183cooperation and on-the-fly business provision, but also pushes the interoperability problems to extreme, 184beyond the boundaries of the enterprises to be integrated. 185Semantics is coming to offer the tools to enable scalable, efficient and cost-effective solutions to these 186problems. Using ontologies and semantics, services can be un-ambiguously described, from data, 187functionality and behavior point of view. These semantics descriptions can be used in operations like 188discovery, selection, composition or aggregation of services to provide meaningful functionality through a 189truly Service Oriented Architecture. SOA can provide domain independent solutions for these operations 190that highly rely on semantics, formal specifications and reasoning. 191It is important to note that providing semantics descriptions for SOA it is not a trivial task and involves 192significant efforts: additionally to the actual implementation and technical interfaces an extra layer, the 193semantic layer, has to be added by each of the service providers. Only after this extra step is 194accomplished the real benefits of semantics can be exploited: old hard-coded, domain-specific solutions 195for service operations can be replaced by general, semantic-based ones and used in inter-enterprise (or 196even intra-enterprise) business scenarios. 197As such, bringing semantics to SOA means adding semantics to the services part of SOA and then 198augmenting SOA with semantic-aware mechanisms to support the elementary operations on services 199(e.g. discovery, selection, composition, invocation etc). 2002.2 The Extra Benefits of SOA with Semantics 201The semantically enhanced SOA inherits, and adds to, the general aims the ‘classical’ SOA is driven by. 202Some of these, as underlined by SOA-RM specification, are “to facilitate the manageable growth of large- 203scale enterprise systems”, “to facilitate Internet-scale provisioning and use of services” and “to reduce 204costs in organization to organization cooperation”. Semantics layers on top of SOA and provides a higher 205level of abstraction which allows the creation of intelligent, dynamic and flexible solutions to support the 206achievement of the above mentioned goals. 207The main aspect where semantics can make the difference is the scalability. Whilst Wwe agree that 208definitely SOA undoubtedly scales much better than existing legacy systems but , soon this is going to be 209not enough. The current techniques in service provision, selection, composition, interoperability and 19wd-see-semanticsoarm-v0.1-r1 22 May 2006 20Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 27
    • 210invocation may scale for thousands of services but it is envisioned that SOA solutions will extend over the 211enterprise boundaries to the Web scale. In the future, the World Wide Web could host billion of services 212and SOA will simply not scale without a significant degree of automation in all the operations regarding 213the services’ life cycle. 214By semantically describing services, they can be far more easilyer discovered and integrated, to the 215degree that they can be used to achieve in ad-hoc collaborative scenarios. By semantically describing 216the information and behavioral model of these services the heterogeneity problems that may appear can 217be solved at a higher level of abstraction in a reusable and technology independent fashion. 218Semantics- enabled SOA allows the integration of services in various execution scenarios that can be 219adjusted and updated without performing any changes on the constituent systems. Further more, such 220execution scenarios are independent of the underlying technologies and can be expressed in a higher 221level (semantic) description language. Bu In this way, the business logic is isolated from the technological 222details allowing better management and maintainability of the overall business solution. 223 224 22wd-see-semanticsoarm-v0.1-r1 22 May 2006 23Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 27
    • 2253 The Reference Model 226The basis of the Semantic SOA Reference Model is illustrated in Figure 1. 227 25wd-see-semanticsoarm-v0.1-r1 22 May 2006 26Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 27
    • 228 229wd-see-semanticsoarm-v0.1-r1 28 22 May 2006 29Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 27
    • 230 Figure 1: Reference Model as UML Class Diagram 2313.1 Web Service 232This is comparable with the notion of service in the SOA-RM, but necessarily describes a service which is 233capable of programmatic invocation and access. This notion is common between OWL-S, METEOR-S 234and WSMO… 2353.2 Goal 236A major difference between SOA-RM and the Semantic SOA Reference Model it that we explicitly model 237the intentions of the client to each service. We borrow this notion from WSMO, though it has appeared in 238primitive form in other SWS work, such as in ontologically representation of ‘service templates’ in 239METEOR-S-related work…This is represented ontologically as a Goal. 2403.3 Mediator 241The Semantic SOA Reference Model will adopt the WSMO principle that any connection made between 242two elements in the model should be represented by a Mmediator. These allow the specification of 243several types of mediation, which is to say bridging the gap between heterogeneous descriptions and/or 244expectations. Insofar as this requires difference in the representation of data, which we call data 245mediation, this is comparable with the OWL-S-related work on shims, but we aim to reproduce the full 246generality of mediators in WSMO which cover also e.g. protocol mediation. 2473.3.1 WG-Mediator 248An important class of Mediator used in the Semantic SOA Reference Architecture is named WG-Mediator 249since it fundamental mediator concerning description of SEE itself describes the mediation between 250goals and web services (and vice versa).… 2513.4 Capability 252A capability is used both in the description of Goals and Web Services to semantically describe both the 253requirements for, and the results of, successful interaction from a global point of view. This is specified 254using logical expressions in the ontology language and consists in four parts, as follow: 255 • Precondition: specifies 256 • Assumption: specifies 257 • Postcondition: specifies 258 • Effect: specifies 31wd-see-semanticsoarm-v0.1-r1 22 May 2006 32Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 27
    • 2593.5 Interface 2603.5.1 Choreography 2613.5.2 Orchestration 2623.6 Behaviour Model… 2633.7 Action Model 2643.8 Process Model 2653.9 Communicable 266Communicable is the means to specify semantically the actions involved in interaction between a 267requester and provider of a service. Ontologically it is a meta-class to concepts and relations ranging 268over the semantic representations of the values which can be passed, and allows an instance value to be 269added specifying the grounding to a syntactic representation (such as a WSDL 1.1 message or a XML 270Schema type). 271 34wd-see-semanticsoarm-v0.1-r1 22 May 2006 35Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 27
    • 2724 Implementing the Relationship between the 273 Semantic SOA Reference Model and the SOA-RM 274 specifications – the SEE approach 275In this section we take each of the SOA-RM elements and discuss how are they covered by WSMO (the 276conceptual model of SEE) and by SEE itselfthe Reference Model. We start with the notion of service, 277continue with dynamics of services and finalized with the actual elements around the concept of service. 278 2794.1 Service 280 281SOA-RM defines the notion of service as follows: “A service is a mechanism to enable access to one or 282more capabilities, where the access is provided using a prescribed interface and is exercised consistent 283with constraints and policies as specified by the service description.” WSMO and SEE The main focus of 284the Semantic SOA Reference Model is on Web services, a type of services that obviously obey conform 285to the above description, albeit in a more restricted setting. 286Additional to the classical Web services of WSDL description and SOAP-based invocations, WSMO the 287Semantic SOA Reference Model provides an extra layer: the semantic description of Web services. 288Further onIn this section , we want intend to prove show that exactly these semantic descriptions layered 289on top of a proper service execution environment, enable what we are calling the new generation of 290semantics-enabled SOA architecture, in accord compliance with the OASIS SOA-RM standard 291specifications. 292 293SOA-RM identifies four main aspects regarding the service that have to be considered in SOA: 294 • Enable access to one or more capabilities. In WSMO and SEE services are seen as well as 295 computational entities that enable a requester to gain access and to consume certain 296 functionality. WSMO prescribes that a service should have only one capability – a stronger 297 condition that the one imposed by the SOA-RM. 298 • Access through a prescribed interface. WSMO The Semantic SOA Reference Model makes a 299 clear distinction between interface and the capability on one hand, and between the interface and 300 the implementation of the service on the other hand. A WSMO service interface must contains all 301 the necessary information one needs to access/invoke the service. 302 • Opaque to the service consumer except from the information and behavioral models in the 303 interface and the information required to asses if a service suits the requester needs. In WSMO 304 the Semantic SOA Reference Model the above mentioned two-sided separations fully match this 305 requirement. The separation between the implementation and the interface assures that none of 306 the private business logics or the internal computational/technical details are revealed. By the 307 separation between the interface and the capability, WSMO the Semantic SOA Reference Model 308 makes sure that it is clearly stated what information needs to be used when finding the suited 309 service (i.e. during the discovery service) and what information is needed after discovery when 310 the service needs to be invoked. In WSMO the interfaces and the capability are semantically 311 described (this description might include also the grounding to the actual implementation of the 312 service, e.g. the WSDL web service). 313 • Consequences of invoking a service should be either response information to the invocation or a 314 change to the shared state of the defined interface. WSMO The Semantic SOA Reference Model 315 goes one step further and as part of the capability, it formally describes the conditions to hold on 316 the outputs after the invocation of the service (i.e. conditions) as well as the changes on the 317 outside world (i.e. effects). SEE The Semantic SOA Reference Architecture has the role defines 37wd-see-semanticsoarm-v0.1-r1 22 May 2006 38Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 27
    • 318 the functionality (during the discovery phase) to check if the post-conditions and the effects match 319 the requester needs. 320It is important to note that because the SEE Semantic SOA Reference Architecture defines operationses 321on services described using the Semantic SOA Reference ModelWSMO services theseis requirements 322are fully wholly fulfilled. Further more, by use of semantics, explicit information about service’s interface 323and capability is given; the semantic descriptions present offer a significant advantage on the WSDL 324description (or on the service descriptions in an UDDI repository) which are in general less expressive 325and in most of the cases rather ambiguous. 3264.2 Dynamics of Services 327 328SOA-RM also provides guidelines regarding the interactions of the requester with a service. As such, it 329identifies three fundamental concepts related with dynamics of the service: Visibility, Interaction and real 330world effect. In the following subsections we will analyze each of them from the perspectives of the 331WSMO and SEE Semantic SOA Reference Model and Architectureperspective. 3324.2.1 Visibility 333Visibility in terms of SOA-RM is characterized in terms of Awareness, Willingness and Reachability. 3344.2.1.1 Awareness 335Awareness is the state whereby the service requester is aware of the service provider or the other way 336around. It is normally achieved by having either the requester or the provider discovering the information 337the other party published in public directory for example. 338WSMO The Semantic SOA Reference Model offers supports for creating the semantic description of 339services, and by using this the Semantic SOA Reference Architecture defines means for enables the 340creation provision of intelligent discovery mechanisms. It is the role of SEE concrete architectures, 341conforming to the Semantic SOA Reference Architecture to provide the actual discovery services that 342would make use of (semantics-enabled) service repositories. 343WSMO The state of the art in the domain of Semantic Web Services, which the Semantic SOA Reference 344Model and Architecture aim to capture, has considered so far only one-way discovery: i.e. discovery of a 345from the requester to the provider from the point of view of a requester. Accordingly to WSMOthe 346Semantic SOA Reference Model provides for , a requester has to formalize its his needs in a Goal (i.e. a 347semantic description of its requirements) and to submit it to an intelligent discovery engine for resolutions. 348The SEE Semantic SOA Reference Architecture includes characterizes such a discovery services as able 349to resolve a Goal and to retrieve all matching services from a given repository (previously the semantic 350descriptions of the services have to be registered in the repository). 3514.2.1.2 Willingness 352Willingness is about concerns the intent to communicate. Even if the discovery process has been 353successful, without willingness to communicate from both requester and provider the interaction will fail. 354WSMO The Semantic SOA Reference Architecture allow for the use of two aspects of the Semantic SOA 355Reference Model to judge willingness of each party to communicate: the capability, which we consider as 356part of the information model, provides a set of global conditions in the precondition and assumptions 357under which each party is willing in principal to communicate; the choreography, which is part of the 358behaviour model, provides a set of interactions in which each party is willing to engage at each stage of 359their interaction.does not directly prescribe any mechanisms dealing with this matter. But WMSO 360assumes that both partners would comply with the behaviors described in the interfaces of the Goal and 361Service, respectively, and that any special conditions that have to be fulfilled or actions to be taken in 362order to have a successful conversation are present in the capability’s preconditions. 363Additionally, since one of SEE‘s role is to manage the conversation there could be compensatory 364measures and strategies implemented in case one of the partners is not willing to interact 40wd-see-semanticsoarm-v0.1-r1 22 May 2006 41Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 27
    • 365It is a task of the Semantic SOA Reference Architecture to ensure that these global conditions are met 366before a goal is mediated against a given service and then, as described later, to mediate between the 367behaviours. 3684.2.1.3 Reachability 369In WSMO The Semantic SOA Reference Architecture acts as a broker between client and services and 370therefore the reachability issue for the client is reduced to the reachability of the implementation of this 371architecture. The reachability of services brokered by the Semantic SOA broker means that, at the 372implementation level, the broker must act as a ‘semantic service bus’ supporting the transport 373mechanisms of all services to be brokered. Implementations of the architecture should also actively 374maintain a record of the status and dynamic reachability of services and include this in the discovery 375process, but this is currently seen as an implementation detail and not mandated by the architecture.this 376aspect is considered to be part of the infrastructure that supports the Semantic Web Services and their 377requesters. 378SEE has the role of providing such an environment and even if the semantic technologies are used to 379enhance the main operations on services (e.g. discovery, invocation), standards are used as underlying, 380lower level technologies (e.g. SOAP, WSDL, etc.). 3814.2.2 Interacting with services 382The SOA Reference Model states: “Interacting with a service involves performing actions against the 383service. In many cases, this is accomplished by sending and receiving messages, but there are other 384modes possible that do not involve explicit message transmission.” The action model of the Semantic 385SOA Reference Model allows not only for explicit messages, modeled as inputs and outputs, but also 386shared means of interaction that have been used in the state of the art for interaction via shared message 387spaces. It is important that these means of interaction are explicitly modeled and also given semantic 388descriptions. 3894.2.2.1 Information model 390Conform to Accordancing to SOA-RM, the information model of a service is a characterization of the 391information that may be exchanged with a service. The information model includes the format of 392information that is exchanged, the structural relationships within the exchanged information and also the 393definition of the terms used. Additionally, an important fact is the semantics associated by the application 394to this information model, semantics which might vary from on system from another. 395One of the strongest point of WSMO and SEE, and in general of semantic-based systems, which we 396intend to capture in the Semantic SOA Reference Model, is that they offer means to unambiguously 397describe such information models. In WMSO this model all the elements provided in the model are 398ontology-centric: everything is semantically describes byd using ontologies. In particular, the action model 399is described foremost in terms of ontological concepts and relations, and only secondly in terms of a 400grounding to syntactic representation. Secondly the inter-relationship and constraints over the semantic 401representation of the communication is given, in the precondition, by a logical expression in the ontology 402language. 403By representing both the view of the client and the view of the service provider ontologically – though not 404necessarily coincidentally, nor even in the same ontology, a principal we call ‘ontological role separation’ 405– we allow for the Semantic SOA Reference Architecture to provide for mediation between requesters 406and providers with All the data exchanged between partners is structurally and semantically described by 407ontologies. SEE is a semantic environment as well and all the internal messages exchanged by its 408components and with the requester and/or receiver are ontology instances, i.e. semantically described 409data. In this way the semantic engagement is clear and it is the same for the requester and for the 410provider. 411If, for whatever reason, this semantic engagement does not coincide for the partners that are 412communicating (i.e., they use different information models) mediation system can be used. Such systems 43wd-see-semanticsoarm-v0.1-r1 22 May 2006 44Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 27
    • 413Implementations of these mediation components are able to resolve the heterogeneity problems between 414different models, using semantic techniques as well. 4154.2.2.2 Behavioral model 416The behavior model deals with “knowledge of the actions invoked against the service and the process or 417temporal aspects of interacting with the service”. It consists of two distinct aspects: the action model and 418the process model. The first one deals with the characterization of actions that can be invoked against the 419service, while the second deals with the temporal relationships of actions and events associated when 420interacting with a service. 421The action model is captured explicitly modelled in semantic terms in WMSO by the capability of the 422service, in the assumptions, preconditions, post-conditions and the effects of the service. They specify 423exactly what conditions need to hold before invoking the service and what conditions need to hold after 424the invocation of the service (both in information space and in the real world). the Semantic SOA 425Reference Model, which are grounded 426The process model is captured by the interface of a WSMO service described in the Semantic SOA 427Reference Model, especially in particular in the choreography. It describes in details the order in which 428interactions can be engaged in what re the expected messages and what is going to be delivered in a 429certain point of in the form of the a stateful conversation. 430It is important to note that both the capability and interface of a service are augmented with semantics: all 431the notions and concepts used to define them are entities from the ontologies with a precise semantics. 4324.2.2.3 Real world effect 433WSMO allows to model in capability of the service (as described in the previous section) what are the 434effects of the service execution in the real world via the ‘effects’ property. This is modelled as an 435ontological logical expression. 436 4374.3 About services 438From SOA RM: “In support of the dynamics of interacting with services are a set of concepts that are 439about services themselves. These are the service description, the execution context of the service and 440the contracts and policies that relate to services and service participants.” 4414.3.1 Service description 442SOA RM requires: “The service description represents the information needed in order to use a service.” 443In WSMOthe Semantic SOA Reference Model, these core service descriptions represent a core element 444in defining Semantic Web Services, which we aim to support automated reasoning over by the use of 445semantic technologies. Therefore Ssemantic descriptions are associated to all resources, thus services 446as well. The semantic descriptions are grounded to concrete service realizations, such as once the 447semantic description is known the implementation of the service can be found as well. 448 449It is important to know that WSMO point out that the Semantic SOA Reference Model allows for both 450functional, including behavioural, and non-functional descriptions of the service. While the functional 451descriptions are formal definitions expressed in terms of ontologies, the non-functional properties are 452extension of the Dublin Core, and might contain human-readable descriptions as well. 4534.3.1.1 Service Reachability 454From SOA RM: “…a service description SHOULD include sufficient data to enable a service consumer 455and service provider to interact with each other.” 46wd-see-semanticsoarm-v0.1-r1 22 May 2006 47Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 27
    • 456In WSMO the Semantic SOA Reference Model the reachability information is captured by grounding 457which has to role of bridging the semantic descriptions with the technical implementation of the service. 458SEE The Semantic SOA Reference Architecture then defines how implements such groundings, both for 459the data as well as for the behavior related descriptions, can used in implementation. 4604.3.1.2 Service Functionality 461As mentioned before, WSMO provides the means to describe the service’s functionality. Every WSMO 462Every service’s description in the Semantic SOA Reference Model has a capability definition, which 463consists of preconditions, assumptions, postconditions and effects. All this elements are formal definitions 464logical expressions referring to terms defined in ontologies. 4654.3.1.3 Service Interface 466As mentioned above, in WSMO the iInterface definitions in the Semantic SOA Reference Models have 467distinctive a first class place in the service description. WSMO sService interfaces has consist of up to 468two main parts: the choreography and orchestration. The first prescribes how a requester can interact 469with the service while the second describes how the service functionality is achieved by composing other 470services functionality. 4714.3.2 Policies and contracts 472WSMO The state of the art in Semantic Web Services technology has defined no standard for the latest 473specifications does not currently offer any support for of Policies and Contract. There is, Hhowever, there 474is ongoing work to align WSMO with existing Web service specifications. in this area and this will be 475included in the Semantic SOA Reference Model once some consensus has been reached on a standard. 4764.3.3 Execution contexts 477From SOA RM: “The execution context of a service interaction is the set of infrastructure elements, 478process entities, policy assertions and agreements that are identified as part of an instantiated service 479interaction, and thus forms a path between those with needs and those with capabilities.” 480WSMO, as conceptual model, The Semantic SOA Reference Model currently does not define how the 481path between the requester and the provider should be established, or what infrastructure elements 482should be used, since this is viewed as outside the scope of the Semantic SOA Reference Architecture 483and an implementation detail. It The Reference Model just creates the artifacts for the requestors and the 484providers to formalize their needs and to describe their capabilities (Goals and Services descriptions), 485respectively. 486It is the role of SEE implementations of the Reference Architecture to tackle this aspect, to manage the 487requester-provider interactions. The conversation between the two parties takes place as specified in the 488interfaces (i.e. choreography and orchestration). Multiple conversations can be managed as well, as well 489as multiple interactions of the same service (several service instances). By grounding, the semantic- 490based methodologies are used in conjunction with the technological/infrastructural components. 491Depending on each particular execution contexts, special operations, such as mediation can take place. 492Since for a particular conversation, a common semantics has to associated to the information and 493behaviors model, different mediation techniques might be employed (at data, process or protocol level). 494 49wd-see-semanticsoarm-v0.1-r1 22 May 2006 50Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 27
    • 4955 References 4965.1 Normative 497Normative references go here 4985.2 Non-Normative 499Non-Normative references go here 52wd-see-semanticsoarm-v0.1-r1 22 May 2006 53Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 27
    • 500A. Glossary 501This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for 502Service Oriented Architecture, Public Review Draft 1.0” and introduces any new terms needed by the 503Semantic SOA Reference. The two glossaries are intended to be used together, therefore terms from the 504other glossary will not be repeated here. 505 506A 507 A’s Definition 508 509B 510 B’s Definition 55wd-see-semanticsoarm-v0.1-r1 22 May 2006 56Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 27
    • 511B. Notations Used 512Within the body text of this document we use UML Class Diagrams to illustrate the model. The formal 513definitions, however, are made in WSML. This is for two reasons: first, we must use a language with well- 514founded semantics, capable of machine reasoning – the general motivation of work in the Semantic Web, 515which has produced several ontology languages; secondly we need a language that allows us to attach 516elements of this model to SWS elements, including goals, and WSML is the only language that allows 517this. 518Specifically, this document sticks to the ontology definition facilities of WSML. The Reference 519Architecture will attach Reference Model concepts to goal descriptions to allow the characterization of the 520components of a Semantic Execution Environment. The Execution Scenarios will attach Reference 521Model concepts, and Reference Architecture goals, to service descriptions to illustrate how the SEE 522components can work together to achieve common tasks. Finally, concrete architectures may be defined 523by linking concrete services to the goals from the Reference Architecture. 524In the remainder of this section we sketch the relationship between UML Class Diagrams, as used within 525the text, to WSML descriptions. In the following section we reproduce these definitions. 526 Concepts 527The fundamental feature of Class Diagrams – and indeed Object-oriented design (OOD), which is the real 528target of UML – are classes, which are shown as square boxes with their identifier listed inside. We use 529UML classes to represent WSML concepts. Where the namespace into which concepts are defined is 530clear, we allow ourselves to omit this information in the Class Diagram. Where different namespaces are 531used, we use the notation for packages to make the namespace clear. 532Figure 2 hence corresponds with Listing 1. 533 534 concept a 535 536 concept _”http://www.example.com/ontologies/ns1#b” 537 Listing 1: Example Concepts in WSML 538 539 540 Figure 2: Representation of WSML Example Concepts in UML Class Diagram 541 542While UML Class Diagrams allow the definition of operations and attributes within classes, we choose not 543to use these and always show classes with an undivided box. Regarding the representation of attributes 544of WSML concepts, see below. 58wd-see-semanticsoarm-v0.1-r1 22 May 2006 59Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 27
    • 545 Subsumption 546The fundamental relationship between concepts in WSML is subsumption. This is represented by 547inheritance in UML Class Diagrams. Since we declare no operations there are no unwanted side-effects 548due to UML/OOD semantics; in particular there are no complications to the use of multiple parents to a 549given concept. 550Figure 3 hence corresponds with Listing 1. 551 552 concept a 553 554 concept b subConceptOf a 555 556 concept c 557 558 concept d subConceptOf {a, c} 559 Listing 2: Example of Subsumption between Concepts in WSML 560 561 562 Figure 3: Representation of Subsumption Example in UML Class Diagram 563 Attributes 564The other explicit relationship between concepts in WSML is via attributes. These are represented by 565(directed) associations in UML Class Diagrams, which is to say associations with a one-way navigability, 566so that the innavigable side of the association (or, more correctly, the end of unspecified navigability) is 567the concept whose definition includes the attribute, and the other side the attribute range. The name of 568the association will be the name of the attribute; where the attribute name is the default ‘hasA’, where ‘a’ 569is the name of the concept that is the attribute range, we shall often omit this. Cardinality constraints are 570represented, where possible, by a constraint on the association. 571The difficult case is where disjunctive attribute ranges are used; here we use two associations with the 572same name, which causes problems in the UML semantics, but this is due to the difference in expressivity 573between UML/OOD and ontology languages (in OOD it is assumed that these types of polymorphic 574references will be made using inclusion polymorphism, i.e. via a common superclass, which is not a 575requirement in most ontology languages). This also causes problems for the representation of cardinality 576Figure 4 hence corresponds with Listing 3. 577 578 concept a 579 580 concept b 581 hasA ofType (0, 1) a 582 583 concept c 584 61wd-see-semanticsoarm-v0.1-r1 22 May 2006 62Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 27
    • 585 concept d 586 att1 ofType {a, c} 587 Listing 3: Example of Attributes between WSML Concepts 588 589 590 Figure 4: Representation of Attributes Example in UML Class Diagram 591 592Disjunctive attribute ranges also cause problems with cardinality constraints; consider the representation 593of ‘concept d att1 ofType(1) {a, c}’, which requires the use of a non-graphical constraint 594language, such as OCL, in UML. 64wd-see-semanticsoarm-v0.1-r1 22 May 2006 65Copyright © OASIS Open 2006. All Rights Reserved. Page 22 of 27
    • 595C. WSML Formalisation of Reference Model 596 wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight” 597 598 namespace {_”http:// http://www.oasis- 599 open.org/apps/org/workgroup/www.semantic- 600 exsoa.org/SemanticSOARMReferenceModel#”, 601 RM “http://www.semantic-soa.org/ReferenceModel#”} 602 603 ontology _http://www.semantic-soa.org/ReferenceModel# 604 _”http:// http://www.oasis-open.org/apps/org/workgroup/semantic- 605 ex/SemanticSOARM#” 606 607 concept wWebService 608 hasCapability ofType (0, 1) cCapability 609 hasInterface ofType iInterface 610 611 concept Ggoal 612 hasCapability ofType (0, 1) cCapability 613 hasInterface ofType iInterface 614 615 concept cCapability 616 precondition ofType_”http://www.wsmo.org/wsml/wsml- 617 syntax#logicalExpression” 618 assumption ofType_”http://www.wsmo.org/wsml/wsml- 619 syntax#logicalExpression” 620 postcondition ofType_”http://www.wsmo.org/wsml/wsml- 621 syntax#logicalExpression” 622 effect ofType_”http://www.wsmo.org/wsml/wsml- 623 syntax#logicalExpression” 624 625 concept Iinterface 626 hasChoreography ofType (0, 1) cChoreography 627 hasOrchestration ofType (0, 1) oOrchestration 628 629 concept cChoreography subConceptOf BehaviourModel 630 631 concept oOrchestration subConceptOf BehaviourModel 632 633 concept BehaviourModel 634 hasActionModel ofType (1) ActionModel 635 hasProcessModel ofType (0, 1) ProcessModel 636 637 concept ActionModel 638 in ofType (1) Communicable 639 out ofType (1) Communicable 640 shared ofType (1) Communicable 641 642 concept Communicable 643 grounding ofType (0, 1) _iri 644 645 concept mMediator 646 hasMediationService ofType (0, 1) {wWebService, gGoal} 647 648 concept wgWGMediator subConceptOf mediator 67wd-see-semanticsoarm-v0.1-r1 22 May 2006 68Copyright © OASIS Open 2006. All Rights Reserved. Page 23 of 27
    • 649 source ofType (1) {wWebService, gGoal} 650 target ofType (1) {WwebService, Ggoal} 651 Listing 4: Semantic SOA Reference Model in WSML 70wd-see-semanticsoarm-v0.1-r1 22 May 2006 71Copyright © OASIS Open 2006. All Rights Reserved. Page 24 of 27
    • 652D. Acknowledgements 653The following individuals were members of the committee during the development of this specification and 654are gratefully acknowledged: 655Participants: 656 Marc Adlam, Oracle Corporation 657 Zachary Alexander, Individual Member 658 Michael Altenhofen, SAP AG 659 Anuprlya Ankolekar, Institute of Applied Informatics and Formal Description Methods (AIFB) 660 Tim Banks, IBM 661 Charlton Barreto, Adobe Systems 662 David Brock, MW2 Consulting 663 Dario Cerizza, CEFRIEL 664 Joseph Chiusano, Booz Allen Hamilton 665 Emilia Cimpian, Digital Enterprise Research Institute (DERI) 666 David Cunningham, Booz Allen Hamilton 667 Emanuele Della Valle, CEFRIEL 668 Paul Denning, Mitre Corporation 669 Marin Dimitrov, Ontotext Lab/Sirma Group 670 John Domingue (chair), The Open University 671 Elmar Dorner, SAP AG 672 Matthew Dovey, Oxford University 673 Mike Evanoff, ManTech Enterprise Integration Center (e-IC) 674 Dieter Fensel, Digital Enterprise Research Institute (DERI) 675 Sri Gopalan, Booz Allen Hamilton 676 Peter Gratzer, Sun Microsystems 677 Stephen Green, Individual Member 678 Marc Haines, Individual Member 679 Thomas Haselwanter, Digital Enterprise Research Institute (DERI) 680 Graham Hench, Digital Enterprise Research Institute (DERI) 681 Hyun Jung, Korean National Computerization Agency 682 Mick Kerrigan (secretary), Digital Enterprise Research Institute (DERI) 683 Eunju Kim, Korean National Computerization Agency 684 Hong-Gee Kim, Digital Enterprise Research Institute (DERI) 685 Paavo Kotinurmi, Digital Enterprise Research Institute (DERI) 686 Ho Kyoung Lee, Korean National Computerization Agency 687 Jean-Luc LEVESQUE, EdiEyes 688 Sandeep Maripuri, Booz Allen Hamilton 689 Monica Martin, Sun Microsystems 690 Tom Michaud, Software AG, Inc. 691 Dugki Min, Individual Member 73wd-see-semanticsoarm-v0.1-r1 22 May 2006 74Copyright © OASIS Open 2006. All Rights Reserved. Page 25 of 27
    • 692 Adrian Mocan, Digital Enterprise Research Institute (DERI) 693 Matthew Moran, Digital Enterprise Research Institute (DERI) 694 Barry Norton, The Open University 695 Srinivas Padmanabhuni, Infosys Technologies 696 Yuanying Pan, Changfeng Open Standards Platform Software Alliance 697 Ash Parikh, Raining Data Corporation 698 Koustubh Pawar, CA 699 Carlos Pedrinaci, The Open University 700 Jebastin Prabaharan, Infravio, Inc. 701 Jiyong Pyon, Korean National Computerization Agency 702 Brahmananda Sapkota, Digital Enterprise Research Institute (DERI) 703 Svante Schubert, Sun Microsystems 704 Ron Schuldt, Lockheed Martin 705 Omair Shafiq, Digital Enterprise Research Institute (DERI) 706 Clifford Thompson, Individual Member 707 Walt Truszkowski, NASA 708 Laurentiu Vasiliu, Digital Enterprise Research Institute (DERI) 709 Tomas Vitvar, Digital Enterprise Research Institute (DERI) 710 Alexander Wahler, NIWA-Web Solutions 711 Michal Zaremba (chair), Digital Enterprise Research Institute (DERI) 712 Maciej Zaremba, Digital Enterprise Research Institute (DERI) 76wd-see-semanticsoarm-v0.1-r1 22 May 2006 77Copyright © OASIS Open 2006. All Rights Reserved. Page 26 of 27
    • 713E. Revision History 714[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. 715 79wd-see-semanticsoarm-v0.1-r1 22 May 2006 80Copyright © OASIS Open 2006. All Rights Reserved. Page 27 of 27