The Common Object Request Broker Architecture (CORBA) middleware platform has been a leading middleware platform in recent years. As is known in the art, CORBA is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together as a single application or set of services. CORBA uses an interface definition language (IDL) to specify interfaces that objects will present to the outside world, and specifies a mapping from the IDL to a specific implementation language. CORBA uses an Object Request Broker (ORB) to send requests from objects executing on one system to objects executing on another system. The ORB allows objects to interact in a heterogeneous, distributed environment, independent of the computer platforms on which the various objects reside and the languages used to implement them. CORBA is specified and further explained in the CORBA Specification, version 3.1 (January 2008), including Part 1 (CORBA Interface) and Part 2 (Interoperability), available from the Object Management Group (OMG) at 109 Highland Ave, Needham, Mass. 02494. The entire CORBA Specification, including at least Parts 1 and 2, is hereby incorporated by reference in its entirety.
CORBA communication typically occurs over an Ethernet or other network, between a Client and Server. FIG. 1 is an illustrative prior art block diagram 10 showing client 12 to server 14 communication, in accordance with CORBA, in an exemplary environment. FIG. 1 illustrates what happens when a client application 16 invokes an operation on an object/servant 24 in a server process 14. To implement an interface, CORBA IDL is compiled into the source code language with which the client 12 or server 14 is implemented. On the client side, this code is called a stub. On the server-side, this IDL code is called a skeleton. Typically, client-side application code 16 invokes a local proxy object 18 (e.g., via a proxy class generated by an IDL compiler). The proxy 18 gets information about the request (e.g., in and inout parameters, operation name) into a binary buffer, which is then passed into the ORB 20A library. The ORB 20A library sends a request message across the network to the server process 14. The ORB 20A waits for a reply message from the server process 14. The ORB 20A returns the reply buffer back to the proxy object 18, which unmarshals inout and out parameters and the return value (or a raised exception), and returns these to the client application code 16.
At the server 14 side, the ORB 20B runs a thread in an event loop that waits for incoming requests. When the request arrives from the client 12 the ORB 20B reads the request's binary buffer and passes this to some code that unmarshals the parameters and dispatches the request to the target servant 24. The code that performs the unmarshalling and dispatching is spread over two components, the Portable Object Adapter (POA) (shown in FIG. 1) and the skeleton code that is generated by the IDL compiler. When the operation in the servant 24 returns, the skeleton code marshals the inout and out parameters (or a raised exception) into a binary buffer and this is returned via the POA 22 to the ORB 20B, which transmits the reply message across the network to the client process 12.
The main protocol for ORB communication as shown in FIG. 1 is the standardized General Inter-ORB Protocol (GIOP), which has been widely deployed for transport in the TCP/IP environment. GIOP also is described further in the aforementioned CORBA Specification, and as of this writing is a version 1.3. GIOP over TCP/IP is known as Internet Inter-ORB Protocol (IIOP). GIOP is a client-server protocol and defines the messages and format that are passed over the ORB between the client and the server object. The data placed in the GIOP follows CORBA Common Data Representation (CDR) syntax for placing and copying the data into an octet stream. CORBA is mainly used on General Purpose Processors (GPPs) using TCP/IP and/or OS Inter-Processor Communications (e.g., shared memory).
There is increasing need to apply technology such as the CORBA GIOP ORB in different types of environments, but some environments, especially embedded environments, require more efficient and/or compact messaging than is provided via the GIOP message and GIOP header formats of FIG. 2. In addition, standard GIOP/IIOP interoperability protocols can be less than optimal for applications having strict requirements for latency, overhead and message sizes. Furthermore, because the CORBA GIOP was originally developed for use in general purpose distributed computing environments, optimization of the GIOP may be required for the best performance in distributed embedded systems, which can be more complex, especially because of the many interfaces with different types of control devices and input/output (I/O) devices. Optimized interoperability protocols are thus becoming of greater importance.