Information Technology Reference
In-Depth Information
3.1.1 Domains and Data Relations
Various languages exist formodeling. Thus, we utilize one that is common
to represent the artifacts we are working on. Colored Petri nets [87]
capture both control and data aspects of a process. In this chapter, we use
them as a common model for both business processes and services.
There are two domains involved in the scenario of service compo-
sition:
business
and
service
. Business domain is also known as the
requirement specification domain in which requirements are repre-
sented by business processes consisting of abstract activities with
input/output data. Service domain is also known as the implementation
domain in which a service is modeled by a set of operations with
input/output data modeled as messages in WSDL.
We borrow some ideas from the UML class diagram and type
definition in the XML schema. Two kinds of relations, in-domain
relation and cross-domain relation, are of our concern. From now
on, the data types in the business domain are denoted with uppercase
strings, while those in the service domain with lowercase strings.
Before we start to define data relations, we need to emphasize the
difference between
data
and
data type
.A
data type
defines a set of
values that a
data
element can take. Since this chapter is about service
composition at build-time (instead of at runtime), we focus on “data
type” instead of “data.” Therefore, except those otherwise noted, the
term
data
also refers to
data type
throughout this chapter. For example,
when we talk about “data relations,” we mean the relations between two
data types. We believe that this can simplify the expression and readers
can easily catch the exact meaning through the context.
In-Domain Relations
We need to use the following in-domain relations:
Aggregation
:
has-a
relation;
Generalization
:
is-a
relation; and
Generation
:
The relation between input and output data types
of a business activity or service operation.
Consider a real-life example, that is, an ADSL Order Processing
Service (AOPS) provided by a telecommunication company. Note that
this example is taken from a real customer case in IBM SOA solution
