> 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.
Absolutely. Have I shouted? If so, I apologize. That is never ever my
intent. It is pointless to do so I think.
> Let me be clear:
>
> 1) Context propagation is part of the GIOP specification, of which
> IIOP is the TCP mapping. Context propagation is defined.
Correct, but irrelevant.
> 2) The contents of a security context have not been defined for
> EJB.
Correct, but irrelevant.
> 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.
I believe you are missing the point. I am not arguing whether IIOP is a
bad protocol or not. In fact, even if everything worked perfectly with
IIOP, i.e. security context propagation was defined and all that, I
think it would be a mistake to use it. IIOP as such is irrelevant in the
case I am making.
What I am opposed to is the general approach to the problem. The problem
is how to do multi-vendor server interoperability. As I have, in great
detail, explained there are (at least) two possible solutions. One is to
choose a wire-protocol. One is to choose an API-based solution. The case
I made was that regardless of the wire-protocol chosen, it is a worse
solution than the second one. I have clearly explained why I think so,
and will not re-iterate.
If I wanted to be offensive (which I don't) I could now argue that you
have decided to not listen to what I say, because your replies clearly
evade the issue. Your replies focus entirely on IIOP, and its merit as a
wire-protocol. You have not commented on the merit of the two different
approaches to server interoperability. Until you do so, your praise of
IIOP is somewhat irrelevant. If we, for some reason, come to the
conclusion that choosing a wire-protocol is indeed the way to go, then,
but only then, should we discuss how to fix IIOP to solve the problem at
hand.
In my humble opinion, it seems you have been looking at the problem for
too long, and can't see the forest for all the trees. You would do well
to step back a bit and reconsider the new landscape. In my opinion, you
are thinking in ways of CORBA and inter-platform interoperability. This
is not the case here, as the platform is only one, namely J2EE. It seems
you consider the new landscape to be the same as the old one. It is not.
It is new, and have new opportunities, which we should embrace in order
to enhance EJB, and its usage, as much as possible.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
