Database Reference
In-Depth Information
Composition/Process
Services' composition is actually what we are aiming for. A simple and descriptive repres-
entation of the service composition is the main goal of the Service Repository's taxonomy
and the foundation for Service Broker.
So, a Process as a Service Composition is a sequenced collection of Services performing
the Operations and assuming the Roles in order to fulfill the complex business logic of
transporting (with possible transformation) of the Object in the form of a Message
between Applications Composition members, presented via public Endpoints (contract,
interfaces), initiated by the Business Event, occurred in the Composition Initiator.
This statement pretty much formalizes the XML entity we will further denote as composi-
tion Execution Plan (EP).
It is also visible from the description of the execution plan that, for its discovery, we need
the names of three entities as input parameters:
• Object
• Event
• Service-Composition Initiator
The properties of the Compositon/Process are
COMPOSITIONLIST_ID
,
PROCESS_ID
,
SERVICE_ID
,
TASK_ORDER
,
OPERATIONTYPE_ID
, and
ROLE_ID
.
Rules
Rules are governing conditions used to control the common aspects of service activities.
Rules Centralization is one of the core SOA patterns employed to establish the Service
Repository in general. However, rules are special because the rule storage realization de-
pends on a particular Rule Engine. Rule Engine (RE) is a special form of Service Engine
with very high performance demands, and these demands are usually accommodated by
placing rule storage as close to the engine as possible. The most obvious repository realiz-
Search WWH ::
Custom Search