CORBA 2.0 friendly EJB

[flitzie]

Hallo

did anybody managed to write an CORBA-friendly EJB with complex types (IDL struct, sequences, ...) and accessed it with a CORBA 2.0 client?

The problem is that IDL structs or sequences of CORBA-friendly EJB's are boxed as valuetypes. Is it possible to enforce JBoss/JacORB to use non-valuetyped binarystreams to communicate with clients? I mean I cannot imagine that it won't be possible, because JacORB already sends "normal" UserException (JBoss 3.2.2 RC4) which CORBA 2.0 clients can unmarshall. To send simple IDL structs I could use UserExceptions, because IDL structs and IDL exceptions are equal, but this would be an ugly way of developing.

Any comments or suggestions are appreciated

flitzie

[flitzie]

Hello developers,

I managed to access an EJB with an CORBA 2.0 client successfully. I re-defined the IDL file for the client to marshall and demarshall the additional valuetype information.

For example:

typedef sequence Binary;

/*
// this is the original struct used in the EJB
struct TestBean {
long count;
string name;
Binary data;
};
*/

// struct for the client to unmarshall the boxed valutyped struct
struct getBoxedTestBean {
long ser;
string host;
string id;
long count;
string name;
Binary data;
};

// struct for the client to marshall a boxed valutyped struct
struct setBoxedTestBean {
long ser; // = 2147483394
string id; // = #pragma ID TestBean "RMI:ejb.corba.test.TestBean:84F24825D7BD12E9:07B7D087B58E218E"
long count;
string name;
Binary data;
};


I am not a CORBA ORB developer so I am asking me why does this work because the corba binarystream of an corba 2.0 and 2.3 client still differs? I want to understand the meaning of these additional valuetype information compared to non-valuetype. I read some CORBA Specs but I couldn't find any usefull information. It would be great if someone of you could post some links with detailed information about marshalling and demarshalling of valuetypes.

TIA

flitzie

[reverbel]

Hi,

> did anybody managed to write an CORBA-friendly EJB
> with complex types (IDL struct, sequences, ...) and
> accessed it with a CORBA 2.0 client?

The MICO distribution (www.mico.org) includes such an example, with the CORBA-friendly EJB being accessed by a C++ client.

> The problem is that IDL structs or sequences of
> CORBA-friendly EJB's are boxed as valuetypes. Is it
> possible to enforce JBoss/JacORB to use
> non-valuetyped binarystreams to communicate with
> clients?

No, as valuetype boxing is standardized behavior. The Java to IDL mapping specification defines that an IDL struct (or sequence) is mapped to a valuebox containing the IDL struct (or sequence).

The rationale for valuetype boxing is preserving the semantics of null parameters. Suppose that Foo is an IDL struct, and consider an IDL operation that takes a Foo parameter:

void myOperation(in Foo foo); // IDL

This operation must receive a Foo instance! CORBA/IDL semantics disallow you to pass some sort of null value instead of a Foo. In Java, if you try to pass the null reference when you invoke myOperation on a CORBA stub, you will get a client-side exception from the stub.

By contrast, consider a similar thing in Java. The following
method could appear in a Remote interface:

void myJavaOperation(Foo foo) throws RemoteException;

Here Foo is the Java class generated (by an IDL to Java translator) from the IDL struc Foo. The point to be noted is that that RMI semantics allow you to pass null to myJavaOperation.
So what would be the (reverse) mapping of myJavaOperation to IDL? I cannot be

void myJavaOperation(in Foo foo); // IDL

because this would rule out null as a valid paramete value.
The OMG-defined mapping is

void myJavaOperation(in ValueboxedFoo foo); // IDL

where ValueboxedFoo is a valuebox that contains a (possibly null) Foo instance. This standard mapping thus preserves the semantics of null parameters, at the expense of valueboxing complexity.

For a very good discussion of the forces that drove the Java to IDL mapping specification to its current state, see

http://www.iona.com/whitepapers/CORBA-EJB-Interoperability-WP-V00-02.pdf

Cheers,

Francisco

[reverbel]

> I managed to access an EJB with an CORBA 2.0 client
> successfully. I re-defined the IDL file for the
> client to marshall and demarshall the additional
> valuetype information.

There is no point in doing this. Just use IDL file that the rmic utility ("rmic -idl -noValueMethods") generates from the EJB interfaces and deal with the valueboxes that appear there. Dealing with these valueboxes might be a bit unpleasant, but is is better than twisting the actual IDL definitions.

In case you're doing the CORBA client in Java: Use idlj to translate to Java the IDL files with rmic-generated valuebox definitions, as JacORB's IDL compiler does not handle the "#pragma ID" directives these definitions contain. After you've generated your client-side stubs with idlj, you can (and should!) use jacorb.jar at runtime. The idlj-generated valuebox code and the JacORB library will work together with no problems.

Cheers,

Francisco

[flitzie]

Hi Reverbel

great thanks for your report about valuetypes and boxes, but this won't help me because I have a dynamic perl client and its orb doesn't support valuetypes. That's why I am looking for a solution accessing the EJB with the perl client. Due to the fact that you cannot create an CORBA-friendly EJB without valuetypes, the client has to marshall and demarshall the information transferd in a valuetyped binarystream. So I redefined the idls. But now I want to understand the meaning of additional information send in the binarystream during the orb communication. I want to find out chances and risks of this "workaround" for a product system.

TIA

flitzie