|
[Up: Object Request Broker]
[Previous: Addressing] [Next: Interoperability]
Once both the interface and the address of an object are known, methods can be invoked and will be executed remotely. Again, how this is done is up to the language mapping.
In C++, special stubs are generated by the IDL compiler for each interface. These are C++ classes that export the methods declared in the IDL file. In addition, an instance of a stub, a stub object, encapsulates a specific object reference.
Whenever a C++ program acquires an object reference, decoded from a stringified object reference, from the Naming Service or as result from another method invocation, the ORB indeed creates a stub object. Since a stub object cannot exist without an object reference, and an object reference rarely exists outside a stub object, these two terms are often used synonymously.
The generated code in the stub takes care of marshalling the method's parameters into a request and passes it on to the ORB, which deciphers the object reference and contacts the server. The remoteness is transparent to the user program: the invocation looks no different than a normal, local invocation.
For the server side, a skeleton is generated by the IDL compiler. The user derives from that skeleton and adds the methods' implementation; an instance of such an object implementation class is called servant. The generated skeleton takes care of receiving the request from the ORB, unmarshalling the parameters and performing the upcall into the user-provided code. This way, the object implementation also looks like a ``normal'' class. The full process is shown in figure 3.5. It shows the ORB to be a component of its own, which is true in the abstract sense only. Usually, it is implemented partly in the client and the server - but the user does not have to be aware of such details.
Stubs and skeletons, as described so far, use static type information: the method names and their parameters must be decided on at compile time, for they are hardwired into the generated code. Alternatively, the Dynamic Invocation Interface (DII) is available on the client side, and the Dynamic Skeleton Interface (DSI) on the server side. Using the DII, a client can compose a request using runtime type information, retrieved for example from an Interface Repository. On the server side, a servant can use the DSI to dissect incoming requests explicitly.
Using the DII on the client side does not require using the DSI on the server side and vice versa. The requests that are sent by DSI or received by DII do not differ from other requests, as both interfaces are used only to perform the work usually done by generated code.
DII and DSI are not only useful for gateways that do not have advance knowledge of the requests they are supposed to forward. Dynamic invocations can also be used in generic front ends, to invoke methods for which no generated code is available, and dynamic skeletons can be used, for example, to support more than one interface with a single servant.
Another feature of the DII is that it allows asynchrony. Invocations through the static interface are always synchronous, the client blocks until the request is processed and answered by the server. The DII provides methods for sending a request asynchronously, and later for polling or waiting for the reply.3.4
On the other hand, static IDL-generated code, apart from being much more comfortable to use, is likely to be faster in constructing requests than code using the dynamic interfaces, which must use generic interfaces for marshalling parameters, such as encapsulating each parameter in an Any value. IDL-generated code, produced by a vendor-specific IDL compiler, can take full advantage of a vendor-specific Static Invocation Interface (SII) if available, which might be able to marshal data much more effectively. This smaller request overhead is especially noticeable with large and complex parameters (such as arrays or sequences) if the server-side computation time is small.
As seen in section 2.2.2, the Parallel Virtual Machine provided asynchronous messaging only - asynchrony is essential for the implementation of parallel systems. In a Master/Slave system, a master distributes a number of small tasks to slaves running in parallel, and must then wait asynchronously for the results to arrive. CORBA Messaging [35], scheduled for CORBA 3.0 [71], will introduce a new feature called Asynchronous Method Invocations (AMI), which allows asynchronous invocations based on IDL-generated skeleton code.
[Previous: Addressing] [Next: Interoperability]
[Up: Object Request Broker]