figure 1
Post on 27-May-2015
414 Views
Preview:
TRANSCRIPT
Reference Model for Semantic Service Oriented Architecture
Working Draft 0.1, 22 May 2006
Artifact Identifier:wd-see-semanticsoarm-v0.1-r1
Location:Current: docs.oasis-open.org/ex-semantics/sematicsoarm/latestThis Version: docs.oasis-open.org/ex-semantics/sematicsoarm/0.1Previous Version: docs.oasis-open.org/ex-semantics/sematicsoarm/0.1
Artifact Type:semanticsoarm
Technical Committee:OASIS SEE TC
Chair(s):John Domingue, Open University, <j.b.domingue@open.ac.uk>Michal Zaremba, DERI, <michal.zaremba@deri.org>
Editor(s):Barry Norton, Open University, b.j.norton@open.ac.ukAdrian Mocan, DERI, adrian.mocan@deri.org
OASIS Conceptual Model topic area:SOA
Related work:This specification depends upon and extends:
Reference Model for Service Oriented Architecture, Public Review Draft 1.0, 10 Feb 2006This specification provides the basis for:
Semantic Web Services Architecture and Information Model SEE Execution Semantics
Abstract:This reference model extends the work done in the OASIS SOA-RM technical committee, defining a reference model for Service Oriented Architecture, by adding the concept of semantics. It should be noted that it is assumed that the reader has already read and is familiar with the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0”. The aim of this reference model is to provide justifications for the need for semantics in Service Oriented Architecture and to show where semantics can be applied in the SOA-RM and the benefits such an application gives.
Status:This document is currently a working draft and will be update as necessary to bring it up to public review draft status in the coming weeks/months. Please send all comments to the editors.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/semantic-ex.
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 21
1
2
3
4
56
78910
1112
1314
151617
181920
2122
2324
25262728
2930313233343536
373839
40414243
12
3
Notices
Copyright © OASIS Open 2006. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 2 of 21
44
45
4647
4849505152535455
5657
5859606162
6364656667
6869707172
7374757677787980818283
45
6
Table of Contents
1 Introduction......................................................................................................................................... 4
1.1 What is a reference model................................................................................................................. 4
1.2 Audience........................................................................................................................................... 4
1.3 Guide to using the reference model..................................................................................................4
1.4 Notation Conventions........................................................................................................................ 4
2 Semantic SOA..................................................................................................................................... 5
2.1 Why Add Semantics to SOA?............................................................................................................5
2.2 The Extra Benefits of SOA with Semantics.......................................................................................5
3 The Reference Model.......................................................................................................................... 6
3.1 Web Service...................................................................................................................................... 6
3.2 Goal................................................................................................................................................... 6
3.3 Mediator............................................................................................................................................ 6
3.3.1 WG-Mediator.............................................................................................................................. 6
3.4 Capability........................................................................................................................................... 7
3.5 Interface............................................................................................................................................ 7
3.5.1 Choreography............................................................................................................................ 7
3.5.2 Orchestration.............................................................................................................................. 7
3.6 …....................................................................................................................................................... 7
4 Implementing the SOA-RM specifications – the SEE approach..........................................................8
4.1 Service.............................................................................................................................................. 8
4.2 Dynamics of Services........................................................................................................................ 9
4.2.1 Visibility...................................................................................................................................... 9
4.2.2 Interacting with services.............................................................................................................9
4.3 About services................................................................................................................................. 10
4.3.1 Service description...................................................................................................................10
4.3.2 Policies and contracts..............................................................................................................11
4.3.3 Execution contexts................................................................................................................... 11
5 Conformance Guidelines...................................................................................................................12
6 References........................................................................................................................................ 13
6.1 Normative........................................................................................................................................ 13
6.2 Non-Normative................................................................................................................................ 13
A. Glossary............................................................................................................................................ 14
B. Notations Used.................................................................................................................................. 15
Concepts............................................................................................................................................... 15
Subsumption......................................................................................................................................... 16
Attributes............................................................................................................................................... 16
C. WSML Formalisation of Reference Model.........................................................................................18
D. Acknowledgements........................................................................................................................... 19
E. Revision History................................................................................................................................ 21
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 3 of 21
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
78
9
1 Introduction
1.1 What is a reference modelThe authors direct the reader to section 1.1 of “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” where a full description of the purpose of a reference model is described.
1.2 AudienceThe SOA-RM public review draft describes the audience as non-exhaustively including:
Architects and developers designing, identifying or developing a system based on the service-oriented paradigm.
Standards architects and analysts developing specifications that rely on service oriented architecture concepts.
Decision makers seeking a "consistent and common" understanding of service oriented architectures.
Users who need a better understanding of the concepts and benefits of service oriented architecture.
The audience of this reference model for Semantic SOA covers the same audience, especially in cases where the architect, developer, analyst, decision maker or user wishes to perform some form of automation within their SOA. As will be described later automation of parts of the SOA usage process is only possible if machines can ‘understand’ the services in the SOA and the addition of semantics is the proposed mechanism for achieving this.
1.3 Guide to using the reference modelWe encourage all readers to read this document in its entirety and make the assumption that the reader has already read the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” in its entirety.
This section of the document introduces the document, its audience, notation conventions etc. Section 2 goes on to describe why semantics are needed in a SOA and the purpose of having a reference model. Section 3 goes on to describe the reference model as an extension of the work done by the OASIS SOA-RM Technical Committee. Finally the document will provide some conformance guidelines and any references that may be interesting or useful to the reader.
1.4 Notation ConventionsFor ease of comparison we use the same notation conventions as the SOA-RM public review draft, namely those keywords from RFC2119: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL.
References are surrounded with [square brackets and are in bold text].
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 21
126
127
128129
130
131132133134135136137138139
140141142143144145
146
147148149
150151152153154
155
156157158159160
1011
12
2 Semantic SOA
2.1 Why Add Semantics to SOA?This section will outline the “why bother” with respect to adding semantics to SOA’s and the benefits you will receive. [Max 2 pages]
2.2 The Extra Benefits of SOA with SemanticsThis section will extend the “benefits of SOA” section from the SOA-RM document with those added benefits received by adding semantics to the reference model. [Max 1 page]
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 21
161
162
163164
165
166167
168
1314
15
3 The Reference ModelThe basis of the Semantic SOA Reference Model is illustrated in Figure 1.
Figure 1: Reference Model as UML Class Diagram
3.1 Web ServiceThis is comparable with the notion of service in the SOA-RM, but necessarily describes a service which is capable of programmatic invocation and access. This notion is common between OWL-S, METEOR-S and WSMO…
3.2 GoalA major difference between SOA-RM and the Semantic SOA Reference Model it that we explicitly model the intentions of the client to each service. We borrow this notion from WSMO, though it has appeared in primitive form in other SWS work, such as in ontologically representation of ‘service templates’ in METEOR-S-related work…
3.3 MediatorThe Semantic SOA Reference Model will adopt the WSMO principle that any connection made between two elements in the model should be represented by a mediator. These allow the specification of several types of mediation, which is to say bridging the gap between heterogeneous descriptions and/or expectations. Insofar as this requires difference in the representation of data, which we call data mediation, this is comparable with the OWL-S-related work on shims, but we aim to reproduce the full generality of mediators in WSMO which cover also e.g. protocol mediation.
3.3.1 WG-Mediator
A fundamental mediator concerning description of SEE itself describes the mediation between goals and web services (and vice versa)…
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 21
169
170
171
172173
174
175176177
178
179180181182
183
184185186187188189
190
191192
1617
18
3.4 Capability
3.5 Interface
3.5.1 Choreography
3.5.2 Orchestration
3.6 …
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 21
193
194
195
196
197
1920
21
4 Implementing the SOA-RM specifications – the SEE approach
In this section we take each of the SOA-RM elements and discuss how are they cover by WSMO (the conceptual model of SEE) and by SEE itself. We start with the notion of service, continue with dynamics of services and finalized with the actual elements around the concept of service.
4.1 Service
SOA-RM defines the notion of service as follows: “A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” WSMO and SEE main focus is on Web services, a type of services that obviously obey the above description.
Additional to the classical Web services of WSDL description and SOAP-based invocations, WSMO provides an extra layer: the semantic description of Web services. Further on, we want to prove that exactly these semantic descriptions layered on top of a proper service execution environment, enable what we are calling the new generation of SOA architecture, in accord with the OASIS SOA-RM standard specifications.
SOA-RM identifies four main aspects regarding the service that have to be considered in SOA:
Enable access to one or more capabilities. In WSMO and SEE services are seen as well as computational entities that enable a requester to gain access and to consume certain functionality. WSMO prescribes that a service should have only one capability – a stronger condition that the one imposed by the SOA-RM.
Access through a prescribed interface. WSMO makes a clear distinction between interface and the capability on one hand, and between the interface and the implementation of the service on the other hand. A WSMO service interface contains all the necessary information one needs to access/invoke the service.
Opaque to the service consumer except from the information and behavior models in the interface and the information required to asses if a service suits the requester needs. In WSMO the above mentioned two-sided separations fully match this requirement. The separation between the implementation ant the interface assures that none of the private business logics or the internal computational/technical details are revealed. By the separation between the interface and the capability WSMO makes sure that it is clearly stated what information needs to be used when finding the suited service (i.e. during the discovery service) and what information is needed after discovery when the service needs to be invoked. In WSMO the interfaces and the capability are semantically described (this description might include also the grounding to the actual implementation of the service, e.g. the WSDL web service).
Consequences of invoking a service should be either response information to the invocation or a change to the shared state of the defined interface. WSMO goes one step further and as part of the capability, it formally describes the conditions to hold on the outputs after the invocation of the service (i.e. conditions) as well as the changes on the outside world (i.e. effects). SEE has the role (during the discovery phase) to check if the post-conditions and the effects match the requester needs.
It is important to note that because the SEE operates on WSMO services this requirements are fully fulfilled. Further more, by use of semantics explicit information about service’s interface and capability is given; the semantic descriptions present a significant advantage on the WSDL description (or on the
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 21
198
199
200201202
203
204
205
206207208209
210211212213214
215
216
217218219220221222223224225226227228229230231232233234235236237238239240
241242243
2223
24
service descriptions in an UDDI repository) which are in general less expressive and in most of the cases rather ambiguous.
4.2 Dynamics of Services
SOA-RM also provides guidelines regarding the interactions of the requester with a service. As such, it identifies three fundamental concepts related with dynamics of the service: Visibility, Interaction and real world effect. In the following subsections we will analyze each of them from the WSMO and SEE perspective.
4.2.1 Visibility
Visibility in terms of SOA-RM is characterized in terms of Awareness, Willingness and Reachability.
4.2.1.1 Awareness
Awareness is state whereby the service requester is aware of the service provider or other way around. It is normally achieved by having either the requester or the provider discovering the information the other party published in public directory for example.
WSMO offers support for creating semantic description of services and by this enables the creation of intelligent discovery mechanisms. It is the role of SEE to provide the actual discovery services that would make use of (semantics-enabled) service repositories.
WSMO considered so far only one-way discovery: form the requester to the provider. According to WSMO, a requester has to formalize its needs in Goal (i.e. a semantic description of its requirements) and to submit it to an intelligent discovery engine for resolutions. SEE includes such a discovery service able to resolve a Goal and to retrieve all matching services from a given repository (previously the semantic descriptions of the services have to be registered in the repository).
4.2.1.2 Willingness
Willingness is about the intent to communicate. Even if the discovery process has been successful without willingness to communicate from both requester to provider the interaction will fail.
WSMO does not directly prescribe any mechanisms dealing with this matter. But WMSO assumes that both partners would comply to the behaviors described in the interfaces of the Goal and Service, respectively, and that any special conditions that have to be fulfilled or actions to be taken in order to have a successful conversation are present in the capability’s preconditions.
Additionally, since one of SEE‘s role is to manage the conversation there could be compensatory measures and strategies implemented in case one of the partners is not willing to interact.
4.2.1.3 Reachability
In WSMO this aspect is considered to be part of the infrastructure that supports the Semantic Web Services and their requesters.
SEE ha the role of providing such an environment and even if the semantic technologies are used to enhance the main operations on services (e.g. discovery, invocation), standards are used as underlying, lower level technologies (e.g. SOAP, WSDL, etc.).
4.2.2 Interacting with services
“Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission.”
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 21
244245
246
247
248249250251
252
253
254
255256257
258259260
261262263264265
266
267268
269270271272
273274
275
276277
278279280
281
282283284
2526
27
4.2.2.1 Information model
Conform to SOA-RM the information model of a service is a characterization of the information that may be exchanged with a service. The information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of the terms used. Additionally, an important fact is the semantics associated by the application to this information model, semantics which might vary from on system from another.
One of the strongest point of WSMO and SEE, and in general of semantic-based systems, is that they offer means to unambiguously describe such information models. In WMSO all the elements provided in the model are ontology-centric: everything is semantically describes by using ontologies. All the data exchanged between partners is structurally and semantically described by ontologies. SEE is a semantic environment as well and all the internal messages exchanged by its components and with the requester and/or receiver are ontology instances, i.e. semantically described data. In this way the semantic engagement is clear and it is the same for the requester and for the provider.
If, for whatever reason, this semantic engagement does not coincide for the partners that are communicating (i.e., they use different information models) mediation system can be used. Such systems are able to resolve the heterogeneity problems between different models, using semantic techniques as well.
4.2.2.2 Behavioral model
The behavior model deals with knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service. It consists of two distinct aspects: the action model and the process model. The first one deals with the characterization of actions that can be invoked against the service, while the second deals with the temporal relationships of actions and events associated when interacting with a service.
The action model is captured in WMSO by the capability of the service, in the assumptions, preconditions, post-conditions and the effects of the service. They specify exactly what conditions need to hold before invoking the service and what conditions need to hold after the invocation of the service (both in information space and in the real world).
The process model is captured by the interface of a WSMO service, especially in the choreography. It describes in details what re the expected messages and what is going to be delivered in a certain point of the conversation.
It is important to note that both the capability and interface of a service are augmented with semantics: all the notions and concepts used to define them are entities from the ontologies with a precise semantics.
4.2.2.3 Real world effect
WSMO allows to model in capability of the service (as described in the previous section) what are the effects of the service execution in the real world.
4.3 About services“In support of the dynamics of interacting with services are a set of concepts that are about services themselves. These are the service description, the execution context of the service and the contracts and policies that relate to services and service participants.”
4.3.1 Service description
“The service description represents the information needed in order to use a service.”
In WSMO, service descriptions represent a core element in defining Semantic Web Services. Semantic descriptions are associated to all resources, thus services as well. The semantic descriptions are grounded to concrete service realizations, such as once the semantic description is known the implementation of the service can be found as well. wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 21
285
286287288289290
291292293294295296297
298299300301
302
303304305306307
308309310311
312313314
315316
317
318319
320
321
322323324
325
326
327328329330
2829
30
It is important to know that WSMO allows for both functional and non-functional descriptions of the service. While the functional descriptions are formal definitions expressed in terms of ontologies, the non-functional properties are extension of the Dublin Core, and might contain human-readable descriptions as well.
4.3.1.1 Service Reachability
“…a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other.”
In WSMO the reachability information is captured by grounding which has to role of bridging the semantic descriptions with the technical implementation of the service. SEE implements such grounding both for the data as well as for the behavior related descriptions.
4.3.1.2 Service Functionality
As mentioned before, WSMO provides the means to describe the service’s functionality. Every WSMO service’s description has a capability definition, which consists of preconditions, assumptions, postconditions and effects. All this elements are formal definitions referring to terms defined in ontologies.
4.3.1.3 Policies Related to a Service
WSMO latest specifications does not currently offer any support for Policies and Contract. However, there is ongoing work to align WSMO with existing Web service specifications.
4.3.1.4 Service Interface
As mentioned above, in WSMO the interfaces have distinctive place in the service description. WSMO service interface has two main parts: the choreography and orchestration. The first prescribes how a requester can interact with the service while the second describes how the service functionality is achieved by composing other services functionality.
4.3.2 Policies and contracts
WSMO latest specifications does not currently offer any support for Policies and Contract. However, there is ongoing work to align WSMO with existing Web service specifications.
4.3.3 Execution contexts
“The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.”
WSMO, as conceptual model, does not define how the path between the requester and the provider should be established, or what infrastructure elements should be used. It just creates the artifacts for the requestors and the providers to formalize their needs and to describe their capabilities (Goals and Services descriptions), respectively.
It is the role of SEE to tackle this aspect, to manage the requester-provider interactions. The conversation between the two parties takes place as specified in the interfaces (i.e. choreography and orchestration). Multiple conversations can be managed as well, as well as multiple interactions of the same service (several service instances). By grounding, the semantic-based methodologies are used in conjunction with the technological/infrastructural components.
Depending on each particular execution contexts, special operations, such as mediation can take place. Since for a particular conversation, a common semantics has to associated to the information and behaviors model, different mediation techniques might be employed (at data, process or protocol level).
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 21
331
332333334335
336
337338
339340341
342
343344345
346
347348
349
350351352353
354
355356
357
358359360
361362363364
365366367368369
370371372
373
3132
33
5 Conformance GuidelinesHere we will specify the guidelines under which third parties can define they are conformant with the semantic SOA reference model. [Max 1 page]
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 21
374
375376
3435
36
6 References
6.1 NormativeNormative references go here
6.2 Non-NormativeNon-Normative references go here
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 21
377
378
379
380
381
3738
39
A. Glossary
This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for Service Oriented Architecture, Public Review Draft 1.0” and introduces any new terms needed by the Semantic SOA Reference. The two glossaries are intended to be used together, therefore terms from the other glossary will not be repeated here.
A
A’s Definition
B
B’s Definition
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 21
382
383384385386
387
388
389
390
391
392
4041
42
B. Notations Used
Within the body text of this document we use UML Class Diagrams to illustrate the model. The formal definitions, however, are made in WSML. This is for two reasons: first, we must use a language with well-founded semantics, capable of machine reasoning – the general motivation of work in the Semantic Web, which has produced several ontology languages; secondly we need a language that allows us to attach elements of this model to SWS elements, including goals, and WSML is the only language that allows this.
Specifically, this document sticks to the ontology definition facilities of WSML. The Reference Architecture will attach Reference Model concepts to goal descriptions to allow the characterization of the components of a Semantic Execution Environment. The Execution Scenarios will attach Reference Model concepts, and Reference Architecture goals, to service descriptions to illustrate how the SEE components can work together to achieve common tasks. Finally, concrete architectures may be defined by linking concrete services to the goals from the Reference Architecture.
In the remainder of this section we sketch the relationship between UML Class Diagrams, as used within the text, to WSML descriptions. In the following section we reproduce these definitions.
ConceptsThe fundamental feature of Class Diagrams – and indeed Object-oriented design (OOD), which is the real target of UML – are classes, which are shown as square boxes with their identifier listed inside. We use UML classes to represent WSML concepts. Where the namespace into which concepts are defined is clear, we allow ourselves to omit this information in the Class Diagram. Where different namespaces are used, we use the notation for packages to make the namespace clear.
Figure 2 hence corresponds with Listing 1.
concept a
concept _”http://www.example.com/ontologies/ns1#b”
Listing 1: Example Concepts in WSML
Figure 2: Representation of WSML Example Concepts in UML Class Diagram
While UML Class Diagrams allow the definition of operations and attributes within classes, we choose not to use these and always show classes with an undivided box. Regarding the representation of attributes of WSML concepts, see below.
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 21
393
394395396397398399
400401402403404405
406407
408
409410411412413
414
415
416417418
419
420
421422
423
424425426
4344
45
SubsumptionThe fundamental relationship between concepts in WSML is subsumption. This is represented by inheritance in UML Class Diagrams. Since we declare no operations there are no unwanted side-effects due to UML/OOD semantics; in particular there are no complications to the use of multiple parents to a given concept.
Figure 3 hence corresponds with Listing 1.
concept a
concept b subConceptOf a
concept c
concept d subConceptOf {a, c}
Listing 2: Example of Subsumption between Concepts in WSML
Figure 3: Representation of Subsumption Example in UML Class Diagram
AttributesThe other explicit relationship between concepts in WSML is via attributes. These are represented by (directed) associations in UML Class Diagrams, which is to say associations with a one-way navigability, so that the innavigable side of the association (or, more correctly, the end of unspecified navigability) is the concept whose definition includes the attribute, and the other side the attribute range. The name of the association will be the name of the attribute; where the attribute name is the default ‘hasA’, where ‘a’ is the name of the concept that is the attribute range, we shall often omit this. Cardinality constraints are represented, where possible, by a constraint on the association.
The difficult case is where disjunctive attribute ranges are used; here we use two associations with the same name, which causes problems in the UML semantics, but this is due to the difference in expressivity between UML/OOD and ontology languages (in OOD it is assumed that these types of polymorphic references will be made using inclusion polymorphism, i.e. via a common superclass, which is not a requirement in most ontology languages). This also causes problems for the representation of cardinality
Figure 4 hence corresponds with Listing 3.
concept a
concept bhasA ofType (0, 1) a
concept c
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 21
427
428429430431
432
433
434435436437438439440
441
442
443444
445
446447448449450451452
453454455456457
458
459
460461462463464465466
4647
48
concept datt1 ofType {a, c}
Listing 3: Example of Attributes between WSML Concepts
Figure 4: Representation of Attributes Example in UML Class Diagram
Disjunctive attribute ranges also cause problems with cardinality constraints; consider the representation of ‘concept d att1 ofType(1) {a, c}’, which requires the use of a non-graphical constraint language, such as OCL, in UML.
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 21
467468
469
470
471472
473
474475476
4950
51
C. WSML Formalisation of Reference Model
wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight”
namespace {_”http:// http://www.oasis-open.org/apps/org/workgroup/semantic-ex/SemanticSOARM#”}
ontology _”http:// http://www.oasis-open.org/apps/org/workgroup/semantic-ex/SemanticSOARM#”
concept webServicehasCapability ofType (0, 1) capabilityhasInterface ofType interface
concept goal hasCapability ofType (0, 1) capability hasInterface ofType interface
concept capability
concept interfacehasChoreography ofType (0, 1) choreographyhasOrchestration ofType (0, 1) orchestration
concept choreography
concept orchestration
concept mediatorhasMediationService ofType (0, 1) {webService, goal}
concept wgMediator subConceptOf mediatorsource ofType (1) {webService, goal}target ofType (1) {webService, goal}
Listing 4: Semantic SOA Reference Model in WSML
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 21
477
478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511
512
5253
54
D. Acknowledgements
The following individuals were members of the committee during the development of this specification and are gratefully acknowledged:
Participants:Marc Adlam, Oracle CorporationZachary Alexander, Individual MemberMichael Altenhofen, SAP AGAnuprlya Ankolekar, Institute of Applied Informatics and Formal Description Methods (AIFB)Tim Banks, IBMCharlton Barreto, Adobe SystemsDavid Brock, MW2 ConsultingDario Cerizza, CEFRIELJoseph Chiusano, Booz Allen HamiltonEmilia Cimpian, Digital Enterprise Research Institute (DERI)David Cunningham, Booz Allen HamiltonEmanuele Della Valle, CEFRIELPaul Denning, Mitre CorporationMarin Dimitrov, Ontotext Lab/Sirma GroupJohn Domingue (chair), The Open UniversityElmar Dorner, SAP AGMatthew Dovey, Oxford UniversityMike Evanoff, ManTech Enterprise Integration Center (e-IC)Dieter Fensel, Digital Enterprise Research Institute (DERI)Sri Gopalan, Booz Allen HamiltonPeter Gratzer, Sun MicrosystemsStephen Green, Individual MemberMarc Haines, Individual MemberThomas Haselwanter, Digital Enterprise Research Institute (DERI)Graham Hench, Digital Enterprise Research Institute (DERI)Hyun Jung, Korean National Computerization AgencyMick Kerrigan (secretary), Digital Enterprise Research Institute (DERI)Eunju Kim, Korean National Computerization AgencyHong-Gee Kim, Digital Enterprise Research Institute (DERI)Paavo Kotinurmi, Digital Enterprise Research Institute (DERI)Ho Kyoung Lee, Korean National Computerization AgencyJean-Luc LEVESQUE, EdiEyesSandeep Maripuri, Booz Allen HamiltonMonica Martin, Sun MicrosystemsTom Michaud, Software AG, Inc.Dugki Min, Individual MemberAdrian Mocan, Digital Enterprise Research Institute (DERI)Matthew Moran, Digital Enterprise Research Institute (DERI)Barry Norton, The Open UniversitySrinivas Padmanabhuni, Infosys TechnologiesYuanying Pan, Changfeng Open Standards Platform Software AllianceAsh Parikh, Raining Data CorporationKoustubh Pawar, CACarlos Pedrinaci, The Open UniversityJebastin Prabaharan, Infravio, Inc.Jiyong Pyon, Korean National Computerization AgencyBrahmananda Sapkota, Digital Enterprise Research Institute (DERI)Svante Schubert, Sun Microsystems
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 21
513
514515
516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564
5556
57
Ron Schuldt, Lockheed MartinOmair Shafiq, Digital Enterprise Research Institute (DERI)Clifford Thompson, Individual MemberWalt Truszkowski, NASALaurentiu Vasiliu, Digital Enterprise Research Institute (DERI)Tomas Vitvar, Digital Enterprise Research Institute (DERI)Alexander Wahler, NIWA-Web SolutionsMichal Zaremba (chair), Digital Enterprise Research Institute (DERI)Maciej Zaremba, Digital Enterprise Research Institute (DERI)
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 21
565566567568569570571572573
5859
60
E. Revision History
[optional; should not be included in OASIS Standards]
Rev Date By Whom What
wd-00 2006-05-24 Mick Kerrigan Initial version
wd-01 2005-10-17 Barry Norton Added initial UML content
wd-02 2005-10-17 Barry Norton Added initial WSML content
wd-see-semanticsoarm-v0.1-r1 22 May 2006Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 21
574
575
576
6162
63
top related