Reference Ontology for Semantic Service Oriented Architectures

walkingceilInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

110 εμφανίσεις

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
1

of
20



Reference
Ontology
for Semantic
Service Oriented Architecture
s

Working Draft 0.1
,

21

September
2007

Artifact Identifier:

wd
-
see
-
semanticsoa
ro
-
v0.1
-
r
1

Location:

Current
:
docs.oasis
-
open.org/ex
-
semantics/sematicsoar
o
/latest

This Version
:
docs.oasis
-
open.o
rg/ex
-
semantics/sematicsoar
o
/0.1

P
revious Version
:

docs.oasis
-
open.org/ex
-
semantics/sematicsoar
o
/0.1

Artifact Type:

semanticsoar
o

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

Adrian Mocan, DERI,
<
adrian.mocan@deri.at
>


Contributing Authors
:

Mick Kerrigan, DERI, <
mick.kerrigan@deri.at
>

James Scicluna, DERI, <
james.sci
cluna@deri.at
>


OASIS Conceptual Model topic area:

SOA

Related work:

Needs to be written

Abstract:

Needs to be written

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 c
oming 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
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
2

of
20


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 i
mplementation 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 applicabl
e 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 RIGH
TS 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 S
pecification 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 specif
ication.

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 provid
e 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 regar
ding 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 av
ailable; 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. C
opies 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
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
3

of
20


Table of Contents

1

Introduction

................................
................................
................................
................................
...........

4

1.1 Motivation and Scope

................................
................................
................................
.........................

5

1.2 Audience

................................
................................
................................
................................
.............

5

1.3 Guide to using this document

................................
................................
................................
.............

6

1.4 Notational Conventions

................................
................................
................................
.......................

6

2

Semantics and SOA

................................
................................
................................
.............................

7

2.1 Semantics

................................
................................
................................
................................
...........

7

2.2 Applying Semantics to SOA
................................
................................
................................
................

8

3

Overview of SOA
-
RM

................................
................................
................................
...........................

9

3.1 What is a service?

................................
................................
................................
..............................

9

3.2 Dynamics of Services

................................
................................
................................
.........................

9

3.3 Service Related Concepts

................................
................................
................................
................

11

4

Reference Ontology for Service Oriented Architectures [Barry]

................................
........................

14

5

Conclusion

................................
................................
................................
................................
..........

15

6

References

................................
................................
................................
................................
.........

16

6.1 Normative
................................
................................
................................
................................
..........

16

6.2 Non
-
Normative

................................
................................
................................
................................
..

16

A.

Glossary

................................
................................
................................
................................
.............

17

B.

Acknowledgements

................................
................................
................................
............................

18

C.

Revision History

................................
................................
................................
................................
..

20



wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
4

of
20


1

Introduction

1

Although Service Oriented Architectures (SOAs) have gathered more attention within Business
2

Organizations, for long there was still no clear understanding of what an SOA in fact is.

SOA was
3

consequently defined in the SOA Reference model [ref: SOA RM]. However, with the emerging Semantic
4

Web technologies, new breeds of SOAs are yet being developed: Semantic Service Oriented
5

Architectures (SSOA). SSOA use semantic technologies to furt
her solve problems that SOAs re limited in.
6

They (SSOAs) provide means to further automate important SOA features, such as discovery,
7

composition and interoperability.

8


9

Different SSOAs are currently being developed resembling common features amongst each
other. The
10

purpose of this document is thus to define a common model for SSOAs. This model will be defined
11

formally using an ontology
. This reference ontology will serve as a reference point for different
12

implementations of SSOAs.

13


14


15

Figure
1

-

The Reference Ontology and how it relates to other work

16


17

Figure
Error! Reference source not found.

depicts how the Reference Ontology relates to other pieces
18

of work within the SOA communities. It is extracted from the SOA Reference Model docume
nt [ref: SOA
19

RM] with the difference that we introduce the Reference Ontology alongside the Reference Model. Our
20

Reference Model is in fact formally defined using an Ontology. Reference Architectures refer to the SSOA
21

architecture document [ref: SSOA RA] a
nd the Concrete Architectures to implementations of semantic
22

based SOAs such as WSMX [ref: wsmx], IRS III [ref. irs] and METEOR
-
S [ref. meteor
-
s]. The Related
23

Models include the Semantic Annotations for WSDL (SA
-
WSDL) [ref sa
-
wsdl] Web Ontology Language
24

fo
r Services (OWL
-
S) [ref owl
-
s] and the Semantic Web Services Ontology (SWSO) [ref. swso].
25

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
5

of
20


Patterns???
The Protocols and Profiles (those considered as part of the related work) are the same as for
26

classical SOAs. However, with respect to Specifications an
d Standards, we further take into accoun
27

emerging Semantic Web Languages such as WSML, RDF, OWL, RIF and SWSL. These de
-
facto
28

“standards” play a very important role since they are the pillars of Semantic Technologies. The Input
29

features (Requirements, Moti
vation and Goals) are the same as for SOAs, with the addition that we
30

emphasize more on automation, as stated earlier.

31

1.1

Motivation and Scope

32

Why going Semantic? What are Semantics anyway? With the term “Semantic” we mean the formal (and
33

thus unambiguous) de
scription of some particular object (more in Section 2). Within our context, these
34

objects are mainly the data handled by the services and the services themselves. Semantic descriptions
35

within SOAs allow reasoning tools to automate tasks. More specifically
, semantics help in the following
36

ways:

37



formally and unambiguously define the data models and processes underlying the system

38



allow automated discovery and composition of services

39



automatically resolve data and process mismatches (and hence ease integratio
n)

40



ease the process of service ranking, negotiation and contracting

41


42

The scope of this document is therefore to provide an ontology that formally describes the different
43

elements comprising a SSOA which allows to achieve the above objectives.

44


45

1.2

Audience

46

The

target audience for this document adds on top of that for the SOA RM. In order to keep the document
47

self
-
contained, we provide an exhaustive list:

48


49



architects and developers designing, identifying or developing a system based on the service
-
50

oriented parad
igm;

51



standards architects and analysts developing specifications that rely on service oriented
52

architecture concepts;

53



decision makers seeking a "consistent and common" understanding of service oriented
54

architectures;

55



users who need a better understanding o
f the concepts and benefits of service oriented
56

architecture.

57



academics and researchers that are pursuing within the Semantic Web and Semantic Web
58

Services areas

59



I.T. consultants that provide businesses with support on semantic technologies and SOAs in
60

gen
eral

61


62


63

64

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
6

of
20


1.3

Guide to using this document

65


66

It is assumed that readers who are not familiar with SOA concepts and terminologies read first the SOA
67

RM and also the SOA Architecture documents since this document builds on top of these concepts.
68

Furthermore, reader
s who are new the concept of Semantic Technologies are encouraged to read this
69

document in its whole entirety.

70

This section introduces the reference model and how it relates to other work (in particular the SOA RM). It
71

defines the audience and also provid
es a description of the notational conventions used in this document.
72

Both of these elements are important in order for the reader to understand the content in the rest of the
73

sections.

74

Section
Error! Reference source not found.

provides an overview of what ar
e Semantics and how they
75

interrelate with SOAs. It starts by describing the deficiencies of the classical SOAs and the problems in
76

building them. It then continues with examples and situations of how Semantic Technologies can help to
77

overcome these deficie
ncies. This Section strengthens the motivations and objectives already described
78

in this section.

79

Section
Error! Reference source not found.

describes the Reference Model. It builds on top of the
80

Reference Model for SOA by introducing new key concepts require
d for SSOAs. It first describes what we
81

understand by a service followed by the dynamics of a service


how the service is perceived by the real
82

world. Other related concepts are also described (including, for example, the behavior of the web
83

service). Thi
s section shows the differences from the classical SOA RM to the SSOA RM and provides
84

the necessary building blocks for specifying the Reference Ontology.

85

Section
Error! Reference source not found.

defines the Reference Ontology for SSOAs.

86

The glossary provid
es definitions of terms that are relied upon within the document. Terms that are
87

defined in the glossary are marked in
bold

at their first occurrence in the document.

88

Note that while the concepts and relationships described in this document may apply to ot
her “service”
89

environments, the definitions and descriptions contained herin focus on the filed of software architectures
90

and make no attempt to completely account for use outside of the software domain. Examples included in
91

this document that are taken fr
om other domains are used strictly for illustrative purposes.

92


93

1.4

Notational Conventions

94

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
95

RECOMMENDED, MAY, and OPTIONAL that appear in this document are to be interpreted as descri
bed
96

in [RFC2119


need reference].

97

The concept map notation used in this document is the same as for that in the SOA RM. We however
98

give a brief description to keep the document self
-
contained.

99

There is no normative convention for interpreting Concept maps

and other than described herein, no
100

detailed information can be derived from the concept maps herein.

101


102


103

Figure
2

-

A basic Concept Map

104

As used in this document, a line between two concepts represents a relationship whereby the re
lationship
105

is not labeled but rather is described in the text immediately preceding or following the figure. The arrow
106

on a line indicates an asymmetrical relationship, where the concept to which the arrow points can be
107

interpreted as depending in some way

on the concept from which the line originates. The text
108

accompanying each graphic describes the nature of each relationship.

109

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
7

of
20


2

Semantics and SOA

110

As introduced in the Reference Model for Service Oriented Architecture (SOA
-
RM) committee
111

specification
,

the not
ion of Service Oriented Architecture has received a lot of attention in the software
112

design and development community. Service Oriented Architectures provides an architectural mechanism
113

for building
applications f
r
om

unassociated units of functionality cal
led services that have no calls to one
114

another embedded within them. In other words SOA is an architecture
that enables an application
115

developer to build an application from loosely coupled services, allowing applications to respond more
116

quickly to changes

in market conditions and improving the reusability, modularity, composability and
117

interoperability of functionality that an engineer develops when building an application.

118

Sadly building Service Oriented Architectures
using existing services
involves
larg
e amounts of human
119

effort in the process of finding and using these services. This human effort is due to the fact that
120

standards for describing services, for example the Web Service Description Language (WSDL), are
121

purely syntactic in nature and thus no a
utomated support for finding and using pre
-
existing services can
122

be created. When building an application using SOA the engineer is looking for Web services that are
123

available, either within his company’s repository of services or on the Web at large that
can fulfill a given
124

piece of functionality. Each time the engineer identifies a location where a service invocation is required
125

he must find candidate services that can fill this slot by browsing in UDDI and ebXML repositories. As
126

these repositories are sy
ntactic in nature the engineer will perform keyword matches against the services
127

available in the repository and select candidates by reading the textual descriptions provided in these
128

repositories, if there are any. Having selected some candidates the eng
ineer must obtain the associated
129

WSDL documents for each of the Web services and begin the process of understanding the endpoints
130

that are made available by each service in terms of the functionality they perform, the inputs that they
131

expect and the output
s that the provide. The engineer may need to get in contact with the providers of the
132

Web service to clarify the functionality offered by the service or perform test invocations against the
133

service to check the behavior of the service. Finally the engineer

will make a selection of one or more
134

services that can fulfill the job and add them to his application.

135

Not only is this process human intensive, but the solution that arises from it is not exactly the adaptable
136

decoupled architecture that Service Orient
ed Architectures promise. Imagine the scenario where a new
137

service comes on the market after the engineer has selected and integrated candidate services into the
138

application. This new service has better functionality than existing services and is also avai
lable at a
139

lower price. This service will never be available to the application, and thus to the end
-
users of the
140

application, unless the engineer finds the service, interprets its function, and integrates it into the
141

application. A similar scenario involv
es the case where the selected service(s) for a given piece of core
142

functionality within the application are not available due to being overloaded, offline for maintenance or
143

are discontinued. Essentially the application as a whole will not function until
the engineer has found and
144

integrated an alternate Web service for this functionality.

145

2.1

Semantics

146

The main limitation of SOA as mentioned above is that the standards that are used for describing Web
147

services are purely syntactic in nature and thus large amo
unts of human effort are required to perform
148

tasks like finding services; But what is the alternative to syntactic descriptions? Semantics is the study of
149

meaning and a semantic description offers the opportunity of providing an unambiguous mechanism for
150

d
escribing things. Semantics comes in many forms, some of which may already be familiar to you. Very
151

light forms of semantics include annotations or tags that can be placed on an entity in order to give a
152

semantic description of what that thing is. Annotati
ons or tags can be seen in action on sites like
153

flickr.com
,

where they are used for denoting what content appears in a particular picture or what a picture
154

is about. Of course the semantics of these annotations is very light and to bring more semantic mean
ing
155

to the annotations being used taxonomies can be introduced. Such structures give a mechanism for
156

providing a controlled vocabulary of terms
, i.e. a controlled set of annotations)

and the relationship
157

between them. For example we can state that the term

banana

is sub class of the term
fruit
. This
158

additional semantic information enables us to reason about the semantic descriptions we have and make
159

decisions based on the semanti
c descriptions, for example
the query
“show me all photos containing a
160

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
8

of
20


piece of

fruit”

is posed, them
those pictures that are annotated with the term banana

would be found
, as
161

banana

is a subclass of
fruit
. To add more semantics we can go even further and allow logical
162

expressions to be added to taxonomies to turn them into ontologie
s, such that more complicated
163

relationships between
entities can be expressed. The addition of axiomatic information in this way also
164

allows for much more sophisticated reasoning to take place and for nre information to be inferred for
165

existing information
, for example the axiom
“all fruit is edible”

placed in a reasoner with the previous
166

example would allow the fact
“bananas are edible”

to be inferred and thus queries like
“show me all
167

photos containing things that are edible”
would find pictures of banana
s.

168

2.2

Applying Semantics to SOA

169

Semantic Web Services are the extension of ontologies to describe Web services in such a way that a
170

machine can reason about the functionality they provide, the mechanism to invoke them, and the data
171

they expect as input and re
turn as output.
In other words each Web service that currently has a syntactic
172

description in the form of a WSDL document will

also

have a semantic description in some formalism
173

once it becomes a Semantic Web Service, in this way it can be seen that Semant
ic Web Services are not
174

a reinvention of Web services but an enhancement to them.

In order to effectively describe Web services
175

semantically we need to have a
n

understand
ing

of
what

elements need to be modeled within our
176

semantic description. Within this d
ocument you will find the R
eference Ontology for Service Oriented
177

Architectures, which provides such a description of what elements need to be modelled in order to
178

effectively describe Web services
semantically

and build Semantically Enabled Service
-
orient
ed
179

Architectures.

180

Once Web services are described semantically it allows for many of the tasks performed by the engineer
181

in building and maintaining and application using SOA to be automated. For example, services can be
182

discovered

based upon the functiona
lity they advertise in their semantic description, can be
selected

183

based upon the advertised (or observed) quality of the service, heterogeneity issues with respect to the
184

data they exchange or the process to invoke them can be
mediated
. This allows for th
e Service Oriented
185

Architecture, now extended with semantic descriptions to create a Semantically Enabled Service
-
oriented
186

Architecture (SESA), to dynamically bind to services at run time, removing the hard wired behavior that
187

we see in current application
s. When new services appear on the market that fulfill functionality needed
188

by the application, they will be considered alongside existing services that are being used already by the
189

application and may be selected over these existing services based on the

requirements of the
190

application. Also if a given service that is usually used by the application is no longer available, it can be
191

replaced by another service that fulfills the same function.

192

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
9

of
20


3

Overview of SOA
-
RM

193

The notion of Service Oriented Architecture
has been greatly used in the last couple of years in the
194

software design and development communities.
Yet, the v
arious
and very often conflicting
definition
s and

195

terminolog
y

for

SOA and its elements
could hamper the adoption process and threaten the succes
s and
196

the
impact of this technology.
In order to provide a standard reference point in the design and
197

implementation of SOAs t
he OASIS SOA
-
RM Technical Committee
1

proposes an abstract framework for
198

understanding the main entities and the relationships betw
een them within a services oriented
199

environment
[1]
.

200

The resulting specification is a SOA Reference Model (SOA
-
RM), which is not directly dependent of any
201

standards, technologies and implementation details.
Its goal is to def
ine the essence of service oriented
202

architecture, a normative vocabulary and a common understanding of SOA. The Reference Ontology
203

takes this reference model as a starting point in defining the main aspects of a semantically
-
enabled
204

Service Oriented Archit
ecture and it specifies how the normative elements of the SOA
-
RM can be
205

augmented with semantics.
As a consequence t
his
section gives a brief overview of the SOA
-
RM,
along
206

the several aspects it covers: the notion of
service
, the
dynamics of service

and th
e service
-
related
207

concepts such as
service description
,

service execution context

and

service contracts and policies
.

208

3.1

What is a service?

209

SOA
-
RM defines a service as “…
a mechanism to enable access to one or more capabilities, where the
210

access is provided
using a prescribed interface and is exercised consistent with constraints and policies
211

as specified by the service description.
” It identifies four main aspects regarding the service that have to
212

be considered in any SOA:

213



A service
e
nable
s

access to one or

more capabilities
.

214



A service enables
a
ccess through a prescribed interface
.

215



A service is
o
paque to the service consumer

except from the information and behavioral models
216

in the interface and the information required to asses if a service suits the request
er needs.

217



Consequences of invoking a service

should be either response information to the invocation or a
218

change to the shared state of the defined interface.

219

It is important to not that SOA
-
RM makes a clear distinction between the capability of a service
(i.e. some
220

functionality created to address a need)
and the point of access where the capability can be consumed in
221

the context of SOA.

222

3.2

Dynamics of Services

223

SOA
-
RM also provides guidelines regarding the interactions of the requester with a service. As su
ch, it
224

identifies three fundamental concepts related with dynamics of the service:
Visibility, Interaction
and
Real
225

World Effect.

226










1

For more details, see
http://www.oasis
-
open.org/committees/soa
-
rm
.

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
10

of
20


Visibility

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

(see
227

Figure
3
)
where:

228



Awareness

is the state whereby the service requester is aware of the service provider or the
229

other way around. It is normally achieved by having either the requester or the provider
230

discovering the information the other party publishe
d in public directory for example.

231



Willingness

concerns the intent to communicate. Even if the discovery process has been
232

successful, without willingness to communicate from both requester and provider the interaction
233

will fail.

234



Reachability

is the state

that characterize
s

service participants that are able to interact, for
235

example by exchanging information.

236


237


238

Figure
3
.
Service

Visibility (
adapted
from
[1]
)

239

The
interaction

with a service is reflecte
d by the actions performed on the service, for example
240

exchanging messages with the services. According to SOA
-
RM the key concepts affecting the interaction
241

with a service are

(see
Figur
e
4
)
:

242



Information Model

of a service charact
erizes the information that may be exchanged with the
243

services and only descriptions of data and information that can be potentially exchanged with the
244

service are included in the information model. The information model can be also portioned in:

245

o

Structure

(Syntax)
refers to the representation, structure, and a form of information.

246

o

Semantics
refers
to the actual interpretation and intent of the data. Semantics becomes
247

important especially when interaction occurs across ownership boundaries since the
248

interp
retation of data must be consistent between the participants in a service interaction.

249



Behavior Model

deals with

“knowledge of the actions invoked against the service and the process
250

or temporal aspects of interacting with the service”.
It consists of two

distinct aspects:

251

o

T
he action m
ode
l

characterizes the actions that can be invoked against the service.
252

Since a great part of the behavior implied by an action is private, the public view of the
253

service includes the implied effects of actions.

254

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
11

of
20


o

The process
model

defines temporal relationships of actions and events associated when
255

interacting with a service. SOA
-
RM does not fully define the process model since it could
256

include aspects that are not strictly part of SOA, e.g. orchestration of services.

257


258


259

Figur
e
4
. Service Interaction (
adapted
from
[1]
)

260

The r
eal
w
orld
e
ffect

it is the ultimate purpose associated with the interaction with a particular service. It
261

can be the response to a request for informati
on or the change in the state of some shared entities
262

between the participants in the interaction.

263

3.3

Service Related Concepts

264

SOA
-
RM identifies a set of concepts crucial in enabling the interaction between a service consumer and a
265

service. These concepts are

the
service description
, the
service policies and contracts

and the
execution
266

context.

267

The
service description

encompasses the information needed in order to use the service

(see
Figure
5
)
.
268

The purpose of the service description

is to facilitate the interaction of the visibility especially if the
269

participants are part of different ownership domains. By using the service description the service
270

consumer should be able obtain the following items of information:

271



That the service is

reachable or not.

272



That the function the service provides is the function required by the requester

273



The set of policies the services operates under.

274



That the service complies with the service consumer’s policies.

275



How to interact with the service, includ
ing the format and content of the information to be
276

exchanged as well as the expected sequence of the information exchange.

277

As a consequence, t
here are
several

important aspects that have to be captured by the service
278

descriptio
n: the service reachability,

the service functionality
, the service
-
related policies, and the service
279

interface.

280

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
12

of
20




Service reachability
is assured by including in the service description enough information to
281

enable the service providers and services consumers to interact with each ot
her.
Such
282

information could include service metadata (e.g. location, supported or required protocols),
283

dynamic information about service (e.g. if the service is currently available), etc.

284



Service functionality

should be unambiguously captured by the servi
ce description and it should
285

contain information about the function of a service and the real world effects that result form it
286

being invoked. This piece of information should be expressed in a general
-
enough way to be
287

understandable by service consumers w
hile in the same time the vocabulary used should be
288

expressive enough to capture the domain
-
specific details of the service functionality. Such
289

information could include a textual description (for humans consumption) or identifiers or
290

keywords referencing
machine
-
processable definitions.

291



Service
-
related policies
should be reflected by the service description in order to enable the
292

prospective service consumer to determine if the service will act in a manner consistent with
293

consumer’s own constraints.

294



The
service interface

describes the means to interact with the service. It could include specific
295

protocols, commands and information exchange by which actions are initiated. It prescribes what
296

information needs to be provided to the service in order
to access

its capabilities and interpret
297

responses. This information is also referred as the information model of the service.

298


299

Figure
5
. Service
Description (
from
[1]
)

300

The
service policy
represents the const
raints or the conditions on the use, deployment or description of a
301

service while a
contract

is a measurable assertion that governs the requirements and expectations of one
302

or more parties.
Policies potentially apply

to various aspects of SOA such as secur
ity, manageability,
303

privacy, etc. but they could also apply to business
-
oriented aspects, e.g. hours of business.
In their turn
304

contracts can as well cover a wide range of aspects of services: quality of services agreements, interface
305

and choreography agre
ements, commercial agreements, etc.

306

The
execution context

represents the set of infrastructure elements, process entities, policy assertion and
307

agreements associated with a particular service interaction, forming a path between service consumers
308

and servi
ce providers. The execution context it is not limited to one side of the interaction but rather with
309

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
13

of
20


the overall interaction which includes the service provider, service consumer and the infrastructure in
310

between.

311


312


313

Figure
6
. Exec
ut
ion Context (adapted
from
[1]
)

314

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
14

of
20


4

Reference Ontology for Service Oriented
315

Architectures [Barry]

316



Figure 3 + Figure 5 + Figure 6 + Figure 9 together motivating where we sit in the model (carefully)

317

o

Way of distinguishing top level

and more descriptive elements

318

o

Information model and behavioral model in more neutral positions

319



Service description and interaction are the entrypoint for semantics

320


321

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
15

of
20


5

Conclusion

322

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
16

of
20


6

References

323

6.1

Normative

324

Normative references go here

325

6.2

Non
-
Normative

326

Non
-
Normative r
eferences go here

327


328

[1]

C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, R. Metz (eds.): Reference Model for Service
329

Oriented Architecture 1.0, OASIS SOA
-
RM Technical Committee Specification, 2 August, 2006,
330

available at:
http://www.oasis
-
open.org/committees/download.php/19679/soa
-
rm
-
cs.pdf

331

[2]

ABC

332


333


334


335


336


337


338


339


340

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
17

of
20


A.

Glossary

341

This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for
342

Service Orien
ted Architecture, Public Review Draft 1.0” and introduces any new terms needed by the
343

Semantic SOA Reference. The two glossaries are intended to be used together, therefore terms from the
344

other glossary will not be repeated here.

345


346

A

347


A’s Definition

348


349

B

350


B’s

Definition

351

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
18

of
20


B.

Ac
knowledgements

352

The following individuals were members of the committee during the development of this specification
353

and are gratefully acknowledged:

354

Participants:

355

Marc Adlam, Oracle Corporation

356

Zachary Alexander, Individual Member

357

Michael

Al
tenhofen, SAP AG

358

Anuprlya Ankolekar, Institute of Applied Informatics and Formal Description Methods (AIFB)

359

Tim Banks, IBM

360

Charlton Barreto, Adobe Systems

361

David Brock, MW2 Consulting

362

Dario Cerizza, CEFRIEL

363

Joseph Chiusano, Booz Allen Hamilton

364

Emilia Cimpia
n, Digital Enterprise Research Institute (DERI)

365

David Cunningham, Booz Allen Hamilton

366

Emanuele Della Valle, CEFRIEL

367

Paul Denning, Mitre Corporation

368

Marin Dimitrov, Ontotext Lab/Sirma Group

369

John Domingue
(chair)
, The Open University

370

Elmar Dorner, SAP AG

371

Mat
thew Dovey, Oxford University

372

Mike Evanoff, ManTech Enterprise Integration Center (e
-
IC)

373

Dieter Fensel, Digital Enterprise Research Institute (DERI)

374

Sri Gopalan, Booz Allen Hamilton

375

Peter Gratzer, Sun Microsystems

376

Stephen Green, Individual Member

377

Marc Hain
es, Individual Member

378

Thomas Haselwanter, Digital Enterprise Research Institute (DERI)

379

Graham Hench, Digital Enterprise Research Institute (DERI)

380

Hyun Jung, Korean National Computerization Agency

381

Mick Kerrigan
(
secretary
)
, Digital Enterprise Research Insti
tute (DERI)

382

Eunju Kim, Korean National Computerization Agency

383

Hong
-
Gee Kim, Digital Enterprise Research Institute (DERI)

384

Paavo Kotinurmi, Digital Enterprise Research Institute (DERI)

385

Ho Kyoung Lee, Korean National Computerization Agency

386

Jean
-
Luc LEVESQUE,
EdiEyes

387

Sandeep Maripuri, Booz Allen Hamilton

388

Monica Martin, Sun Microsystems

389

Tom Michaud, Software AG, Inc.

390

Dugki Min, Individual Member

391

Adrian Mocan, Digital Enterprise Research Institute (DERI)

392

Matthew Moran, Digital Enterprise Research Institute (DERI)

393

Barry Norton, The Open University

394

Srinivas Padmanabhuni, Infosys Technologies

395

Yuanying Pan, Changfeng Open Standards Platform Software Alliance

396

Ash Parikh, Raining Data Corporation

397

Koustubh Pawar, CA

398

Carlos Pedrinaci, The Open University

399

Jebastin Prabahar
an, Infravio, Inc.

400

Jiyong Pyon, Korean National Computerization Agency

401

Brahmananda Sapkota, Digital Enterprise Research Institute (DERI)

402

Svante Schubert, Sun Microsystems

403

Ron Schuldt, Lockheed Martin

404

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
19

of
20


Omair Shafiq, Digital Enterprise Research Institute (DER
I)

405

Clifford Thompson, Individual Member

406

Walt Truszkowski, NASA

407

Laurentiu Vasiliu, Digital Enterprise Research Institute (DERI)

408

Tomas Vitvar, Digital Enterprise Research Institute (DERI)

409

Alexander Wahler, NIWA
-
Web Solutions

410

Michal Zaremba
(chair)
, Digital E
nterprise Research Institute (DERI)

411

Maciej Zaremba, Digital Enterprise Research Institute (DERI)

412

wd
-
see
-
semanticsoar
o
0.1
-
r1


21 September 2007

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
20

of
20


C.

Revision History

413

[optional; should not be included in OASIS Standards]

414

Rev

Date

By Whom

What

wd
-
00

200
7
-
09
-
13

Mick Kerrigan

Initial
T
OC from F2F Meeting

wd
-
01

200700921

Adrian Mocan

Content added to Section 3


415