Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-03-17
2002-01-29
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S203000
Reexamination Certificate
active
06343332
ABSTRACT:
BACKGROUND OF THE INVENTION
(1) Field of the Invention
The present invention relates to a communication link information generating device, and more particularly, to a communication link information generating device for generating inter-applications communication link information for a three-tier client/server system constituted, for example, by a client/server system utilizing a distributed object-oriented technique for communications therein and a general-purpose computer having no distributed object environment.
(2) Description of the Related Art
A client/server system is a system in which the functions of applications are distributed to clients and servers so that processes may be executed cooperatively by the entire system via a network. In a system of such configuration, a client is primarily dedicated to being a user interface, while the principal objective of a server is to accept a request from a client generated during an interactive process with a user and to perform the necessary process. Each client has the function of executing a process in response to an event occurring with reference to the user interface, and accordingly, increased functions inevitably tend to increase the client's load. Therefore, in order to avoid close connections of the functions and to impart expansibility and flexibility to the system, there has been proposed a hierarchical system having a multi-tier system configuration such that at least one tier intervenes between the client tier and the server tier.
In client/server systems, there is also a demand for enhancement in the reliability, expansibility and flexibility of inter-applications communications, and a distributed object environment is one environment that meets the demand.
Object-oriented development in which an application is regarded as an object is spreading widely as a technique of improving the efficiency of program development. Among such techniques, CORBA (Common Object Request Broker Architecture) is the set of rules for a distributed object-oriented technique defined by the OMG (Object Management Group) whereby, in a distributed system, a client application can retrieve a server application without the need to recognize the location or packaging thereof.
With CORBA, the interface information of a server application is laid open for common use on the network of the client/server system, so that a client application can readily make use of the server application as if it is calling a program within a local system. The functions and software for communicating between objects are called ORB (Object Request Broker), and IIOP (Internet Inter-ORB Protocol) is adopted as a communication procedure for inter-ORB connections.
FIG. 7
exemplifies the configuration of a three-tier system. In
FIG. 7
, the three-tier system comprises a client
100
, a server system
110
, and a data server
120
. A client application
101
is installed in the client
100
, a server application
111
is installed in the server system
110
, and another server application
121
is installed in the data server
120
. Thus, the server application
111
also functions as a client application with respect to the server application
121
.
FIG. 7
illustrates, by way of example, the case where an object A of the client application
101
calls an object B of the server application
111
and the object B in turn calls an object C of the server application
121
. Exchange of messages between these objects is achieved by means of an interface information file, an ORB mechanism and an inter-ORB communications protocol.
The interface information file is created for each of the client and server applications by describing interface information about the objects in an interface definition language (IDL) conformable to the syntax as provided by CORBA, followed by compiling with the use of a dedicated IDL compiler. In CORBA, the interface information file for the client is called a stub, and that. For the server is called a skeleton.
The client application
101
is associated with a stub
102
and an ORB mechanism
103
, the server application
111
is associated with an ORB mechanism
112
, a skeleton
113
, a stub
114
and an ORB mechanism
115
, and the server application
121
is associated with an ORB mechanism
122
and a skeleton
123
. The stub
102
and the skeleton
113
are each an interface information file created by compiling an IDL file
131
describing information about the object B, and the stub
114
and the skeleton
123
are each an interface information file created by compiling an IDL file
132
describing information about the object C.
IIOP, which is a standard protocol of CORBA, is used for the communications between the ORB mechanisms
103
and
112
and between the ORB mechanisms
115
and
122
.
Another server
140
, which is also located on the network, provides a naming service
141
. The naming service
141
serves to respond to an inquiry about where on the network the object that is needed by an object of an application exists, and constitutes a database in which objects are managed by their names along with the addresses of servers where the objects are located. Thus, a client application calls an object of a server application by its name, whereupon the ORB mechanism refers to the naming service
141
to obtain the address of the server system where the object of the server application is located. By making a request to the server system by means of the obtained address, it is possible to make use of the object.
The following explains how an object is called in the three-tier system configured as described above. First, the object A of the client application
101
calls the object B, and this means calling an object (operation) loaded into the stub
102
and corresponding to the object B. Since this operation does not have interface information necessary for communications, the ORB mechanism
103
refers to the naming service
141
and, based on the obtained address of the server system
110
, sends a request of the client application
101
to the ORB mechanism
112
of the server system
110
by using the IIOP protocol. On receiving the request via the ORB mechanism
112
, the object B transfers the request to the object C. Also in this case, communications are performed in a like manner by using the naming service
141
to acquire the address of the data server
120
on the network. The server application
121
of the data server
120
then processes the request from the object B. The object C supplies the object B with the result of processing, and the object B provides the object A with the response from the object C. Consequently, the client application
101
is supplied with the result of processing.
In three-tier systems such as the one described above, there often arises a need to use a large general-purpose computer as the third-tier data server
120
. In such a case, the second-tier server system
110
performs a gateway process in which it merely transfers requests from the client
100
to the general-purpose computer. This configuration serves to improve the reliability and performance of the overall system and also permits reuse and effective use of existing database systems.
The CORBA technique is applied to open architecture-based computers fabricated using a standard operating system and standard hardware. General-purpose computers, on the other hand, are constructed based on their own architectures, and therefore, the problem mentioned below arises where a general-purpose computer is applied to the third tier in a three-tier system.
First, the general-purpose computer, which originally does not employ distributed object-oriented techniques, needs to be provided with an ORB mechanism for cooperation with the distributed object-oriented technique.
In CORBA, the individual object names must be unique on the network for the purpose of management; therefore, even if the interfaces between relevant twos of the three tiers are the same, two IDL definitions, that is, an IDL source defining the interface between the c
Courtenay III St. John
Fujitsu Limited
Staas & Halsey , LLP
LandOfFree
Communication link information generating device, a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication link information generating device, a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication link information generating device, a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2817907