Object Migration Pattern: Towards Stateful Web Services in Grid ...

Object Migration Pattern: Towards Stateful Web Services in Grid Environments? Morris Riedel Central Institute of Applied Mathematics Research Centre J¨ ulich, D-52425 J¨ ulich, Germany [email protected]

Abstract. There is a real demand to migrate existing software architectures and business process implementations towards modern Service Oriented Architectures. In practice, however, Web Services are the most used technology for implementations of such Service Oriented Architectures. Recently, developments in this area are often combined with the advantages of Grid computing through the use of Open Grid Services Architecture concepts. This leads to stateful Web Services that are quite similar to stateful objects in Object Oriented Systems. In this paper, we formalize details of an Object Migration Pattern that provides aspects on how an existing Object Oriented System can be migrated through the use of Open Grid Services Architecture concepts to a completely heterogenous and distributed system that characterize modern Grids. This pattern lays the foundation to provide advanced tooling for the recently proposed Web Service Resource Framework and thus allows an effective use of Grid resources such as supercomputers or clusters via dedicated services.

1

Introduction

Object Oriented Programming (OOP) brought a new programming paradigma by the usage of interfaces and elegant delegation design concepts. In this paper, we present several details of an Object Migration Pattern (OMP) that provides aspects on how an Object Oriented System (OOS) can be migrated to a heterogenous and distributed system. One example of such systems could be a Grid which provides access to resources that are typically geographically dispersed. To accomplish that, we focus on the possibilities to automize the complete migration of an OOS towards a Service Oriented Architecture (SOA). This allows partial re-use of existing architectures that are in production usage and prevents developers from manually refactoring every class. In practice, these SOAs are often implemented using the Web services technology. Recently, the strength of this technology is combined with the advantages of Grid computing through the usage of Open Grid Service Architecture (OGSA) [1]. In particular, we create stateful Web services that interact with other stateful Web services like stateful ?

This work is partially funded by the UniGrids project under EC grant IST-2002004279, duration: July 2004 - June 2006.

2

objects that interact with other stateful objects in OOP, leading to a system that is compliant with the recently proposed Web Services Resource Framework (WS-RF) [2]. In this context, it seems very reasonable to wrap existing architecture using Web service technologies. But this approach is not really supported by sophisticated tooling, except, for instance, such tools as Java2WSDL or WSDL2Java [3]. In particular, the focus of these tools is just on an interface and helper classes that provide functionality related to communication with remote systems. Here, we present some aspects of an OMP, a pattern that focus on the whole process of migrating an existing architecture completely towards Web services and thus lays the foundation for advanced tooling. For example, tools for a mapping process from properties of a simple class to properties of stateful resources in Web service environments. In this paper, we try to formalize such mappings and provide examples related to a bank scenario. The proposed migration aspects facilitate the re-use of implementations within Grids, potentially across several Virtual Organizations (VOs) [4]. In addition, the proposed OMP can split an architecture into computational intensive parts that should be located on supercomputers or large clusters and into other parts, wherein massive computational power is not really necessary. In conclusion, the OMP provides the functionality for a dynamic distribution of dedicated architecture parts on dedicated systems. This is accomplished by combining the advantages of Grid computing through the use of OGSA concepts and the strength of Web services. The remainder of this paper is structured as follows. Section 2 provides an overview of the used Web Services Resource Framework and the related Web Services Addressing mechanism. While some migration aspects of the OMP are shown in Section 3, Section 4 concludes the paper and provides an outlook of future work.

2

Representation of Stateful Web Services

The Open Grid Services Architecture (OGSA) [5] is defined as a concept of using principles from both the stateful Grid environments and Web services techniques. OGSA became a paradigma to integrate resources and different services across distributed, heterogenous environments. The evolution of OGSA leads to a recently proposed de-facto standard, namely Web Services Resource Framework (WS-RF) [2]. Among other things, WS-RF also aims at exploiting Web services standards such as Web Services Addressing (WS-Addressing) [6]. The key concepts of WS-RF are stateful Web Service Resources (WS-Resources) [7], including their creation, addressing and lifetime management. In particular, a WS-Resource is the composition of a stateful resource and a Web service that exposes the state of the resource using Web Services Resource Properties (WS-RP) [8]. In practice, the state of a WS-Resource is often represented as a XML tree. However, WS-Resources are addressed via so-called Endpoint References (EPRs) of the WS-Addressing specification [6]. In addition, WS-RF specifies a factory pattern that is defined as everything that brings a WS-Resource into existence. In this paper, we use the Autonomic Factory Approach [9] that implements the

3

factory pattern in terms of a dedicated factory service for each Web service to allow a wider range of functionality. Several WS-RF hosting environments are available, e.g. WSRF::Lite, or WSRF.NET. Furthermore, the European UniGrids (Uniform Interface to Grid Services) project [10] will provide a WS-RF implementation as well as a standard set of services, namely UNICORE/GS, to access heterogenous resources in distributed environments.

3

Migration towards Stateful Web Services

In this section, we will provide some examples on how an existing OOS can be migrated towards a WS-RF compliant architecture. We formalize, which migration aspects must be accomplished to get to WS-RF compliant versions of existing architectures and how the migration aspect can be automized by tooling. Such tools typically consist of sourcecode parsers and predefined migration mappings from usual OOP source to Grid-oriented source. In a more general view, the whole mappings of the here presented migrations form a so-called Object Migration Pattern (OMP). Created components and services of such architecture can be easily integrated into distributed environments such as modern Grid environments, shown in Figure 1. The most important migration aspect

Fig. 1. Distributed and autonomous services that are interfacing WS-RF.

is the transition of the lifetime of a simple object into the lifetime of a whole service that exposes the functionality of such an object. Lifetime issues include creation, life-cycle and destruction of the service. More precisly, the lifetime of an object typically starts with his creation by calling something similiar to Account acc = new Account(). This object creation can be easily transformed into WS-RF compliant services by the creation of an AccountFactoryService and an AccountService, including their corresponding Web Service Description Language (WSDL) files. The automatically created portType of the AccountFactoryService implements the WS-RF factory pattern by the provision of a createInstance() operation that is responsible to create multiple WS-Resources such as AccountResourceInstances. In fact, such instances can be accessed through the AccountService. However, the split into two independent services leads to a major difference between the presented tooling and the often used Java2WSDL tooling. For instance, the migration process shifts the location of the constructor of the Account class to the factory service while all other public methods of the class are migrated into the AccountService. Note that no sourcecode of the Account class or its methods are really transformed, instead only WSDL files were created, consisting of operations with the same signature as the methods of

4

this class. Such methods represent the exposed operations of the automatically created Web service as shown in Figure 1, e.g. the makeTransaction() operation. Notice that the lifetime of objects is not decidable by sourcecode parsers, therefore we assume a lifetime without end in the first prototypes. Other elements

Fig. 2. Public WS-RPs and internally used private WS-RPs.

of the WSDL files such as types or messages can be generated automatically using predefined XML schema for simple datatypes such as strings or integers. On the other hand, complex object datatypes were simply realized with an EPR type that should address an instantiated WS-Resource, realizing the correspondent datatype. The customerEPR, for instance, is such an EPR and addresses a CustomerResourceInstance of another remote service, called CustomerService. Hence, object references were transformed into service references when transforming a method of a class into a WSDL operation, which allows, for instance, that the CustomerService can be hosted on another machine as the AccountService. A typical scenario for such distributed systems is a Grid environment of a bank wherein the AccountService need to be hosted on a massive cluster system, because of all the computational intensive transactions. On the other hand, a CustomerService can be hosted on a simple server, because information related to customers are often more static. As mentioned earlier, the created WSDL documents describe the new services, but their real implementations are not created yet. To automatically create an implementation of a service via tooling, the class file can be parsed and transformed into an architecture for the service consisting of several classes. Let us consider these classes are called AccountFactoryServiceImpl, AccountServiceImpl, and AccountResource. While the AccountFactoryServiceImpl class provides the implementation of the AccountFactoryService, the AccountServiceImpl class provides the implementation of the AccountService. So far, there are no main differences compared to usual tooling with WSDL2Java, except the AccountResource class that represents an implementation of WS-Resources. By adding an IAccount interface, consisting of all the methods of the Account object without the constructor, we can exchange different implementations of Account classes more easily. According to the WS-RP specification, a WS-Resource can expose properties that can be easily transformed by tools. More precisly, the class file can be parsed and all public properties or getter and setter methods of properties can be used for the creation of WS-RPs. In fact, all these methods can be removed from the transformed class, because the methods GetResourceProperty() or SetResourceProperty() [8] will be used instead. As shown in Figure 2, these operations can work with a XML tree that contains the public properties such as balance while an internal private resource properties tree can be used to manage private properties in WS-Resources such as the customerEPR. Finally, to allow differ-

5

ent implementations of WS-RPs, we add an interface with methods consisting of operations defined in the WS-RP specification. When parsing sourcecode

Fig. 3. Table with object references and their related service references.

of the Account class, there can be constructs that create other objects within the Account class, for instance a Customer object. This initiates two actions. Firstly, a CustomerService and a related CustomerFactoryService is created. Secondly, the object oriented invocation of a method of the Customer object must be exchanged by a remote service invocation call as shown in Figure 3. Here, we assume that that any call of an object external operation is identified by a signature like objectreference.methodname(). Hence, the parsing and automation process needs to manage a table that identifies which object reference belongs to which EPR. To be more independent from potentially different WS-RF implementations and their invocation calls, we provide an interface consisting of methods like createWSCall(instanceEPR, methodName, parameters[]). If the WS-RF implementation changes, only the implementation of this interface must be changed. In this context, it seems very reasonable to consider all possibilities this automatic approach offers. For instance, one has to consider that there should be a mechanism to explicitly define classes that should be migrated or those which should not be, since the created services are too fine grained. This means, without providing any kind of such information, for instance, each Integer object will be a transformed into a service providing plus and minus operations. This should be avoided, because it leads to performance problems and communication overheads. To solve this problem, aspect-oriented programming can be used for labelling classes to indicate if a class should be migrated towards Web services or not. Another aspect of the migration is the destruction of a service, which can be difficult, because of the modern garbage collector concept. A class has not necessarily a destructor that can be used to map this easily into a WS-RF compliant solution. Therefore, the WS-ResourceLifetime [11] specification provides the setTerminationTime() method to define an explicit lifetime of the WS-Resource and the Destroy() operation can be used to map to a destructor. Finally, a detailed view on the automation process identifies some further issues that are not described here. For instance, the migration of architectures that use inheritance. A superclass that is used by the implementation of two different subclasses leads to the demand for the tool to put the inherited code of the superclass in both subclasses, because their services may be hosted on

6

different machines. Additionally, some preconditions have to be defined, such as the fact that the architecture and their classes should not rely on permanent connections to remote database servers or other remote resources. Also, during the run-time of the created SOA, new problems come into existence that must be concerned such as partial failures of several services or bad latency accross the network.

4

Conclusion

In this paper, we presented aspects of an OMP that is capable of migrating existing architectures into SOAs in an automatic way. Furthermore, the provision of standards-compliant Web service interface of a class makes it possible to reuse this class also in other software architectures that may need similiar classes. For instance, the demand of having a representation of a customer class can be found in very much architectures. The presented aspects lay the foundation for advanced tooling that help developers to easily merge existing applications into a distributed Grid environment. In conclusion, the migration aspects allow a more effective use of dedicated resources such as supercomputers or cluster systems that, for example, may host the account service to compute transactions more effectively. Finally, our approach has to provide solutions for problems related to polymorphic calls and dynamic dispatch. This means, it is statically not decidable, by a code parser, what the target class of a call is. However, we presented the OMP that ’combines the advantages of Grid computing through the use of OGSA concepts and the strength of Web services’.

References 1. Foster, I., et al.: (Open Grid Services Architecture) http://www.ggf.org/documents/GFD.30.pdf. 2. Czajkowski, K., et al.: (The Web Services Resource Framework) http://www.oasisopen.org/committees/download.php/6796/ws-wsrf.pdf. 3. Group, A.: (Apache eXtensible Interaction System) http://ws.apache.org/axis/. 4. Foster, I., Kesselmann, C., Tuecke, S. In: The Anatomy of the Grid: Enabling Scalable Virtual Organizations. (2001) 5. Foster, I., Kesselmann, C., Nick, J.M., Tuecke, S. In: The Physiology of the Grid. John Wiley & Sons Ltd (2003) 217–249 6. Box, D., et al.: Web Services Addressing (WS-Addressing) (2004) http://www.w3.org/Submission/ws-addressing/. 7. Foster, I., et al.: (Modeling Stateful Resources with Web Services) http://devresource.hp.com/drc/specifications/wsrf/ModelingState-1-1.pdf. 8. Graham, S., et al.: (Web Services Resource Properties) http://docs.oasisopen.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.pdf. 9. Riedel, M.: Prospects and Realization of Flexible Service Offers in a Grid Environment. Technical Report JUEL-4154, Research Centre J¨ ulich (2004) 10. European UniGrids Project, http://www.unigrids.org. 11. Graham, S., et al.: (Web Services Resource Lifetime) http://docs.oasisopen.org/wsrf/2004/11/wsrf-WS-LifeTime-1.2-draft-03.pdf.