On comp.object.corba, Steve Vinoski wrote:
> My advice? Don't use valuetypes. As I believe I've made clear in several
> publications on this topic, I personally despise them. They're horribly complicated
> for what little they give you. I think they're only marginally useable within
> close-knit communities of clients and servers that were developed together.
My short response to this is: I agree. Good advice.
My long response relates this issue to the EJB to CORBA mapping:
Are you aware that the EJB folks seem to think that defining an EJB-to-CORBA
mapping that maps Java serializable objects to CORBA valuetypes will magically
produce "interoperability" between CORBA clients and EJB servers? Obviously it
will provide interoperability for Java-based clients that have access to the
implementation (and thereby provide interoperability among EJB/IIOP vendors),
but I think the EJB folks are making a big mistake to assume that IIOP
interoperability of non-Java clients to EJB servers will be USABLE, or even
work at all.
Let's suppose for example you write a finder method on an EJB entity bean
that returns a java.util.List (a JDK 1.2 collection type). Now if you apply
the RMI-to-IDL mapping from OMG document 98-03-08.pdf, you will end up
having the IDL operation for the finder method returning the valuetype
that is generated from java.util.List, assuming that any can be generated
as java.util.List is an interface, not a class. (EJB methods that return
collections will frequently have an 'interface' return type, rather than
a concrete implementation such as java.util.LinkedList). The trouble
with the valuetype for java.util.List is that it has no fields! Oh well, so
our CORBA 2.3 C++ client with OBV support that just took us six months to
implement can't talk to an entity bean. Never mind! (We didn't implement this,
I am just being sarcastic).
So how could we write a legal finder method (returning a collection) for an
EJB entity bean that is accessible to a non-Java CORBA client with full
support for CORBA 2.3 OBV? We might think that the following excerpt from
the OMG RMI-to-IDL document would help:
RMI/IDL value classes that were mapped from IDL types using the IDL to Java
mapping are not mapped back to IDL. Instead, the original IDL definitions are used.
However an EJB 1.1 finder method is only allowed to return an JDK 1.1
Enumeration, or a JDK 1.2 Collection (List is one of these). We are
not allowed to have a finder method that returns an array of object
references.
So I will summarize this section by making the assertion that the EJB-to-CORBA
mapping guarantees IIOP interoperability only with Java/CORBA or EJB clients.
If Sun intends things to stay this way, they should be up front about it,
and make it clear that what they are defining is Java/IIOP interoperability.
If not, they should fix the EJB-to-CORBA mapping.
I expect that nothing will change. I have raised these issues before, in the
EJB Roundtable, to no avail. I expect that most customers, when they come around
to integrating their flash new EJB system with the outside world, will find that
it is easier to put an XML messaging or CORBA 2.2 (no OBV) front end on their
EJB application, than it is to get the promised interoperability to work.
> If you must use them, I would stick with the most simple subset of their
> functionality, otherwise you'll get into dark corners where different ORBs will
> either get things wrong, or won't support things at all.
Would you care to elaborate on the "most simple subset" you have in mind,
assuming that you weren't referring to the "empty" subset?
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
