Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-07-02
2001-08-28
Banankhah, Majid (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06282580
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is related to object-oriented computer systems and, more particularly, to a bridge allowing communication between different implementations of object request brokers.
As individual computer systems increasingly become more powerful and complex, the integration of these heterogeneous computer systems becomes a very desirable yet difficult task. Users' expectations for interoperability have increased dramatically due to the availability of highly interoperable platforms such as UNIX, Microsoft Windows and Apple Macintosh. Unfortunately, vendor-specific solutions for integrating heterogeneous computer systems have generally been unsatisfactory. This is especially true because vendor-specific solutions require upgrades to take into account new product releases.
The Object Management Group (OMG) has promulgated standards for nonvendor-specific solutions for heterogeneous systems integration. At the heart of OMG's standard is the Common Object Request Broker Architecture (CORBA). CORBA is a distributed environment defined using object-oriented concepts to hide all differences between programming languages, operating systems, hardware platforms, and object location. This interoperability is achieved through well-defined interface specifications at the application level.
Well-defined protocols exist for allowing systems to communicate by agreeing to certain standards that will be used. The Open Systems Interconnection (OSI) seven layer model is possibly the most widespread of these protocols. The lowest layer, the Physical layer, describes how the physical network is accessed. The Data Link layer provides reliable transmission across a physical link. The Network layer deals with connection establishment and routing. The Transport layer provides reliable end-to-end transmission. The Session layer is concerned with connection control. The Presentation layer deals with data syntax and transparency to the applications. Lastly, the upper layer, the Application layer, describes end-user functionality. Conceptually, CORBA resides in the Application layer.
A central component of CORBA is the Object Request Broker (ORB) which is the infrastructure for providing transparent distributed communication across heterogeneous systems. The CORBA specification describes all the standard interfaces for ORBs. The Basic Object Adapter (BOA) is an initial set of ORB interfaces for object implementations.
CORBA is a peer-to-peer distributed computer facility where all applications are objects. Objects can alternate between being a client and a server, where a client object is defined as being the originator of an object invocation and a server object is defined as being the recipient of an object invocation. Server objects are also referred to as object implementations. Typically, objects play both roles at one time or another.
CORBA provides two mechanisms with or through which applications may communicate: static interfaces and dynamic interfaces. In static interfaces, the parameters are defined at compile-time whereas in dynamic interfaces, the parameters are defined at run-time.
Static interfaces include a stub and a skeleton. The client object links to the stub so that from the client's perspective, the stub acts like a local function call. Transparently, the stub provides an interface to the ORB that encodes and decodes the specified operation's parameters into communication formats suitable for transmission. The skeleton is the corresponding server-side implementation of the interface. When the server object completes processing of the request, the skeleton and stub return the results to the client, along with any exceptions that are generated by either the server or the ORB.
Dynamic interfaces are an alternative to compiled static interfaces. Dynamic interfaces include a Dynamic Invocation Interface (DII) and a Dynamic Skeleton Interface (DSI). The DII is a generic facility for invoking any operation with a run-time-defined parameter list. A run-time interface description of the operation signature specifying the parameter list is retrieved during run-time. Thus, a request can be constructed to previously unknown operation or object type. The DSI is the corresponding server-side implementation of the interface. Use of the dynamic interface instead of the static interface is transparent to object implementation.
Current CORBA ORB products support software integration across multiple platforms. ORB implementations may be generic across multiple platforms or platform-specific. Platform-specific ORB implementations offer many advantages including more efficient implementation resulting from closer ties to the operation system. As an example, Sun Microsystems' NEO provides shared services extensions to the Solaris operating system. NEO supports standards such as OMG's CORBA specifications.
Although platform-specific implementations of CORBA offer many advantages, there is a need for more efficient systems and methods for providing communication between different implementations of ORBs.
SUMMARY OF THE INVENTION
Embodiments of the present invention provide innovative systems and methods for providing communication between different implementations of object request brokers. A bridge including a proxy object allows communication between the object request brokers. The proxy object within the bridge stores the server object reference in its reference data. The proxy object translates messages (e.g., requests and responses/exceptions) to the transfer protocol of the server object and redirects these messages according to the server object reference stored in the proxy object's reference data. Thus, an efficient mechanism for providing communication between different implementations of object request brokers is achieved.
In one embodiment, the present invention provides a method of providing communication between a first object request broker utilizing a first transport protocol and a second object request broker utilizing a second transport protocol, comprising the steps of: storing within the reference data of a proxy object a reference to a server object; the proxy object receiving a request in the first transport protocol from a client object on the first object request broker; the proxy object translating the request to the second transport protocol; and the proxy object sending the translated request to the server object specified by the stored reference.
In another embodiment, the present invention provides a system for providing communication between different implementations of object request brokers, comprising: a first object request broker utilizing a first transport protocol; a client object on the first object request broker; a second object request broker utilizing a second transport protocol, the first and second transport protocols being different; a server object on the second object request broker; and a proxy object that translates a request in the first transport protocol from the client object to the second transport protocol and sends the translated request to the server object specified by a reference to the server object stored in the reference data of the proxy object.
Other features and advantages of the present invention will become apparent upon a perusal of the remaining portions of the specification and drawings.
REFERENCES:
patent: 5187787 (1993-02-01), Skeen et al.
patent: 5539909 (1996-07-01), Tanaka et al.
patent: 5613148 (1997-03-01), Bezviner et al.
patent: 5692183 (1997-11-01), Hapner et al.
patent: 5708828 (1998-01-01), Coleman
patent: 5724503 (1998-03-01), Kleinman et al.
patent: 5732270 (1998-03-01), Foody et al.
patent: 5778369 (1998-07-01), Pascoe et al.
The Common Object Request Broker: Architecture and Specification, Revision 2.0, Jul. 1995.*
OMG, ORB 2.0 RFP Submission: ORB Interoperability, OMG TC document 94.3.1, pp. 1-40, Mar. 7, 1994.*
Brando, Thomas; Interoperability & the CORBA Specification; MITRE Document MP 95B-58; pp. 1-13; Feb. 1995.*
Object-Orientation FAQ: HP-ORB &
Banankhah Majid
Beyer Weaver & Thomas
Caldwell P
Sun Microsystems Inc.
LandOfFree
Bridge providing communication between different... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Bridge providing communication between different..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Bridge providing communication between different... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2437470