Browse Prior Art Database

A Process for Supporting Multiple Concurrent Versions of a Remotely Deployed Grid Service

IP.com Disclosure Number: IPCOM000019480D
Original Publication Date: 2003-Sep-16
Included in the Prior Art Database: 2003-Sep-16
Document File: 3 page(s) / 15K

Publishing Venue

IBM

Abstract

The article discusses the use of a separate class loader for each remotely deployed web service. This insures that each version of the grid service can load its version of the web service without conflicting with other versions of the web service. Furthermore, since we are not utilizing the classloader associated with the web application, we do not force a reloading of all the classes associated with the web application and thus avoid a restart of the web application which would destroy our long running web services.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

  A Process for Supporting Multiple Concurrent Versions of a Remotely Deployed Grid Service

Problem Solved or Discovery Made by this Invention

Web Services, and grid-based web services, such as those defined by the Open Grid Services Architecture (OGSA), have the potential to bring tremendous benefit to the enterprise. Since these technologies are web service based, they allow for better interoperability and improved distributed system integration than previously possible. Grid services extend web services by providing enhanced resource sharing and scheduling support, support for long-lived state commonly required by sophisticated distributed applications, as well as support for inter-enterprise collaborations. Grid Services in many situations can be long running web services, and it may be necessary over time to deploy new versions of a web service as well as have concurrent versions of a service running. One problem with this is that web services are typically implemented using a Servlet in an application server as part of a web application. In this environment, when one tries to deploy an updated version of a web service, the web application recognizes that new class files must be loaded an begins the process of loading these classes by reloading the complete web application with a new class loader. This has the side effect of requiring the complete web application to be reloaded with the new class loader. As a result, any long running web services that were associated with this web application need to be restarted which in many cases can cause the web service to stop operating properly.

The problem results from the mapping of a class loader to each web application which is too coarse grain for web services. Thus it would appear that the proper way to solve this problem would be to have the web service engine manage classloaders for each of its web services and thus be able to support the deployment of updated versions of web service and multiple concurrent versions of the same web service without impacting existing web services that are executing. Unfortunately, experience with attempts to support multiple executing versions of Servlets has demonstrated that there are several problematic issues that manifest themselves when attempting to support multiple versions of a component in a web application environment. Specifically, the following issues occur when supporting multiple versions of a component:
? Garbage Collection of Old Versions-How do we know when we can garbage collect old versions of a component?

? Routing-How can we route a client to a new version of a component when it might be using a static stub for accessing the component?

? Addressing-When you have multiple versions of a component, how do you insure each component has a distinguishable address that can be used to locate it?

Fortunately, Grid services provide sufficient mechanisms to develop a process for supporting multiple concurrent versions of a grid service....