C++ IIOP client implications

Question

I have some general questions regarding a C++ CORBA iiop client to WLS6.1
(using any orb, but in particular using the tux orb):
What are the implications of a CORBA C++ client to EJBs hosted on WLS. What
particular limitations exist (theoretical or practical) in terms of
parameter types for method invocations - in particular non-primitive
parameters?
To clarify:
Largely, OBV in a C++/EJB environment means that you have to provide a C++
implementation of any OBV classes that are passed to, or returned from, an
EJB interface (as well as the standard interfaces/exceptions, etc).
In a java-java environment, it is perfectly normal that you would want to
pass some Bulk Accessor (or Value Object - dont like that name). These could
be of the form of HashMaps or ArrayLists etc, or may be a simple struct-like
class. There may even be more complicated classes with embedded logic - but
we will ignore these for the time being.
My questions are:
1) How do we write simple struct-like classes - what rules do we need to
follow? Are there interfaces to implement that would take advantage of CORBA
marshalling instead of object serialisation (interesting, but not that
important)?
2) Do we need to provide our own C++ implementations of standard containers
as HashMap or ArrayList? Do BEA provide a library of such "standard" class
implementations?
3) If the interface returns an ArrayList (or any Collection class) of custom
Data Objects, ala:
public List getLoadsOfStuff() {
ArrayList stuff = new ArrayList();
stuff.add(new MyBulkAccessor("milk", "biscuits", 12));
return stuff;
how is the ejbc tool aware that there is a class "MyBulkAccessor" that
requires IDL generated? (this also has implications in a java-java world
when using ejbc's client-jar generation)
4) Are there C++ implementations of other javax classes such as the
javax.ejb.Handle etc? Do developers need to provide implementations of these
objects?
Thanks.
Nick

Answer 1

Cheers, Thanks.
"Andy Piper" <[email protected]> wrote in message
news:[email protected]...
"Nick Minutello" <[email protected]>
writes:
>
I have some general questions regarding a C++ CORBA iiop client toWLS6.1
(using any orb, but in particular using the tux orb):
What are the implications of a CORBA C++ client to EJBs hosted on WLS.What
particular limitations exist (theoretical or practical) in terms of
parameter types for method invocations - in particular non-primitive
parameters?
To clarify:
Largely, OBV in a C++/EJB environment means that you have to provide aC++
implementation of any OBV classes that are passed to, or returned from,an
EJB interface (as well as the standard interfaces/exceptions, etc).
In a java-java environment, it is perfectly normal that you would wantto
pass some Bulk Accessor (or Value Object - dont like that name). Thesecould
be of the form of HashMaps or ArrayLists etc, or may be a simplestruct-like
class. There may even be more complicated classes with embedded logic -but
we will ignore these for the time being.There are virtually no physical limitations to the passing of
valuetypes to and from WLS from a C++ client. The limitations are
more, as you have noticed, the complexity of the implementation. The
only real limitation is where objects have names that cannot be
disambiguated using the mangling rules of the Java to IDL spec. This
generally only happens if you design things to break these rules
(i.e. almost never).
In terms of the complexity issue, the real problem is custom
valuetypes. Objects that generate stanadard valuetypes (and that means
things that are simply serializable) are reasonably easy to manipulate
and moreover Tuxedo will generate default implementations for these
using the -i flag. This is another advantage in using the Tuxedo C++
client orb rather than Visibroker, say. The generated default
implementations are usually sufficient for most uses. Note also that
WLS does not generate functions for valuetypes, we only spit out the
data. There are good reasons for doing this, but a side effect is that
the implementation of valuetypes in C++ is made much easier. If you
look in the iiop examples in WLS 6.1 you will see that we have also
demonstrated how to extend a valuetype implementation with
functionality that makes it look like its java counterpart.
But back to custom valuetypes. Java objects that have custom
marshalling (i.e. define writeObject or are externalizable), require
custom valuetype implementations in C++. This makes the C++
implementation much more complex since you have to write the
marshalling code for the valuetype implementations yourself. In the
WLS examples the iiop entity example shows this for ArrayList. On the
plus side you only have to do this once, so you could build up a
library of custom marshaled valuetype implementations. On the minus
side, there is no guarantee that the Java marshaling will not change
(as it did for ArrayList between JDK 1.30 and JDK 1.3.1).
My questions are:
1) How do we write simple struct-like classes - what rules do we need to
follow? Are there interfaces to implement that would take advantage of
CORBA
marshalling instead of object serialisation (interesting, but not that
important)?My advice would be to make sure the java objects you use are simply
serializable, i.e. avoid the custom marshalling problem. Then add any
helper functions you require in the C++ implementation.
2) Do we need to provide our own C++ implementations of standard
containers
as HashMap or ArrayList? Do BEA provide a library of such "standard"class
implementations?You would if you wanted to use these data items. We do not provide
standard implementations of these - although there is an example for
ArrayList in the iiop examples.
3) If the interface returns an ArrayList (or any Collection class) of
custom
Data Objects, ala:
public List getLoadsOfStuff() {
ArrayList stuff = new ArrayList();
stuff.add(new MyBulkAccessor("milk", "biscuits", 12));
return stuff;
how is the ejbc tool aware that there is a class "MyBulkAccessor" that
requires IDL generated? (this also has implications in a java-java world
when using ejbc's client-jar generation)ejbc is not aware. We have modified rmic to allow generation of IDL
for all java classes. So in this case you would have to do:
rmic -idl java.util.ArrayList
to make sure you had the appropriate IDL.
4) Are there C++ implementations of other javax classes such as the
javax.ejb.Handle etc? Do developers need to provide implementations of
these
objects?We haven't provided any implementations of these. We have, however, in
6.1 tried to make sure that the common java types used by EJBs are
simply serializable (including handles and enumerations) so that they
are at least useable from C++.
andy