2010 IEEE 6th World Congress on Services
Virtual Services in Cloud Computing Jicheng Fua
[email protected]
Wei Haob
Michael Tuc
Biao Maa
Joshua Baldwina
Farokh B. Bastanid
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
a
Computer Science Department, University of Central Oklahoma, b Computer Science Department, Northern Kentucky University c School of Business and Information Systems, Dakota State University d Computer Science Department, The University of Texas at Dallas
cloud computing. Service composition makes it possible to reuse existing services to achieve some new goals to save both the development cost and time. Many different techniques for automating web service composition have recently been investigated. Among these techniques, AI planning-based web service composition techniques have been extensively applied [9]. The key idea behind this technique is that web services can be modeled as AI planning actions and a web service composition problem can be transformed into a corresponding AI planning problem. The use of the Semantic Web has made this transformation possible. For example, the ontology language OWL-S [8] is specifically designed to connect with AI planning. Each service in OWL-S is modeled as four key elements, namely, inputs, outputs, preconditions, and effects [9]. However, AI planning based service composition methods have a common problem, i.e., if the planning process fails, no partial solution is present. For example, to serve a demand in cloud, 100 services should be involved. Suppose, somehow, one of the services is missing or stops working, then the planning process would return failure although the majority of the services are available. Based on this problem, we propose the concept of virtual services. A virtual service exists only conceptually and there is no physical counterpart. Nevertheless, during the planning process, the virtual service is treated in the same way as physical services. The goal is to enable the planning process to go through even though the traditional planning process may fail. In this paper, we propose a general algorithm for identifying virtual services in the case of planning failure. A Graphplan-based [2] algorithm is proposed to implement the general algorithm. After a virtual service is derived, it will be used to bridge the semantic gap such that the planning process can succeed. The benefits of using virtual services fall into two aspects: (1) It facilitates the reuse of existing services even in the case of planning failure; (2) The specification of the virtual service provides valuable information for problem analysis, design, and development.
Abstract Cloud computing has aroused wide research interests and has been accepted by industry. Services are playing the essential role in cloud computing as cloud computing refers to “both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services”. Therefore, service-oriented architecture should play an important role in cloud computing. In addition, one of the characteristics of cloud computing is to make services available on demand. Given a group of services, different demands may involve different set of services and in different order. This is related to services reuse and composition. However, existing methods only solve service composition in a binary manner: Either a solution exists or no solutions at all. In this paper, we propose the concept of virtual services, which physically do not exist, but are conceptually treated in the same way as physical services. Virtual services are useful when traditional service compositions fail. Virtual services can connect the existing physical services and enable the composition process to succeed. The specifications of virtual services will provide valuable information about how to develop real services to meet the requirements of the given demand. In this paper, we present algorithms that can help identify the virtual services in the case of composition failure and provide the specification of virtual services for further analysis and development.
1. Introduction Cloud computing is characterized as making services available on demand. Services are essential to cloud computing, in which all the applications are delivered as services and the beneath datacenter hardware and software are referred as cloud [1]. Given a large number of services in the cloud, it is unpractical to define all the possible ways of using the services ahead of time. As a result, service reuse and composition cannot be avoided in 978-0-7695-4129-7/10 $26.00 © 2010 IEEE DOI 10.1109/SERVICES.2010.125
467
The rest of this paper is organized as follows: In Section 2, the system model for virtual services in cloud computing is discussed. In Section 3, we introduce the general algorithm for virtual services identification. In Section 4, we present the Graphplan-based algorithm that realizes the general algorithm. The improvements are discussed and an example is provided to illustrate the idea. In Section 5, we conclude the paper and identify some future research directions.
adopted and implemented, it will be removed from the virtual cloud and put into a real cloud. For service modeling, we follow the modeling method specified in [9], in which the capabilities of services are modeled with a 4-tuple, namely, inputs, outputs, preconditions, effects, i.e., I, O, P, E. Such modeling makes it natural to model a service as an action in AI planning and model the service composition process as an AI planning problem. Hence, throughout this paper, we assume that AI planning technique is used for service composition. Our algorithms are also based on AI planning and propose virtual services in the event of the regular planning process failure. The virtual services will enable the planning process to continue.
2. System Model
3. General Algorithm for Virtual Services Identification
Microsoft
Google
In this section, we provide a general algorithm that is independent of any specific planning algorithms and provides outlines for virtual service proposal if the regular planning process cannot go through. First of all, we make the following definitions to facilitate the discussions.
Virtual Cloud Cloud Amazon
Definition 1 (Planning Problem). A planning problem is a triple S0, G, O, where S0 is the initial state, G is the goal state, and O is the finite set of actions.
Figure 1: Virtual services in the cloud
S0 and G are two proposition sets, which consist of propositions to denote the initial and goal states. Each action a in O consists of precondition and effect, which are represented as pre(a) and eff(a), respectively.
Cloud computing is also known as Internet computing, whose goal is to set users free from the management of hardware, software, and data resources and shift these burdens to cloud service providers [3]. The applications in the cloud are delivered as services, which are represented as solid squares in Figure 1. The major companies, such as Google, Microsoft, Amazon, etc, all provide their own clouds. We consider services in the cloud consisting of physical services and virtual services (denoted as dotted squares in Figure 1). This model is designed to overcome the common issue that even though the majority of services are available in the cloud, a single miss of a piece of information will make service reuse and composition fail. Due to the security and business reasons, it is not practical to allocate a virtual service to a cloud owned by a specific company. Hence, in our system model, virtual services belong to a virtual cloud, which is denoted as the dotted ellipse in Figure 1. The virtual cloud is not owned by any companies and exists only conceptually. Conceptually, virtual services are treated in the same way as the physical services. They have clear specifications and semantic meanings. In the event of regular service composition failure, virtual services are used to bridge the semantic gaps and enable the composition processes to proceed. If a virtual service is
Definition 2 (Reverse Action). Action a is called a reverse action of action b iff pre(a) = eff(b) and eff(a) = pre(b), which is denoted as a = b-1. The reverse actions are only used for semantic computing. We do not really try to reverse an action/service. Instead, we use the reverse actions to facilitate discovering the missing information. We can extend the Definition 2 to planning problems as well, i.e., S0, G, O-1 = G, S0, O-1, in which the two planning problems are reverse of each other, i.e., the initial and goal states of the first planning problem are the goal and initial states of the second planning problem. In addition, the actions in the second planning problem are in the reverse form of those in the first planning problem. Figure 2 shows the outline of the algorithm. In the first step (line 1), the normal planning process 1 is performed. If the goal is reachable, then the regular service composition routine is followed to generate the composite service. Otherwise, the algorithm initiates a reverse planning process 2 (2 = 1-1), which starts from goal G and strives backwards to the initial state S0.
468
The idea is to have the planning process 1 go as far as possible towards goal G and have the planning process 2 go as far as possible towards the initial state S0. Then, based on the stopping points of the two planning processes, the algorithm proposes a virtual service vs, whose effects will contain the missing information for 1 so that 1 can go through. Meanwhile, the precondition of vs will contain the missing information for 2 so that 2 will succeed as well. Figure 3 visually illustrates the role played by the virtual service, which serves as the bridge between 1 and 2.
service reuse can be increased through the use of virtual services. In Section 4.4, we use an example to illustrate how the proposed algorithm works.
4.1 Graphplan Graphplan is a classic planning algorithm that operates on a planning graph, which is a directed, layered graph interleaved with proposition levels and action levels. The first proposition level contains the initial conditions and the first action level consists of actions that are applicable to the first proposition level. There is a special type of actions called “No-Op” that propagate the propositions from the current proposition level to the next proposition level. The effects of the regular actions in the action level together with the propositions propagated by no-ops from the current proposition level form the next proposition level. This corresponds to the graph expansion phase, during which the planning graph is extended in the forward direction until it has achieved a necessary (but perhaps insufficient) condition for plan existence. Then, the algorithm switches to the solution extraction phase, which performs a backward-chaining search on the graph to identify a valid plan.
1. Start planning 1 on the planning problem S0, G, O; 2. If goal G is not reachable Then 3. Start another planning process 2 on the planning problem G, S0, O-1 4. Based on the stopping points of 1 and 2, propose a virtual service vs that connects 1 and 2 so that both of the planning processes can go through; 5. Else 6. Generate the composite service; 7. End If
4.1.1 Level-off. Every planning graph has a fixedpoint, which is called level-off [2][5]. It happens when two adjacent proposition levels of the forward planninggraph are identical, i.e., they contain the same set of propositions and have the same exclusivity relations as shown in Figure 4, in which the proposition level Pi is identical with Pi+1. If we continue to expand the planning graph, the next action level Ai+2 will be identical with Ai+1. Action level Ai+2 will generate another proposition level which is identical with Pi+1. And the same pattern repeats forever. Hence, “level-off” can be seen as an endless loop, in which all applicable actions have been used, but cannot generate the desirable effects to exit the loop. When leveloff happens while the goal has not been reached, it means that there are no solutions to the current planning problem.
Figure 2. General Algorithm In 2, all the actions are in the reverse form of those in 1. Therefore, it is obvious to see if 1 fails to reach goal G, then 2 must fail to reach S0, too. Otherwise, we will get a contradiction by following the reverse direction of the plan generated in 2 to get a plan for 1.
1 S0
virtual service
2
G
P0
Figure 3: The role of virtual service
4. Virtual Service Identification Graphplan-based Algorithm
Pi
Ai+1
with
In this section, we propose an algorithm that implements the general algorithm (see Figure 2) for virtual service identification based on Graphplan [2]. In Section 4.1, we briefly introduce Graphplan, its properties, and justify why we chose Graphplan to implement the general algorithm. In Section 4.2, we present the Graphplan-based algorithm. In Section 4.3, we discuss how to make improvements so that the level of
Identical
Figure 4: Level-off
469
Pi+1
be the missing propositions. In line 5, the precondition of vs is calculated as pre(vs) = S0 Pl2, where Pl2 is the last proposition level containing all the propositions in 2. The difference between S0 and Pl2 is the set of propositions that is missing backward from the goal G. If the virtual service takes these missing propositions as the precondition and effect, then the planning processes in 1 and 2 will succeed.
In addition, due to no-ops, all the propositions in the current proposition level will appear in the next proposition level. As a result, when level-off happens, the last proposition level contains all the propositions in the current planning graph. This feature can be exploited to facilitate the identification of virtual services, which is discussed in Section 4.2. 4.1.2 Justification. The reasons that we chose Graphplan to implement the general algorithm lies in three aspects. (1) It is very efficient; (2) The planning graph is very informative and presents many valuable properties, e.g., level-off, that can be used for virtual services identification; (3) many up-to-date AI planners are based on Graphplan or planning graph, such as Conformant FF [6], Contingent FF [7], POND [4], etc. Therefore, the algorithm proposed in this paper can be readily applied to other AI planners.
4.2 Graphplan-based Identification Algorithm
Virtual
4.3 Improvements The way of deriving the precondition and effect for the virtual service in the algorithm of Figure 5 is still too rough. For example, we assume that the precondition of the virtual service comes directly from the initial state S0 without relying on any other actions. This eliminates the possibility that some intermediate actions generate the state in which the virtual service can be applied. Similarly, the way of calculating the effect of the virtual service may eliminate the possibility that the virtual service will enable other existing actions to achieve the goal G. As an improvement, we follow the principle that we should reuse as many existing services as possible when proposing the virtual service. Hence, the effect of the virtual service may not directly contribute to the goal G, instead, it generates an effect that enables some existing services such that the current planning process can continue. The set, Pl2 G, contains propositions that do not depend on the goal G in 2. The set of Pl2 G Pl1 will be the propositions missing in 1. However, there is a possibility that some propositions in G are never used by any regular actions in 2. They are simply propagated by no-ops to Pl2. Such kind of propositions should be generated by the virtual service so that the complete goal G can be achieved. This set of propositions can be calculated as follows,
Service
In this section, we present a Graphplan-based algorithm that follows the idea illustrated in Figure 2 to propose a virtual service in the case where the planning process fails. The virtual service will be treated as the regular service such that the planning process will proceed.
/*vs: is the virtual service to be proposed*/ 1. Start planning 1 on the planning problem S0, G, O; If level-off happens Then 2. 3. Start another planning process 2 on the reverse planning problem G, S0, O-1 4. Assume that Pl1 is the proposition level that level-off is identified in 1; and Pl2 is the proposition level that level-off is identified in 2 . 5. pre(vs) = S0 Pl2; 6. eff(vs) = G Pl1; 7. Else 8. Generate the composite service; 9. End If
G ∐∈ 2 ()
(1)
where Al2 is the last action level that contains all the actions in 2 1 ; ∐∈ 2 () is the union of preconditions of all the actions in 2. Then, the result of (1) is a set of propositions in G that are never used in any actions in 2. Hence, the only way to generate this set of propositions is to include it in the effect of the virtual service, i.e., (G ∐ ∈ 2 ()) eff(vs). We modify line 6 in Figure 5 as,
Figure 5: Virtual Service Identification based on Graphplan This algorithm replies on Graphplan’s intrinsic feature, i.e., level-off. The reason that the planning process levels off is that some propositions are missing such that the goal state is not reachable. Therefore, in line 6 of Figure 5, the effect of the virtual function is calculated as eff(vs) = G Pl1, where Pl1 is the last proposition level in 1 containing all the propositions that can be reached from the initial state S0. The difference between G and Pl1 will
1
The planning graph has a property that actions appear in the current action level must appear in the next action level as well due to the propagation of propositions. As a result, the last action level contains all the actions.
470
If ((Pl2 G Pl1) (G ∐∈ 2 ())!= Empty) then eff(vs) = (Pl2 G Pl1) (G ∐ ∈ 2 ()); Else eff(vs) = G Pl1; End if
(Pl1 S0) Pl2
(2)
If the propositions are needed in both the forward planning 1 and backward planning 2, then they are good candidates for the precondition of the virtual service. Hence, in the first step, the algorithm checks whether (2) is empty. Pl1 S0 is the set that does not rely on the initial state S0. The intersection of Pl1 S0 and Pl2 will be the propositions needed in both of the planning processes. If the result is empty, we will change back to the way in line 5 of Figure 5 to calculate the precondition of the virtual service. The updated algorithm is shown in Figure 6.
We first check whether ((Pl2 G Pl1) (G ∐ ∈ 2 () is an empty set. If the set if empty, the algorithm switches back to the way in line 6 of Figure 5 to calculate the effect. Otherwise, the algorithm uses this set as the effect of the virtual service. As a result, the virtual service only generates the effect that must be generated to enable the planning process to continue. The virtual service relies on existing services to generate the rest of goal set.
4.4. An Example As a simple example, we assume that there is a home inspection company, which provides on-demand home inspection services, such as roof, foundation, fire alarm, etc. The company is planning to put its services to the cloud so that both the customers and its inspectors can take advantage of the benefits of cloud computing. Currently, the company has the following services for inspectors:
/*vs: is the virtual service to be proposed*/ 1. Start planning 1 on the planning problem S0, G, O; 2. If level-off happens Then 3. Start another planning process 2 on the planning problem G, S0, O-1 4. Assume that Pl1 is the proposition level that level-off is identified in 1; and Pl2 is the proposition level that level-off is identified in 2. 5. If((Pl1 S0) Pl2) != EMPTY then 6. pre(vs) = ((Pl1 S0) Pl2); 7. Else 8. pre(vs) = S0 Pl2; 9. End If 10. If ((Pl2 G Pl1) (G )!= Empty) then 11. eff(vs) = (Pl2 G Pl1) (G ); 12. Else 13. eff(vs) = G Pl1; 14. End If 15. Else 16. Generate the composite service; 17. End If
Service Name InspectQuery
GIS
Precondition
Effect
Valid(userId), Valid(password), Valid(inspectDate) Available(inspections , inspectDate), Reserved(car, inspectDate)
Available(inspections, inspectDate) Available(itinerary, inspectDate)
Table 1: Service list An inspector uses the “InspectQuery” service to check a specific date and see if there are any inspections scheduled for him. After obtaining the list of inspections, the inspector will reserve a car provided by the home inspection company on that specific date. Then, the inspector will use the GIS service to get an itinerary for that specific date. The itinerary is supposed to be optimal in terms of distance. Now, an inspector wants to get the itinerary for a specific date by providing the userId, password, and the date on which the inspections are scheduled. Then, the planning algorithm is run and tries to get a composite service that can fulfill the requirements. Obviously, the regular AI planning-based methods will fail due to the miss of car reservation service. If the algorithm in Figure 6 is executed, then we obtain Pl1 = {Valid(userId), Available(Inspections, inspectDate), Valid(password), Valid(inspectDate)}, where Pl1 is the last proposition level when level-off happens in 1. Pl1
Figure 6: Updated algorithm for virtual service identification Following the same principle, we can modify line 5 in Figure 5 for the precondition of the virtual service so that the virtual service would rely on the intermediate actions to enable its precondition during the planning process. The determination of the precondition for the virtual service is subtle because an action can either have an empty precondition set which means that it can be applied at anytime without any constraints or its precondition can include all the propositions in Pl1. All are right choices. In the updated algorithm, we use the following heuristic:
471
contains all the propositions that can be generated in 1. Similarly, Pl2 = {Available(itinerary, inspectDate), Available(Inspections, inspectDate), Reserved(car, inspectDate)). The initial state S0 = {Valid(userId), Valid(password), Valid(inspectDate)} and the goal G = { Available(itinerary, inspectDate)}. According to the algorithm, the specification of the virtual service is as follows,
Although the algorithms in this paper can propose the specifications for the virtual services, the virtual services only serve as suggestions to the given AI planning problems. The specifications do not take quality of service and other attributes into consideration. In the future, we will construct a system model for virtual service proposal and the virtual services generation process will be systematically evaluated according to the system model. In this way, the virtual services will be able to better reflect the true needs in cloud computing.
pre(vs) = (Pl1 S0) Pl2 = {Available(Inspections, inspectDate)}; eff(vs) = ((Pl2 G Pl1) (G ∐ ∈ 2 () ) = {Reserved(car, inspectDate)}.
6. References [1] M. Armbrust, et al., “Above the Clouds: A Berkeley View of Cloud Computing,” UCB/EECS-2009-28
The specification of the virtual service is valid since only when the inspector has inspections scheduled on a particular date, can he reserve a car. After the reservation, a car is reserved. (In this simple example, we do not consider the situation of reservation failure.)
5. Conclusions Directions
and
Future
[2] A. Blum and M. Furst, “Fast planning through planning graph analysis”, Artificial Intelligence, 90, 1997, pp. 281–300. [3] H. Brian, Cloud computing, Communications of the ACM, Volume 51, Issue 7, July 2008.
Research
[4] D. Bryce, S. Kambhampati, and D. E. Smith, “Planning Graph Heuristics for Belief Space Search”, Journal of Artificial Intelligence Research, Volume 26, 2006, pp. 35–99.
In this paper, we propose the concept of virtual services. A service is called virtual when it only exists conceptually. Virtual services are designed to facilitate service reuse and overcome the problems associated with the traditional service composition methods, i.e., either return a solution(s) or no solutions at all. In contrast, virtual services are used to connect physical services and enable the service composition process to continue. We present a general algorithm based on AI planning for service composition. The algorithm outlines the steps to generate virtual services in the situation of planning failure. Then, a Graphplan-based algorithm is designed to implement the general algorithm. Finally, we propose an improvement for the Graphplan-based algorithm. The updated algorithm follows the principle that we should reuse as many existing services as possible when virtual services are used. Since the proposed algorithm uses only Graphplan’s intrinsic features, it can be readily applied to other up-to-date AI planners that are based on planning graph. Virtual services are treated in the same way as regular services and are used to bridge the semantic gaps so that the planning process will succeed. The proposed virtual services have definite specifications, i.e., preconditions and effects. The generated plans with virtual services are helpful in illustrating how the services are composed together and how existing services are used. Meanwhile, the virtual services present concrete ideas to the designers and developers about what kind of information is missing and how to implement a service to fulfill the given demand.
[5] M. Ghallab, D. Nau, P. Traverso, Automated planning: theory and practice, Morgan Kaufmann (2004), pp. 113-139. [6] J. Hoffmann and R. Brafman, “Conformant Planning via Heuristic Forward Search: A New Approach”, Artificial Intelligence, Vol. 170 (6-7), 2006, pp. 507–541. [7] J. Hoffmann and R. Brafman, “Contingent Planning via Heuristic Forward Search with Implicit Belief States”, In Proceedings of the 15th International Conference on Automated Planning and Scheduling, Monterey, CA, USA, June 2005. [8] D. Martin et al, OWL-S: Semantic Markup for Web Services, http://www.w3.org/Submission/OWL-S/, 2004. [9] M. Paolucci, T. Kawamura, T. R. Payne, and K. P. Sycara, “Semantic matching of web services capabilities”, In ISWC’02, pages 333–347, London, UK, 2002. [10] J. Rao and X. Su, “A survey of automated web service composition methods”, 1st Int. Workshop on Semantic Web Services and Web Process Composition, SWSWPC2004, LNCS, San Diego, USA. (2004)
472
