Introduction to Service Domain Spaces: Enforcing Valid Semantic Constraints on Service Composition

schoolmistInternet and Web Development

Oct 22, 2013 (4 years and 21 days ago)

83 views

Introduct
ion to Service Domain Spaces: Enforcing V
alid
Semantic Constraints on Service Composition


Jeremy Caine

IBM Global Business Services

jeremy_caine@uk.ibm.com


October

2006


Abstract

-

This paper int
roduces the conce
pt of Service
Domain Space
s
. They are a new validation construct that
can help design valid composite services within a given
semantic context. S
uch constructs

could be used informally
as part of service
-
based system design, or more formal
ly in
middleware. Options discussed will be the use of RDF and
OWL technologies to define the semantic relationship
contract, and the extension of Service Component
Architecture to attach the constraint within composite
service assembly and runtime envir
onments. The paper
articulates the need to consider valid semantics in service
composition and potential middleware and tooling
implementations; and will be used to explore how
development of the ideas can be progressed

Keywords:

SCA, semantic, constraint,

validation,
composite, domain
.

1

Introduction



In a service
-
oriented architecture (SOA) we define a
set of business
-
aligned services that are typically

realised

through a set of collaborating software components.
A
co
mposite application (a.k.a.
SOBA
1
) invo
kes a collection
of these

realised

services to support some business
processing.
A service is an operation accessible via
a
well
defined interface. A service consumer binds to the service
and invokes the operation using particular connection
protocols and
exchanges data messages. In non
-
trivial
systems these services are often combined in a
collaboration hierarchy.

The
re

are two types of
collaboration
models relevant to
service composition: dependency processing and workflow
processing.

1.1

Dependency Processin
g


The traditional “call stack” programming model where
the invocation of a service requires the invocation and
response of other services before it can return its response



1

Service
-
oriented business application (SOBA) is a term
coined by Gartner.

to the service consumer. This sort of processing typically
occurs in a transaction
processing managed environment.

1.2

Workflow Processing


A long running asynchronous programming model
where the service consumer does not wait for the service to
complete its processing, rather the consumer is event driven
and reacts to service responses from

the workflow. The
workflow chains a number of services together to

fulfil

its
processing; of course some of those services can be
composite services themselves. A workflow manager
operates in addition to one or more transaction processing
environments and

usually manages state information
relating to the service consumer’s workflow instance; this
state information can be used by the various services
invoked within the workflow.

Collaborations are designed to have

some overall context
within their

processin
g. For example, service
s that
collaborate to set
-
up
a new bank account. The overall
exchange of messages between services needs to be
meaningful to the collaboration whilst the execution of a
particular service is stateless

(in the context of the
collabora
tion)

and stand
-
alone simply exposing it’s i
nbound
and outbound processing.

A service does not usually “understand” the collaboration
processing context that surrounds the data in the message it
is receiving. A request / reply service takes an inbound
mess
age, validates the various schemas of data in the
message, possibly adapts the data, uses this data in the
internal processing of the service’s business logic, and then
performs processing on the data for transmission of an
outbound message.

This article p
roposes a method for applying meaningful
constraints on the collaboration of a service composition.
These constraints can be used to validate th
e service
composition at
design time (“assembly”) and potentially at
run
-
time.

1.3

Service Component Architecture

Se
rvice Component Architecture (SCA) [1] is a
set of
specification
s used to describe and facilitate the
composition of software services.

It uses a
declarative
language through which the composition of services can be
specified.
A composite application is de
livered through an
implementation model and an assembly model. Services are

realised

as software developed using a variety of
programming languages and programming styles. Business
applications are assembled through the wiring of service
interfaces.



Fig
. 1. An SCA model (see [1])

SCA is an extensible set of specifications that allow richer
capabilities to be developed into business application
design and runtime. It is this feature that is consider later as
a means to inject semantic processing with the
design or
runtime of a software system.

2

Defining

a Service Composition

Relationship


In order to validate a service composition we need to
define valid interactions of services


the messages that are
passed in and out of service operation calls. A service

composition flow will have the outbound message of one
service operation becoming the inbound message of another
service operation. We need
first
to ensure that when the
service composition is designed it is valid that the
semantics of a message are relev
ant to that outbound and
inbound message usage.

It is important to note at this stage that this composition
validation is optional. There may be design scenarios when
the overall collaboration of a system needs to be done in a
robust and precise domain of
interest. That domain will
attach specific relationships and meaning to its data.

A trivial example will be used to illustrate this constraint
validation scenario.

Consider the following set of services:



Area



a set of operations to make various 2D surfac
e
area calculations.



Arithmetic



a set of operations to perform simple
arithmetic calculations, such as add, subtract, multiply
etc.



Weather



a set of operations relevant to weather
measurements, such as Celsius /Fahrenheit temperature
conversions.

One
system design scenario could be the creation of a new
composite service


Building


that provides operations to
calculate and describe aspects of a building architecture.
For example, given a set of room dimensions the Building
service could return the to
tal floor area offered by the
building. In order to create this service it would make sense
to use the Area service to calculate individual room areas
and the Arithmetic service to add up all the room areas so
that a total floor area can be calculated. It
clearly makes no
sense to use the Weather service temperature conversions
as part of Building service.

The service operations of Area, Arithmetic and Building
use messages defined by various data schemas. At the data
processing level the elements of these
different messages
could be the same data type e.g. decimal for XML schemas
would be xsd:decimal.

Without composition validation it
would be possible to combine Area and Weather in a
service composition that has no real meaning.

3

Proposal


The proposal is t
o add semantic constraints for service
compositions through the attachment of an external policy

contract to the service composition definition.
The service
definition itself describes only the
syntactic relationship of
message flows through the collaborat
ion. The policy
contract definition describes the valid semantic relationship
of message flows through the collaboration. The default
validation is that if no semantic relation is defined the
composition is not valid.

The composition constraint and the ser
vices it relates
are

known are known collectively as

a “domain space”


a
contract within which a domain
of
semantic relationship
exists.


Fig. 2. Initial view of
domain space contract

These domain spaces are formal descriptions of the correct
and allowab
le uses of software service. The domain space
sets context by which the s
emantic processing (such as
rules, proof etc) can occur. This formal description serves
to remove inference on how services should interact with
each other.

4

Solution


A potential impl
ementation of this concept is related
to Web Services and Service Composition Architecture
(SCA). In an SCA environment services can be combined
in modules and systems. A “wire” defines the message flow
between two services. The extensible nature of SCA al
lows
for policies to be attached to

artefacts

within the
composition. The composition constraint contract could be
associated with the wire.

The composition constraint contract itself could be
described using RDF

[2]

and OWL

[3]
. The service
operations (We
b Services
-

WSDL port type operation

[4]
)
would be RDF resources and OWL representations could
describe what RDF resource relationships are possible.

The constraint contract can then be implemented as piece
of
semantic software processing using whatever s
emantic
runtime technology is appropriate to the domain space.


Fig. 3. Extending the SCA implementation

The Figure 3 overlay shows how the domain space contract
could be implemented as some semantic processing
software and bound into the service wiring.

As part of defining a service model through a set of WSDL
descriptions, a designer could also define the valid domain
spaces

(which could utilise SAWSDL [5] and OWL
-
S [6]
for example)
. The service composition assembly
environment could validate composition
s against the linked
domain space contracts. This would ensure meaningless
compositions could not be produced.

Bibliography

Subsequent to writing this paper, the following reference
was found offering a similar insight to solutions to this
problem.

http://www.geodise.org/files/Papers/ISWC4
-
8
-
final.pdf


References

[1]

Service Component Architecture,
http://w
ww
-
128.ibm.com/developerworks/library/specification/ws
-
sca/


[2]

Resource Description Framework,
http://www.w3.org/RDF/


[3]

Web Ontology Language,
http://www.w3.org/TR/owl
-
features/


[4]

Web Services Description Language,
http://www.w3.org/TR/wsdl


[5]

Semantic Annotations for WSDL and XML Schema
,
http://www.w3.org/2002/ws/sawsdl/spec
/


[6]

OWL
-
based Web Service Ontology,

OWL
-
S
(formerly DAML
-
S)
,
http://www.daml.org/services/owl
-
s/