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