Semantic SOA Reference Architecture

economickiteInternet and Web Development

Oct 21, 2013 (3 years and 10 months ago)

97 views

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
1

of
24




Semantic
SOA Reference Architecture

Working Draft
v
0
.1
-
r
5
,
21

July

200
7

Artifact

Identifier:

wd
-
see
-
ssoa
-
ra
-
v0.1
-
r
5

Location:

Current
:
v0.1
-
r
5
,
21

July

2007

This Version
:
v0.1
-
r
5
,
21 July

2007

P
revious Version
:

v0.1
-
r
3
,
16
June

2007

Artifact Type:

Refe
rence A
rchitecture

Technical Committee:

OASIS
SEE

TC

Chair(s)
:

John Domingue
,
Open University,
<
j.b.domingue@open.ac.uk
>

Michal Zaremba
, DERI

Innsbruck
,

<michal.zaremba@deri.at
>

Editor(s):

Mick Kerrigan
, DERI

Innsbruck
,
<mick.kerrigan@deri.at
>

Matthew Mora
n, DERI

Galway
,
<matthew.moran@deri.org>

Michal Zaremba, DERI

Innsbruck
, <michal.zaremba@deri.at
>

Contributing Authors
(s):

Emilia Cimpian, DERI Innsbruck <emilia.cimpian@deri.at>

Thomas Haselwanter, DERI Innsbruck, <thomas.haselwanter@deri.at>

Joerg Hoffma
nn
, DERI Innsbruck,

<joerg.hoffmann@deri.at>

Jacek Kopeck
ý
, DERI Innsbruck <jacek.kopecky@deri.at>

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

Barry Norton, Open University, <
b.j.norton@open.ac.uk
>

James Scicluna, DERI Innsbruck <james.scicluna@d
eri.at>

Ioan Toma, DERI Innsbruck <ioan.toma@deri.at>

Tomas Vitvar, DERI Galway <tomas.vitvar@deri.org>

M
aciej

Zaremba
, DERI

Galway
,
<
maciej.zaremba@deri.org
>


OASIS Conceptual Model topic area:

SOA
, Reference Architecture, Semantic Web

Related work:

This
specification is related to:

1

The related work is specified in the separate OASIS SEE TC document titled
“Background and Related Work”.

2

The
reference model
is specified in the separate OASIS SEE TC document titled

Reference Model for Semantic Service Orien
ted Architecture
”.

Abstract:

This document provides a specification for a Semantic Service Oriented Reference Architecture.
The application of Semantic Web technology to SOA brings enormous potential for tackling
interoperability problems that recur betwee
n software applications both within the scope of an
organization and across organization boundaries in the case of business
-
to
-
business (B2B)
interactions. Industry middleware, supporting Web Services as an enabling technology for SOA,
OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
2

of
24


face the need to inc
orporate Semantic Web technology to allow for greater automation of the
tasks surrounding interoperability issues. In this specification, a reference architecture is
described, identifying the functionality required for a Semantic SOA, and describing how t
hat
functionality can be combined to satisfy the semantic interoperability problems of SOAs.

Status:

This document is in DRAFT status.
This document is updated periodically on no particular
schedule.

Technical Committee members should send comments on th
is 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/
ex
-
semantics
.

For information on wh
ether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the Technical Committee web page (
www.oasis
-
open.org/
commi
ttees/
ex
-
semantics
/ipr.php
.

The non
-
normative errata page for this specification is located at
www.oasis
-
open.org/
committees/
ex
-
semantics
.

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
3

of
24


Notices

Copyright © OASIS Open 200
7
. All Rights Reserved.

All capitalized terms in the following text have the meani
ngs 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 Technica
l
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 re
voked 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 INFORMATI
ON 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 infringe
d 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 obli
gation 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 lice
nse 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 propr
ietary 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.

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
4

of
24


Table of Contents

1

Introduction

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

5

1.1

Organization of the
Deliverable

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

5

1.2

Motivation
................................
................................
................................
................................
.....

5

1.3

Scope

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

5

1.4

Underlying Princi
ples

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

5

1.5

Summary
................................
................................
................................
................................
......

5

2

Global View

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

6

3

Conceptual Model
................................
................................
................................
................................
.

7

4

Services View

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

9

4.1

Broker Services

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

9

4.1.1

Discovery

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

9

4.1.2

Selection

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

10

4.1.3

Composition

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

11

4.1.4

Data Mediation

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

12

4.1.5

Process Mediation

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

13

4.1.6

Transport Handler

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

13

4.1.7

Grounding

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

13

4.1.8

Choreography Execution

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

14

4.1.9

Orchestration Execution

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

15

4.2

Base Services

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

15

4.2.1

Logical Reasoner

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

15

4.2.2

Repository

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

15

4.3

Vertical Services

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

18

4.3.1

Service management

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

18

4.3.2

Security

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

18

5

Process View

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

19

5.1

Processes in the Context of SSOA

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

19

5.2

Describing process behavior a
s Execution Semantics

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

19

5.3

Goal
-
based Discovery Process

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

19

5.4

Service Invocation Process

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

19

5.5

Achieve Goal (Discovery and Invocation) Process

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

19

5.6

Summary
................................
................................
................................
................................
....

19

6

Future Work

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

20

Appendix A. Acknowledgements

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

22

Appendix B. Appendix A


SEE API (Operations)

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

23

Appendix C. Revision History
................................
................................
................................
......................

24



OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
5

of
24


1

Introduction

1

1.1

Organization of the Deliverable

2

It’s organized in
four
sections. This first section describes the motivation and scope. The second
provides
3

a global vi
ew placing the SSOA RA in context. The

third
and fourth
sections describe two views on the
4

reference architecture. The first of these is the services view, which describes the functionality required by
5

a SSOA. Next is the process view which identifies the
behavior

required of an SSOA and describes the
6

how the various services that make up the reference architecture combine to provide this
behavior
.

7

1.2

Motivation

8

Reading this should provide a non
-
expert in this area with the motivation for why an SSOA RA is us
eful
9

and relevant.

10

1.3

Scope

11

For example the SSOA RA identifies the functionality and
behavior

required, but does not prescribe the
12

ontological language or any technology
-
specific design choices (with the exception of the dependence on
13

grounding to WSDL Web Se
rvice descriptions).

14

1.4

Underlying Principles

15

Brief description

on
principles of Semantic Web Services and SOA (and possibly others)

16

1.5

Summary

17

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
6

of
24


2

Global View

18


19

Figure
1
: Global view on SEE (modified from
[ref to SESA journal]
)

20


21

The global

view shows how the services of SEE fit in the context of a problem
-
solving system (modified
22

from [ref to SESA journal]. There are five layers shown in
Figure
1
. These are:

23



Stakeholders: they form the group of various users
that

u
se the functionality of the architecture.
24

They include the users of backend systems, users formulating requests through graphical tools
25

and Web portals, and develop
er
s and system administrators monitoring and m
odifying the
26

resources used by
the system.

27



Pr
oblem solving layer: the applications and tools supporting stakeholders in the formulation of
28

problems and the description of requests that semantically encapsulate the problem description.

29



Service request layer: these are represented as the goals that are

created by the problem solving
30

layer that are dispatched to SEE
for resolution

31



Middleware layer: contains the
platform

services that are required to enable Semantic Web
32

services to be used for the resolution of goals from the problem
-
solving layer. This i
s analogous
33

to the middleware functionality offered by many enterprise service bus products. However the
34

services provided by SEE pay special attention to how Semantic Web technology can be
35

harnessed to provide a more automated solution to the design and e
xecution of applications
36

using a
S
ervice
Oriented A
rchitecture.

37



Service provider’s layer: the business services that provide the functionality t
o actually achieve
38

part
of
or
the

entire

goal. They are represented as endpoints usually, but not necessarily,
39

d
escribed using WSDL.

40

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
7

of
24


3

Conceptual Model

41

The conceptual model is provided by the Semantic Execution Environment Technical Committee’s
42

document, currently available as a draft,

Reference Model for Semantic Service Oriented Architecture

43

[Norton and Mocan, 20
07]. In this section we provide only an overview for convenience
, explaining the
44

model as diagrammed in
Figure
2
.

45


46


47

Figure
2
: Reference Model as UML Class
Diagram

48


49

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
8

of
24


The central notions for service descri
ption are the WebService concept, and its counterpart Goal.

The
50

Semantic SOA Reference Model is notable is drawing this distinction between the
offered

service,
51

described from the point of view of the provider, and the
required

goal, described from the po
int of view of
52

the would
-
be consumer.

Both are given a description in terms of
ontologies
, which they import. In both
53

the description subsists in two parts: the
capability

is used to structure the description of
functionality
; the
54

interface

is used to des
cribe
behaviour
. The latter therefore subsists in the SOA
-
RM concepts of an
55

action model

and a
process model
.

The former imposes logical conditions that must exist over the action
56

model and other ontological features

before execution
, in the
precondition

and
assumption

respectively,

57

and over these models following successful execution, in the
postcondition

and
effect

respectively.

58

Mediators are used to specify
a connection between two models and the mediation that needs to take
59

place to bridge their dissi
milar representations. The Reference Architecture will use a WG
-
Mediator, for
60

instance, to
which WebService models can be connected to which Goals using mediation to overcome
61

the differences in action and process models.

62

63

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
9

of
24


4

Services View

64

As introduced in section
2

there are two types of services involved when a requester wishes to interact

65

with a Semantic Execution Environment namely platform services and business services. Business
66

services are those services available on the Web and whose semantic descriptions are available to the
67

SEE. This section is related to the Platform services, whi
ch are those services that make up the Semantic
68

Execution Environment itself and which manipulate elements of the Reference Model in order to fulfill the
69

requests of users. Platform s
ervices are broken down into three different categories within the Semant
ic
70

Execution Environment, namely broker services, base services and vertical services. In this section each
71

of these different categories are explained and examples of the sorts of services that exist within each
72

category are mad
e with associated descripti
ons.

73

4.1

Broker

Services

74

Middleware is software that allows independent applications, using heterogeneous definitions for the
75

various information items that they require, to be able to communicate with each other, in an apparently
76

transparent manner. For SEE,
the middleware services enable it to act as a broker between client service
77

requests and business services capable of satisfying those requests. Ultimately, through discovery,
78

composition, mediation and invocation based on Semantic
Web
service annotation,
SEE aims for flexible
79

goal
-
driven service invocation where independent and heterogeneous service requesters and providers
80

transparently co
-
operate together.


81

4.1.1

D
iscovery

82

The functionality of service discovery is further decomposed into three aspects. These a
re goal
83

abstraction, service discovery and Web service discovery
:

84


85

Goal
Abstraction:

Goal abstraction is an optional pre
-
processing step
that

creates an abstract goal from
86

a concrete goal. An abstract goal contains no instance data in its definition wherea
s a concrete goal will
87

contain instance data. For example a concrete goal would be
b
uy a
b
ook called Harry Potter and The
88

Goblet of Fire

while a corresponding abstract goal would be simply
buy a book
. The motivation for
89

abstract goals is they provide a hig
her level goal description used in the next step (Web service
90

discovery) to filter a potentially large set of candidate services. It can also be the case that the goal can
91

be matched with some existing abstract brokered goal via data mediation, in which c
ase a GG
-
Mediator
92

connecting the goals, and specifying the mediation, will be returned.

In many cases goal abstraction will
93

not be required as the goal given to a Semantic Execution Environment by the requester will already be
94

abstract and any instance dat
a required will already be provided in a separate ontology.

95


96

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#Goal

1



rm#Instance

0
..*



rm#GG
-
Mediator

0 .. *


97

Web
Service Discovery:

At this stage, Web services are matched with

goals at an abstract level based
98

on the requested capability described in the abstract goal. Several types of matches may be found
99

between the goal and candidate Web service descriptions. These include exact match, plug
-
in match,
100

subsumption match, inters
ection match, and disjointness. The match may also involve an already
101

computed mediation, which may be communicated via a WG
-
Mediator. This phase identifies a set of Web
102

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
10

of
24


service descriptions that may be able to handle the request without yet taking cogniza
nce of the instance
103

data sent by the service requester. In our example, the request is not to buy any book but specifically a
104

Harry Potter

book.

105


106


107

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#WebService

0 .. *



rm#WG
-
Mediator

0 .. *


108

Service Discovery
:

At this stage, services which match at abstract level are matched at instance
-
level.
109

This involves the use of the original data provided by the service requester and may involve invoking the
110

service provider to obtain informati
on that is not included directly in the service description. In the context
111

of our example, it is unlikely that a book seller will include details of their entire catalogue in the service
112

description. Rather, book sellers like Amazon, provide an operation
on their Web service enabling the
113

lookup on the availability and details of specific items. This part of discovery may also involve the
114

resolution of contractual or usage
-
negotiation issues that may be indicated in the service description.

115


116

Input

(type)


(
multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#WebService

0 .. *

rm#Instance

0..*

rm#WG
-
Mediator

0 .. *


117

4.1.2

Selection


118

Selection is the process where one service which best satisfies user preferences is selected from the
119

candidate services retur
ned from the service discovery stage. As selection criteria, specified by the user,
120

various non
-
functional properties such as Service Level Agreements (SLA), Quality of Services (QoS),
121

etc. can be obtained from the goal description. On the service side the

requested non
-
functional
122

properties values are either directly specified in the service description or are provided (computed or
123

collected) by a monitoring tool. Non
-
functional properties specified in goal and service descriptions are
124

expressed in a seman
tic language, by means of logical rules using terms from NFP ontologies.

125

An integrated part of the Selection is the Ranking process which generates an order list of services out of
126

the candidate services set. The logical rules used to model non
-
functional

properties of services are
127

evaluated, during the ranking process, by a reasoning engine. Additional data is considered including
128

user preferences i.e. which non
-
functional properties user is interested and the ordering direction as well
129

as concrete instan
ces data extracted from the goal description. The non
-
functional properties values
130

obtained by evaluating the logical rules are sorted and the order list of services is built. Once the ranking
131

process is completed, as a final step of the selection process
the best candidate service is selected.

132


133

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#WebService

0..1

rm#WebService

1
.. *



OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
11

of
24


4.1.3

Composition

134

Often, a web service that fulfills the entire user requirement is not available. A common

example is travel
135

planning, where usually there is no single provider covering all the transportation and accommodation as
136

required for a particular itinerary. A more significant example is Business Process Management (BPM),
137

where a company seeks to imple
ment a new functionality by combining different services in its existing
138

repository.

139

Combining existing Web Services in a way that suits the requirement is, in general, a programming task.
140

Composition, or web service composition (WSC),

serves to support,
or even fully automate, that
141

programming. Automatic programming is known to be prohibitively difficult both in theory and practice;
142

however, WSC has better chances to succeed due to its strong reliance on existing pieces (combination
143

of existing functional
ities as opposed to implementation of entirely new functionalities). Also, in many
144

practical scenarios, the desired combinations are not overly complex. The tedious aspect for human work
145

is finding the right services, and working out the details of combini
ng them; both things might be
146

supported quite well by a computer.

147

Composition is usefully seen to happen at two different levels of abstraction: the
functional level

and the
148

process level.
At the functional level, web service executions are atomic transact
ions characterized
149

entirely by the properties of their start and end points. The process level is much more realistic, in viewing
150

web services as evolving and interacting processes with complex behavioral interfaces. Naturally,
151

composition at the functiona
l level (although it is still a hard problem) is much easier, both in theory and
152

practice, than at the process level. Hence the former serves as a pre
-
filter for the latter: once a solution
153

has been found that is valid relative to the functional descriptio
ns, that solution is used as input to process
154

level composition, where it is refined to also be valid relative to the procedural descriptions.

155

Functional level descriptions of web services are typically written using a logic, specifying a condition


156

the
p
recondition

--

that must hold in order to apply the web service, and specifying another condition


the
157

postcondition



that will hold upon execution of the web service. Formalisms of this kind have been
158

considered for a long time in AI, and can be suitabl
y adapted and extended for the purpose of WSC. For
159

process
-
level composition, formalisms and methods from formal verification and from automatic deduction
160

naturally lend themselves.

161

In its simplest form, the component returns accepts a Goal and returns a
sequence of Web Services that
162

fulfill the task. Optionally, if a specific set of Web Services is at hand prior the composition, the
163

component attempts to find the relevant Web Services within this set. Although the returned Web
164

Services are in sequence, it

might be the case that some (or all) of them are independent of each other
165

and may be executed in parallel or in some other order. To this extent, we leave this process up to an
166

external tool/component. This behavior is based on typical A.I. Planning tech
niques whereby the planner
167

is not responsible for determining the flow of control of the relevant actions but rather to order the actions
168

in a simple way such that the target goal is achieved.

169

However, in most contexts related to Web Services (especially w
ithin BPM), one would like to achieve a
170

workflow of the composed web services. Such a workflow would then be directly executed by an
171

execution engine. In the context of SEE, such workflows would be described as an Orchestration. Note
172

that a parallelization

tool may also be integrated within this phase but it is
not
necessary. Without such a
173

facility, the orchestration would be simply an explicit description with a sequence of Web Services to
174

execute.

175

Compose Goal

176

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#WebService

0..*


177

Compose Goal

178

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
12

of
24


rm#Goal

1

rm#WebService

0..*

rm#WebService

0..*




179

Compose Goal

180

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#Orchestration

0..*


181

Compose Goal

182

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1

rm#Orchestration

0..*

rm#WebService

0..*




183

4.1.4

Data Mediation

184

The Data Mediation component in SEE deals with heterogeneity problems that can appear a
t the data
185

level. All messages in SEE are expressed in a semantic language, meaning that data to be mediated is
186

described in terms of ontologies, i.e. data consists of ontology instances.

187


188

In this context, the heterogeneity problems at the data level appe
ar when the requester and the provider
189

of a service use different ontologies to conceptualize their domain. As a consequence, data has to be
190

transformed from the terms in one ontology (e.g. the requester’s) into the terms of the other ontology (e.g.
191

the pr
ovider’s). This can be done during the discovery phase or in subsequent interactions between
192

requester and provider. Due to the fact that these transformations must take place during run
-
time the
193

whole process has to be completely automatic. The data media
tor component in SEE achieves this by
194

relying on a set of mappings (semantic relationships) between the source and target ontology identified
195

during design
-
time and stored in a persistent storage.

196


197

The mappings correspond to logical rules that are execute
d during run
-
time by a reasoning engine. There
198

are various ways (formalisms) of representing these rules, depending on the reasoning support available.
199

In order to encourage and enable the interoperability between various mediation systems and to allow the

200

flexible and the easy management of these mappings, a language independent format is more desirable.
201

But as a consequence, each time a set of such mappings have to be applied in a concrete scenario (as
202

the instance transformation in SEE) the mappings hav
e to be
grounded

to a concrete ontology
203

representation language. The grounding not only transforms the mappings in an executable rules, but
204

also associates them with a formal semantics which assures that the mapping rules are unequivocally
205

interpreted and
executed.

206


207

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#
Instance

1
..*

rm#
Instance

0
..*

rm#OO
-
Mediator

1



OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
13

of
24


4.1.5

Process
Mediation

208

Process Mediation deals with solving the heterogeneity mismatches at the behavioral level. That is,
209

considering
that two processes have to interact (one of them has to provide inputs that will contribute to
210

the successful execution of the other one), but their interaction is hampered either by the underlying
211

ontological formalism or by the sequence of actions taken
by the two processes, the Process Mediator
212

has the role of providing the necessary mechanism for solving these heterogeneity problems. As a
213

service, a Process Mediator operates on two processes, represented in a certain formalism. It needs to
214

know on what
particular stage of the execution the two processes are, and what outputs have already
215

been generated by the two processes.

216


217

[Baeten, 2005] in his well known history of process algebra, provides several definitions for processes.
218

One of them states that a

process consists of a number of states and a number of transitions for going
219

from one state to another. The draw
-
back of this model is the lack of mechanisms for modeling the
220

interaction

aspects


that is, during the execution from initial state to the fi
nal state, a system may interact
221

with another system. Considering this definition with respect to the choreography definition of a Semantic
222

Web Service, the choreography model can actually be considered a process, with the additional
223

advantage of offering
information regarding these interactions.

224

In this context, the process mediation interface needs to be adjusted as defined in the following table

225


226

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#

2

[rm#Choreograhy,
<identifier>]

2

<identif
ier>

1




227

4.1.6

Transport Handler

228

The purpose of SEE is to enable the more flexible discovery, selection, composition and invocation of
229

Web services. Invoking a Web service means sending a message over the wire
,

using one of a number of
230

combinations of transpo
rt and messaging protocols. The Transport Handler is responsible for encoding
231

any required protocols for outgoing messages and decoding any such protocols for incoming messages.

232

Needs more.

233


234

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)





4.1.7

Grounding

235

Within SEE, all data types are instances of the semantic concepts from the SSOA RM. However, as the
236

majority of existing Web services communicate using XML messages, transformations from the semantic
237

data to XML (and vice versa) is necessary. Th
ese transformations are called
lifting

(from XML to
238

semantics) and
lowering

(from semantics to XML). Both lifting and lowering can potentially be achieved
239

with a single bidirectional mapping specification.

240

The grounding transformations are required in orde
r for the SEE to be able to invoke a Web service. For
241

instance, Choreography Execution will be creating
service
-
invocation events

that identify the Web service
242

operation to be invoked, along with any required input data. As shown in Figure 2, this data is
lowered
243

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
14

of
24


into an XML message that is then sent to the Web service, and any XML message coming back is then
244

lifted back to the semantic form that can be used by the SEE.

245


246


247

Figure 2: An illustration of lifting and lowering grounding transformations

248


249

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)





4.1.8

Choreography

Execution

250

The Choreography part of a service interface describes the behavior of the service from a client point of
251

view; this definition is in accordance to the following definition g
iven by the W3C Glossary [W3C Glossary,
252

2004]:
Web Services Choreography concerns the interactions of services with their users. Any user of a
253

Web service, automated or otherwise, is a client of that service. These users may, in turn, may be other
254

Web Serv
ices, applications or human beings
.

255

After discovering a Web service description, one has to know the observable behavior of the Web service
256

in order to achieve the desired functionality. Choreography Execution is responsible for using the
257

choreography desc
riptions of both the service and goal to drive the conversation between them. It is the
258

responsibility of Choreography Execution to maintain the state of a conversation and to take the correct
259

action when that state is updated. For example, the update of t
he state of a choreography instance may
260

be the result of a message received from a service provider. The consequent action, as described in the
261

choreography instance, could be to forward the unchanged message to the service requester.

262


263

In SSOA RM, we propo
se the use of abstract state machines as the formalism for the rule
-
based
264

description of choreographies. Choreography Execution in the SEE architecture has three main
265

responsibilities:

266



Evaluating the transition rules defined in the Choreography Interface d
escriptions

267



Determining the legal instances after each transition fires

268



Driving service invocation through creation of service
-
invocation events

269


270

During the first step, the interface
choreography
descriptions
of the goal and Web service
are fetched

and
271

in
stantiated
. Once
both

choreographies are initialized, the start of the conversation is triggered by the
272

instance data sent by the requester. This leads to
establishment of a conversation
. During the interaction
273

between the two choreographies, the data bein
g exchanged is appropriately checked for conformance
274

with respect to the choreography description
.
Process and data mediation are used as required
.
275

Furthermore, during the evaluation of the rules, the choreography engine sets up the data required for
276

invoc
ation from the choreography description. The Choreography Engine does not perform the invocation
277

itself but rather
creates the appropriate service
-
invocation events.
The interaction between the two parties
278

stops when either a choreography fails or all the
required input data from the requester is consumed.

279

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
15

of
24


rm#WebService

1

rm#
Instance

0..1

rm#Goal

1



4.1.9

Orchestration

E
xecution

280

Web services may use a composition of other Web services, goals and med
iators to provide their
281

functionality. In such a case, execution of the Web service involves the invocation of an Orchestration
282

Engine over the orchestration of the service, which is a process model. Each step within an orchestration
283

process may involve th
e evaluation of logical expressions over an ontology, the execution of a new goal,
284

Web service or mediator, or the interaction with a goal or Web service, and as a result the update or
285

storage of instances in an ontology.

286


287

Input

(type)


(multiplicity)

Outp
ut

(type)


(multiplicity)

rm#WebService

1

rm#Instance

0..
1


288

4.2

Base

Services

289

The lowest layer within the SEE reference architecture is the base service layer, which provides low level
290

functionality required by the broker layer above.

This layer can be view

as a utility layer providing the
291

generic tools needed to perform my complex functions at higher levels.

292

4.2.1

Logical Reasoner

293

The semantic markup of Web services using specific ontologies provides the knowledge required by
294

computer systems to help them automat
e tasks that otherwise require human intervention at run
-
time.
295

Combining ontology
-
based markup with logic and reasoning provides very powerful instruments.
296

Knowledge represented formally, using logical languages, can be interpreted and reasoned about by
297

ma
chines. Reasoning allows implicit knowledge to be inferred from existing knowledge and form an
298

extremely powerful tool when combined with ontologies.

299

In the context of SEE, the Reasoner component is required for discovery as well as both process and
300

data
mediation. As a starting input, the current release of the WSMX Reasoner component allows for
301

hierarchical queries on concepts, such as requests for sub
-
concepts or super
-
concepts, entailment and,
302

some support for queries against the knowledge base availab
le to the reasoner.

303

The Semantic Execution Environment (SEE) needs the reasoning component for service discovery as
304

well as both process and data mediation. To enable processing of these tasks in an automated manner,
305

machines need to have access to structu
red knowledge. Knowledge described formally using logical
306

languages can be interpreted and reasoned about by machines.

The Reasoning component in the SEE
307

architecture provides an infrastructure for defining, managing and reasoning about formally represente
d
308

knowledge
.

309

4.2.2

Repository

310

The repository component within the SEE reference architecture is responsible for storing all those
311

elements of the SEE Reference model needed by other components within the architecture in order to
312

fulfill their functionality. Th
us the repository must be capable of storing ontologies, goals, web services
313

and mediators. In terms of functionality over this repository of content it must be possible for new
314

elements to be stored within the repository, existing elements to be retrieved

or removed from the
315

repository, and information provided to a requester about the contents of the repository.

316

Store Ontology

317

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
16

of
24


Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#
Ontology

1




318

Store Web Service

319

Input

(type)


(multiplicity)

Outp
ut

(type)


(multiplicity)

rm#WebService

1




320

Store Goal

321

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Goal

1




322

Store Mediator

323

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

rm#Mediator

1




324

Retrieve Ontology

325

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Ontology

0..1


326

Retrieve Web Service

327

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#WebService

0..1


328

Retrieve Goal

329

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Goal

0..1


330

Retrieve Mediator

331

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
17

of
24


Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Mediator

0..1


332

Remove Ontology

333

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Onto
logy

0..1


334

Remove Web Service

335

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#WebService

0..1


336

Remove Goal

337

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Goal

0..1


338

Remove Mediator

339

Input

(type
)


(multiplicity)

Output

(type)


(multiplicity)

<Identifier>

1

rm#Mediator

0..1


340

List Ontologies

341

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)



<Identifier>

0…*


342

List Web Services

343

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)



<Identifier>

0…*


344

List Goals

345

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
18

of
24


Input

(type)


(multiplicity)

Output

(type)


(multiplicity)



<Identifier>

0…*


346

List Mediators

347

Input

(type)


(multiplicity)

Output

(type)


(multiplicity)



<Identifier>

0…*


348

4.3

Vertical Services

349

Needs Intro

350

4.3.1

Service manage
ment

351



Deploying and managing of services for SEE middleware

352



Management of service descriptions in the SEE registry

353

4.3.2

Security

354

Security is ubiquitous across all layers and must be entwined with each middleware service as
355

appropriate. Additionally there may be

authentication and authorization control for access to SEE as a
356

unit.

357


358


359

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
19

of
24


5

Process View

360

This section should contain simple UML diagrams for each of the processes that SEE supports. UML
361

sequence diagrams may be easier to read than activity diagrams.

Existing

material is available from the
362

earlier SEE Architecture intermediate deliverable and DIP and Knowledge Web research project.

363

The processes should be a superset of
those supported by IRS and WSMX as two concrete architectures
364

and implementations for SEE.

365

5.1

Processes in the Context of SSOA

366

5.2

Describing process
behavior

as Execution Semantics

367

5.3

Goal
-
based Discovery Process

368

5.4

Service Invocation Process

369

5.5

Achieve Goal (Discovery and Invocation) Process

370

5.6

Summary

371


372

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
20

of
24


6

Future Work

373

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
21

of
24


7

References

374

[Baeten, 2005] J. C. M. Baeten:
A b
rief history of process algebra,
Theoretical Computer S
cience, 335(2

375

3):131

146, 2005.

376

[Norton and Mocan, 2007] B. Norton and A. Mocan:
Reference Model for Semantic Service Oriented
377

Architecture
, OASIS Semantic Execution Environment Technical Committee Dra
ft, 2007

378


379

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
22

of
24


Appendix A.

Acknowl
e
dgements

380

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
23

of
24


Appendix B.

Appendix A


SEE
API (
Operations
)

381

OASIS SEE TC Architecture and Information Model


08 September 2006

Copyright
©

OASIS Open 2006. All Rights Reserved.


Page
24

of
24


Appendix C.

Revision History

382

[optional; should not be included in OASIS Standards]

383


384

Revision

Date

Editor

Changes Made

1

23
/
02
/200
7

matt
hew.moran@deri.org

First ToC of SSOA RA specification taking
draft specification for SEE Architecture and
Interoperability v0.1 r16, as foundational
input.

2

18/04/2007

matthew.moran@deri.org


Added initial
content for section 3: Global
View and section 5: Services View. The
content came from existing work within SEE
directly and from a journal paper on SESA,
referenced and to be published in June
2007.

3

16/05/2007

mick.kerrigan@deri.org


Minor editorial changes, added comments to
existing text and built to
-
do list for the next
revision

4

16/06/2997

mick.kerrigan@deri.org

New content on Data Mediation from Adrian
M
ocan, on Orchestration from Barry Norton,
and
Process Mediation
review by Emilia

Cimpian
. Interfaces for *most* of the
components along with Additional content
additions in the headings of some sections
and general editorial contributions by Mick

Kerrigan
.

5

21
/07/07

mick.kerrigan@deri.org


New content on composition from James,
new content on grounding from Jacek.
Updates of interfaces and descriptions from
Mick.

Process Mediation updated by Emilia.

6

29/08/
07

b.j.norton@open.ac.uk

New content on Reference Model.


385