MASON: A Model for Adapting Service-oriented ... - Semantic Scholar

MASON: A Model for Adapting Service-oriented Grid Applications∗ Gang Li1, Jianwu Wang1, Jing Wang1, Yanbo Han1, Zhuofeng Zhao1, Roland M. Wagner2 and Haitao Hu1 1

2

Software Division, ICT, Chinese Academy of Science, PRC Fraunhofer Institute for Software and Systems Engineering, Dortmund, Germany {ligang, wjw, wangjing, yhan }@ict.ac.cn

Abstract. Service-oriented computing, which offers more flexible means for application development, is gaining popularity. Service-oriented grid applications are constructed by selecting and composing appropriate services. They are one kind of promising applications in grid environments. However, the dynamism and autonomy of environments make the issues of dynamically adapting a service-oriented grid application urgent. This paper brings forward a model that supports not only monitoring applications through gathering and managing state and structure metadata of service-oriented grid applications, but also dynamic application adjustment by changing the metadata. Besides that, the realization and application of the model is presented also.

1 Introduction In grid environments, services are important resources that can be viewed as a kind of grid application components[1]. A developer can quickly construct large-scale and distributed applications by selecting and composing appropriate services, resulting in so-called service-oriented grid applications (SOGA). However, due to independent evolution of services and dynamic changes of requirements, those applications encounter challenges of dynamic adaptation. On one hand, services are locally autonomous. Service providers independently develop and maintain their services, and services can freely join or quit grid environment. The independent changes of services can make original services, which that compose an application, not meet users’ requirements any more. On the other hand, problems due to requirement changes still exist and requirement changes are even more dynamic. So, dynamic adjustment of application structures and behaviors is needed. In addition, in order to adapt an application, states of application components should be known. So it is also necessary to monitor a SOGA on application level. ∗ This

paper is supported by the National Natural Science Foundation of China under Grant No. 60173018, the Young Scientist Fund of ICT Chinese Academy of Science under Grant No. 20026180-22 and the Key Scientific and Technological Program for the Tenth Five-Year Plan of China under Grant No. 2001BA904B07.

The composite service execution model of SWORD[2], proposed by Stanford University, is useful to gathering states of a SOGA. During the execution of a SOGA, each service is presented by an operation and the execution model is described as the connection of the related operations. The execution logic of the services is manifested in the execution model, but the execution logic in the application cannot be changed. To adapt to changes in network environments, Israel Ben-Shaul etc. present a component model and a composition model for distributed application development and deployment[3]. The component model allows the modification of both structure and behavior of components, and the composition model enables to dynamically deploy components into remote sites and dynamically reconfigure the deployment. However, services are special components that are much more autonomous, which cannot be modified by users. Although the models benefit SOGA adaptation, there is still much work to be done in order to adjust a SOGA on application level. Other typical research includes work related to BPEL4WS[4] and GSFL[5]. Currently, some execution environments for BPEL4WS can trace the execution by visible means. They offer the function of monitoring, but the monitoring granularity is very coarse. Among the service composition model supported by GSFL, there is a life cycle model for describing the life cycle of activities and services in a service composition, which enables to get application states. Although monitoring is a necessary part of dynamic adjustment, current work related to both BPEL4WS and GSFL does not support the adjustment of application. Aiming at the special and open issues of adjusting a SOGA, we developed the CAFISE Framework[6]. CAFISE Framework is an environment that supports developing, running and adjusting a SOGA. In the CAFISE Framework, we bring forward a model for monitoring and adjusting a SOGA, which is named MASON (Model for Adapting a Service-Oriented Grid Application) model. It supports not only monitoring application through gathering and managing state and structure metadata of service compositions, but also dynamic adjustment by changing the metadata. Our work benefits from architecture reflection[7,8]. Architecture reflection keeps software architecture as a meta description of software. Our work uses dynamic application structures as the meta description, which present a SOGA on implementation level from architecture angles, and are more concrete and helpful to adjusting. In addition, the MASON model supports gathering and showing the states of a SOGA on different levels, which cannot be achieved with architecture reflection. The remainder of this paper is organized as follows. Before presenting the MASON model, concepts about the SOGA in the CAFISE Framework, which are related to the model, are briefly given in section 2. Section 3 presents the model in details. Section 4 describes the model realization in the CAFISE Framework. Section 5 gives a case study on how to adjust a SOGA through the model. Section 6 sums up with several concluding remarks.

2 The SOGA Specified with Darnel In the CAFISE Framework, a SOGA is presented with Darnel (Dynamic Service Composition Description Language)[9], which is an executable service composition

description language that uses the activities associated with services to organize the collaboration among services. The application written in Darnel is mainly composed of coordination among services and its context. The context describes the situation and the target or intermediate results of the coordination. Thus, we can not only get the intermediate state of the coordination but also dynamically adjust the application by analyzing the deflection of the target and intermediate results. As a structure segment supporting modularization, a coordination block mainly includes coordination partners and their relations, sub-context and involved activities. Activities are structure units of the application, which include structure activity and simple activity. Structure activities define the control logic of the application and simple activities denote service placeholders. Simple activities dynamically associate with services that are basic function units and programming components of the SOGA. Services can be chained with connectors[10] that are referenced by simple activities. With the model presented in this paper, the SOGA in Darnel can be adjusted dynamically.

3 The Model for Dynamically Adapting a SOGA To dynamically adapt a SOGA in Darnel, we present the MASON model. It depicts the dynamic structures and states of a SOGA, stores related metadata and specifies how to obtain state and structure data of an application. Referring to the model, software developers can design tools that support monitoring and dynamically adjusting a SOGA. The model is based on the object-oriented notion, yet it is not a simple application of the object concepts. Services are basic function units of a SOGA. They are programming components on a higher abstract level and can evolve independently. In the MASON model, objects are abstract of services or service compositions. These objects are dynamically and locally created while the application is running, and do not need centralized management. Besides that, objects in the MASON model support dynamic and adaptive adjustment to a SOGA. With these objects, the structure and state metadata can be modified, and the service connections and member services can be changed. The adjustment capabilities enhance adaptability of a SOGA in volatile grid environments as well as the exception handling ability. 3.1 Model Definition The MASON model includes a set of runtime objects, relationships among them and model interfaces. Runtime objects are objects that are created while a SOGA is running, and they contain data related to dynamic structures and states of the SOGA. Relationships among runtime objects include structure and behavior relationships, with which runtime objects are linked up as a whole. The model interfaces contain essential operations through which dynamic structures and states data can be gotten and changed. Some details about the primary runtime objects are presented in table 1. In those runtime objects, a kind of important properties is related to application states. The runtime objects contain state related properties on different levels that

describe states of services, activities and coordination blocks. The activity state properties of the simple activity object and the structure activity object describe the states of the relevant activities of a SOGA. There are five kinds of activity states: ready, running, suspended, completed and terminated. The simple activity object additionally contains a service state property that shows the state of the service bound with the activity. As a part of a SOGA, the service associated with an activity is not stateless, it has four kinds of states: ready, running, completed and terminated. The coordination object in the object coordination layer contains state information of a coordination block in a SOGA, which includes ready, running, terminated and completed state. Table 1. Primary Runtime Objects of the MASON model Runtime Objects

Main Properties

application name, context and coordination module set coordination block name, Coordination activity set, initial activities, current activities, current state activity name, subset of Structure activity, current activity, activity activity state App

Main Operations getX getX, setX, addX and deleteX getX, setX, addX and deleteX

Simple activity

activity name, current state and service state

getX and setX

Connector

Ports, selection function, currently selected service, connection partners, candidate services

getX, setX, addX and deleteX

Remarks It contains application global information. It can be used to get coordination block state and change its structure. It can be used to get activity state and adjust the activity. It can be used to get activity state and associated service, and to adjust a simple activity. It specifies dynamic service connection and enabling connection reconfiguration.

The runtime objects above-mentioned are not irrelevant. They compose a hierarchical structure, which mainly consists of elemental layer, object coordination layer and global object layer. With the three layers, the runtime objects are organized in different granularities. The elemental layer is the fundamental one of the three layers, and the objects in this layer are runtime images of simple activities, structure activities and connectors of the SOGA in Darnel language. The object coordination layer is in the middle tier, and is used to conglutinate and coordinate the objects of elemental layer. The coordination objects represent coordination blocks of the SOGA and contain references to runtime objects of elemental layer according to the coordination blocks’ structures. Besides that, a coordination object marks the initial activities and current running activities in application execution. The global object layer is on top of the hierarchical structure and the App objects in this layer are used to get global information of an application, whose context properties record global data, intermediate and target results. An App object property, named coordination block set, contains references to coordination objects. The runtime objects and their structure relationships describe a SOGA structure on meta level.

The runtime objects have relationships not only in structure aspect, but also in behavior aspect. When an object property related to application state changes, the relevant objects may be infected due to the relationships among them. For example, when a service that is bound with a simple activity is available, the simple activity object’s current state property is “ready” also. When the service is invoked, the simple activity object’s current state property is changed into “running”. The coordination object, which contains the simple activity object, will change its related property. These relationships are pictured in figure 1. Thus, runtime objects can influence each other at the behavior aspect.

Fig. 1. Example of Behavior Relationships among Runtime Objects

With structure and behavior relationships, the runtime objects form an organic whole that interact with outside through model interfaces. Operations of the runtime objects, such as get, set, add and delete, compose interfaces of the model with which data of states and dynamic structures can be obtained and reconfigured. To prevent the security issues that arise from unlimited modification, the model interfaces put restrictions on accessing to the objects. For example, because services are autonomous, contrived modifications to service states are not permitted; only operations that adjust states of simple activities and service binding strategy of connectors are offered. All in one word, those objects of the MASON model encapsulate operations and meta data of application structures and states, and the model contains structure and behavior relationships among the objects. By changing the meta data through the model interfaces, the model supports dynamically adjusting a SOGA. 3.2 Supports for Dynamic Adjustment When a SOGA is dynamically adjusted, execution information like states should firstly be gotten. The MASON model supports monitoring a SOGA mainly through the introspection of structure and state. The runtime objects store relevant data, so with the model interfaces, application structure and state data can be gotten. Table 2 lists parts of contents that can be gotten and monitored with the model. It shows that through different operations of runtime objects, user can acquire application states information in different granularities. Other information, such as structure and context, can be gotten in similar way. With the dynamic structure and state information gotten from the MASON model, the dynamic adjustment of a SOGA can be achieved through model interfaces on object coordination layer and elemental layer. These operations can modify the structure and state metadata. Table 3 lists parts of adjustments that the model supports.

Table 2. Parts of Monitored Contents and Related Runtime Objects Monitoring type monitoring application states

Monitored contents coordination block state activity state service state

Runtime objects coordination

Operation examples getCoordinationState

structure/simple activity simple activity

getActivityState getServiceState

Table 3. Parts of Adjusted Contents and Related Runtime Objects Adjustment type adjusting application structures adjusting application states

Adjusted contents coordination block structure service binding strategy coordination state activity state

Runtime objects coordination

Operation examples addSimpleActivity

connector

setBindingType

coordination structure/simple activity

setCoordinationState setActivityState

4 Model Realization Adjusting Tool Adjustment Interfaces SOGA in Darnel Interpreter

Service Access Proxy

Runtime Object Management Module

Execution Environment

Services

Fig. 2. Realization of the MASON model in the CAFISE Framework

The MASON model presents a reference for designing tools that support dynamic adjustment of a SOGA. Up to now, the model has been realized in CAFISE Framework. The realized modules are illustrated in figure 2. In the framework, execution environment and adjusting tool are two key components. The MASON model is manifested by the execution environment, which interprets and executes a SOGA. The adjusting tool gets and changes needed data through model interfaces implemented by execution environment, through which user can make timely modification on running applications. The execution environment of CAFISE Framework mainly includes Interpreter, Runtime Object Management Module (ROMM), Adjustment Interfaces and Service Access Proxy etc., among which the ROMM and Adjustment Interfaces are designed

referring to the MASON model. When the interpreter interprets a SOGA, it invokes the system object factory. The factory creates runtime object App, which initiates other relevant runtime objects according to execution situations. The ROMM takes charge of managing these runtime objects. It chooses the ready activities in the coordination block and sends the result to the interpreter. If the activity is a structure one, the ROMM sets its activity state property. If the activity is a simple one, after setting the property, the ROMM determines whether it is necessary to create a connector object according to the situation of service connection. After the connection between activity and service is confirmed, the interpreter invokes the service access proxy and resets the properties of runtime objects through the ROMM. The Adjustment Interfaces realize the MASON model interfaces, which provide methods to access and manipulate runtime objects. Based on the Adjustment Interfaces, monitoring and adjusting tools can be designed by developers.

5 Case Study In this section, a case study is presented in which the MASON model is applied to the project FLAME2008 in order to provide a flexible dynamic adjustment tool for the end user. The case contained in this case study relates to a journalist’s travel plan. The journalist combines the services provided by diverse providers into a SOGA and executes it to get the expected results. But during the application running, he may want to change some parts of the SOGA so as to rearrange his plan. Therefore a tool that can adjust the SOGA during runtime is needed. The MASON model is used in the system to dynamically adjust a SOGA. Firstly the user needs to monitor the application. As far as how to monitor a SOGA is concerned, the Adjustment Interfaces provide essential supports. In this case, the interface is implemented through observer pattern[11]. Taking monitoring a simple activity as an example, figure 3 illustrates how to use the realized MASON model to monitor with the pattern. Start

public class InterpreterEngine { public voidexecuteNode(){ RunningSimpleActivityrsActivity=newRunningSimpleActivity(); MonitorActivityState mAState=newMonitorActivityState(rsActivity); …… if (node instanceof RunningSimpleActivity){ (RunningSimpleActivity)node.setActivityState("running"); …… } } } public class RunningSimpleActivityState extends Observable{ public voidsetState(String strState){ if (!this.activityState.equals(strState)){ this.activityState=strState; this.setChanged(); } this.notifyObservers(changingActivity); } …… }

interpreterEngine.setBreakPoint(activityA);

public class RunningSimpleActivity{ RunningSimpleActivityState rsActivityState; …… public voidsetActivityState(StringactivityState){ this.activityState=activityState; ras.setState(activityState); } }

pubic class MonitorActivityState implements Observer { public MonitorActivityState(RunningSimpleActivityState rAStatus){ rAState.addObserver(this); } public voidupdate(Observable ob, Object arg){ RunningSimpleActivityrsActivity=(RunningSimpleActivity)arg; if(rsActivity.getActivityState().compareTo("running")==0) …… } }

Fig. 3. Example of Monitoring

If the Breakpoint is set successfully

Else

SimpleActivity activityB ＝new SimpleActivity(); //create a new simple activity object:activityB activityB.setConnector(connectorB); //set the service bund with the activity

interpreterEngine.notifyFail (activityA); //create the event of unsuccessfully setting breakpoint at simple activity A

activtyB.setContext(contextB); //set activityB's context

coordinationObj.addSimpleActivity(activtyA, activityC,activityB); //add activtiyB

interpreterEngine.validate(); //validate the adjustment

interpreterEngine.resumeExcecution(); //resume from breakpoint

End

Fig. 4. Example of Adjusting

If user’s demands change or services do not return expected results, a SOGA can be dynamically adjusted through the realized MASON model to adapt to those changes. Firstly, the structure and state data related to the application segments, which will be influenced by the changes, can be gotten through the runtime objects. With the data, the interpreter judges whether a breakpoint can be set at the affected activities. If the breakpoints are feasible, the affected running activities are suspended with methods of the Adjustment Interfaces. Then breakpoints are set and executing contexts are saved. Dynamic structures related to the adjustments are changed through runtime objects. After changing, the integrity and validity of changed application structure are checked. At last, breakpoints are cancelled and the application is resumed to execute. Taking adding a simple activity as an example, figure 4 presents the key steps of dynamic adjustments. activityA and activityC are runtime objects that represent simple activity A and C. IA new simple activity B bound with a service is added between simple activity A and C.

Fig. 5. The Adjusting Tool in the CAFISE Framework

Based on the forementioned, an adjusting tool has been implemented which is illustrated in figure 5. It is composed of Adjusting Field, Control Panel, Reusable Coordination Block Repository and Service Community. In the Adjusting Field, different states of a SOGA are marked with different colors. Monitoring details can be shown by doubly clicking on the monitored application components. When the application is to be dynamically adjusted, services can be dragged from the Service Community to create new simple activities; structure activities can be changed with the Control Panel; reusable coordination blocks can be gotten from the Reusable Coordination Block Repository. Other adjusting operations, such as setting breakpoints, are available through the right clicked menu (shown in figure 5). Experiences of realizing and applying the MASON model in this case shows: 1) with the model, states of a SOGA can be gotten and shown conveniently; 2) dynamic and flexible adjustment of a SOGA, such as adding new simple activities and replacing existing services, can be achieved.

6 Conclusions In grid environments, services evolve independently and requirements of users are volatile. Those factors bring adaptation requirements to service-oriented grid applications. To solve the problem, the MASON model for adapting service-oriented grid applications is presented in this paper. The model contains metadata of application states and dynamic structures. It can be created dynamically and locally. Through the model interfaces, the application states can be gathered and the application structures and behaviors can be dynamically adjusted. With the experiences of realizing and applying the model, we conclude: 1. The model supports not only monitoring through gathering and managing state and structure metadata of service-oriented applications, but also dynamic adjustment by changing the metadata. 2. By supporting adjustment, the model enables dynamic adaptation and on-line evolution of service-oriented grid applications.

References 1.

I. Foster, C. Kesselman, J. Nick and S. Tuecke. Grid Services For Distributed System Integration. IEEE Computer. Vol. 35, no.6, 2002, pages 37-46. 2. S. R. Ponnekanti, A. Fox. SWORD: A Developer Toolkit for Web Service Composition. The Eleventh World Wide Web Conference (Web Engineering Track). Honolulu, Hawaii, May, 2002. 3. I. Ben-Shaul, O. Holder, and B. Lavva. Dynamic Adaptation and Deployment of Distributed Components in Hadas. IEEE Transactions on Software Engineering. Vol. 27, no.9, 2001, pages 769-787. 4. T. Andrews F. Curbera etc. Business Process Execution Language for Web Services Version 1.1. http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/. May 2003. 5. S. Krishnan1, P. Wagstrom1 and G. Laszewski. GSFL: A Workflow Framework for Grid Services. http://www-unix.globus.org/cog/projects/workflow/. July 2002. 6. H. Yanbo, Z. Zhuofeng, L. Gang etc. CAFISE: An Approach to Enabling Adaptive Service Configuration of Service Grid Applications. Journal of Computer Science and Technology. Vol. 18, no.4, 2003, pages 484-494. 7. C. E. Cuesta, P. Fuente, and M. Barrio-Solárzano. Dynamic Coordination Architecture through the Use of Reflection. Proceedings of the 2001 ACM Symposium on Applied Computing (SAC), pages 134-140. 8. G. Blair, G. Coulson, P. Robin, and M. Papathomas. An Architecture for Next Generation Middleware. Proceedings of Middleware '98. Springer Verlag, September 1998, pages 191-206. 9. CAFISE group. Darnel Language Specification. Technical Report. Software Division, ICT, CAS, 2002. 10. L. Gang, H. Yanbo, Z. Zhuofeng, W. Jianwu and R. M. Wagner. An Adaptable Service Connector Model. Proceedings of VLDB’29 Workshop on Semantic Web and Databases. Berlin, Germany, 2003, pages 79-90. 11. E. Gamma, R. Helm, R. Johnson and J. Vlissides. Design Patterns: Elements of Reusable Software Architecture. Addison-Wesley, 1995.