Sanjeev, you wrote:
> Valuetype marshaling/unmarshaling is designed to use run-time information
> about the actual type of the value object. It is not necessary
> that the concrete valuetype be specified in IDL. In your example above,
> the Enumeration/Collection in the finder's signature would probably be mapped
> to an abstract valuetype in IDL. At runtime, the concrete object
> returned by the EJB finder will be marshaled by the EJB server's
> ORB into the reply IIOP message, along with sufficient information (such
> as RepositoryId) to allow the client to determine the type of the value
> object which it needs to instantiate during unmarshaling. Obviously
> your C++ client needs to have the libraries for the value types available
> in its environment. For server-specific value types (as in this case),
> your EJB server vendor will probably need to provide the client library,
> while application-specific value type libraries would be created by
> the developer.
I see a couple of problems here. The CORBA 2.3 Java to IDL mapping states:
1.2.4 RMI/IDL Value Types
An RMI/IDL value type represents a class whose values can be moved between
systems. So rather than transmitting a reference between systems, the actual state of
the object is transmitted between systems. This requires that the receiving system
have
an analogous class that can be used to hold the received value.
Value types may be passed as arguments or results of remote methods, or as fields
within other objects that are passed remotely.
A Java class is a conforming RMI/IDL value type if the following applies:
1. The class must implement the java.io.Serializable interface, either directly
or indirectly, and must be serializable at run-time. It may serialize references to
other RMI/IDL types, including value types and remote interfaces.
There is no mention of Java interfaces here, only classes. Do you
interpret this statement to include the interfaces java.util.List
and java.util.Collection as "Java classes"?
1.3.5.3 Methods
It is not required that methods in RMI/IDL value classes be mapped into OMG IDL.
...
However, there may be cases where it is useful to map value type methods to OMG
IDL and tools may choose to support options to map methods.
I would suggest that with the current state of the Java to IDL mapping,
the IDL mapping for Java 2 collections is ambiguous, and provides no
guarantee of usable interoperability with non-Java clients. At a minimum,
the EJB-to-CORBA mapping would need to specify the precise IDL mapping for
Java collection types. There should be no ambiguity here.
> The exact runtime details might differ from language to language,
> you can get them from the relevant OMG mapping specs.
How many EJB customers are going to have the expertise required to
map Java 2 collections onto equivalent IDL, and develop libraries
so that they can access an entity bean from a non-EJB client program?
What guarantee do EJB customers have that different vendors will map
collections to the same IDL? How quickly do you think a CORBA vendor
would be able to deliver the infrastructure to enable COM/ActiveX
clients to talk to EJB components?
The EJB-to-CORBA spec needs to provide usable interoperability with
non-EJB clients, not "textbook" interoperability. I am ready and willing
to be convinced that we can achieve usable interoperability in the long term,
but I believe that this will require a lot more attention to detail than is
evident in the current EJB-to-CORBA spec, and until that has happened we
need some alternatives.
Another option worth considering in some detail is a standardized "alternative"
mapping that would not require the use of valuetypes. For example, here is some
sample IDL for an entity bean's home interface that doesn't use valuetypes
(exceptions omitted for brevity).
module com
{
module acme
{
struct AccountKey
{
...
};
interface Account
{
...
};
typedef sequence < Account > AccountList;
interface AccountHome
{
Account create();
Account findByPrimaryKey(in AccountKey key);
AccountList findAccountsInCity(in string city);
};
};
};
Note that any CORBA 2.0 client would be able to use this IDL today.
> -Sanjeev Krishnan
> Java Enterprise Technologies,
> Sun Microsystems Inc.
Can you identify the appropriate individuals within Sun who I should continue
this discussion with?
________________________________________________________________________________
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".
