Method for a group of services to operate in two modes simultaneously

Abstract

The invention is a method of handling groups of services where the makeup and structure of the groups can be determined and changed while the application is running. In one embodiment a group of services is grouped as a coordinator cohort group with respect to one client and, at the same time, as a peer group with respect to another client. This is accomplished by registering with a lookup service a coordinator cohort group proxy and a peer group proxy. Clients may download from the lookup service either group proxy in order to use the group of services in the desired mode.

Description

CROSS-REFERENCE TO RELATED APPLICATION [0001] This application is a divisional application of U.S. application Ser. No. 09 / 940,367 filed Aug. 28, 2001, incorporated herein by reference.BACKGROUND OF INVENTION [0002] A distributed system is a collection of autonomous computing entities, hardware or software, connected by some communication medium. While often the computing entities are geographically dispersed, in some instances they might be separate processors in a multi-processor computer or even separate software routines executing in logically isolated memory space on the same computer. A computing entity need not be a traditional computer, but more generally can be any computing device, ranging from a large mainframe to a refrigerator or a cell phone. A distributed application is an application that executes on a distributed system and one in which parts of the application execute on distinct autonomous computing entities. [0003] Whenever a distinct component of a distributed a...

AI Technical Summary

Benefits of technology

"The present invention is a method for handling dynamic groups of services that can be determined and changed while the application is running. This is accomplished through a group proxy that is generated at run time and handles interactions with groups of services on behalf of one or more clients. The group proxy consists of a group logic shell and a service proxy for each service in the group. The group proxy buffers calls from the client to its group when the group is unavailable because it is in transition and transmits the stored client commands to the group when the transition is complete. This invention provides a way for clients and services to communicate with groups of services without having to provide the logic and maintaining the purity of the look-up service and other infrastructure services."

Problems solved by technology

In addition, the same pre-compiled program cannot move from one platform to a different one during its execution.

This distributes and delays the specificity of the pre-compiled option.

On the other hand, more frequent updates require additional computational capacity and communication bandwidth.

However, a peer group also requires more resources, both bandwidth and computational, than a CC group because all of the group members are working and responding to each client request.

At the end of the lease, if the lease is not renewed, there is no guarantee of availability.

If the expectation is that a client will continue to request lease renewal from a service, but then does not renew its lease, the service may assume that the client has failed, or is otherwise unavailable.

This is especially important because components only rarely plan and announce their failure and are not able to predict network outages.

It is far more common that failures and outages are unexpected, and that the consequence is an inability to announce anything.

The shorter the lease period, the sooner a failure can be detected.

Similarly static group proxies, or software wrappers, for clients have been described in Alberto Montresor et al., Enhancing Jini with Group Communication, University of Bologna, Department of Computer Science, Technical Report UBLCS-2000-16, but these group proxies cannot be modified during execution of the distributed application to accommodate changes in group make-up and structure.

A number of problems can be found in these and other implementations and putative descriptions of distributed applications.

This logic is very complex and the skill set required to write such software is very different from the skills required to write the underlying client or service.

Further, many existing clients and services exist that do not have group logic, and even for clients and services that are being newly written it can be challenging to write this logic as part of the module.

The assumption of group-awareness prevents existing, or legacy, software from being able to take advantage of the benefits of groups (unless they are rewritten) and burdens new applications with providing the necessary group logic to operate with the particular implementation of the group service.

Moreover, static wrappers introduce an additional, distinct point in the computation, with negative performance and, ironically, fault tolerance implications, since such solutions can never operate in the same process space.

In all frameworks, group structures were static and therefore did not permit transitions between group structures.

A major problem with current distributed computing methodologies that support groups is that changes to the group's membership are invasive; that is, services within a group cannot be changed without temporarily halting the availability of the application.

Further, in current systems, if a service, whether grouped or single, is unavailable, the client is burdened with handling this unavailability; if it does not, the client may wait indefinitely, take incorrect steps, or even crash.

Another limitation of current approaches is that group structure, CC, peer or otherwise, is not modifiable without also stopping and then restarting the application, again leaving existing clients in the lurch.

Images