International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010
Dependable ESB Routing in Hybrid Service Execution Environment∗ Yang Zhang State Key laboratory of Networking and Switching Technology, Beijing University of Posts & Telecommunications, Beijing 100876, China
[email protected] doi: 10.4156/aiss.vol2.issue1.7
Abstract Meshing up telecommunication and IT services is a big challenge to support the evolution towards the next generation services over heterogeneous networks. Adopting hybrid service execution environment builds a corner stone for IT/Telecom service integration. However, how to make them work coherently and assure the quality of service is a key issue in the hybrid service execution environment. In this paper we propose a high level architecture of the environment and dependable ESB routing scheme to address the issue. The architecture depicts how to support both request/response and publish/subscribe service interaction paradigms. The routing scheme depicts how to improve service availability and reliability for the two interaction paradigms. Finally, the application of the approach is given.
Keywords: Enterprise Service Bus, Service Execution Environment, Service Routing 1. Introduction Telecom service providers are always seeking new paradigms of service creation and execution to reduce new services’ time to market and increase profitability. New market opportunities like integration of voice, video and data services are emerging. Therefore, telecom service providers try to develop next generation services that leverage both on the Internet and on telephony networks. That is to say, the convergence and integration of services is offered by IT providers with telecom operators ones [1][2][3]. The reuse and integration of exiting IT services in value added ones is very difficult for the increasing software systems complexity and the different middleware standards used for communications. Generalizing telecom functionalities offered by telecom service execution environment to more abstract standard interfaces is often necessary to allow IT developers to reuse and integrate telecom services. Although telecom functionalities are abstracted and implement as telecom services, they are still different from IT services. Service interactions among telecom services are often event-driven and asynchronous. Therefore, these goals pose new requirements on the execution environment for hybrid services. The IT service execution environment and the telecom service execution environment can work coherently together with Enterprise Service Bus (ESB) collaborating different interaction paradigms. Service-Oriented Architecture (SOA) proposes the prevailing software paradigm for dynamically integrating loosely coupled services in a distributed heterogeneous environment. Specifically, ESB supports transparent service integration and routes messages among services [4] [5] [6]. ESB also provides functions such as data format transforming, message routing, and service management. It is the most important that ESB provides both the request/response interaction paradigm and the publish/subscribe interaction paradigm, which satisfies the requirement of telecom service integration. However, current ESB routing techniques and tools do not explicitly support some important system’s issues such as dependability. We can make some key observations about ESB routing dependability. First, a dependable ESB routing scheme is necessary to deal with the network’s complexity and dynamism. In addition, if ESB is ∗
Supported by the National Natural Science Foundation of China under Grant No. 60432010; National Grand Fundamental Research 973 Program of China under Grant No. 2007CB307103; China Postdoctoral Science Foundation funded project under No. 20090450335.
83
Dependable ESB Routing in Hybrid Service Execution Environment Yang Zhang with a central architecture, it will have a single point of failure because large–scale environments are open, dynamic, and complex. Thus, a dependable ESB framework should have a distributed architecture. Second, ESB routing scheme need provide automated adaptation mechanism to ensure continuous operations despite node failures or unpredictable load fluctuation, such as a load balancing method to improve availability in service integration. Thus, a ESB routing scheme should have a distributed framework and provide dependable mechanism for improving composite service’ availability and reliability. This paper proposes a dependable Hybrid Service Execution Environment (HSEE) framework. In order to implement the dependability, a dependable ESB routing scheme is constructed, which functions load balancing and failover. An Abstract Service Routing Table (ASRT) is defined using abstract service names and subscription content by which composite services are orchestrated and dynamically routed. ASRT is instantiated at runtime by replacing the abstract service name with the URI of the real service providers, or by matching subscription content with published events to forward published events. At runtime, the dependable routing scheme uses virtual group and rendezvous point to model dependable service routing in the Service Overlay Network (SON). Based on the model, load ratio algorithm and distributed feedback control algorithm are adopted to realize load-balancing routing and failover. Most of current research try to design dynamic service routing in ESB [7][8][9]. The Abstract Routing Table for business processes in [7] is similar with our ASRT, but it did not address the dependable issue. In the work of [8], a content-based routing scheme was proposed. It did not address the dependable issue either. The work of [9] proposed dynamic reliable service routing in ESB, but whether it supported load balancing and failover is unknown. Our work is similar to the work of [10]. While it put focus on cluster scenarios and failure recovery, our work tries to address the issue in general scenarios and provides load-balancing and failover capacity. The work of [11] mainly provided a framework for runtime service diagnose and adopted dynamic reconfiguration for recovery. It did not specify whether load balancing can be achieved. The contribution of this paper is two-fold. Our first contribution is that the dependable ESB routing model is proposed for HSEE in the SON. Our second contribution is the design of a novel dependable ESB routing algorithm to realize load balancing and failover. The rest of the paper is organized as follows. Section 2 proposes high level architecture of HSEE. Section 3 depicts the routing model and algorithm. Section 4 describes applications. Section 5 summarizes the research.
2. High Level Architecture of the Hybrid Service Execution Environment To overcome inherent constraints the current vertically integrated networks are currently migrating to horizontally layered structures offering open and standard interfaces, that is, a service platform, based on shared services and network enablers. Therefore, these goals pose new requirements on the execution environment for hybrid services to support thus platform. JAIN-SLEE (Jain Service Logic Execution Environment) [12] [13] [14] standard specification is emerging as a new event-based service execution environment targeted to telecom domain, aiming at overcoming the performance limitations of J2EE-like application server based on request-response interaction style. In fact, communication services have strong real-time requirements, support mainly asynchronous interactions, and leverage efficiently on native protocol capabilities. Generalizing telecom functionalities offered by JAIN-SLEE to more abstract standard interfaces is often necessary to allow IT developers to reuse and integrate telecom services. Although telecom functionalities are abstracted and implement as telecom services, they are still different from IT services. Service interactions among telecom services are often event-driven and asynchronous. In addition, different networks might only have a pool of services, but with service blending across networks, more automated service delivery capabilities should be provided with the keys being the self organization of the service overlay network and service dependability. Based on the former ideas, a distributed service delivery platform has been developed (named BSDP platform) in our team. The hybrid service execution environment plays a key role in the platform to
84
International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010 integrate services at runtime. Dependable routing mechanism in ESB provides the assurance of service availability, service reliability within the hybrid service execution environment. Figure 1 depicts the architecture of the hybrid service execution environment.
Process Enterprise Service
Engine Service
Management
Bus Service
Management
Service
Configuration
Service
Configuration
Broker
Framework
Broker
Framework
Overlay Network Layer
Overlay Network Layer
Heterogeneous
JSLEE
Network
JSLEE
Figure 1. High level architecture of the Hybrid Service Execution Environment
Telecom service building blocks in JSLEE are exposed as web services through an ESB adapter and service registries in ESB. The core functionality of an ESB is supporting disparate applications and services to communicate using different protocols. It also enables services to interact with each other based on the quality of service requirements of the individual transactions. The ESB service broker provides content-based routing for dispatching publish/subscribe messages from one service to another service. Distributed ESB nodes over heterogeneous networks self-organize into service overlay network, and the overlay network layer in ESB functions self-organization. Process engines are in charge of service orchestration. Current BPEL4WS (Business Process Execution Language for Web Service) language offers several workflow features, like Sequence, Parallel Split, Synchronization, Exclusive Choice, Simple Merge, Multi Choice, Synchronizing Merge, and Implicit Termination, but it does not allow to define interactions based on publish-subscribe pattern. Based on WS-Notification, the ESB service broker can act as event-broker, and Process Engine can act as a local application to support the publish/subscribe paradigm. Therefore, IT services and telecom services can interact asynchronously and integrated.
3. Dependable ESB routing scheme When IT services and Telecom services are integrated, the request/response and publish/subscribe interaction model both should be supported in the HSEE. For telecom services, the quality of service should be assured without regard to the interaction model. The ESB plays a key role in the HSEE to support transparent service integration and routes messages among services. In addition, a dependable routing scheme in ESB can provide some QoS assurance for services. Because large–scale environments are open, dynamic, and complex, ESB products with a central architecture also have a single point of failure. Thus, a dependable ESB framework should have a distributed architecture, and an ESB routing scheme need provide automated adaptation mechanism to ensure continuous operations despite node failures or unpredictable load fluctuation, such as a load balancing method to improve availability in service integration. Dependable routing scheme uses virtual group and rendezvous point techniques to model dependable service routing in the SON. Based on the model, load ratio algorithm and distributed feedback control algorithm are adopted to realize load-balancing routing and failover. In each ESB, three layer routing
85
Dependable ESB Routing in Hybrid Service Execution Environment Yang Zhang steps are executed where abstract routing table make it easy for business processes to orchestrate services, service broker in ESB binds and invokes the detail service, and overlay routing manger actually forwards service messages in the SON. 3.1. Definition In a business process, services are orchestrated based on abstract services which are dynamically bound at run time in ESB. So, we define abstract service routing table (ASRT) to abstract detail service for business process to compose services. The service broker in ESB maps an ASRT to Instance Service Routing Table (ISRT) by which service messages can be routed. In a service overlay network, service messages are forwarded to neighbor ESBs. We define Overlay-Network Routing Table (OSRT) by which service messages routed from ISRT can really be forwarded to overlay neighbor ESBs. Definition 1. Abstract Service Routing Table is defined as a set of abstract service name or subscription filter. ASRT = { sID, aPath, filterSet} Where 1) sID is the identity of the composite service for a business process. 2) aPath is an abstract service path composed of abstract service names. 3) filterSet is a set of service event filter corresponding to the interest of sID . Definition 2. Overlay-Network Routing Table is defined as follows: OSRT = {destAddr , ( NBaddr1 ,, NBaddri )} Where 1) destAddr identifies the location of a ESB node. 2) NBaddr is a neighbor ESB node in the SON when a service message need be sent to destAddr . OSRT is independent of detail services and computed according to the topology of the SON. It is similar to the routing table in the Internet and P2P network. In this paper, the routing algorithm for OSRT will not be described. It is only used to really forward service messages to neighbor ESB nodes.
Definition 3. Instance Service Routing Table is defined as follows: ISRT = {sNameOrFilter , {destAddrj , ( status1 ,, statusk )}}
1) sNameOrFilter is an abstract service name or an event filter for publish/subscribe communication among services. 2) destAddr identifies the location of a ESB node which is a service provider or a subscription node. 3) status of destAddr is computed by intermediary ESB nodes according to local information or collected information. One sNameOrFilter may corresponds to multiple destAddr . For example, multiple service instances can serve the same service request, or a published event should be sent to multiple service consumers who subscribe to the event. 3.2. Framework In a publish/subscribe paradigm, participants can act both as producers (publishers) or consumers (subscribers) of information that takes the form of events. Subscribers can express which events they
86
International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010 want to receive issuing subscriptions. Subscriptions express conditions on the content of events (content-based subscription model), called filter. The paradigm states that once an event is published by a service, for each subscription whose conditions are satisfied by the event (i.e., the event matches the subscription), the corresponding subscriber must be notified. The basic building block of systems implementing the publish/subscribe paradigm is a distributed service broker in ESB whose goal is to diffuse any published event from the publisher to the set of matched subscribers. The complete decoupling and asynchronous communication offered by this form of interaction makes it very appealing for modern distributed telecom services. To support the publish/subscribe interaction in these settings, our HSEE is built on top of a service overlay network connecting all user nodes (both publishers and subscribers). The main problem with such systems is the adoption of an event diffusion mechanism able to scale with both the size of the system (number of users) and the load (number of events and subscriptions). It is possible to adopt a technique called virtual group whose purpose is to adapt the system at run-time in order to mimic the presence of subscription regionalism. With virtual group, ESB nodes hosting similar subscriptions are moved to close logical distance inside the overlay network with the aim of reducing the number of independent paths each event has to travel to reach all its target subscribers. Figure 2 depicts a virtual group of ESB nodes in a SON. Publisher Service Subscriber Service A
Subscriber Service B Virtual
Group
Subscriber Service
ESB
C
Figure 2. Virtual group of ESB nodes in a SON
In figure 2, ESB nodes A, B, C have the same subscription, and self-organize into a virtual group. In these ESBs, there are local services, called subscriber service, to subscribe the event. In the publishingevent ESB node, there is a local service, called publisher service, to produce the event. If there is no virtual group, the event is transmitted along thin arrow lines. After forming the virtual group, the event is transmitted along bold arrow lines. In the latter case, the virtual group can be leveraged to reduce the number of independent paths each event has to travel, and greatly reduce the amount of resources consumption.
Adopting the similar idea as the virtual group model, in request/response interaction model, multiple service instances to the same request choose a ESB node as a rendezvous point, which are moved to close to the rendezvous point as far as logical distance inside the overlay network. All requests to this service are passed through the rendezvous point. At the rendezvous point, the service broker in the ESB executes load balancing algorithm when routing the request messages. The rendezvous point model can be degenerated to the server clustering model. If each ESB node hosting the business process itself executes the load balancing algorithm, the rendezvous point model can be expanded to distributed load balancing model. The rendezvous point not only balance load, but also invoke new service instance to replace a failure ESB node. Figure 3 depicts the rendezvous point model for dependable routing mechanisms in ESB.
87
Dependable ESB Routing in Hybrid Service Execution Environment Yang Zhang 3.3. Dependable Routing Scheme Non-rendezvous-point ESB nodes route service messages to the service rendezvous point which registers as the service provider of that specific service. The rendezvous point computes load ratio as a routing criterion. As multiple service instances are distributed, the rendezvous point should not be assumed to get the detail runtime information of a service instance such as CPU consumption and memory occupation, and so on. Therefore, load ratio is used to represent the load capacity of service providers in a time period. Service
Consumer
S1
Service Load Balancer S2 Rendezvous Point
Service
Consumer Sn
Figure 3. The rendezvous point model for dependable routing mechanisms in ESB
Definition 4 (LRA). Load Ratio Algorithm It uses wi as the i -th time window to compute load ratio rateLoad i , j of the service provider SPj . ai , j denotes as the number of requests from SPj arrived at wi . ri , j denotes as the number of
responses from SPj arrived at wi . rateAi , j is request ratio for SPj at wi , rateRi , j is response
ration for SPj at wi , and α j is a decay factor for SPj which is often the same as others’. 1) Initial: rateA0, j = 0 , rateR0, j = 0 , rateLoad 0, j = 0 , ai , j = 0 , ri , j = 0 . 2) Accumulate the counters at present point of wi : ai , j = ai , j + 1 , if a request message arrives at wi and is routed to SPj . ri , j = ri , j + 1 , if a response message from SPj arrives at wi .
3)
Compute request and response ratio: rateAi , j = α j * rateAi , j + ai , j / wi , rateRi , j = α j * rateRi , j + ri , j / wi .
4)
Compute load ratio:
88
International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010 rateLoad i , j = rateAi , j − rateRi , j , f (rateLoad i , j ) = { j | min(rateLoad i , j )} where function f
gets the service provider whose load
ratio is the minimum. If α j = 0 , then load ratio rateLoad i , j represents the variation of load in SPj at current time window. If α j > 0 , then load ratio rateLoad i , j considers the history effects. If rateLoad i , j is small or negative, the load capacity of SPj can be deduced to increase and be suitable for serving another request. The assumption behind this method is that when SPj responses quickly, its load capacity is sufficient. rateLoad i , j also includes the effect of the path from the rendezvous point to SPj . This algorithm does not use remote information and can be executed on any ESB node to realize fully distributed load-balancing routing. If SPj fails, rateLoad i , j will be close to rateAi , j and ri , j = 0 . Then, if needed, the rendezvous point can invoke a new service copy to replace the failure one. Based on LRA, the dependable routing scheme executed by service broker in ESB is defined as follows. Process
Event Analyzer
Engine
ASRT
Routing Manager
Load Balancer
ISRT
Overlay Routing Manager
OSRT
Figure 4. Dependable Routing Approach Overview Definition 5 (DRS). Dependable Routing Scheme The dependable routing approach overview is depicted in Figure 4. 1) The process engine interprets the workflow, identifies the possible abstract paths, and records the paths in ASRT. 2) Once the service flow is initiated for execution, the messages are exchanged among the services via
89
Dependable ESB Routing in Hybrid Service Execution Environment Yang Zhang the service bus following the path definition. Each service is represented by an Abstract Service Name. 3) For the abstract service name, the next routing node often is the rendezvous point. According to the address of the rendezvous point, Overlay Routing Manager forwards the request message to the next neighbor ESB in OSRT. 4). At the rendezvous point, the ESB knows there may exist multiple service instances. For each service instance Service j , it computes rateLoad i , j at wi according to LRA. 5) The rendezvous ESB execute as follows: a)
The Event Analyzer extracts the content value DV of configured field in the request message q .
b)
If there exist some past request messages that have been sent to service instance Service j and
they contain DV content, then q is still sent to Service j , else c)
Computes
f (rateLoad i , j ) = { j | min(rateLoad i , j )} according to LRA and invokes Overlay
Routing Manager with f (rateLoad i , j ) as destAddr input.
6) According to f (rateLoad i , j ) , the Overlay Routing Manager forwards the request message to the next neighbor ESB in OSRT. If the rendezvous point can collect the detail runtime information of a service provider such as CPU utility and memory occupation, and son on, we adopt control theory to precisely control the quality of service. Each ESB node has a local feedback control system and a distributed feedback control system as in figure 5. The distributed feedback controller is responsible for maintaining the appropriate QoS balance between nodes such as load balance. The local feedback controller is responsible for tracking the global QoS set point set by distributed controller and ensuring that tasks that are admitted to this ESB node have a minimum miss ratio (the request is not responded in a given time period or rejected, which becomes miss request) and the node remains fully utilized. If one node has minimum miss ratio or utilization, it will be chosen to serve a new service request. Readers can refer to [15] for more details.
Avg
Miss Controller min
Avg
Util. Controller
Admission Control Local Controller
Service System
Figure 5. Load Balancing Based on Distributed Feedback Control
90
+
International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010 Events produced by producers are routed like service requests. The published event routing approach overview is as follows: 1) From the producer to the virtual group: An event can be generally published on any node in the SON, therefore it must be routed from there, to at least one node belonging to the target virtual group. The goal of outer-group routing is to reach the target virtual group involving a number of nodes as small as possible, thus generating the minimum number of spam messages. 2) Inner-Group routing: Once the event reaches one member of the virtual group, the dissemination inside the virtual group can follow a multicast tree in the sub-network of the SON.
4. Applications Our BUPT Multimedia Conference System (BMCS) has been deployed in China Unicom Corporation Ltd. Beijing Branch, which is run in HSEE. BMCS is designed to provide scalable multimedia conferencing services to a diverse set of users. The architecture is flexible enough to support users with various network bandwidth requirements and endpoint capabilities. It supports users behind firewalls, NATs, and proxies. There are three main components: media processing services, conference call control services and multimedia conference processes. Our early work [16] presented the detail prototype. Figure 6 depicts the framework of BMCS.
Figure 6. The Framework of BMCS The conference call control services are implemented with a third party call control state machine and two B2BUA call state machines. 3PCC refers to the ability of one entity to manage a call in which communication is actually between other parties. Users can take advantage of this SIP feature to request other parties to create or join a conference, to request the multimedia conference processes (hosting on Media Server/AS) to invite third parties to a conference, or to request that the multimedia conference processes expel participants from a conference. ESB network is used to deliver conference call control service and distribute the control messages exchanged among various components in the system. This simplifies building a scalable solution, since messages can be delivered to multiple destinations without explicit knowledge of the publisher. Service providers can be added dynamically. Moreover, the dependable routing mechanism in ESB provides load balancing and assures request messages for the same conference to be routed to the same conference call control service providers. We provide media processing services at server side to support a diverse set of clients. Some clients have limited network bandwidth, processing and display capacity. Either they can not receive multiple
91
Dependable ESB Routing in Hybrid Service Execution Environment Yang Zhang audio and video streams or they can not process and display them. Therefore, server side services should generate combined streams for them. The services which we have implemented include audio mixing, video mixing etc. We also have an RTP stream monitoring service. All these services require real-time processing and usually high computing resources. The dependable routing mechanism chooses suitable media processing services according to the load ratio of service providers. The BPEL process definition should consider the people activity as a new activity type that focus on user interactions and people activities, which implemented by human tasks performed by users. In multimedia conference scenarios, the conference owner or participant can be involved in conference processes as a special kind of implementation of an activity. From the point of view of the BPEL business process, a people activity is a basic activity. Here, we design two people activities as conference form people activity and conference request people activity, which are implemented as two kinds of events published in the SON. When a people activity is initiated by a BPEL engine, the engine creates work items for this activity and distributes them to all users eligible to perform it. Once the conference owner has performed his or her task, the work item is completed and the conference process continues.
5. Conclusions This paper presents an on-going research on dependable ESB routing where a high level architecture of the hybrid service execution environment and dependable ESB routing scheme are proposed. The architecture depicts how to use ESB to support both request/response and publish/subscribe service interaction paradigms for meshing up the environment. The dependable routing scheme uses virtual group and rendezvous point to model dependable service routing in SON. Based on the model, load ratio algorithm and distributed feedback control algorithm are adopted to realize load-balancing routing and failover. The multimedia conference application is implemented based on this environment and routing scheme.
6. References [1] C.A. Licciardi, P. Falcarin. “Analysis of NGN service creation technologies”. IEC Annual Review of Communications, pp. 537-551, 2003. [2] A. Baravaglio, C.A. Licciardi, C. Venezia. “Web service applicability in telecommunication service platforms”. In proceedings of International Conference on Next Generation Web Services Practices, 2005. [3] Berthold Butscher, A NGN orientation and Application Environment, http://www.gip.com/K_Vortrag_FOKUS.pdf. [4] D. Chappell. Enterprise Service Bus. O'Reilly, 2004. [5] M. Gilpin, K. Vollmer. The Forrester Wave: Enterprise Service Bus. In: Tech Choices, November, 2005. [6] J.L. Marechaux. Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus. IBM Developworks, March 2006. [7] X.Y. Bai, J.H. Xie. DRESR: Dynamic Routing in Enterprise Service Bus, Proc. IEEE ICBE, 2007. [8] Gulnoza Ziyaeva, Eunmi Choi, Dugki Min. “Content-based intelligent routing and message processing in Enterprise Service Bus”. Proceedings of the 2008 International Conference on Convergence and Hybrid Information Technology, pp. 245- 249, 2008 [9] B. Wu, SH.J. Liu, L. Wu. “Dynamic reliable service routing in Enterprise Service Bus”. Proceedings of the 2008 IEEE Asia-Pacific Services Computing Conference , 349-354, 2008. [10] J.W. Yin, H.W. Chen, SH.G. Deng, ZH.H. Wu. “A dependable ESB framework for service integration”. IEEE Internet Computing, Vol.13, pp. 26-34, 2009. [11] K.J. Lin, M. Panahi, Y. Zhang, J. Zhang, S.H. Chang. “Building accountability middleware to support dependable SOA”. IEEE Internet Computing, Vol.13, pp. 16-25, 2009. [12] JSR-22. JAINTM SLEE API Specification. Retrieved December 5, 2007 from http://jcp.org/aboutJava/communityprocess/final/jsr022/index.html
92
International Journal on Advances in Information Sciences and Service Sciences Volume 2, Number 1, March 2010 [13] Sandford Bessler, Joachim Zeiss, Rene Gabner, Julia Gross. “An Orchestrated Execution Environment for Hybrid Services”. Kommunikation in Verteilten Systemen (KiVS), pp. 77-88, 2007. [14] Paolo Falcarin, Politecnico di Torino. “Communication Web Services and JAIN-SLEE Integration Challenges”. International Journal of Web Services Research. Vol. 5, no. 4, pp. 59-78. Oct.-Dec. 2008. [15] John A. Stankovic, Tian He, Tarek Abdelzaher, Mike Marley, Gang Tao, and Sang Son. “Feedback Control Scheduling in Distributed Real-Time Systems”. Real-Time Systems Symposium, 2001. (RTSS 2001), pp. 59-70, 2001. [16] Bo Cheng, Yang Zhang. “Design of Services-Orientated Multimedia Conference Process Management”. International Conference on Computer Science and Information Technology, pp. 915-919, 2008.
93
