Browse Prior Art Database

Mobility of Service Components - For better reliability and scalability Disclosure Number: IPCOM000010767D
Original Publication Date: 2003-Jan-20
Included in the Prior Art Database: 2003-Jan-20
Document File: 7 page(s) / 55K

Publishing Venue



Internet has evolved with the passage of time and today it is morphed into a widely distributed computing platform. The concepts like Service Oriented Architectures (SOA) have seen their development and materialisation as an integral part of this evolution. Though, SOA brings lot of good things, service components in SOA are usually bound to the execution environment where they have been started. They are not able to relocate to another equivalent environment when required, thereby faulting on promises with respect to performance and reliability. This is an attempt to propose a solution to this problem by enabling mobility of service components by building a "Mobile Services Framework", while maintaining the current state of these components. Capability of stateful migration also makes these service components "autonomous" and improves their overall applicability in numerous scenarios.

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 15% of the total text.

Page 1 of 7

Mobility of Service Components - For better reliability and scalability

INTRODUCTION Disclosed is the solution to enable the stateful mobility of the service components in Service Oriented Architecture (SOA) without making any changes to the base specifications of the same. Capability of stateful migration makes the service components "autonomous" and improve their overall applicability in numerous scenarios.

A Service Oriented Architecture (SOA) combines the ability to invoke remote objects and functions (called "services") with tools for dynamic service discovery, placing an emphasis on interoperability. Examples include Sun's Jini [1] and Microsoft's .NET [4]. SOA provide dynamic binding between the participants and has provision of runtime Service Level Agreements (SLA). However the service components are bound to the node on which they are hosted. The (Quality of Service) QoS promises become dependent on the state of the hosting system.

Virtualisation of Services In order to surmount this shortcoming, services should become virtual with respect to their execution environment. This can be made possible if: -

- Services are able to handle changes in their execution environment (which include both local state of their current hosting node as well as the global state, of which that node is a part).

- Services are inherently capable of finding a suitable host, which satisfies and provides all that is required to host the services subject to a specified QoS. A Service can suspend its current execution, bundle itself in its current state, move to another one or more nodes and resume its execution from the current state.

- Services become Locationaly Transparent to the consumer (of that service). This implies that even if the Service might have moved to the new location (host), the consumer must able to continue to work with the same Service Handle that was obtained earlier.

- The Services hosting infrastructure redirects requests to services that have moved, to their new location and binds the consumer's reference to the service transparently to the new location.

- Services are scalable. They should be capable to work equally well and must utilise the fullest capability of every node on which it resides and ensuring the inter-operability with lesser capable nodes at the sametime.

Some Scenarios These are some of the scenarios, which support the need of having mobility as a desirable feature of the service components in the SOAs.

Pervasive Devices like PDA carried by a person, devices in car, cell phone, wearable PC etc form various networks among themselves and other devices in their vicinity, usually on adhoc basis. Hence if a service is being provided by a node, which is about to move out of the network, it should be possible, that service running on that device stops its execution, collect its state (list of nodes using its services, session information if any of these nodes), finds another suitable node within the network, port...