Rickard,
First, let me agree with others on one point: we should try to
discuss these issues with some decorum; there is not reason to
shout.
> > > * RMI/IIOP has technical and historical problems in the sense that
> > > context propagation is not fully defined yet in that particular
> > > technology, or the subset specification IIOP which it relies upon.
> >
> > Sorry, but this is false. The OMG's GIOP specification (of which,
> > IIOP is the TCP mapping) defines how contexts are propagated. The
> > OMG's OTS specification defines how transaction contexts are
> > propagated (using the underlying GIOP mechanism). The only real
> > issue is that there is no agreement as to how the Security
> > Principal is propagated, since this is a currently a Java-ism.
>
> You're contradicting yourself. First you say that I'm wrong when I say
> that context propagation is not fully defined, and then you say I'm
> right because security context propagation is not yet defined. What's it
> gonna be? From your description my statement is still true. I'm not an
> IIOP expert though, so I might be missing something here.
Let me be clear:
1) Context propagation is part of the GIOP specification, of which
IIOP is the TCP mapping. Context propagation is defined.
2) The contents of a security context have not been defined for
EJB.
The first statement is saying that there is a well-defined bucket
into which we can put contexts. The second statement is saying
that no one has standardized on what to put into the bucket, in
order to support the EJB security model, yet. So, let's go ahead
and standardize on the contents of the bucket, and move on!
If you look back at the history of RMI, early on it was not possible
to support RMI over IIOP, due to the limitations of IDL data types.
To address this limitation, we, Sun and IBM authored a specification
whereby we extended IDL to support more complex data types, which are
now a superset of the Java data types. Now, it is possible to have
RMI running over IIOP. This work was done specifically to allow
EJBs to be able to interoperate using IIOP.
It seems a little silly, to me, now that we have done 99% of the
work required to support EJB over IIOP, to say: "nobody has defined
the security context, so RMI-over-IIOP is broken." Instead, let's
define this last 1%, and move on.
Regarding the rest of you post, the basic argument is: "I'm not
saying that IIOP is bad, I'm just saying it's not good enough."
I am not trying to show that IIOP is better than anything else.
Nor am I trying to convince you to implement your product over
IIOP. I am simply stating that RMI-over-IIOP provides 99% of
what is needed to provide interoperability for EJB, and if
customers want interoperability (and the ones we talk to do),
then it is the right way to go.
Much better to finish a 99% solution that is based on a known,
proven technology than to start over from scratch.
-jkw
===========================================================================
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".
