"Jonathan K. Weedon" wrote:
>
> Why application server interoperability
> should be based on smoke signals
>
> ...
Jonathan,
While I am in general agreement that interoperability based on IIOP is a good
thing, I note that in your test program you are checking for the correct
propagation of 'null' values. For this to work with IIOP, you have to adhere
strictly to the Java to IDL mapping using valuetypes. As documents from your
own web site show, this itself causes interoperability problems with external
ORB clients that don't support IDL valuetypes. This is not a small problem, no
matter how hard anyone tries to trivialise it!
I would have dearly loved to see a specification from Sun (or the OMG) of an
alternate Java to IDL mapping that doesn't require the use of valuetypes. In
particular, this alternative mapping would make use of IDL sequence and struct
types in place of collection and value types. For example, check out this EJB
home interface (for an entity bean) mapped to IDL:
module Bank
{
interface Account;
interface AccountHome;
exception MinimumBalanceException
{
string message;
};
struct AccountKey
{
int value;
};
struct CustomerKey
{
int value;
};
interface Account
{
void remove
(
)
raises (::CtsComponents::RemoveException);
AccountKey getPrimaryKey
(
);
void deposit
(
in double amount
);
void withdraw
(
in double amount
)
raises (::Bank::MinimumBalanceException);
double getBalance
(
);
double getMinimumBalance
(
);
void setMinimumBalance
(
in double amount
);
};
typedef sequence < Account > AccountList;
interface AccountHome
{
Account create
(
in AccountKey accountKey,
in CustomerKey customerKey
)
raises (::CtsComponents::CreateException);
Account findByPrimaryKey
(
in AccountKey primaryKey
)
raises (::CtsComponents::FinderException);
::Bank::AccountList findByCustomer
(
in CustomerKey customerKey
)
raises (::CtsComponents::FinderException);
};
};
In this example, the CtsComponents module contains ordinary IDL types for
the EJB standard application exceptions.
Using IDL like this, I can get Orbix/COBOL on the mainframe to talk directly
to EJBs without writing any EJB->CORBA wrapper objects. Are you prepared to
tell me that this kind of interoperability is less important than following
the RMI/IIOP spec to the letter? Do you perhaps think that we need a valuetype
mapping for COBOL and that everything will then be fine? Has anyone written
a COBOL implementation of the valuetype operations that correspond to the
Java 2 collection types?
Also, slightly off-topic, I am curious to see how EJB vendors who claim to
support RMI/IIOP support marshalling of the Java classes generated from IDL
struct/union types. Of course since these types are serializable they are
legal RMI/IIOP value types, but since the CDR syntax for struct/union types
does not permit null values, any implementation that preserves null values
passed for such types would be non-compliant.
And what would be the correct RMI/IIOP mapping for a Java array of the
following class that was generated from an IDL struct type? Would it be a
valuetype containing a sequence or just a sequence?
public final class Date implements org.omg.CORBA.portable.IDLEntity
{
public double dateValue;
public Date()
{
}
public Date
(double dateValue)
{
this.dateValue = dateValue;
}
}
A note for those who don't know already, org.omg.CORBA.portable.IDLEntity
extends java.io.Serializable.
In summary, I would say that even if we can agree on interoperability using
IIOP, that doesn't even begin to answer all the questions.
By the way, if anyone is interested in working with me on defining some kind of
standard Java/IDL mapping that doesn't use valuetypes, let me know. I suspect
however that most vendors are too locked up in the hype of RMI/IIOP to be
truly interested in having usable standards-based interoperability for EJB.
________________________________________________________________________________
Evan Ireland Sybase EAServer 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".
