Figure 1

561 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
561
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Figure 1

  1. 1. 1 2Reference Model for Semantic Service 3Oriented Architecture 4Working Draft 0.1, 22 May 2006 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 22
  2. 2. 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 22
  3. 3. 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 22
  4. 4. 84Table of Contents 851 Introduction..............................................................................................................................................5 86 1.1 What is a reference model................................................................................................................5 87 1.2 Audience...........................................................................................................................................5 88 1.3 Guide to using the reference model..................................................................................................5 89 1.4 Notation Conventions.......................................................................................................................5 902 Semantic SOA.........................................................................................................................................6 91 2.1 Why Add Semantics to SOA?...........................................................................................................6 92 2.2 The Extra Benefits of SOA with Semantics.......................................................................................6 933 The Reference Model..............................................................................................................................7 94 3.1 Web Service.....................................................................................................................................7 95 3.2 Goal..................................................................................................................................................7 96 3.3 Mediator............................................................................................................................................7 97 3.3.1 WG-Mediator.............................................................................................................................7 98 3.4 Capability..........................................................................................................................................8 99 3.5 Interface............................................................................................................................................8 100 3.5.1 Choreography............................................................................................................................8 101 3.5.2 Orchestration.............................................................................................................................8 102 3.6 …......................................................................................................................................................8 1034 Implementing the SOA-RM specifications – the SEE approach...............................................................9 104 4.1 Service..............................................................................................................................................9 105 4.2 Dynamics of Services.....................................................................................................................10 106 4.2.1 Visibility ..................................................................................................................................10 107 4.2.2 Interacting with services..........................................................................................................10 108 4.3 About services................................................................................................................................11 109 4.3.1 Service description .................................................................................................................11 110 4.3.2 Policies and contracts.............................................................................................................12 111 4.3.3 Execution contexts .................................................................................................................12 1125 Conformance Guidelines.......................................................................................................................13 1136 References............................................................................................................................................14 114 6.1 Normative.......................................................................................................................................14 115 6.2 Non-Normative...............................................................................................................................14 116A. Glossary...............................................................................................................................................15 117B. Notations Used.....................................................................................................................................16 118 Concepts.............................................................................................................................................16 119 Subsumption........................................................................................................................................17 120 Attributes.............................................................................................................................................17 121C. WSML Formalisation of Reference Model............................................................................................19 122D. Acknowledgements..............................................................................................................................20 123E. Revision History....................................................................................................................................22 124 125 10wd-see-semanticsoarm-v0.1-r1 22 May 2006 11Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 22
  5. 5. 1261 Introduction 1271.1 What is a reference model 128The authors direct the reader to section 1.1 of “Reference Model for Service Oriented Architecture, Public 129Review Draft 1.0” where a full description of the purpose of a reference model is described. 1301.2 Audience 131The SOA-RM public review draft describes the audience as non-exhaustively including: 132 • Architects and developers designing, identifying or developing a system based on the service- 133 oriented paradigm. 134 • Standards architects and analysts developing specifications that rely on service oriented 135 architecture concepts. 136 • Decision makers seeking a "consistent and common" understanding of service oriented 137 architectures. 138 • Users who need a better understanding of the concepts and benefits of service oriented 139 architecture. 140 141The audience of this reference model for Semantic SOA covers the same audience, especially in cases 142where the architect, developer, analyst, decision maker or user wishes to perform some form of 143automation within their SOA. As will be described later automation of parts of the SOA usage process is 144only possible if machines can ‘understand’ the services in the SOA and the addition of semantics is the 145proposed mechanism for achieving this. 1461.3 Guide to using the reference model 147We encourage all readers to read this document in its entirety and make the assumption that the reader 148has already read the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” in its 149entirety. 150This section of the document introduces the document, its audience, notation conventions etc. Section 2 151goes on to describe why semantics are needed in a SOA and the purpose of having a reference model. 152Section 3 goes on to describe the reference model as an extension of the work done by the OASIS SOA- 153RM Technical Committee. Finally the document will provide some conformance guidelines and any 154references that may be interesting or useful to the reader. 1551.4 Notation Conventions 156For ease of comparison we use the same notation conventions as the SOA-RM public review draft, 157namely those keywords from RFC2119: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 158SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL. 159 160References are surrounded with [square brackets and are in bold text]. 13wd-see-semanticsoarm-v0.1-r1 22 May 2006 14Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 22
  6. 6. 1612 Semantic SOA 1622.1 Why Add Semantics to SOA? 163This section will outline the “why bother” with respect to adding semantics to SOA’s and the benefits you 164will receive. [Max 2 pages] 1652.2 The Extra Benefits of SOA with Semantics 166This section will extend the “benefits of SOA” section from the SOA-RM document with those added 167benefits received by adding semantics to the reference model. [Max 1 page] 168 16wd-see-semanticsoarm-v0.1-r1 22 May 2006 17Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 22
  7. 7. 1693 The Reference Model 170The basis of the Semantic SOA Reference Model is illustrated in Figure 1. 171 172 173 Figure 1: Reference Model as UML Class Diagram 1743.1 Web Service 175This is comparable with the notion of service in the SOA-RM, but necessarily describes a service which is 176capable of programmatic invocation and access. This notion is common between OWL-S, METEOR-S 177and WSMO… 1783.2 Goal 179A major difference between SOA-RM and the Semantic SOA Reference Model it that we explicitly model 180the intentions of the client to each service. We borrow this notion from WSMO, though it has appeared in 181primitive form in other SWS work, such as in ontologically representation of ‘service templates’ in 182METEOR-S-related work… 1833.3 Mediator 184The Semantic SOA Reference Model will adopt the WSMO principle that any connection made between 185two elements in the model should be represented by a mediator. These allow the specification of several 186types of mediation, which is to say bridging the gap between heterogeneous descriptions and/or 187expectations. Insofar as this requires difference in the representation of data, which we call data 188mediation, this is comparable with the OWL-S-related work on shims, but we aim to reproduce the full 189generality of mediators in WSMO which cover also e.g. protocol mediation. 1903.3.1 WG-Mediator 191A fundamental mediator concerning description of SEE itself describes the mediation between goals and 192web services (and vice versa)… 19wd-see-semanticsoarm-v0.1-r1 22 May 2006 20Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 22
  8. 8. 1933.4 Capability 1943.5 Interface 1953.5.1 Choreography 1963.5.2 Orchestration 1973.6 … 22wd-see-semanticsoarm-v0.1-r1 22 May 2006 23Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 22
  9. 9. 1984 Implementing the SOA-RM specifications – the SEE 199 approach 200In this section we take each of the SOA-RM elements and discuss how are they cover by WSMO (the 201conceptual model of SEE) and by SEE itself. We start with the notion of service, continue with dynamics 202of services and finalized with the actual elements around the concept of service. 203 2044.1 Service 205 206SOA-RM defines the notion of service as follows: “A service is a mechanism to enable access to one or 207more capabilities, where the access is provided using a prescribed interface and is exercised consistent 208with constraints and policies as specified by the service description.” WSMO and SEE main focus is on 209Web services, a type of services that obviously obey the above description. 210Additional to the classical Web services of WSDL description and SOAP-based invocations, WSMO 211provides an extra layer: the semantic description of Web services. Further on, we want to prove that 212exactly these semantic descriptions layered on top of a proper service execution environment, enable 213what we are calling the new generation of SOA architecture, in accord with the OASIS SOA-RM standard 214specifications. 215 216SOA-RM identifies four main aspects regarding the service that have to be considered in SOA: 217 • Enable access to one or more capabilities. In WSMO and SEE services are seen as well as 218 computational entities that enable a requester to gain access and to consume certain 219 functionality. WSMO prescribes that a service should have only one capability – a stronger 220 condition that the one imposed by the SOA-RM. 221 • Access through a prescribed interface. WSMO makes a clear distinction between interface and 222 the capability on one hand, and between the interface and the implementation of the service on 223 the other hand. A WSMO service interface contains all the necessary information one needs to 224 access/invoke the service. 225 • Opaque to the service consumer except from the information and behavior models in the 226 interface and the information required to asses if a service suits the requester needs. In WSMO 227 the above mentioned two-sided separations fully match this requirement. The separation between 228 the implementation ant the interface assures that none of the private business logics or the 229 internal computational/technical details are revealed. By the separation between the interface and 230 the capability WSMO makes sure that it is clearly stated what information needs to be used when 231 finding the suited service (i.e. during the discovery service) and what information is needed after 232 discovery when the service needs to be invoked. In WSMO the interfaces and the capability are 233 semantically described (this description might include also the grounding to the actual 234 implementation of the service, e.g. the WSDL web service). 235 • Consequences of invoking a service should be either response information to the invocation or a 236 change to the shared state of the defined interface. WSMO goes one step further and as part of 237 the capability, it formally describes the conditions to hold on the outputs after the invocation of the 238 service (i.e. conditions) as well as the changes on the outside world (i.e. effects). SEE has the 239 role (during the discovery phase) to check if the post-conditions and the effects match the 240 requester needs. 241It is important to note that because the SEE operates on WSMO services this requirements are fully 242fulfilled. Further more, by use of semantics explicit information about service’s interface and capability is 243given; the semantic descriptions present a significant advantage on the WSDL description (or on the 25wd-see-semanticsoarm-v0.1-r1 22 May 2006 26Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 22
  10. 10. 244service descriptions in an UDDI repository) which are in general less expressive and in most of the cases 245rather ambiguous. 2464.2 Dynamics of Services 247 248SOA-RM also provides guidelines regarding the interactions of the requester with a service. As such, it 249identifies three fundamental concepts related with dynamics of the service: Visibility, Interaction and real 250world effect. In the following subsections we will analyze each of them from the WSMO and SEE 251perspective. 2524.2.1 Visibility 253Visibility in terms of SOA-RM is characterized in terms of Awareness, Willingness and Reachability. 2544.2.1.1 Awareness 255Awareness is state whereby the service requester is aware of the service provider or other way around. It 256is normally achieved by having either the requester or the provider discovering the information the other 257party published in public directory for example. 258WSMO offers support for creating semantic description of services and by this enables the creation of 259intelligent discovery mechanisms. It is the role of SEE to provide the actual discovery services that would 260make use of (semantics-enabled) service repositories. 261WSMO considered so far only one-way discovery: form the requester to the provider. According to 262WSMO, a requester has to formalize its needs in Goal (i.e. a semantic description of its requirements) 263and to submit it to an intelligent discovery engine for resolutions. SEE includes such a discovery service 264able to resolve a Goal and to retrieve all matching services from a given repository (previously the 265semantic descriptions of the services have to be registered in the repository). 2664.2.1.2 Willingness 267Willingness is about the intent to communicate. Even if the discovery process has been successful 268without willingness to communicate from both requester to provider the interaction will fail. 269WSMO does not directly prescribe any mechanisms dealing with this matter. But WMSO assumes that 270both partners would comply to the behaviors described in the interfaces of the Goal and Service, 271respectively, and that any special conditions that have to be fulfilled or actions to be taken in order to 272have a successful conversation are present in the capability’s preconditions. 273Additionally, since one of SEE‘s role is to manage the conversation there could be compensatory 274measures and strategies implemented in case one of the partners is not willing to interact. 2754.2.1.3 Reachability 276In WSMO this aspect is considered to be part of the infrastructure that supports the Semantic Web 277Services and their requesters. 278SEE ha the role of providing such an environment and even if the semantic technologies are used to 279enhance the main operations on services (e.g. discovery, invocation), standards are used as underlying, 280lower level technologies (e.g. SOAP, WSDL, etc.). 2814.2.2 Interacting with services 282“Interacting with a service involves performing actions against the service. In many cases, this is 283accomplished by sending and receiving messages, but there are other modes possible that do not involve 284explicit message transmission.” 28wd-see-semanticsoarm-v0.1-r1 22 May 2006 29Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 22
  11. 11. 2854.2.2.1 Information model 286Conform to SOA-RM the information model of a service is a characterization of the information that may 287be exchanged with a service. The information model includes the format of information that is exchanged, 288the structural relationships within the exchanged information and also the definition of the terms used. 289Additionally, an important fact is the semantics associated by the application to this information model, 290semantics which might vary from on system from another. 291One of the strongest point of WSMO and SEE, and in general of semantic-based systems, is that they 292offer means to unambiguously describe such information models. In WMSO all the elements provided in 293the model are ontology-centric: everything is semantically describes by using ontologies. All the data 294exchanged between partners is structurally and semantically described by ontologies. SEE is a semantic 295environment as well and all the internal messages exchanged by its components and with the requester 296and/or receiver are ontology instances, i.e. semantically described data. In this way the semantic 297engagement is clear and it is the same for the requester and for the provider. 298If, for whatever reason, this semantic engagement does not coincide for the partners that are 299communicating (i.e., they use different information models) mediation system can be used. Such systems 300are able to resolve the heterogeneity problems between different models, using semantic techniques as 301well. 3024.2.2.2 Behavioral model 303The behavior model deals with knowledge of the actions invoked against the service and the process or 304temporal aspects of interacting with the service. It consists of two distinct aspects: the action model and 305the process model. The first one deals with the characterization of actions that can be invoked against the 306service, while the second deals with the temporal relationships of actions and events associated when 307interacting with a service. 308The action model is captured in WMSO by the capability of the service, in the assumptions, preconditions, 309post-conditions and the effects of the service. They specify exactly what conditions need to hold before 310invoking the service and what conditions need to hold after the invocation of the service (both in 311information space and in the real world). 312The process model is captured by the interface of a WSMO service, especially in the choreography. It 313describes in details what re the expected messages and what is going to be delivered in a certain point of 314the conversation. 315It is important to note that both the capability and interface of a service are augmented with semantics: all 316the notions and concepts used to define them are entities from the ontologies with a precise semantics. 3174.2.2.3 Real world effect 318WSMO allows to model in capability of the service (as described in the previous section) what are the 319effects of the service execution in the real world. 320 3214.3 About services 322“In support of the dynamics of interacting with services are a set of concepts that are about services 323themselves. These are the service description, the execution context of the service and the contracts and 324policies that relate to services and service participants.” 3254.3.1 Service description 326“The service description represents the information needed in order to use a service.” 327In WSMO, service descriptions represent a core element in defining Semantic Web Services. Semantic 328descriptions are associated to all resources, thus services as well. The semantic descriptions are 329grounded to concrete service realizations, such as once the semantic description is known the 330implementation of the service can be found as well. 31wd-see-semanticsoarm-v0.1-r1 22 May 2006 32Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 22
  12. 12. 331 332It is important to know that WSMO allows for both functional and non-functional descriptions of the 333service. While the functional descriptions are formal definitions expressed in terms of ontologies, the non- 334functional properties are extension of the Dublin Core, and might contain human-readable descriptions as 335well. 3364.3.1.1 Service Reachability 337“…a service description SHOULD include sufficient data to enable a service consumer and service 338provider to interact with each other.” 339In WSMO the reachability information is captured by grounding which has to role of bridging the semantic 340descriptions with the technical implementation of the service. SEE implements such grounding both for 341the data as well as for the behavior related descriptions. 3424.3.1.2 Service Functionality 343As mentioned before, WSMO provides the means to describe the service’s functionality. Every WSMO 344service’s description has a capability definition, which consists of preconditions, assumptions, 345postconditions and effects. All this elements are formal definitions referring to terms defined in ontologies. 3464.3.1.3 Policies Related to a Service 347WSMO latest specifications does not currently offer any support for Policies and Contract. However, there 348is ongoing work to align WSMO with existing Web service specifications. 3494.3.1.4 Service Interface 350As mentioned above, in WSMO the interfaces have distinctive place in the service description. WSMO 351service interface has two main parts: the choreography and orchestration. The first prescribes how a 352requester can interact with the service while the second describes how the service functionality is 353achieved by composing other services functionality. 3544.3.2 Policies and contracts 355WSMO latest specifications does not currently offer any support for Policies and Contract. However, there 356is ongoing work to align WSMO with existing Web service specifications. 3574.3.3 Execution contexts 358“The execution context of a service interaction is the set of infrastructure elements, process entities, 359policy assertions and agreements that are identified as part of an instantiated service interaction, and 360thus forms a path between those with needs and those with capabilities.” 361WSMO, as conceptual model, does not define how the path between the requester and the provider 362should be established, or what infrastructure elements should be used. It just creates the artifacts for the 363requestors and the providers to formalize their needs and to describe their capabilities (Goals and 364Services descriptions), respectively. 365It is the role of SEE to tackle this aspect, to manage the requester-provider interactions. The conversation 366between the two parties takes place as specified in the interfaces (i.e. choreography and orchestration). 367Multiple conversations can be managed as well, as well as multiple interactions of the same service 368(several service instances). By grounding, the semantic-based methodologies are used in conjunction 369with the technological/infrastructural components. 370Depending on each particular execution contexts, special operations, such as mediation can take place. 371Since for a particular conversation, a common semantics has to associated to the information and 372behaviors model, different mediation techniques might be employed (at data, process or protocol level). 373 34wd-see-semanticsoarm-v0.1-r1 22 May 2006 35Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 22
  13. 13. 3745 Conformance Guidelines 375Here we will specify the guidelines under which third parties can define they are conformant with the 376semantic SOA reference model. [Max 1 page] 37wd-see-semanticsoarm-v0.1-r1 22 May 2006 38Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 22
  14. 14. 3776 References 3786.1 Normative 379Normative references go here 3806.2 Non-Normative 381Non-Normative references go here 40wd-see-semanticsoarm-v0.1-r1 22 May 2006 41Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 22
  15. 15. 382A. Glossary 383This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for 384Service Oriented Architecture, Public Review Draft 1.0” and introduces any new terms needed by the 385Semantic SOA Reference. The two glossaries are intended to be used together, therefore terms from the 386other glossary will not be repeated here. 387 388A 389 A’s Definition 390 391B 392 B’s Definition 43wd-see-semanticsoarm-v0.1-r1 22 May 2006 44Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 22
  16. 16. 393B. Notations Used 394Within the body text of this document we use UML Class Diagrams to illustrate the model. The formal 395definitions, however, are made in WSML. This is for two reasons: first, we must use a language with well- 396founded semantics, capable of machine reasoning – the general motivation of work in the Semantic Web, 397which has produced several ontology languages; secondly we need a language that allows us to attach 398elements of this model to SWS elements, including goals, and WSML is the only language that allows 399this. 400Specifically, this document sticks to the ontology definition facilities of WSML. The Reference 401Architecture will attach Reference Model concepts to goal descriptions to allow the characterization of the 402components of a Semantic Execution Environment. The Execution Scenarios will attach Reference 403Model concepts, and Reference Architecture goals, to service descriptions to illustrate how the SEE 404components can work together to achieve common tasks. Finally, concrete architectures may be defined 405by linking concrete services to the goals from the Reference Architecture. 406In the remainder of this section we sketch the relationship between UML Class Diagrams, as used within 407the text, to WSML descriptions. In the following section we reproduce these definitions. 408 Concepts 409The fundamental feature of Class Diagrams – and indeed Object-oriented design (OOD), which is the real 410target of UML – are classes, which are shown as square boxes with their identifier listed inside. We use 411UML classes to represent WSML concepts. Where the namespace into which concepts are defined is 412clear, we allow ourselves to omit this information in the Class Diagram. Where different namespaces are 413used, we use the notation for packages to make the namespace clear. 414Figure 2 hence corresponds with Listing 1. 415 416 concept a 417 418 concept _”http://www.example.com/ontologies/ns1#b” 419 Listing 1: Example Concepts in WSML 420 421 422 Figure 2: Representation of WSML Example Concepts in UML Class Diagram 423 424While UML Class Diagrams allow the definition of operations and attributes within classes, we choose not 425to use these and always show classes with an undivided box. Regarding the representation of attributes 426of WSML concepts, see below. 46wd-see-semanticsoarm-v0.1-r1 22 May 2006 47Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 22
  17. 17. 427 Subsumption 428The fundamental relationship between concepts in WSML is subsumption. This is represented by 429inheritance in UML Class Diagrams. Since we declare no operations there are no unwanted side-effects 430due to UML/OOD semantics; in particular there are no complications to the use of multiple parents to a 431given concept. 432Figure 3 hence corresponds with Listing 1. 433 434 concept a 435 436 concept b subConceptOf a 437 438 concept c 439 440 concept d subConceptOf {a, c} 441 Listing 2: Example of Subsumption between Concepts in WSML 442 443 444 Figure 3: Representation of Subsumption Example in UML Class Diagram 445 Attributes 446The other explicit relationship between concepts in WSML is via attributes. These are represented by 447(directed) associations in UML Class Diagrams, which is to say associations with a one-way navigability, 448so that the innavigable side of the association (or, more correctly, the end of unspecified navigability) is 449the concept whose definition includes the attribute, and the other side the attribute range. The name of 450the association will be the name of the attribute; where the attribute name is the default ‘hasA’, where ‘a’ 451is the name of the concept that is the attribute range, we shall often omit this. Cardinality constraints are 452represented, where possible, by a constraint on the association. 453The difficult case is where disjunctive attribute ranges are used; here we use two associations with the 454same name, which causes problems in the UML semantics, but this is due to the difference in expressivity 455between UML/OOD and ontology languages (in OOD it is assumed that these types of polymorphic 456references will be made using inclusion polymorphism, i.e. via a common superclass, which is not a 457requirement in most ontology languages). This also causes problems for the representation of cardinality 458Figure 4 hence corresponds with Listing 3. 459 460 concept a 461 462 concept b 463 hasA ofType (0, 1) a 464 465 concept c 466 49wd-see-semanticsoarm-v0.1-r1 22 May 2006 50Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 22
  18. 18. 467 concept d 468 att1 ofType {a, c} 469 Listing 3: Example of Attributes between WSML Concepts 470 471 472 Figure 4: Representation of Attributes Example in UML Class Diagram 473 474Disjunctive attribute ranges also cause problems with cardinality constraints; consider the representation 475of ‘concept d att1 ofType(1) {a, c}’, which requires the use of a non-graphical constraint 476language, such as OCL, in UML. 52wd-see-semanticsoarm-v0.1-r1 22 May 2006 53Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 22
  19. 19. 477C. WSML Formalisation of Reference Model 478 wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight” 479 480 namespace {_”http:// http://www.oasis- 481 open.org/apps/org/workgroup/semantic-ex/SemanticSOARM#”} 482 483 ontology _”http:// http://www.oasis- 484 open.org/apps/org/workgroup/semantic-ex/SemanticSOARM#” 485 486 concept webService 487 hasCapability ofType (0, 1) capability 488 hasInterface ofType interface 489 490 concept goal 491 hasCapability ofType (0, 1) capability 492 hasInterface ofType interface 493 494 concept capability 495 496 concept interface 497 hasChoreography ofType (0, 1) choreography 498 hasOrchestration ofType (0, 1) orchestration 499 500 concept choreography 501 502 concept orchestration 503 504 concept mediator 505 hasMediationService ofType (0, 1) {webService, goal} 506 507 concept wgMediator subConceptOf mediator 508 source ofType (1) {webService, goal} 509 target ofType (1) {webService, goal} 510 Listing 4: Semantic SOA Reference Model in WSML 55wd-see-semanticsoarm-v0.1-r1 22 May 2006 56Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 22
  20. 20. 511D. Acknowledgements 512The following individuals were members of the committee during the development of this specification and 513are gratefully acknowledged: 514Participants: 515 Marc Adlam, Oracle Corporation 516 Zachary Alexander, Individual Member 517 Michael Altenhofen, SAP AG 518 Anuprlya Ankolekar, Institute of Applied Informatics and Formal Description Methods (AIFB) 519 Tim Banks, IBM 520 Charlton Barreto, Adobe Systems 521 David Brock, MW2 Consulting 522 Dario Cerizza, CEFRIEL 523 Joseph Chiusano, Booz Allen Hamilton 524 Emilia Cimpian, Digital Enterprise Research Institute (DERI) 525 David Cunningham, Booz Allen Hamilton 526 Emanuele Della Valle, CEFRIEL 527 Paul Denning, Mitre Corporation 528 Marin Dimitrov, Ontotext Lab/Sirma Group 529 John Domingue (chair), The Open University 530 Elmar Dorner, SAP AG 531 Matthew Dovey, Oxford University 532 Mike Evanoff, ManTech Enterprise Integration Center (e-IC) 533 Dieter Fensel, Digital Enterprise Research Institute (DERI) 534 Sri Gopalan, Booz Allen Hamilton 535 Peter Gratzer, Sun Microsystems 536 Stephen Green, Individual Member 537 Marc Haines, Individual Member 538 Thomas Haselwanter, Digital Enterprise Research Institute (DERI) 539 Graham Hench, Digital Enterprise Research Institute (DERI) 540 Hyun Jung, Korean National Computerization Agency 541 Mick Kerrigan (secretary), Digital Enterprise Research Institute (DERI) 542 Eunju Kim, Korean National Computerization Agency 543 Hong-Gee Kim, Digital Enterprise Research Institute (DERI) 544 Paavo Kotinurmi, Digital Enterprise Research Institute (DERI) 545 Ho Kyoung Lee, Korean National Computerization Agency 546 Jean-Luc LEVESQUE, EdiEyes 547 Sandeep Maripuri, Booz Allen Hamilton 548 Monica Martin, Sun Microsystems 549 Tom Michaud, Software AG, Inc. 550 Dugki Min, Individual Member 58wd-see-semanticsoarm-v0.1-r1 22 May 2006 59Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 22
  21. 21. 551 Adrian Mocan, Digital Enterprise Research Institute (DERI) 552 Matthew Moran, Digital Enterprise Research Institute (DERI) 553 Barry Norton, The Open University 554 Srinivas Padmanabhuni, Infosys Technologies 555 Yuanying Pan, Changfeng Open Standards Platform Software Alliance 556 Ash Parikh, Raining Data Corporation 557 Koustubh Pawar, CA 558 Carlos Pedrinaci, The Open University 559 Jebastin Prabaharan, Infravio, Inc. 560 Jiyong Pyon, Korean National Computerization Agency 561 Brahmananda Sapkota, Digital Enterprise Research Institute (DERI) 562 Svante Schubert, Sun Microsystems 563 Ron Schuldt, Lockheed Martin 564 Omair Shafiq, Digital Enterprise Research Institute (DERI) 565 Clifford Thompson, Individual Member 566 Walt Truszkowski, NASA 567 Laurentiu Vasiliu, Digital Enterprise Research Institute (DERI) 568 Tomas Vitvar, Digital Enterprise Research Institute (DERI) 569 Alexander Wahler, NIWA-Web Solutions 570 Michal Zaremba (chair), Digital Enterprise Research Institute (DERI) 571 Maciej Zaremba, Digital Enterprise Research Institute (DERI) 61wd-see-semanticsoarm-v0.1-r1 22 May 2006 62Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 22
  22. 22. 572E. Revision History 573[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 574 64wd-see-semanticsoarm-v0.1-r1 22 May 2006 65Copyright © OASIS Open 2006. All Rights Reserved. Page 22 of 22

×