World Wide Web (2010) 13:475–495 DOI 10.1007/s11280-010-0093-1
A dynamically self-configurable service process engine Jian Cao & Haiyan Zhao & Minglu Li & Jie Wang
Received: 4 February 2009 / Revised: 13 May 2010 Accepted: 20 May 2010 / Published online: 5 June 2010 # Springer Science+Business Media, LLC 2010
Abstract The performance of a process engine is one of the key factors that contribute to the successful deployment of systems, based on a service-oriented architecture. A novel service process engine that can be self-configured dynamically is introduced in the paper. It is based on the Jini platform, and leverages of Jini services to provide key functionalities. It automatically maintains the global performance by performing load balancing and configuring the system structure dynamically. A heuristic algorithm is applied to indicate every client’s request with a workload tag after a service process model is designed. Based on workload tags of client requests and the status of available services in the engine, a controller allocates the requests to appropriate services and dynamically reconfigures the engine based on fuzzy control algorithms. Algorithms and the architecture for the engine are discussed in detail; in addition, performance experiments are performed to show the effectiveness and feasibility of the proposed approach. Keywords service process . service process engine . autonomic computing . workload tag . fuzzy control
1 Introduction Today’s Internet has been evolving from an information sharing platform into a resource sharing platform [15]. The evolution relies on technology and standard developments, J. Cao (*) : M. Li Department of Computer Science and Technology, Shanghai Jiaotong University, 80, Donchuan Road, Shanghai 200240, People’s Republic of China e-mail:
[email protected] H. Zhao School of Computer Engineering, University of Shanghai for Science and Technology, Shanghai 200093, People’s Republic of China J. Wang Department of Civil and Environment Engineering, Stanford University, Stanford, CA 94305, USA
476
World Wide Web (2010) 13:475–495
among which service oriented architecture (SOA) [17] plays a predominant role [21]. Services are well known building blocks for modern information systems [29], which are loosely coupled and mostly autonomous reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols [18, 26, 27]. It is widely believed that the SOA is breeding the new paradigm for designing and implementing the next generation Web [2]. In SOA, a single-functioned service is unable to meet the requirements of an end user in most cases so as to these standalone services have to be able to cooperate with each other, advertise themselves for their functions, and be discovered and invoked using standard industry-wide specifications. As a way to define the cooperative relationship among services, service composition has become an important topic in both academic research and industry [3, 14]. The approach of service composition can be roughly categorized into two types [16]. One is the point-to-point composition, of which participants invoke services directly with each other without a centralized or semi-centralized intermediary. The other type is the service orchestration, which integrates individual services via a process model that describes the interaction rules between applications based on service messages, execution logic and invocation sequences. The service orchestration approach is more popular in service composition research due to its better controllability than the point-to-point one’s so that many service process engines[1, 9, 10, 19, 24] are built around some web service process modeling languages such as BPEL4WS [7] and WSCI [28]. A group of web services orchestrated by a process model can be generally represented as a composite service. When a request is made for the composite service, the process model is first parsed. Subsequently, a set of atomic services are invoked by the service process engine, based on the control logic that is defined by the process model, and the current state of the executing process. As more processes are deployed, the workload that needs to be handled by the engine increases significantly. In SOA, a public composite service is used by large number of users. Consequently, this causes the workload of the system to be unpredictable. Therefore, the performance of a process engine becomes one of the key issues for deploying a successful SOA since a poorly designed engine may suffer workloads brought by a large amount of service requests every day. Most today’s service process engines are built around a centralized architecture, such as ActiveBPEL Engine [1] and Jbpm Engine [10]. The single engine architecture will inevitably become a source of system failures and a bottle-neck for the system performance since the workload might easily exceed its design capacity. To avoid the limitations of the centralized architecture, the concept of installing duplicate servers with an identical process engine in a distributed architecture to improve the performance and availability is widely accepted and implemented [9, 19, 24]. But simply adding more engines usually cannot guarantee the performance of the system is improved proportionally to the dramatic increase of cost of the equipments and operations. Therefore, we need to consider other approaches to deal with this problem more appropriately. One possible way is to develop load balancing algorithms for the service processes to maintain acceptable performance level under varying load conditions. In addition, a service process engine should be able to provide scalability in coping with high-varying load of applications that require flexibility, timeliness for serving various end users. It is possible that many users invoke a process engine within a short period of time to cause the total amount of transactions increasing dramatically. Although we can reserve enough computing resources for the service processes, most of them will be wasted during
World Wide Web (2010) 13:475–495
477
off-peak workload conditions. For today’s enterprise IT systems, a cost-effective infrastructure, where high performance computer servers are shared among many applications, plays a dominant role. Within this infrastructure, a resource allocation mechanism is required for a service process engine to maintain the global performance for the whole IT system. More specifically, on-demand enterprise IT services cry for a dynamically configurable architecture of the service process engine. In the paper, a novel service process engine is proposed. It is based on the Jini platform [23] and employs Jini services to provide functions for a service process engine. It can automatically keep balance between required performance and utilized resources according to the load status of all running services. A heuristic algorithm is applied to indicate every client’s request with a workload tag after a service process model is designed. Based on workload tags of client requests and status of available services in the engine, a controller allocates the requests to appropriate services and dynamically reconfigures the engine based on a fuzzy control algorithm. The remainder of this paper is organized as follows. Section 2 introduces a service-based framework for self-configurable service process engine. Section 3 presents a heuristic algorithm as how to evaluate and indicate a client’s request with workload tag for a service process model. Section 4 introduces an approach for how to solve the engine configuration problem through a fuzzy control algorithm. Section 5 describes some potential implementation issues. Section 6 provides some experimental results for a prototype system that implements our framework and algorithms. Section 7 discusses related work and finally Section 8 provides some conclusions for our approach and discusses potential future tasks for refining the approach.
2 The framework of a self-configurable service process engine (S2PE) The proposed service process engine contains three layers: an access layer, a management layer and an enactment layer, as depicted in Figure 1. The enactment layer consists of
Web Server
Web Service
......
Jini Service
Access Layer
Management
Process Manager
Layer
Jini Network
Service Node
Service Node
Navigation Service
Navigation Service
Admin. Service
Connection Service
......
......
Figure 1 A distributed service process engine.
Service Node Navigation Service Monitor Service ......
Enactment Layer
478
World Wide Web (2010) 13:475–495
common functions provided by most service engines. The functions are implemented as enactment services and each function is corresponding to several duplicating services, which are deployed into a set of service nodes respectively. The management layer (the process manager) is the core layer of the service process engine, which provides access, management and monitor interfaces to the enactment layer; in addition, it provides some other services for interacting with the access layer. The access layer provides different approaches for clients to connect to the system; for example, a client can be a browser based application, or an application invoking web services or Java applications capable of invoking Jini service directly. The architecture of the process manager is shown in Figure 2. The process service proxy (PSP) provides a unified interface to the access layer. The service request dispatcher (SRD) is responsible for selecting a proper service from a service cache to respond to the request from clients and returns the selected service’s proxy to PSP. The function of the service cache manager (SCM) is to maintain an available enactment service cache, which caches distributed enactment service’s proxies in the local machine and maintains the content of service cache automatically when there is any change of distributed enactment services. For example, the SCM may delete unavailable enactment service record or update the attributes of some enactment service so that all enactment services kept in the cache are available and their information is correct. The load balancing manager (LBM) is responsible for managing the request distribution within enactment services; it dynamically computes and adjusts the load of each enactment service according to a predefined load-balancing strategy. The service configurator (SC) monitors overall performance of the system, and it will decide to deploy or un-deploy, start or stop services based on the workload of the engine. The service quality analyzer (SQA) collects information from nodes and evaluates the aggregated performance by summing up the values of several factors. The process event manager (PEM) receives and records all events from services into a log database, which can be used to monitor, analyze and optimize the system. The service node manager (SNM) is a component being employed to register the host machine’s address and monitor the availabilities of these machines. The persistence storage manager (PSM) is a facility to support the data storing during the execution of the service process. The persistent data
Process Service Proxy
Service Request Dispatcher
Load Balancing Manager
Service Configurator
Service Quality Analyzer
Process Event Manager
Service Node Manager
Figure 2 The structure of process manager.
Persistent Storage Manager
Access Controller
Service Cache Manager
World Wide Web (2010) 13:475–495
479
includes a service invocation log, a configuration file of the process manager and all the information of the enactment service proxy kept in the service cache and other services. The access controller (AC) maintains access rights of all users, and it also checks the validity of each request. As shown in Figure 1, the access layer, the management layer and the enactment layer communicate with one another through a Jini network infrastructure. The Jini infrastructure is a new network computing paradigm introduced by Sun Microsystems that can provide a network-wide plug-and-play environment [23]. The services are the entities that can be used by a person, a program, or another service within the federation of all networked computing resources. The infrastructure supports the discovery and a joint protocol that enables services to discover one another and register themselves with lookup services. The Jini technology provides us with rich functions to establish a flexible, stable and extensible distributed computing environment. It also simplifies development of a distributed service process engine. The functions of a service process engine are implemented as Jini services so that the management layer can take advantage of Jini facilities to search and invoke these services easily. Moreover, Jini infrastructure offers good performances comparing with other service architectures [4].
3 Workload estimation for service request to the process engine When a request is received, the process engine infers how to react to it based on the interpretation of the logics of a service process model. Obviously, different service request usually brings unequal workload to a process engine due to the different computational complexities of various service process models. For example, in a test in our prototype system, which simulates the response times for different process navigation requests, the engine spends 10547 ms to process one request and spends only 656 ms to process another one. In order to predict the workload generated by service process instances within a service engine, we must analyze the intrinsic behaviors of the control flow of service process models. In [6], stochastic processes, more specifically the first-order continuous-time Markov chains (CTMC), are employed to describe the control flow behaviors. The mean turnaround time of a workflow instance can be deduced by the transient analysis of the corresponding CTMC. The execution of a workflow instance spawns a set of activities, which in turn generates service requests to different server types. The optimized configuration can be designed accordingly for this situation. Although this model maintains overall system performance after every reconfiguration, it does not provide any function to optimize the response time for each client’s request although the workload brought by each client request differs greatly. We notice that the functions within a process engine can be broadly classified into following categories: connection functions, process control functions, activity control functions, process status functions, activity status functions and administration functions. Among them, some functions, which are invoked during execution time of different process models, do not generate many dissimilar workloads. For example, the workloads generated by executing functions of process attribute change or administrations are almost equal. Through analyzing working mechanism of a general process engine, it is found that the functions relating to process navigation tasks, such as process control and activity control, brings different levels of workload to the engine. As a result
480
World Wide Web (2010) 13:475–495
we provide the following discussion on how to balance the request workload among navigation services. In a process model, control flows are composed of transition links among activities. Each activity can have one or more transitions either going into or out of it. If a transition links two activities A and B, i.e., it is an output transition of activity A and an input transition of activity B, then B is called a target activity of the transition. For an activity, restrictions are defined for those incoming and outgoing transitions, known as joins and splits respectively. There are two types of restrictions: AND and OR. An AND restriction on an incoming set of transitions indicates that all transitions must be evaluated to be true for the next activity to start. An OR restriction on an incoming set of transitions indicates that only one transition needs to be evaluated to be true before the activity will execute. An AND restriction on an outgoing transition indicates that every path at a split will be executed. An OR restriction at an outgoing transition indicates that only one path will be executed, which evaluates to be true. After the status of the activity has been changed, the engine then continues navigating within parallel process branches, which consists of multiple activities and transitions. An activity can be implemented by (one or more) service(s), sub-flows or another process loop [20]. The activity can also be defined as a human-based web service [8]. When invoked, the service notifies an individual a task to do and passes the input data in an appropriate form. After the task is completed with an output result, the service returns to its caller, passing the result as an output data. In all the cases, how the result is actually obtained in a previous step may be completely transparent to the caller. When the engine is notified to process an activity and the restriction on incoming transitions is satisfied, it first starts the activity. When the activity to be processed is a human service invocation activity, or a receiving activity in which the process has to block and waits for a matching message to arrive [20], the engine does not continue to navigate in the processing branch and waits for human interferences or incoming message. We call this kind of activity as blocking activity. For an automatic application service invocation activity, the engine sends a request to a dedicated server and waits for its response. When this activity finishes, the engine continues to navigate in the automatic task processing branch. For sub-flows or process loop, we can expand them and insert them into the top layer model so that we can deal with them as the same way above. When navigation meets an OR restriction on an incoming set of transitions for an activity in a path, the activity can be started since one of its transitions evaluates to be true. But when the restriction is an AND type, we must evaluate all the incoming transitions to determine whether the activity can be started. As indicated in Figure 3(a), after activity A finishes the engine will navigate in two parallel process branches, namely p1 and p2. In p1, all the incoming transitions of activity B must be evaluated. Since t1 is true, whether activity B can be started is determined by the value of transition t0. Based on the information of the process model, whether t0 is true or false is undetermined even after A finishes. For some special cases, there may be an implicit logic that defines a rule such that if A starts, t0 becomes true too, as depicted in Figure 3(b). For this scenario, to treat t0 as another incoming transition for B is redundant. We assume that for the models discussed in the paper, this kind of redundancy has been eliminated. Another case is that when A finishes t0 becomes true with certain probability. For the example shown in Figure 3(c), if the probability that activity A’ ends earlier than A is 0.3, then it is rational to assume when
World Wide Web (2010) 13:475–495
t0
t
p1 B
t1 A
481
t3 0.7
t2
X
C
(b)
t4
E
t5
F
0.3
B
t1 Aʼ
D
p2
A
X
A
t0 t1
B
(c)
(a) Blocking Activity
Automation Activity
AND-Split OR-Split AND-Join OR-Join
Figure 3 Some examples of process model.
A finishes, B can be started with probability 0.3. However this kind of probability is more a fictitious assumption than a reality in most cases because a workflow model is generally a complex stochastic network without a fixed probability per se. Since the workload prediction can be justified when we obtain enough instance data, we use a simplified approach to approximate this kind of probability as follows. For an activity, if the number of input transitions with restriction AND is n, then the probability that this activity can start is 1/n. Since we consider workloads brought by process paths, the probability will be carried over to the output transitions of the activity. For example, in Figure 3(a), the probability of activity B can start is 0.5, so that the probability of transition t3 becomes true is also 0.5. The well-structured process model consists of matching pairs of a node that splits the transitions and a node that joins the transitions. Although different process models can model the same behavior, well-structured models are often preferred because they are easier to comprehend and analyze, and can be represented as a regular expression [11]. The process model can be transformed into the well-structured model using local transformation rules that preserve the execution semantics automatically [11]. The following algorithm is designed for well-structured models without loss of generality. As the first step to estimate the workload, we should find which activities will be executed automatically after an activity has finished. Suppose activity Ao finishes, its outgoing transition becomes true. When a transition meets a Split logic node, all of its outgoing transitions become true. When a transition meets an AND-Join logic node that has multiple input transitions, if one of its transitions is false then the outgoing transition of this logic node is false. When a true transition meets an OR-Join logic node that has multiple input transitions, the outgoing transition of this logic node becomes true. When a true transition meets an automation activity, this activity’s outgoing transition becomes true. When a transition meets a blocking activity, this activity’s output transition becomes false. When no more transition can become true after applying above rules continuously, a subgraph which only includes all true transitions and automation activities linked by these transitions can be obtained. In the algorithm, the total workload is represented in terms of the expected value calculated over all possible process paths with some probability distribution.
482
World Wide Web (2010) 13:475–495
Suppose activity Ao finishes, the heuristic algorithm to estimate the possible workload is as follows: Call Calculate_Workload(A0); Public Function Calculate_Workload (strActivity as string) as float Dim SUM as float; Dim tempSUM as float For each activity a in target activities of strActivity tempSUM=Activity_Workload(a) w=1 From strActivity to a will meet one or more logic nodes When meet an AND-Split OR OR-Join w=w*1 When meet an AND-Join w=w/n (n is the total number of input transitions) When meet an OR-Split w=w*p (p is the occurrence probability of activity a) SUM=SUM+tempSUM*w Calculate_Workload=SUM End Function Public Function Activity_Workload (strActivity as string) as float If strActivity is a blocking activity Then Activity_Workload=0 Return End If If strActivity is an automation activity Then Activity_Workload=Service Execution Time+Calculate_Workload(strActivity) End If End Function
Figure 4 is an online shopping service process model. Among those activities included in the process model, A1, A4 and A7 are blocking activities. After a user input his information and order, the service process engine continues its navigation. Figure 5 shows the simplified process model. According to the algorithm, the calculation process is: Calculate_Workload(A1)= Activity_Workload(A2)+0.7*Activity_Workload(A3)+0.3*Activity_Workload(A4) Activity_Workload(A2)=800+ Calculate_Workload(A2) Activity_Workload(A3)=600+Calculate_Workload(A3) Activity_Workload(A4)=0 Calculate_Workload(A2)=Activity_Workload(A5)/2 Calculate_Workload(A3)=Activity_Workload(A5)/2 Activity_Workload(A5)=1500+Calculate_Workload(A5) Calculate_Workload(A5)=0.1*Activity_Workload(A6)+0.9*Activity_Workload(A7) Activity_Workload(A6)=400 Activity_Workload(A7)=0
The final result is 2529 ms. When applying above algorithm, it is assumed that the response time of each service is already known. The response time of a service can be modeled as one part of quality of service (QoS). In recent years, QoS support for Web services has become a widely investigated area and has shown to be an effective mechanism in Web services’ discovery particularly in discriminating between services that share similar functionalities. This information can be obtained from QoS description of Web Service [13, 25, 31], estimated
World Wide Web (2010) 13:475–495
483
A2 800ms Calculate
A6 400ms 1500ms A5
Total Cost
A1 Input User
& Order
0.7
Message
Online
A3 600ms
Information
Return Error
A7
Payment
Process
Retrieve Credit
Order
Card Information
A4 0.3
Input Credit Card Information
Figure 4 An online shopping service process model.
based on experience or gathered from past invocation records. Although performances of a service are affected by many factors, such as network speed, workload or system failures, they often don’t change too much when these factors are maintained in fixed levels. This result is shown in experiments conducted in [30]. If we need to model the response time of a service more accurately, we can define several typical statuses and represent it’s response times respectively. In addition, the workload calculated will be mapped to a fuzzy number so that its uncertainty is partially reflected.
4 A dynamic configuration approach for S2PE 4.1 Dynamic configuration and fuzzy control After receiving service requests, the service process engine should allocate them to specific services for processing. In order to maintain high performance, the engine should balance the workload among dedicated enactment services and increase the number of enactment services if necessary. In order to design a load balancing algorithm, one has to develop a mathematical model of the system and determine the characteristics of the model by applying various analytical techniques. However, to model a system with a lot of uncertain A2 800 ms Calculate Total Cost
A3 600 ms 0.7
Retrieve Credit Card Information
A4 0.3
Input Credit Card Information
Figure 5 The simplified process model.
A6 400ms 1500ms A5 Online Payment
Return Error Message
A7 Process Order
484
World Wide Web (2010) 13:475–495
parameters, complex and non-linear relationships among the leading variables have to be recognized. This limitation makes it very hard, if not intractable, to apply conventional control theory to design the workload balancing mechanism for the process engine. For example, for a service engine, the workload usually cannot be precisely calculated in advance and the time required to execute the same action for a service is also affected by a number of other variables, such as communication speed, status of computers and so on. To overcome this problem, fuzzy logic control can be applied successfully instead of the conventional ones. A fuzzy logic control system consists of a Fuzzifier, a Fuzzy Rule Base, an Inference Engine, and a Defuzzifer. The fuzzifier has the effect of transforming crisp measured data into suitable linguistic values. Then the fuzzy rule base stores the empirical knowledge of the operation of the process of the domain experts. The inference engine is the kernel of fuzzy logic control and it has the capability of simulating human decision making by performing approximated reasoning to achieve a desired control strategy [12]. By applying a fuzzy logic control system, a nonlinear service processing system with great complexity and uncertainty can be effectively described and controlled by fuzzy logic rules without the need for employing complex conventional mathematical models. 4.2 Fuzzy rule based load balancing We adopt fuzzy set theory to describe both of request workload and service capability. “small” and “big” are selected as atom word variants. By adding decorating operators, we can obtain the language variant set {“Very Small(VS)”, “Small (S)”, “Little Small(LS)”, “Little Big(LB)”, “Big (B)”, “Very Big(VB)”}. Each language variant is corresponding to a fuzzy number. Since all requests have been indicated with workload information, they can be easily mapped into a fuzzy number, which can be represented by some shape of membership function. We should also evaluate, based on many factors, the capability of each service. Firstly, the capability of each service is closely related to the performance of the underlying hardware. Secondly, it relies on the engine’s current workload status, i.e., whether it is busy or not. Besides these two leading factors, the Operating System (OS) and other unexpected workload of the computer may also affect the performance. As an example, we select CPU frequency, memory size, the average invoking time, CPU usage and memory usage as the indexes. The evaluation function definition for each index is listed as following: CPU Frequency: 8 0 u1 1:5 < U1 ¼ ðu1 1:5Þ=1:5 1:5 < u1 3:0 : 1 u1 > 3:0 Memory Size: U2 ¼ Invoking Time: U3 ¼
8
10000 1 ðu3 4000Þ=60000 4000 < u2 10000 : 1 u2 4000
World Wide Web (2010) 13:475–495
485
CPU Usage: U4 ¼ Memory Usage: U5 ¼
8
90 30 < u5 90 u5 30
A weight is also given to each index so that we can obtain a weighted summarizing capability value based on the result of the evaluation function for each index. In all our experiments, we set weights for CPU frequency, memory size, invoking time, CPU usage and memory usage as 0.3, 0.2, 0.2, 0.15 and 0.15 respectively according to their relative importance. The summarizing value is used to indicate service capability, which is a fuzzy number. The fuzzy control rule for allocating requests to services are based on a “BestMatch” principle, i.e., if the workload of request is “Big”, then we should allocate it to a service with “Big” performance value, and if the workload is “Very Big”, it should be allocated to a service with “Very Big” performance value. If a node in which a strictly corresponding performance value cannot be found, we select the one with the nearest value. 4.3 Fuzzy rule based service dynamic configuration To get better performance of the service process engine, simply relying on designing a better load balancing algorithm is barely enough. When the global performance is lower than our expectation, new service instances should be activated and added to the system. In contrast, when the performance is way beyond expectation, some of service instances can be de-activated and closed. The performance is measured in terms of average response time deviation (ARTD) of whole system at regular intervals. The system will record actual invocation time minus estimated invocation time for each request and their average is ARTD. Five language variants {“Very Slow(VS)”, “Slow(S)”, “Acceptable(A)”, “Quick(Q)”, “Very Quick(VQ)”} are adopted to measure the performance. The performance of whole system is always changing. Variation on performance deviation (VoPD) represents the change trend of performance deviation, which can be calculated using the formula: VoPD ¼ðARTD2 ARTD1 Þ=Δt Similarly, we adopt the fuzzy set {“Negative Big(NB)”, “Negative Small(NS)”, “Middle(M)”, “Positive Small (PS)”, “Positive Big(PB)”} to describe the VoPD. The operations for creating or removing one or more services are defined as a fuzzy set as follows {“Add More Services(AM)”, “Add Services(AS)”, “Keep Current Services(KC)”, “Stop Services(SS)”, “Stop More Services(SM)”}. The number of services we add or remove should be mapped into crisp numbers through a defuzzifer. For example, in our experiment, to “Add Services” means to start one service instance while to “Add More Services” means to start two service instances. The fuzzy rule set is defined in Table 1.
486
World Wide Web (2010) 13:475–495
Table 1 Fuzzy rule table for service configuration. VoPD-ARTD
VS
S
A
Q
VQ
NB
KC
KC
SS
SM
SM
NS
AS
AS
KC
SS
SM
M
AS
AS
KC
SS
SS
PS PB
AM AM
AS AM
KC AS
SS KC
SS KC
5 Implementation issues for the framework 5.1 Service joins into process manager The procedure of an enactment service joining into a process manager is shown in Figure 6. Firstly, an enactment service uses Jini Discovery Protocol to find out the lookup service in the Jini network. When the lookup service is discovered, it uploads its own proxy and relevant attributes’ information into the lookup service through a Jini Service Join Protocol. Meanwhile, the process manager obtains the enactment service proxy and check whether there is a new enactment service within the engine. Whenever a new enactment service enters into the Jini network, the process manager will be notified; after receiving the notification, the manager downloads the service proxy and stores it into the service cache. 5.2 Handling clients’ service requests The way that the process manager handles requests from client is shown in Figure 7. Whenever the process manager receives a request from a client, it passes the requests to the service request dispatcher (SRD). The SRD first checks client’s access right. After validating the request, the SRD selects a proper service from the service cache to deal with the request. During the selecting process, the SRD determines whether there is a specific service responsible for serving this type of request according to predefined rules. If there is,
Lookup Service Proxy A
Download Proxy
Upload Proxy
Other Proxies Request Event Process Manager
Service A
Service Cache
Service Proxy
Proxy A
Service Entity
Proxy B
Service Attribute
Proxy C
Figure 6 The process of service joining into process manager.
World Wide Web (2010) 13:475–495
487 Process Manager 4
2
Service Dispatcher
3.1
1
3.4
3.1
3.2
3.2 Service Cache
Service A 5
Load-balancing Manager
5
Service B
3.3
Figure 7 The process of accessing services through process manager.
this related service is invoked; otherwise, the service dispatcher asks the load-balancing manager to select a proper service; more specifically, the load-balancing manager will select a service proxy from the service cache according to a pre-defined heuristic best-matching load balancing strategy and return this service proxy to the service request dispatcher so that this service can be invoked. 5.3 Service configuration In order to deploy services and configure them automatically, an architecture, which includes a service configuration controller, a service code provider and several service nodes, is designed to deal with the proposed automatic service configuration functionality. The diagram for the architecture is shown in Figure 8. All the components of the architecture are connected by the Jini network. A protocol is designed to support automatic configuration within the network. The service configuration controller(SCC) first broadcasts its existence together with its network address to service nodes through the multicast protocol and then handles the service deployment and configuration process. A service node registers its address to the service configuration controller and as a result, the controller provides the service a running environment and controls the execution of this service. The controller employs lifecycle management interfaces of Jini to start or stop a service. In practice, a service implementation repository server is used to store class files of all the service implementations. When a service is ready to be deployed, the server is requested to send the relevant files for this service to a service node so that a registered service can be installed on that node. Register Service Node
Service Node
Download Service Code
Send Command Service Code Provider
Service Configuration Controller
Send Command Register Service Node Figure 8 Service dynamic configuration.
Service Node
Down load Service Code
488
World Wide Web (2010) 13:475–495
a. Service Node Information
b. Deployed Service List
c. Service Execution Information
Figure 9 The management tool of service process engine.
World Wide Web (2010) 13:475–495
489
Table 2 System configurations for the experiment. CPU
Memory SIZE OS
Main Software Packages
1 Intel Pentium 4 CPU 1.8G 512 M
Windows XP Professional Navigation Service
2 Intel Pentium 4 CPU 3.0G 256 M
Windows XP Professional Navigation Service
3 Intel Pentium 4 CPU 2.4G 1024 M
Administration Function Service Windows XP Professional Navigation Service
4 Intel Pentium MCPU 1.7G 1024 M
Windows XP Professional Workflow Manager, Database
Status Function Service
Navigation Service
In the protocol, the SCC can send a set of commands, which includes connect, deploy, un-deploy, start and stop, to a service node. Connect: it is applied to test the connectivity of each service node so that the SCC can monitor the status of service nodes and then take care of only the available service nodes. Deploy: it is applied to deploy services to a dedicated service node. Un-deploy: it is applied to un-deploy installed services from a service node to release resources. Start: it is used to start the service that has been deployed. Stop: it is used to stop those started enactment services deployed in a service node.
6 Experiment results of a prototype system We have implemented a prototype system of the service process engine for validation and testing. Figure 9 shows the management tool we developed. In this tool, all available enactment services and executing tasks are listed and monitored. The parameters of each service node, such as the number of concurrent users, CPU and memory usage percentages are shown. All messages exchanged within different parts of the system, such as the execution result of the enactment service and the response of remote events are also recorded and displayed. Experiments were performed to analyze the average response time for each client request in such a distributed service process environment. The service process engine resides in four disparate computers and their configurations are shown in Table 2. Six language variants {“Very Small(VS)”, “Small (S)”, “Little Small(LS)”, “Little Big (LB)”, “Big (B)”, “Very Big(VB)”} are adopted to measure both workload of the request and service capability. Their membership functions are shown in Figures 10 and 11 respectively. In order to simulate more realistic client access patterns, a request sequence was generated based on a random number generator to produce random sequences of service requests within a given time interval. The first experiment was conducted to compare the fuzzy logic based load-balancing method with a random and a round-robin algorithm. The results are shown in Figure 12. Obviously, it can be found that with the increase of the number of service requests, the average response time is increasing for all the methods. However, the fuzzy logic based method consistently performs better than other two algorithms. The experiment parameters are defined according to the historical test data. The second experiment was conducted to demonstrate the service dynamic configuration mechanism for the service process engine. The member functions of ARTD and VoPD are shown in Figures 13 and 14 respectively.
490
World Wide Web (2010) 13:475–495
Figure 10 Workload membership function.
1 S
VS
1
Figure 11 Service capability membership function.
LB
B
VB
5
10
15
20 100 ms
S
LS
LB
B
0.2
0.4
0.6
0.8
1 VS
Figure 12 Average response time vs. number of concurrent requests.
LS
VB
1
4 Service Nodes Average Response Time (ms) 25000 Random Round-robin Fuzzy
20000
15000
10000
5000
0
6
12 18 24 30 36 42 48 54 60 Number of Concurrent Requests
World Wide Web (2010) 13:475–495
491
Figure 13 ARTD membership function.
1 VS
S
A
-2000 -1500 -1000 -500
0
Q
VQ
500 1000 1500 2000 2500 ms
Figure 15 shows the change of the number of service requests when time elapses. For this experiment, we record the average response time of the engine under the number of concurrent service requests maintained as the following sequence {24 requests, 30 requests, 36 requests, 30 requests, 24 requests} respectively. As we can notice, the navigation service number is also changing correspondingly when the number of concurrent requests changes, as shown in Figure 16; but the change of the average response time is kept in a relative small range, as shown in Figures 17 and 18 shows the change of the average response time of the engine when two services are applied. It can be found that the change is more intense than it in Figure 17.
7 Related works The research on the service process engine has become increasingly important thanks to the continued rise in the popularity of using SOA. Up to now, there are many engines providing service process enactment support. For examples, commercial engines, like IBM WebSphere MQ Workflow [9], Oracle Process Manager [19], Tibco iProcess Engine [24] are already available. Some free open source engines like Jbpm Engine [10] and ActiveBPEL Engine[1] also exist. Although these engines can be deployed as multiple instances, each instance of the same engine is a standalone one without the capability to communicate with other instances; and as a result, its inherent structure cannot be configured dynamically. With the same aim as ours for a dynamically configurable engine, the JOpera is a service process engine that can run on a cluster of computers and reacts to workload variations by altering its configuration for optimal use of available resources [22]. Specifically, the system employs an autonomic controller that monitors the current workload and state of the system. The difference between ours and that of JOpera is JOpera does not distinguish different load levels brought by various service requests and dissimilar capabilities of service nodes. In contrast, we develop a fuzzy control method for the engine that takes advantage of such information to better match service requests and the capabilities of underlying service nodes. A service process engine is very similar to a workflow engine. Various distributed workflow engines have been proposed and developed, and there are already many distributed business workflow management systems in the market. Although the Figure 14 VoPD membership function.
1 NB
NS
M
PS
PB
-400
-200
0
200
400 ms/s
492 Figure 15 The number of concurrent requests vs. time.
World Wide Web (2010) 13:475–495
Number of Concurrent Requests 40 30 20 10 0 60203
90360
165547
225782
301078
225782
301078
Time (ms)
Figure 16 The service number vs. time.
Service Number
5 4 3 2 1 0
Figure 17 The average response time vs. time.
60203
90360
165547 Time (ms)
Average Response Time (ms) 10000 8000 6000 4000 2000 0
Figure 18 The average response time vs. the number of concurrent requests.
60203
90360
165547 Time (ms)
225782
301078
Average Response Time (ms) 12000 10000 8000 6000 4000 2000 0
24
36
30 Time (ms)
30
24
World Wide Web (2010) 13:475–495
493
components of these systems are distributed across several nodes, their structures cannot be changed dynamically. In [5], the load-balancing technology for distributed WFMSs is given and a workflow load index to measure load level of workflow engines is defined. But it does not provide details as how to develop a re-configurable workflow engine. In [6], a goal-driven auto-configuration tool is introduced and the tool can recommend an appropriate system configuration in terms of replicated workflow, application, and communication servers, so as to meet given goals for performance, availability, and performance at low system costs. The basic idea of our service process engine system is very similar to theirs. In their system, a workflow engine can have several copies and the load is distributed to these distributed engines. In our system, the interfaces of the process engine are implemented as separate services, which can be deployed independently. By doing so, we increase the scalability and also the flexibility of the whole engine. Besides this difference, they construct their tools based on the CORBA, while in our system, the Jini architecture is adopted so that the system can be re-configured more easily with the help of the Jini services.
8 Conclusion and future works Popular Internet applications need to be able to scale to large number of users and concurrent requests. These applications make use of multiple services, and a centralized process engine is used for orchestrating the interaction between these services. As a result, the centralized process engine can become a potential system bottleneck. In this paper, we propose a distributed selfconfigurable service process engine. In the architecture, service requests with different loads are allocated to corresponding services with different capabilities. Enactment services are added and removed, based on the needs of the system. As a result, the proposed engine is designed as a system for high performance and high availability. Currently, we have developed a prototype as a proof-of-concept. In the future work, we will be enhancing the system with new capabilities. These include: (1) (2)
Design of a more efficient workload-balancing algorithm, which is able to autonomously perform rule optimization; Design of an engine that is capable of discovery of available resources, and perform deployment of enactment services to support load increases. So far, we have developed the auto-deploying tools for services and we will integrate these tools into the system.
Acknowledgements This work was supported by China NSF (under Grant No. 60873230), Basic Research of Shanghai Science and Technology Commission (under Grant No. 08JC1411700), Program for New Century Excellent Talents in University (under Grant No. NCET-08-0347), the National High-Tech Research and Development Plan of China (under Grant No. 2007AA01Z137 and 2006AA01A124).
References 1. Active Endpoints: The ActiveBPEL Community Edition Engine, http://www.activevos.com/communityopen-source.php(2009) Accessed 5 Feb. 2009 2. Darlington, J., Cohen, J., Lee, W.: An architecture for a next-generation Internet based on web services and utility computing, in Proceeding 15th IEEE International Workshops on Enabling Technologies:
494
3. 4. 5.
6.
7.
8.
9. 10. 11.
12. 13. 14. 15. 16. 17. 18. 19. 20.
21. 22.
23. 24. 25. 26. 27. 28.
World Wide Web (2010) 13:475–495 Infrastructure for Collaborative Enterprises (WETICE′06), 26–28 June 2006, pp.169–174(2006) doi: 10.1109/WETICE.2006.1 Dustdar, S., Schreiner, W.: A survey on web services composition. Int. J. Web Grid Services 1, 1–30 (2005). doi:10.1504/IJWGS.2005.007545 Furmento, N., Hau, J., Lee, W., Newhouse, S., Darlington, J.: Implementations of a service-oriented architecture on top of Jini, JXTA and OGSI. Lect Notes Comput Sci. 3165, 90–99 (2004) Gillmann, M. Mindermann, R. Weikum G., Workflow Management with Service Quality Guarantees, in Proceedings of the 2002 ACM SIGMOD international conference on Management of data (Madison, Wisconsin, June 03–06, 2002) Lecture Notes In Computer Science, 1901(2000) 186–197 doi: 10.1145/ 564691.564718 Gillmann, M., Weissenfels, J., Shegalov, G., Wonner, W., Weikum, G.: A Goal-driven AutoConfiguration Tool for the Distributed Workflow Management System Mentor-lite, in ACM Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data (Dallas, U.S.A.,18–20 May 2000). pp.595–595 (2000) doi: 10.1145/335191.336577 IBM, BEA Systems, Microsoft, SAP AG, Siebel Systems: Business Process Execution Language for Web Services version 1.1, http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ (2005) Accessed 5 Feb. 2009 IBM: SOA programming model for implementing Web services, Part 8: Human-based Web services, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/index.html (2005) Accessed 5 Feb. 2009 IBM: WebSphere MQ Workflow, http://www-01.ibm.com/software/integration/wmqwf/ (2009) Accessed 5 Feb. 2009 Jboss: Jbpm, WS-BPEL Runtime User Guide, http://docs.jboss.com/jbpm/bpel/v1.1/userguide/(2007) Accessed 5 Feb. 2009 Jussi Vanhatalo, J., Völzer, H., Leymann, F., Moser, S., Automatic workflow graph refactoring and completion, Proceedings of the 6th International Conference on Service-Oriented Computing, (Sydney, Australia, December 01–05, 2008) pp.100–115 (2008)doi:10.1007/978-3-540-89652-4_11 Kosko, B.: Neural networks and fuzzy systems: a dynamical systems approach to machine intelligence. Prentice-Hall, Englewood Cliffs (1992) Menasce, D.A.: QoS issues in Web services. IEEE Internet Computing 6(6), 72–75 (2002). doi:10.1109/ MIC.2002.1067740 Milanovic, N., Malek, M.: Current solutions for web service composition. IEEE Internet Comput. 8(6), 51–59 (2004). doi:10.1109/MIC.2004.58 Milenkovic, M., Robinson, S.H., Knauerhase, R.C., Barkai, D., Garg, S., Tewari, A., Anderson, T.A., Bowman, M.: Toward internet distributed computing. Computer 36(5), 38–46 (2003). doi:10.1109/MC.2003.1198235 MomentumSI Inc.: Service Composition, http://www.serviceoriented.org/service_composition.html (2007). Accessed 5 Feb. 2009 Newcomer, E., Lomow, G.: Understanding SOA with Web Services. Addison Wesley (2005) OASIS, UDDI Version 3.0.2, http://www.uddi.org/pubs/uddi_v3.htm (2004). Accessed 5 Feb. 2009 Oracle: Oracle BPEL Process Manager Developer’s Guider, http://download-west.oracle.com/otndocs/ products/bpel/bpeldev.pdf (2005) Accessed 5 Feb. 2009 Ouyang Chun, van der Aalst Wil M. P., Dumas Marlon, ter Hofstede Arthur H. M., La Rosa Marcello: Service-oriented processes: an Introduction to BPEL. In: Cardoso, J. (eds.) Semantic Web services : Theory, Tools, and Applications, Chapter 8, pp.155–188. Information Science Reference (IGI Global) (2007) Papazoglou, M.P., Georgakopoulos, D.: Service oriented computing. Comm. ACM 46, 1025–28 (2003). doi:10.1145/944217.944233 Pautasso, C., Heinis, T., Alonso, G., Autonomic Execution of Service Compositions, in Proceedings of the 3rd International Conference on Web Services (ICWS 2005) (Orlando, Florida, July 2005) pp. 435– 442 (2005) doi: 10.1109/ICWS.2005.28 SUN: Jini(TM) Architecture Specification, Version 2.0, http://www.sun.com/software/Jini/specs/Jini2_0. pdf (2003) Accessed 5 Feb. 2009 Tibco: TIBCO Business Studio™, iProcess Developer’s Guide, http://www.tibco.com/devnet/resources/ business_studio/tib_bs_procdev_user.pdf (2008) Accessed 5 Feb. 2009 Tsesmetzis, D., Roussaki, I., Sykas, E.: Modeling and simulation of QoS-aware Web service selection for provider profit maximization. Simulation 83(1), 93–106 (2007). doi:10.1177/0037549707079229 W3C, Latest SOAP versions, http://www.w3c.org/TR/soap(2007). Accessed 5 Feb. 2009 W3C, Web Services Description Language (WSDL) 1.1, http://www.w3c.org/TR/wsdl (2001). Accessed 5 Feb. 2009 W3C: WSCL: The Web Services Conversation Language, http://www.w3.org/TR/wscl10/ (2002) Accessed 5 Feb. 2009
World Wide Web (2010) 13:475–495
495
29. Weber, R., Schuler, C., Neukomm, P., Schuldt, H., Schek, H.: Web service composition with O’GRAPE and OSIRIS. In: Freytag, J. C., Lockemann, P. C., Abiteboul, S., Carey, M. J., Selinger, P. G., Heuer, A. (eds.) Proceedings of the 29th international Conference on Very Large Data Bases–Volume 29 (Berlin, Germany, September 09–12, 2003). pp. 1081–1084. Very Large Data Bases. VLDB Endowment (2003) 30. Yu, W.D., Radhakrishna, R.B., Pingali, S., Kolluri, V.: Modeling the measurements of QoS requirements in Web service systems. Simulation 83(1), 75–91 (2007). doi:10.1177/0037549707079228 31. Zeng, L., Benatallah, B., Dumas, M., Kalagnanam, J., Sheng, Q.: Quality-driven web services composition, in Proceedings 12th International Conference on the World Wide Web (WWW) (Budapest, Hungary, 20–24 May 2003) pp. 411–421 (2003) doi: 10.1145/775152.775211
