Content uploaded by Morris Riedel
Author content
All content in this area was uploaded by Morris Riedel
Content may be subject to copyright.
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
m.riedel@fz-juelich.de
Abstract. There is a real demand to migrate existing software archi-
tectures 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 Architec-
tures. 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 het-
erogenous 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 mi-
gration 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-2002-
004279, 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 Frame-
work (WS-RF) [2]. In this context, it seems very reasonable to wrap existing
architecture using Web service technologies. But this approach is not really sup-
ported 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 re-
mote 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 mi-
gration 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 lo-
cated 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 us-
ing principles from both the stateful Grid environments and Web services tech-
niques. 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 Frame-
work (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 ex-
poses 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 Uni-
Grids (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 mi-
gration aspects must be accomplished to get to WS-RF compliant versions of
existing architectures and how the migration aspect can be automized by tool-
ing. 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 ar-
chitecture 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 Lan-
guage (WSDL) files. The automatically created portType of the AccountFacto-
ryService implements the WS-RF factory pattern by the provision of a create-
Instance() 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 construc-
tor 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, there-
fore 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 correspon-
dent datatype. The customerEPR, for instance, is such an EPR and addresses
aCustomerResourceInstance of another remote service, called CustomerService.
Hence, object references were transformed into service references when trans-
forming a method of a class into a WSDL operation, which allows, for instance,
that the CustomerService can be hosted on another machine as the AccountSer-
vice. 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 tool-
ing, 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 Ac-
countFactoryServiceImpl,AccountServiceImpl, and AccountResource. While the
AccountFactoryServiceImpl class provides the implementation of the Account-
FactoryService, 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 ex-
change 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 SetResour-
ceProperty() [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 ob ject 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 ob ject 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 identi-
fied by a signature like objectreference.methodname(). Hence, the parsing and
automation process needs to manage a table that identifies which object refer-
ence belongs to which EPR. To be more independent from potentially different
WS-RF implementations and their invocation calls, we provide an interface con-
sisting 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 pos-
sibilities 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 op-
erations. 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 ser-
vice, 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] specifica-
tion provides the setTerminationTime() method to define an explicit lifetime of
the WS-Resource and the Destroy() operation can be used to map to a destruc-
tor. 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 re-
use 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.oasis-
open.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.oasis-
open.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 Envi-
ronment. 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.oasis-
open.org/wsrf/2004/11/wsrf-WS-LifeTime-1.2-draft-03.pdf.
