Connection concentrator for distributed object systems

Details Connection concentrator for distributed object systems Connection concentrator for distributed object systems

1999-10-15

2002-03-12

Maung, Zarni (Department: 2154)

Electrical computers and digital processing systems: multicomput

Distributed data processing

C709S241000

Reexamination Certificate

active

06356930

ABSTRACT:

FIELD
The present invention relates to the distributed Object Oriented Systems. In particular, the invention relates to an apparatus and method for improving communication between clients and servers employing object software technology.
BACKGROUND
Conventional client-server networks employ dedicated connections between one another. In general, the client communicates directly with the server and any requests made by the client are handled by the server. This does not pose a problem in conventional networks because the number of overall connections between the clients and servers is relatively low. However, as more clients connect to more servers and as the client-server communication incorporates more object references, the number of interconnections increases dramatically. Presently, and in the future, the conventional client-server systems that incorporate object references will be overburdened and a solution to this problem must be found.
Accordingly, a limitation of the existing distributed object systems is their inability to scale to handle a large number of clients. In a distributed object system (for example, Common Object Request Broker (CORBA) (1), Java Remote Method Invocation (RMI) (2), and Distributed Component Object Model (DCOM) (3)) objects can be running all over the network. A client invokes a method on an object by first obtaining a reference to it. An object reference typically contains the network address of the server in which the object is instantiated as well as some unique datum that identifies the object within the server. When a method is invoked on the object, the client's ORB (Object Request Broker) runtime typically makes a direct connection to the server and forwards the invocation to the server using an object protocol (for example, most CORBA implementations use Internet Inter ORB Protocol, IIOP).
FIG. 1
illustrates the client ORB runtime opening up a direct connection to each server with which it needs to communicate in the previous art. The figure shows a client
100
in communication with server
1
110
and server
2
120
. The circles denote clients and servers and the two headed arrows denote connections. Server
1
contains two objects
112
and
114
and server
2
contains a single object
122
in FIG.
1
.
With the scheme illustrated in
FIG. 1
, if there are N clients and M servers, there could be up to N times M connections between them in the previous art as shown in FIG.
2
.
FIG. 2
illustrates client ORB runtimes opening up a direct connection to each server with which they need to communicate. The figure shows client
1
211
in communication with server
1
251
, server
2
252
and server M
259
, where M is some number larger than
2
. In
FIG. 2
, this communication is illustrated by two-headed arrows between client
1
and three servers, server
1
, server
2
, and server M. Servers
3
through (M−1) are present, and in communication with client
1
, but are not illustrated for convenience.
Similarly,
FIG. 2
shows client
2
212
in communication with server
1
251
, server
2
252
and server M
259
. In the Figure, this communication is illustrated by two-headed arrows between client
2
and server
1
, server
2
and server M. Servers
3
through (M−1) are present, and in communication with client
2
, but are not illustrated for convenience.
Finally, the figure shows client N
219
, in communication with server
1
251
, server
2
252
and server M
259
, where M is some number larger than
2
. Clients
3
through (N−1) are present, but are not illustrated for convenience. In the Figure, communication is illustrated by two-headed arrows between client N and server
1
, server
2
, and server M. Servers
3
through (M−1) are present, and in communication with client N, but are not illustrated for convenience.
Each server contains one or more objects,
2511
,
2512
,
2521
and
2591
. Objects
2511
and
2512
are located on server
1
and objects
2521
and
2591
are located on servers
2
and M, respectively.
For large values of N and M, the number of connections between clients and servers increase beyond the capabilities of even the largest of computing systems. The result is that the object system starts to perform poorly and/or starts to reject service.
Several relevant publications are provided and incorporated herein by reference. The Common Object Request Broker (CORBA) and Internet Inter-ORB Protocol (IIOP) specifications are published by the Object Management Group at http://www.omg.com. The Java Remote Method Invocation lava RMI) specifications are published by Sun Microsystems Java Software Division at http://wwwjavasoft.corn/products/rmi. The Distributed Component Object Model is published in “Professional DCOM Programming” by Dr. R. Grimes (1997) ISBN 1-86100-60-X.
A goal of the invention is to overcome the identified limitations and to provide a connection concentrator for distributed object systems.
SUMMARY
A goal of the invention is to overcome the identified limitations and to provide a connection concentrator for distributed object systems. Exemplary embodiments are provided for use with the Internet, but other communication protocols can be used. This invention improves the network by incorporating gateway structures disposed between the conventional client-server architecture. The invention also provides an object request broker (ORB) at the client and the gateway so that the gateway can efficiently access objects from the servers and retrieve the object on behalf of the client. Additional clients can connect to the same gateway and access the same objects without an attendant increase in links to the server with the object.
In another embodiment of the invention, the object request broker also resides on the server and the gateway can access objects from the clients and retrieve the object on behalf of the server.
In yet another embodiment of the invention, additional gateways are disposed in series to further reduce the number of connections to the object servers.
Advantages of the invention include an increased capability of a network system to provide access to objects without overburdening the network. Additionally, the network can be further improved by placing additional gateways in series to further reduce the number of connections to the object servers.


REFERENCES:
patent: 5329619 (1994-07-01), Page et al.
patent: 5553242 (1996-09-01), Russell et al.
patent: 5717747 (1998-02-01), Boyle, III et al.
patent: 5727145 (1998-03-01), Nessett et al.
patent: 5748897 (1998-05-01), Katiyar
patent: 5754763 (1998-05-01), Bereiter
patent: 5774668 (1998-06-01), Choquier et al.
patent: 5793965 (1998-08-01), Vanerbilt et al.
patent: 5862328 (1999-01-01), Colyer
patent: 6003083 (1999-12-01), Davies et al.
patent: 6009266 (1999-12-01), Brownell et al.
patent: 6018805 (2000-01-01), Ma et al.
patent: 6044409 (2000-03-01), Lim et al.
patent: 6105067 (2000-08-01), Batra
patent: 6115744 (2000-09-01), Robins et al.
patent: 6125363 (2000-09-01), Buzzeo et al.
patent: 6182154 (2001-01-01), Campagnoni et al.
patent: 2001/0010053 (2001-07-01), Ben-Shachar et al.
patent: 822492 (1997-02-01), None

Affiliated with

Also associated with

Rating

Connection concentrator for distributed object systems does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Connection concentrator for distributed object systems, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Connection concentrator for distributed object systems will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2816314