Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-12
2002-09-17
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S203000, C709S241000
Reexamination Certificate
active
06453362
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to data processing systems, methods and computer program products and, more particularly, to data processing systems, methods and computer program products for distributed object environments.
BACKGROUND OF THE INVENTION
The explosive growth of the Web, the increasing popularity of personal computers (PCs) and advances in high-speed network access have brought distributed computing to the forefront. In addition, there is currently interest in distributed objects for object-oriented applications. Various architectures currently exist for accessing objects located within distributed computing environments. One such architecture is the language-neutral Common Object Request Broker Architecture (CORBA). At the core of the CORBA architecture is an Object Request Broker (ORB) that acts as an object bus over which objects transparently interact with other objects located locally or remotely.
Other language-specific models for distributing applications include Distributed Component Object Model (DCOM) and Remote Method Invocation (RMI). DCOM is an object-oriented implementation for distributing ActiveX® applications (ActiveX® is a trademark of Microsoft, Redmond, Wash.). RMI is an object-oriented implementation for distributing Java® applications (Java® is a trademark of Sun Microsystems, Mountain View, Calif.).
In a distributed object environment, a client application communicates with a remote server application through a “server stub” located on the machine (computer) hosting the client application. The stub is obtained from a remote object registry (i.e., a naming service). Remote object registries are well known to those skilled in this art. Typically, a registry is located on the computer hosting the server application and is referred to as a “server-side” registry. In a distributed object environment, a single server application may typically support multiple client applications. However, a server application must generally be started with an associated stub registered in the server-side registry, before a client application can access the server application.
FIG. 1
schematically illustrates a client application
10
, resident within a computer
11
, communicating with a server application
14
located on a remote computer
12
hosting one or more server applications. In
FIG. 1
, the client application
10
wants to communicate with a server application named “MyApp”
14
located on the remote computer
12
. Upon initially starting up, the application “MyApp”
14
registered itself with the server-side registry
16
as illustrated. In the illustrated server-side registry
16
, the application “MyApp”
14
has identifier (also referred to as a name or key) “MyApp” and the stub “AppStub”. To communicate with the “MyApp” application
14
, the client application
10
obtains the server stub
18
for the “MyApp” application
14
from the server-side registry
16
. As is understood by those skilled in this art, client application requests to a server application are made using a server stub associated with the server application and that is obtained from the computer hosting the server application. A server stub
18
communicates with an associated server application via a server skeleton
19
, as is known to those skilled in this art.
Based on the operating platform of a server application, it may be desirable to run the server application in a user's address space. Instead of running a single instance of the server application in a shared address space, each user would run an instance of the server application in a private (user) address space. In some multi-user systems, such as IBM's Multiple Virtual Storage (MVS) systems, running instances of a server application within user address spaces may be required to achieve an acceptable level of protection, security and user authentication.
However, running an instance of a server application in a user address space generally means that user address space creation, server application startup and registration with a server-side registry cannot occur until a user performs “login” procedures with a computer hosting the server application. Unfortunately, after initiating login procedures with the hosting computer, and requesting that a server application be started, there may not be an automatic notification back to the requesting client application that the server application is started and ready to serve client requests. For example, in
FIG. 1
, if the server application “MyApp”
14
is not already running when the client application
10
makes a request to the server application “MyApp”
14
, the client application may not be aware of when the server application “MyApp”
14
is ready to accept requests.
A possible solution to the problem of knowing when a server application is active involves allowing client applications to poll a server-side registry until a valid server stub associated with a server application is returned. Unfortunately, polling is generally not an acceptable solution, particularly in a distributed object environment, because of the complexities polling adds to client applications and because of increases in network traffic.
Other issues of concern with the use of server-side registries relate to reliability, security and object naming. A server-side registry may provide a single point of failure. For example, if a server-side registry terminates abnormally, client applications may be unable to make requests to server applications. Although multiple server-side registries may be utilized to overcome this limitation, multiple server-side registries are generally not desirable because of the administrative complexities involved.
A server-side registry typically provides an application programming interface (API) that allows a client application to query objects registered within the registry. From a security standpoint, a rogue client application could access a server application via a server-side registry API without having permission.
Another drawback of server-side registries is that a client application generally needs to know the name of a registered server stub associated with a particular server application. In an environment of a single computer hosting multiple server applications, wherein each server application registers its own server stub, care must be taken to ensure that server objects are registered with unique names. Each client application accessing a server application needs to be aware of what naming scheme is being used and of any changes to existing naming schemes.
SUMMARY OF THE INVENTION
In view of the above discussion, it is an object of the present invention to allow client applications to know when a server application is ready to receive client application requests without requiring polling.
It is another object of the present invention to reduce processing disruptions between a server application and multiple client applications because of a server-side registry failure.
It is another object of the present invention to enhance security with respect to objects within a distributed object environment.
It is another object of the present invention to reduce naming complexities involved in a distributed object environment including multiple computers hosting server applications.
These and other objects of the present invention are provided by systems, methods and computer program products for invoking a server application resident on a first computer to handle requests from a client application resident on a second computer, remote from the first computer, using a client-side remote object registry. According to the client-side perspective of the present invention, the first computer includes an authentication server and one or more additional server applications resident thereon. The second computer, hosting the client application, has a remote object registry resident thereon. An object, referred to as a ticket and associated with the client application, is created and includes an acknowledgment method associated the
Bittinger F. Dirk
Liebl Christopher J.
LandOfFree
Systems, methods and computer program products for invoking... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Systems, methods and computer program products for invoking..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Systems, methods and computer program products for invoking... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2897385