Universal object request broker encapsulater

Details Universal object request broker encapsulater Universal object request broker encapsulater

1997-04-07

2001-01-30

Banankhah, Majid (Department: 2755)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

Reexamination Certificate

active

06182154

ABSTRACT:

BACKGROUND OF THE INVENTION
This invention relates generally to data processing systems. More particularly, it relates to communications between objects in different address spaces.
Object oriented programming (OOP) has been touted as a promising new technology to speed the development of software by allowing more efficient reuse and customization of software modules called objects. Objects are units of software which encapsulate both data and methods, an organization which makes the software both easier to maintain and enhance. Despite its promise, object oriented technology is only starting to be utilized in major commercial software products.
Several obstacles confront the software developer in using OOP. The first obstacle is the plethora of object oriented languages and toolkits which embrace different incompatible models of what objects are and how they should behave. For example, “pure” object oriented languages such as Smalltalk operate smoothly so long as they are in the supplied runtime environment. When interacting with foreign environments, the objects are reduced to data structures which do not retain the advantages of encapsulation and reuse which objects offer. Hybrid languages such as C++ require less runtime support, but employ tight bindings between the objects and their clients which means that the client programs have to be recompiled even when relatively minor changes are made to the objects. In summary, objects developed in one language could rarely be used in another.
The System Object Model, “SOM”, is an object oriented technology designed to unite various object oriented approaches. In SOM, the interfaces of the classes of objects, the methods they support, the return types, and so forth are specified in the Interface Definition Language. The actual implementation of the object class can be written in any language the developer prefers, even a procedural language such as C. Thus, the advantages of OOP can be extended to programmers of non-object oriented programming languages. SOM is described in greater detail in copending and commonly assigned application, Ser. No. 07/805,668 “Language Neutral Objects” filed May 4, 1992 to M. Conner et al. which is hereby incorporated by reference.
Various standards bodies exist which encourage compliance to certain standard architectures. One of these standards is the Common Object Request Broker Architecture (CORBA) promulgated by the Object Management Group (OMG) and X/Open. The Object Request Broker (ORB) described in the architecture is analogous to the Remote Procedure Call (RPC) familiar to those working in the UNIX environments. Like the RPC, an ORB is a mechanism which allows processes working in one address space to communicate with others in another address space. An ORB intercepts a call from an object in one address space, encapsulates it into a network protocol, decodes the call for the target object in another address space and returns the results back to the calling object. Object Request Broker is an a improvement upon the RPC as it is designed to provide the higher level of flexibility and power offered by object oriented programming.
Unfortunately, since CORBA specifies the ORB interface but little about how ORBs function, it is possible to write ORBs which are CORBA compliant, but do not communicate with each other. In fact, this is the rule rather than the exception. Of the five or six ORB implementations known to the applicants, none can handle objects native to another ORB. Nor can the ORBs communicate with one another.
The present invention provides a mechanism for interconnecting a theoretically unlimited number of Object Request Brokers with arbitrary implementations.
SUMMARY OF THE INVENTION
Therefore, it is an object of the invention to pass requests from requesters to a target objects written to different object request brokers.
It is another object of the invention to minimize the overhead associated with the gateway mechanism.
It is another object of the invention to limit the necessary change to existing object request broker implementations.
It is another object of the invention to maintain the transparency of the gateway mechanism to requestors.
These and other objects are accomplished by a mechanism for passing a request from a calling object in a first address space to a target object in a second address space written to different ORBS. First, the request is passed from the calling object to an object request broker to which the calling object is written which normally handles requests to remote objects for the calling object. Responsive to a determination that the target object is foreign to the object request broker, a foreign object request broker to which the target object is written is located. A proxy object is generated according to the protocol of the foreign object request broker and stored in the first address space. A pointer is returned to calling object so that communication from the calling object to the target object may be established through the proxy object.
The preferred mechanism to determine the foreign object request broker is a manager of proxy managers object to which is registered a plurality of proxy manager each of which creates proxy objects for a respective foreign ORB. The manager of proxy manager repetitively passes the target object identifier to each proxy manager until a proxy manager is found which recognizes the target object. The recognizing proxy manager creates the proxy object. One preferred embodiment places the manager of proxy managers and its associated proxy mangers on a gateway machine to limit the overhead of the process to a single powerful server rather than duplicate the mechanism throughout a network.


REFERENCES:
patent: 4251687 (1981-02-01), Deutsch
patent: 4984177 (1991-01-01), Roundel et al.
patent: 5181247 (1993-01-01), Holl
patent: 5187790 (1993-02-01), East et al.
patent: 5255326 (1993-10-01), Stevenson
patent: 5274740 (1993-12-01), Davis et al.
patent: 5315709 (1994-05-01), Alston, Jr. et al.
patent: 5329619 (1994-07-01), Page et al.
patent: 5475817 (1995-12-01), Waldo
patent: 5481721 (1996-01-01), Serlet et al.
patent: 5511197 (1996-04-01), Hiel et al.
patent: 5732270 (1998-03-01), Foody et al.
The Common Object Request Broker: Architecture and Specification, Object Management Group and X/Open, Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design, Inc. and SunSoft, Inc.
G. H. Gonnet “Handbook of Algorithms & Data Structures”, Addison-Wesley, 1984, p. 23.
W. Richard Stevens, “Unix Network Programming” Prentice Hall, 1990, pp. 88, 185.
John Rymer, “Distributed object interoperability”, Distributed Computing Monitor, v10, n3, p3(26), Mar. 1995.
ICL, “ORB Interoperability”, OMG document 94.3.3, Mar. 1994.
Universal Networked Objects, OMG TC document 94.9.32, Sep. 1994.
BNR, “OMG Object Request Broker 2.0 Interoperability and Initialisation RFP Response”, Mar. 1994.
The Common Object Request Broker: Architecture and Specification by Object Management Group and X/Open. Copyright 1991, 1992 by Digital Equipment Corporation, Hewlett-Packard Company, HypeDesk Corp., NCR Corp. Object Design, Inc. SunSoft, Inc.

Affiliated with

Also associated with

Rating

Universal object request broker encapsulater does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Universal object request broker encapsulater, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Universal object request broker encapsulater will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2524162