figure 1

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, <[email protected]>Michal Zaremba, DERI, <[email protected]>

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

OASIS Conceptual Model topic area:SOA

Related work:This specification depends upon and extends:

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

Semantic Web Services Architecture and Information Model SEE Execution Semantics

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

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

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/semantic-ex.

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

1

2

3

4

56

78910

1112

1314

151617

181920

2122

2324

25262728

2930313233343536

373839

40414243

12

3

mailto:[email protected]

mailto:[email protected]

Notices

Copyright © OASIS Open 2006. All Rights Reserved.

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

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

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

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

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

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

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


44

45

4647

4849505152535455

5657

5859606162

6364656667

6869707172

7374757677787980818283

45

6

Table of Contents

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

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

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

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

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

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

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

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

3 The Reference Model.......................................................................................................................... 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


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].


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]


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)…


169

170

171

172173

174

175176177

178

179180181182

183

184185186187188189

190

191192

1617

18

Barry Norton, 10/17/06,

Subclasses?


I suppose?

3.4 Capability

3.5 Interface

3.5.1 Choreography

3.5.2 Orchestration

3.6 …


193

194

195

196

197

1920

21


Do we need to introduce ontologies and oo-mediators as first class? Probably (ontology, at least), if this is what (as we've agreed informally) we want to pass along with the goal to goal-oriented execution...

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


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.”


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. 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).


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]


374

375376

3435

36

6 References

6.1 NormativeNormative references go here

6.2 Non-NormativeNon-Normative references go here


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


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.


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.


concept a

concept b subConceptOf a

concept c

concept d subConceptOf {a, c}

Listing 2: Example of Subsumption between Concepts in WSML

Figure 3: Representation of Subsumption Example in UML Class Diagram

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

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


concept a

concept bhasA ofType (0, 1) a

concept c


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.


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


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


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)


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


574

575

576

6162

63

figure 1

Documents

oasis party

oasis technical committee

oasis intellectual

oasis website

oasis standard

oasis requests

oasis committee specification

oasis ipr policy