J. Cent. South Univ. Technol. (2010) 17: 357-362
DOI: 10.1007/s11771-010-0053-z 
A novel group-based actived active service protocol for migrating workflows
WANG Rui(王睿)1, 2, ZENG Guang-zhou(曾广周)1
1. School of Computer Science and Technology, Shandong University, Jinan 250061, China;
2. School of Computer Science and Technology, Shandong Economic University, Jinan 250014, China
? Central South University Press and Springer-Verlag Berlin Heidelberg 2010
Abstract: Based on the methods of acquaintance cache and group-based intelligent forwarding of service recommendations, a novel group-based active service (GAS) protocol for migrating workflows was proposed. This protocol did not require service requesters to discover services or resources. The semantic acquaintance knowledge representation was exploited to describe service groups and this semantic information was used to recommend service to respective clients. The experimental results show that the new protocol proposed offers better performance than other protocols in terms of first-response-time, success-scope and ratio of success-packet-number to total-packet-number. When the number of service request packet is 20, the first-response-time of GAS protocol is only 5.1 s, which is significantly lower than that of other protocols. The success-scope of GAS protocol is 49.1%, showing that GAS protocol can effectively improve the reliability of mobile transactions. And the ratio of success-packet-number to total-packet-number of GAS protocol is up to 0.080, which is obviously higher than that of other protocols.
Key words: migrating workflows; active service; service groups; service recommendation
1 Introduction
Resource acquirement and management is a challenge for migrating workflows. Researches in the field of migrating workflows primarily focused on workflow specifications [1-2]. They deal with the problem of managing the flow of data from a service site to another site in workflows. However, the primary assumption in such workflow specifications is that the workflow designer has the ability of knowing the perfect knowledge of all the details of the process and predicting changes of network configuration.
There have been considerable researches and industry effort in Web services in the context of wired as well as partly wireless network. Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. The basic components of Web services, such as simple object access protocol (SOAP) [3], web services description language (WSDL) [4] and universal description discovery and integration protocol (UDDI) [5], solve the interoperability problems of heterogeneous applications, but they are still not sufficient for large-scale industrial applications because of the lack of flexibility necessary in a dynamic business environment. The concept of active service for mobile middleware was proposed by CHUANG and ALVIN [6]. But discovering or retrieving useful information from the WWW is a difficult task [7-9]. The relevant information that users are interested in is hidden in the irrelevant data, or scattered over various sources. In order to solve this problem, a novel group-based active service (GAS) protocol for migrating workflows was proposed, which did not have broadcast storm problem and was guaranteed to recommend services (if present) for clients in migrating workflows.
The solution exploited the semantic capabilities offered by the web service modeling ontology (WSMO) to effectively describe services/resources workflows [10]. The services presented on the service organization sites were divided into several groups based on the acquaintance knowledge sharing. The group-based recommender information was used to intelligently forward among acquaintances in migrating workflows and improve the reliability of mobile transactions.
2 Preliminaries
2.1 Goal-oriented migrating workflow model
In Refs.[11-12] the framework of migrating workflow based on the mobile computing paradigm was proposed, which was easy to construct and manage in environments characterized by high levels of mobility.
A goal-oriented migrating workflow model shown in Fig.1 comprises autonomous, loosely coupled components that are composed of a workflow engine, service organizations and migrating instances. Each migrating instance is mapped into a business goal. A migrating workflow transfers its code (specification) and its execution state to a service organization site, negotiates a service to be executed on its behalf, receives the results, and moves on. A sequential business flow is constructed dynamically by means of migrating instances which constitute the flow creation and run at different working places (service organizations) simultaneously. Hence, the migrating workflow can improve the scalability and flexibility with the characteristic of uncertainty and variability. Considering such a model, the migrating workflow system technology has to evolve towards cooperation and integration.
Fig.1 Goal-oriented migrating workflow model
The workflow engine is the main actor that is identified together with its strategic objectives and goals. The goal of main actor is in the composite state, which is the root state of the hierarchical structure.
A composite goal GC is a tuple: GC={Gname, Gtime, Gcost, {GMI}}, where Gname is the name of the composite goal; Gtime is the valid time of the composite goal; Gcost is the cost of the composite goal; and {GMI} is the set of sub-goals of the composite goal.
The main actor is decomposed into a number of sub-actors (migrating instances). The goal of migrating instance is a sub-goal that accommodates a single state that cannot be split any more. Migrating instances’ goals are representations of an objective for which fulfillment is sought through the execution of workflow services.
A migrating instance (MI) is a tuple, which is expressed by: MMI={GMI, St, A, LMI}, where GMI is the sub-goal of GC; St is the current state of the MI; A is the set of anchorages where MI migrates to; and LMI is the lifetime of the MI.
A service organization is a computational entity that is able to achieve MIs’ goal. At the same time, a service organization might provide one or more services.
A service organization agent (SOA) is a tuple, which is expressed by: ASOA={SID, SG, Kprivate, Kshare}, where SID is the ID of the service organization agent; SG is the goal of the service organization agent; Kprivate is the knowledge about the condition of forming its group, and conditions specify the required state of the anchorage and its possible group members; and Kshare is the knowledge about the effect of this service organization. The effect is the description of the state of the MI that is guaranteed to be reached after the successful execution of the workflow service.
2.2 Coalition, group and acquaintance
In the subject domain, the whole collection of agents participating in migrating workflows will be understood as the multi-agent community. The concept of a coalition will be introduced as a collection of service organization agents that share information about their resources and all agree with possible groups.
A coalition is a tuple: C={{GR}, {CG}, Kpublic}, where {GR} is a set of groups; {CG} is a set of goals; and Kpublic is a set of Kshare that associates each set of group.
Define a group as a set of service organizations, which agree with a single, well-specified goal. Group members commit themselves to collaborate on the within-group-shared goal.
A group is a tuple: GR={gr_id, gr_goal, S, Lgroup, {Kshare}}, where gr_id is the ID of the group; gr_goal is the goal of the group; S is a set of SOAs; Lgroup is the lifetime of the group; and {Kshare} is a set of knowledge about the effect of this group execution.
A group, unlike a coalition, is usually regarded as a short-term agreement between collaborative organi- zations. The members of group must agree on the goals that they achieve. They share the knowledge, thus a goal is decomposed into a set of tasks. The tasks will be delegated by the group members.
Members of a group may have acquaintance relation. The acquaintances must agree on the goals that they achieve. Each acquaintance may participate in one group of ‘friendly’ organizations. At the same time, it may be actively involved in several groups of service organizations cooperating in fulfilling specific shared goals. Computation and communication complexity of forming such a group depends on the amount of knowledge that the SOA is related to the others and on sophistication of the SOA capability to reason about the other SOAs’ resources, plans and intentions. At run time, when SOA receives a goal that is beyond its capability, it evaluates other SOAs’ capability and skill, forms the group by recognizing those SOAs that have capability to achieve the goal, figures out the most qualified peer, and recommends to MI.
3 GAS protocol
The GAS protocol is based on the methods of acquaintance cache and group-based intelligent forwarding of service recommendations. This protocol achieves efficient network bandwidth usage as well as increased flexibility in the service matching process. Acquaintance knowledge sharing of SOAs gives the protocol to be the distributed approach that is different from other registries based on centralized/ semi-centralized service discovery protocols.
3.1 Formation of service group
Service groups are initiated by each individual SOA that has one or more services. Each service has a corresponding service description using WSMO-based ontology. Every SOA sends a list of information of forming service group in its radio range. The entire peer SOAs that are in their radio range are considered to be within the coalition. In this phase, SOAs analyze the information about the members of the migrating workflow coalition and make an attempt to form their acquaintance groups. In principle, each SOA compares its own private knowledge (i.e., group formation restrictions) with the public knowledge about the possible group members (i.e., goal of the organization and competence). When the SOA detects a possible future collaborator, it will invite the collaborator to join the group. Throughout the negotiation process, the invitee chooses the best group according to its collaboration preferences of SOAs from existing groups. If failure happens, this invitee might start a new group by itself.
A packet of service group formation (SGF) that is sent to the possible acquaintances contains the following fields (shown in Fig.2).
Fig.2 Structure of service group formation packet
Each service group formation packet contains that indicates the packet type. and are used to disambiguate duplicate service group formation information. contains information about the service. field indicates the expired time of the service group. Each packet also contains a field called . This field enumerates the groups of all the non-local group services that the sender SOA belongs to.
When a service group formation packet is sent from SOAsender to other SOAs, the field will be constructed in the following manner:
If (send(SGF)){
While(each SOA1 … SOAM belonging to Service- coalition)
{
If (SOAi is not in local-group and
Match(SOAsender-Kprivate, SOAi-Kshare))
Contract(SOAsender, SOAi) ;
Add SOAi to local-group;
}
}
3.2 Acquaintance cache
Each SOA in the migrating workflow maintains a finite cache to store information of its acquaintance in its group. Whenever SOA receives a packet about group formation, it performs the following steps to store its acquaintance information.
If (duplicate (SGF))
Discard packet;
Else
{
Extract local group information;
Extract other groups information;
Store entry in acquaintance cache;
Set the lifetime on the entry;
}
Each entry in the acquaintance cache contains the following fields (shown in Fig.3).
The acquaintance cache in each SOA contains and that are used to disambiguate duplicate acquaintance information. Field indicates the acquaintance’s goal, conditions and effects. Field contains a list of the groups that the corresponding acquaintance belongs to.
3.3 Service recommendation
In a service organization site, if MI’s service request cannot be satisfied by this SOA alone, a service recommendation will be proposed, which is a process that SOA actively provides information about other workflow sources, and potentially satisfy the MI’s desires.
By virtue of acquaintance cache, the local cache (in an ideal scenario) contains the descriptions of services goal in the sites within group. The service request description is matched with the services present in the local group of the source site. Thus, by comparing the request with the local group, the protocol is able to automatically check the availability of services within this group. Thus, this protocol achieves efficiency in recommending services (if available) in the acquaintances. When a match is found in the SOA’s group, a service recommendation will be constructed. The service recommendation packet contains the following fields (shown in Fig.4).
indicates the packet type. is used to disambiguate duplicate packet information. specifies the number of acquaintance of which these recommendations may travel. determines the set of neighboring service organizations that may be selected for this service recommendation. If the request matches one of those acquaintances, then there will be a chance that the available service might be recommended. Thus, instead of broadcasting the request, the protocol chooses the recommendation among those acquaintances. The process is performed as the following steps:
While (each entry in acquaintance cache)
{
If match (acquaintance description, service request)
{Add acquaintance to recommender list;
Recommender counter++;
Forward the recommendation to MI;
If (the recommendation is never forwarded)
Broadcast the service request to the other groups;
}
}
Each SOA contains a lightweight service matching module that performs several activities [13]. It matches a service request to a service description present in the SOA’s knowledge. Services are matched based on the goal of SOA, conditions and effects. This matching module may potentially use the semantic features of WSMO to increase the richness of service matching. This is used to fill up the respective entries in the service group formation and service recommendations.
When a service recommendation matches a MI request, whether the service is local or not, the MI will generate a migrating reply. The MI will find the previous address from recommender list to send the reply. The reply of MI thus follows the path through which the commendation travels.
Fig.3 Structure of acquaintance cache
Fig.4 Structure of service recommendation packet
4 Experimental analysis
The GAS protocol was simulated on the well-known simulator Glomosim [14-15] under different mobility scenarios. Several interesting experiments were carried out to test the scalability and the efficiency of GAS protocol in migrating workflows. Experiments were carried out by a topology consisting of 25-100 sites. To evaluate the improvement of GAS protocol, the following two protocols were implemented: a traditional flooding scheme for service discovery (BASIC) and an ODMRP [16].
4.1 Performance metrics
Three performance metrics are considered in the experiments.
(1) First-response-time. It is the interval between the generation of the MI’s request packet and the arrival of the corresponding SOA’s first reply packet. It measures the promptness of these service protocols.
(2) Success-scope. It is the scope of protocol sessions in which SOA receives at least one reply packet. It reflects the effectiveness of these service protocols.
(3) Ratio of success-packet-number to total-packet- number (SPN2TPN). This metric is the ratio of success-packet-number to the number of all packets (request packets, service recommendation/advertisement packets, and reply packets). It reflects the efficiency of these service protocols.
4.2 Experimental results
Three experiments were performed, which used the two selected service discovery protocols and GAS protocol, respectively, where request numbers were set to be 20, 40, 60, 80, and 100, respectively. Each set consisted of 100 similar simulations. Experimental results are shown in Figs.5-7.
Fig.5 shows the effect of request number on first- response-time metric. It can be seen that GAS improves the system performance in terms of first-response time. The first-response time of GAS is significantly lower than that of BASIC. When the number of service request packet is 20, the first-response time of GAS is only 5.1 s, while that of BASIC reaches 8.0 s. In BASIC and ODMRP, this metric keeps almost constant. However, in GAS protocol, this metric decreases gradually along with the increase of request packet number. As request packet number increases, more service requests will be matched
Fig.5 First-response-time under different request packet numbers
in fewer groups. Hence, first-response-time will be reduced.
Fig.6 shows the effect of request packet number on success-scope metric. It can be seen that GAS effectively improves the success-scope of mobile transactions. When the number of service request packet is 20, the success-scope of GAS is 49.1%, while that of BASIC only reaches 30.0%. The increase of request number leads to the failure of the packet transmission, which can greatly decrease the success-scope since reply packets are very few. Therefore, in BASIC and ODMRP, success-scope decreases along with the increase of request packet number. However, in GAS protocol, group-based service recommender operation makes up for the negative effect of request packet number on this metric. Hence, success-scope is not decreased in GAS protocol.
Fig.6 Success-scope under different request packet numbers
Fig.7 shows the effect of request packet number on SPN2TPN metric. This metric is determined by request packet number, service recommendation/advertisement packets and reply packet number. Hence, the results in this figure are intelligible. It can be seen that the SPN2TPN of GAS is significantly higher than that of other protocols. When the number of service request packet is 20, the SPN2TPN of GAS reaches 0.080, while that of BASIC is only 0.022. Based on the results, GAS is almost the most efficient protocol under different request packet numbers. The superiority of GAS over BASIC and ODMRP protocols in this metric is more remarkable with higher request packet number.
Fig.7 SPN2TPN under different request packet numbers
5 Conclusions
(1) A novel active service protocol, GAS, is introduced. In GAS, acquaintance cache and group- based service recommendation are introduced for migrating workflows. SOA recommends the acquaintances in its group to MI. This eliminates complexity of service discovery and service advertisement.
(2) A series of performance metrics such as first- response-time, success-scope and ratio of success- packet-number to total-packet-number are given. According to the experimental results, it is believed that GAS is a more preferable service protocol for migrating workflows.
(3) Future work will be focused on improving the pervasive use of the active service protocol to settle the problem of collaboration across multiple service organizations. With this enhancement, group-based active service protocol will become the cornerstone of goal-oriented migrating workflows.
References
[1] DEHNERT J, DER VAN A. Bridging the gap between business models and workflow specifications [J]. International Journal of Cooperative Information Systems, 2004, 13(3): 289-332.
[2] WANG J C, ROSCA D. Dynamic workflow modeling and verification [J]. Lecture Notes in Computer Science, 2006, 4(1): 303-311.
[3] GUDGIN M, HADLEY M, MENDELSOHN N, MOREAU J J, NIELSEN H F. SOAP version 1.2. Part Ⅰ: Messaging framework [R]. Cambridge: W3C, 2003.
[4] CHINNICI R, GUDGIN M, MOREAU J J, SCHLIMMER J, WEERAWARANA S. Web services description language (WSDL) version 2.0. Part Ⅰ: Core language [R]. Cambridge: W3C, 2004.
[5] CLEMENT L, HATELY A, VON R C, ROGERS T. UDDI version 3.0. 2 [R]. Billerica: OASIS, 2004.
[6] CHUANG S N, ALVIN T. Active service for mobile middleware [J]. World Wide Web, 2005, 8(2): 127-157.
[7] HUHNS M N, SINGH M P. Service-oriented computing: Key concepts and principles [J]. IEEE Internet Computing, 2005, 6(1): 75-81.
[8] PAPAZOGLOU M P, DEN V H. Service-oriented design and development methodology [J]. International Journal of Web Engineering and Technology, 2006, 2(4): 412-442.
[9] PAPAZOGLOU M P. Web services: Principles and technology [M]. Upper Saddle River: Pearson Prentice Hall, 2008.
[10] ROMAN D, LAUSEN H, KELLER U, DE B J, BUSSLER C, DOMINGUE J, FENSEL D, HEPP M, KIFER M K R B. D2v1. 2. web service modeling ontology (WSMO) [R]. Cambridge: W3C, 2005.
[11] ZENG Guang-zhou, DANG Yan. The study of migrating workflow based on the mobile computing paradigm [J]. Chinese Journal of Computers, 2003, 26(10): 1343-1349. (in Chinese)
[12] WANG Rui, ZENG Guang-zhou. Adoptive scheme for developing organizational teamwork of workflow resources [J]. Journal of Computational Information Systems, 2009, 5(1): 207-212.
[13] CARDOSO J, NETLIBRARY I. Semantic web services: Theory, tools and applications [M]. Chocolate Avenue Hershey: Information Science Reference, 2007.
[14] FEELEY M, HUTCHINSON N, RAY S. Realistic mobility for mobile ad hoc network simulation [J]. Lecture Notes in Computer Science, 2004, 4(2): 324-329.
[15] KATO T, ONO M, HIGAKI H. Parallelization of GloMoSim wireless network simulator [J]. IPSJ SIG Technical Reports, 2006, 2(1): 55-58.
[16] BAE S H, LEE S J, SU W, GERLA M. The design, implementation, and performance evaluation of the on-demand multicast routing protocol in multihop wireless networks [J]. Network, IEEE, 2000, 14(1): 70-77.
Foundation item: Project(60573169) supported by the National Natural Science Foundation of China
Received date: 2009-05-26; Accepted date: 2009-08-22
Corresponding author: WANG Rui, PhD, Associate professor; Tel: +86-531-88526397; E-mail: kingkeen@126.com
(Edited by CHEN Wei-ping)
