Index > Module Overview > CorbaBindingRuntime

The CORBA Runtime Binding

The CORBA runtime binding allows client and/or server applications using Yoko to communicate with corresponding CORBA clients and servers which implement some common interface. The binding uses the WSDL files (and the CORBA binding information contained within it) produced by the Yoko tools to convert the web service request into a format that can be invoked on a CORBA target.

Summary of Proposed Solution

On the client side, the runtime binding implements the Celtix API interface ClientBinding which provides the mechanisms necessary for invoking requests on a target. Into these invoke operations, Celtix ObjectMessageContextsare provided which contain parameter information which is to be included with the operation invocation. The binding converts these ObjectMessageContextobjects into a Stax XMLEvent sequence which is then used by the binding to create the corresponding CORBA object. These objects are then packaged into a CORBA DII request that is invoked on the CORBA target. Return values or exceptions are then retrived from the DII request and returned to the Yoko client which made the initial operation invocation.

Similarly, on the server side, the binding uses a combination of a CORBA DSI Servant and an server binding which implements the Celtix Binding API interface ServerBinding. Incoming requests are handled by the DSI Servant which is responsible for converting the CORBA request into a Stax XMLEvent sequence which can be then marshalled into an Object that Celtix can handle. The servant then creates and invokes the correct Yoko operation based on information from both the incoming CORBA request and CORBA binding information contained in the WSDL file. Return values or exception generated from the Yoko operation invocation are then added to the initial CORBA request and returned to the CORBA application which made the request.

As mentioned above, marshalling and unmarshalling of CORBA types to Yoko types will be done through the use of the Stax API. Yoko types will perform the conversion to and from Stax events using DataReaders and DataWriters from Celtix which will use XMLEventReaders and XMLEventWriters. CORBA type will use a Yoko intermediate object which stores the objects data and type information from the WSDL file for performing the conversion from CORBA object to/from Stax events. This use of Stax as a common form for describing an object and its value should allow for the appropriate conversions between Yoko and CORBA types.

CORBA Types Currently Supported By The Binding

Features To Be Added

The binding will also support the following CORBA types shortly:

  • Any type (still has issues - see below)
  • Nested and Recursive types

Additionally, the following features will also be implemented in the binding:

  • Configuration of binding/CORBA functionality via configuration files

Issues

Any Types

  • Currently, there is a problem in the binding with knowing how to store an object in a CORBA Any before we write it to the output stream. Since Yoko is using Stax, all objects that we receive from Celtix are encoded into a sequence of XMLEvents, with the actual object value being represented as a character string. The problem arises when we have a character string which could have been generated from different Celtix objects. For example, when a Boolean object with the value FALSE is encoded into a Stax event, it yields the character string "false". Similarly, when a String object with the value "false" is encoded into a Stax event, it also has the character representation of "false". When the binding then attempts to insert one of these values into an Any, it does not know from the Stax event whether the string "false" came from an encoded String or Boolean value. This can then create issues on the CORBA side (client or server) when the CORBA application attempts to extract the value as a specific type (e.g. string via the any.extract_string()) when it has been encoded as the other type (e.g. boolean)