Integration of Mobile Agents technology and Globus for assisted design and
automated development of Grid Services
Abstract—According to SOA model (Service Oriented Architecture),services can be used or can use other services. Participation is not supported. A service cannot collaborate with other partners being aware of this collaboration. As Grid services are developed according to the SOA model, we investigate how the integration of mobile agent technology in Grid architectures can help to overcome this limitation. Aims of this contribution are: design and development of agent based Globus services. Mobile agents programmers can execute their application on Grid infrastructures. Grid users, on their own, can invoke mobile agents services using standard Web Services technology. Here we define a model of agent-enabled Grid node and describe the architecture we have designed and realized. In particular we implemented some services to manage and monitor mobile agents platforms executing on a Grid node. We support inter-Grid Nodes agent mobility that exploits globes authentication mechanisms. The more general result is the definition of a service model and a framework for developing and deploying Mobile Agents based Grid services. Our framework supports programmers by automatic generation of code that
implements, for each new designed service, a proxy between
I. INTRODUCTION: BEYOND THE SOA MODEL
We refer to Grid Computing when we are addressing issues related to parallel and distributed algorithms for high performance computations in Grid environment. When we deal with Grid platforms and resources, we are talking about Grid Services[1]. Grid platforms have adopted the SOA (Services Oriented Architecture) model to make available and usable their resources to any users and applications. Grid services can be invoked by standard SOAP messages. Components of legacy Grid platforms, such as MDS[2] in Globus, work as services directory and can export, for each record, binding information and WSDL interface. According to FIPA[23] Standard also Agent platforms are compliant with the SOA model because each agent provides or exploits a service. Furthermore services are invoked by well formed Agent Communication Language messages, encoded by XML. Like the UDDI in a SOA system, an agent that implements a registry of available services is mandatory in any platforms. It is called Directory Facilitator and accepts requests from other agents to publish, remove or discover services. Another agent called AMS manages white pages, where each alive agent is registered and by which it can be contacted. However both Grid and Agents go beyond the classical SOA model. Grid tries to overcome a technological limitation of Web Services which do not provide persistence of I ntermediate results. We mean that Web Service execution is session-less. An user is not recognized when it invokes a second time the same service. WSRF[6] extends web services technology by adding some mechanisms which grant persistence. Globus employs WSRF to provide stateful services. State-less model of web services is a consequence of a more important principle of SOA model. A requestor is the only actor able to invoke services and to compose them in order to build an application. It is aware of this composition and of its execution status. A service provider delivers result of its computation when it is invoked, but it is not aware if it is taking part to a more complex application, and above all it is not aware about the status of this application. When a requestor becomes itself a provider of a complex service, it cannot collaborate with other providers at same level. It can only answer to a request without to know how its response is exploited at an higher level. This hierarchical organization of service simplifies the architecture, but does not allow implementation of applications based on parithetic collaboration of software entities. A Service can be used or can use other services, but it cannot collaborate with them. A Virtual Organization, exploits Grid technology to share resources among its users and applications. However the adoption of a SOA model and of Web Services technology makes no possible the design of complex strategies of collaboration among the parties belonging to a Virtual Organization. Let us consider a distributed scheduler. It is hard to conceive a collaboration among local schedulers, executing on each Grid node, which act according to a common plan, whose objective is to optimize system utilization or to minimize turnaround of scheduled applications. Supporting agent execution on a Grid architecture allows agent based application to exploit Grid resources. Furthermore it provides new models to overcome the limitations introduced above. Agents can collaborate or compete to pursue a goal. They can take part to a complex application behaving the vision of the its status. Furthermore the application status could be distributed among the participants. Nevertheless much effort has been spent to support exploitation of Agent technology in Grid, none of contributions known by authors address integration of an agent platform into a legacy Grid middle-ware. A Grid middle-ware is sometime not exploited at all, sometime agents technology is used to build a new middle-ware, which cannot inter-operate with other ones. Of course this is a limiting assumption because, to allow agent execution on a Grid resource, it needs to authenticate agent’s owner as a Grid user, according with middle-ware policies and by middle-ware mechanisms. Agents must be able to move and to execute, on each Grid resource that belongs to a Virtual Organization, according with their owner’ permissions. Furthermore most of all proposed solutions provide services for other agents. Here agent based services can be provided to be exploited by Grid community, by Grid users and requestors, which can use agent technology without being aware of ot. Second section describes related work. In third section we present an architecture design of a framework that supports development and execution of mobile agents based services. Fourth section introduces our prototypal implementation. Then we describe the developing cycle and the instruments, which have been extended and integrated, for implementing and deploying a service. Finally conclusion is due.
