2016 IEEE World Congress on Services Computing
A Novel Method and Environment For Scalable Web Services Orchestration
Venkatesan Devanathan
Anna University, Chennai, India
d.venkatesan@aubit.edu.in
Abstract—One major problem with flow based web service
composition is its explicit dependence on the partner link
WSDL files to compose and invoke partner functionality. This
implicitly ties up (rather freezes) the participants of the
composition in a client -server fashion preventing possibility of
partnership evolution or tweaking (say based on certain
business rules). This hard partner links reduces flexibility, and
reliability of the composition. This work suggests speech-act
like message based (dynamic) composition of partner links in a
web service orchestration by introducing middleware
infrastructure namely OIMS (open interaction middleware
service) middleware that act like a broker cum proxy between
collaborating web services. This architectural model is argued
to have better error resilience and adaptability than traditional
hard partner links. This work suggests an implementation
environment that extends WS-BPEL syntax to arrive at IOIAF
(intelligent open interaction application framework)
programming or realization environment for the same.
Keywords- Web Services Composition; Speech Acts; WS-BPEL
Middleware Application Architecture; Business Process
Modeling & Composition
I. INTRODUCTION
Services computing paradigm provides important
abstraction layer over traditional computing infrastructure
such as components to make them interoperable.
Technologies/standards such as XML (for platform inter-
operability) and WSDL (for interface abstraction of the sever
component at the client side) offer critical interoperability
foundation for individual computing resources. Web services
revolutionized the component integration using messages
between interacting partners rather than by direct coupling as
in traditional approaches. But web services composition
methods still retains client-server flavor. The partner links of
the collaboration are specified statically at the design time.
This traditional design principle or aspect can be tweaked
and modernity (or innovation) can be introduced here.
Like WSDL introduced a separation / abstraction layer
for interface from its implementation, this work suggests a
separation of need to depend on explicit WSDL interfaces
and its hard coded URI while arriving at design of
orchestration applications. Orchestration applications should
be free to choose any partner link meeting the specified
criteria at run time as well. Effectively the web applications
should not worry about the exact client (WSDL) interfaces,
its syntax and service locations (given in its URI) at design
time. It is proposed here that orchestration should be based
on a generic WSDL interface that is depicted as set of OIMS
message (explained in section II.B) templates for each web
service port types. This will free up client dependency on
978-1-5090-2616-6/16 $31.00 © 2016 IEEE
DOI 10.1109/SERVICES.2016.27
Authorized licensed use limited to: Instituto Nacional De Telecomunicações (INATEL). Downloaded on August 05,2022 at 22:02:33 UTC from IEEE Xplore. Restrictions apply.
Sridhar Sundaramurthy
Anna University, Chennai, India
s.sridhar@annauniv.edu
partner link URIs explicitly making orchestration truly
distributed rather than client-server in nature. To the best of
our knowledge, this kind of web service orchestration [3] has
not been attempted in the past. Traditional dynamic
composition approaches do not use middleware [3].
II. ARCHITECTURE MODEL OF OPEN MIDDELWARE
INTERACTION SERVICES (OIMS)
A. OIMS based information systems architecture.
Design of enterprise information systems by composing
discrete web services has several road blocks such as
availability, QoS, reliability and governance. Service
aggregation support the automation of business processes by
loosely coupling services across different departments /
enterprises. Traditional service orchestration works by
exchanging SOAP messages at the application layer level.
Individual services are not programmed to communicate
with other services. In the composite applications,
application level data elements (that is part of orchestration
application) must be exchanged, manipulated and populated
as messages between services. These modifications are as
per the business logic and this constitute the effect of
collaborative data processing. It is proposed here to extend
traditional WS-BPEL programming environment (called
WS-BPELX) to support open partner link orchestration. This
resulting environment is called as IOIAF (intelligent open
interaction application framework)(explained in section III).
WS-BPELX applications warrants a middleware (namely
open interaction middleware services – OIMS) that support
and act as a broker or proxy for the exchange of messages
between client application and partner links at run time.
Figure 1 depicts the inter-relationship between various
application components that make use of OIMS. OIMS
middleware protocol stack is shown in table 1.
Table 1 OIMS protocol stack
SOAP based OIMS messages–encoded in WS-Addressing
XML based SOAP messages
HTTP or equivalent transport & lower level layers
It may be noted that OIMS middleware is still a services
standard complaint service and hence interoperate using
SOAP messages. OIMS messages are specially loaded into a
regular SOAP messages and delivered to OIMS middleware.
B. OIMS message format
OIMS messages adopts tailored version Agent
Communication Language (ACL) standard of FIPA/IEEE
body [2]. This is done with a goal of future expandability
and incorporation of results obtained in ACL based system
integration research(1,4),as this work use “ask” and tell”.
128
 OIMS

Client (IOIAF composer

OIMS messages Message

WS-BPELX_Application
Application ..N

messaging
based router

Invoked Operation PT
OIMS
(WS-BPELX Script)

SOAP messages
orchestration and Application 2

PT
partner link Application1

PARTNERLINK
invocation OIMS

OIMS messages
Message Web Service
& launcher)

HOST..1
router applications 1..N

messages
SOAP

1..N
PARTNERLINK
HOST..2..to..N

Fig. 1 Schematic of WS-BPELX Client (IOIAF) Orchestrator, OIMS middleware and WS-Partner links node
Figure 2 shows message structure of OIMS messages. In III. IMPLEMENTATION ENVIRONMENT
OIMS <<speech-act-type>> is restricted to only “ask” and IOIAF is realized by extending popular WS-BPEL
“tell” performatives.“ask” message is sent by orchestrating orchestration platform (like JBOSS Riftsaw/Apache ODE).
client to OIMS middleware that in turn process the The service application designers- at design time- need to
“content” datum to decide upon the partner link to choose specify End Point Address (EPA) equivalents- in terms of
and invoke. OIMS takes up the responsibility of partner link OIMS message templates -along with application specific
invocation and returning of the results to the WS-BPEL constraints such as QoS, cost and response time. IOIAF
orchestration client application. The “content” filed has a replace “invoke” constructs of WS-BPEL with
description of WS input, output, metadata of interaction, “OIMSInvoke” to leverage OIMS. OIMSInvoke codifies
specification of rules of interaction (such as QoS or partner link invocation using designer provided information
reputation or popularity index) and choice of partner links to using WS-Addressing technology; <wsa:To/Action> fields
choose from. This permits traditional simplicity and at the now carries end point addressing information as a OIMS
same time permits error resiliency and evolution if desired. speech act to OIMS middleware. OIMS decodes this speech
The “content” parameter may adopt rigorous logical syntax act to determine actual EPAs at run time and invokes one or
such as Knowledge interchange format or OWL-DL [1,4]. more service EPs (application level multi-casting is possible
(<<speech-act-type>>
here that is relevant to IOT domain; a controller can receive
:sender <<sending-WebService-Id>> update from all partnered clients using a single message).
:receiver <<receiver WebService Id/description>> EPs can respond back to invoker in synchronous or
:content <<action-specification such WS input, asynchronous manner using connected message Id. IOIAF
output, preferred partner locations/QoS/Cost..>>
:ontology <<adopted-ontology-type in CONTENT>> do not envisage any changes to the underlying web services
:sa-msg-id : <<message-Id>> infrastructure and localizes innovation only to OIMS
:in-reply-to <<conversation-Id>> ) middleware, client application level thus ensuring backward
Fig. 2 Syntax of OIMS speech act like messages compatibility to existing services. Separation and indirection
OIMS message templates (table 2) are formulated based by OIMS mediation among service collaborators permits
on a typical WSDL file of a partner link application increase of application throughput, scalability and resilience
category. This can be provisioned by the WS provider (due to separation of concern). Thus need for hardcoded link
themself during design time like OWL-S annotation and between clients/consumer and server/provider is obviated.
published along with WSDL. For each port type of the IV. CONCLUSION
WSDL there exist a OIMS message template section (that
specify input, output, operation name, bindings and other OIMS middleware adaptively/configurably mediate
business/ orchestration constraints & rules). OIMS message services orchestration of clients. WS-BPELX applications
formats are suitable for encoding into OIMS speech acts: Its are backwards compatible to existing environments hence
“content” parameter specifies input, output parameter types OIMS/IOIAF proposed here likely to find favor industrially.
and datum, operation name, ontology mapping & inference Existing WS-BPEL applications can be selectively extended
rules, applicable business rules/constraints that needed to be with IOIAF constructs wherever it provides real benefits.
fulfilled by partner before it can be chosen by OIMS engine REFERENCES
for linking as a service partner at run time. [1] B. Schiemann,U.Schreiber.OWL-DL as FIPA-ACL content language.
Table 2 OIMS Message Dependency Stack(visible at IOIAF) In Formal Ontology for Communicating Agents, Malaga, Spain,2006
OIMS message template–WSDL document based [2] FIPA Specification-ACL- Part 2. FIPA, 1998. http://www.fipa.org
Component Interface definition – in terms of WSDL [3] Pablo Rodriguez-Mier et al., Automatic web service composition with
Component implementation- Binary format a heuristic-based search algorithm. DOI: 10.1109/ICWS.2011.89.
[4] Michael A. Covington, Speech Acts in Electronic Communication.
13thConference on System Sciences. ISBN 0-8186-7862-3/97. 1997

129

Authorized licensed use limited to: Instituto Nacional De Telecomunicações (INATEL). Downloaded on August 05,2022 at 22:02:33 UTC from IEEE Xplore. Restrictions apply.