On the contrary. My argument is that passing context the way IIOP does
it, is the way to go. I really like the way an OTS service plugs into
the ORB, does the context propagation, checks it on input and output,
etc. From my understanding of SOAP, it supports this model.
With regards to RMI, I would like RMI to include context propagation in
a similar manner, so RMI becomes a preferred wire-protocol for RMI-RMI,
IIOP the preferred wire-protocol for IIOP-IIOP, and anything else you
want to use works pretty much the same.
When I refer to RMI I refer to RMI/JRMP and I think the missing piece is
in the wire protocol, not in the stubs. JRMP should allow you to add
additional context propagations across the wire, allowing an RMI client
to interact with EJB without client transactions, or a future RMI to add
more context propagations.
I know the design you guys have (and BEA, and as you know we share it)
for putting all the smarts in the stub. But I consider that to be an
implementation detail, not a design.
Even if we can support your proposal out of the box (in fact, that's
what we do today with RMI), I consider it an implementation detail. And
I do not believe an interoperability spec should address that through
relying on a certain way to implement RMI, even if it superior. It
should rely on adding missing functionality to the wire protocol.
arkin
"Rickard �berg" wrote:
>
> > I don't see how IIOP prevents one from using SOAP, nor do I see how
> > enabling two different severs from two different vendors to talk IIOP
> > (or IIOP over HTTP) prevent them from also talking SOAP, nor do I see
> > how it prevents all of these from also doing RMI.
> >
> > I agree that RMI works better, and should definitely be supported, I
> > just don't see why RMI is the only way to do things, and why we have to
> > structure EJB so it only works with RMI.
> >
> > Since RMI does not, at the moment, enable interoperability, supporting
> > IIOP for that makes a lot of sense. Corret me if I'm wrong.
>
> (since I'm replying I think you can guess my next statement ;-)
>
> You're wrong. If different servers from different vendors using
> different protocols are to be interoperable (i.e. being able to properly
> transfer implicit context between servers), it would require an API
> which the stubs could use to extract this implicit context information
> from. Defining this API is my proposal, and BEA's, on how to support
> server interop. in EJB.
>
> Also, when you say ".. so it only works with RMI" you are technically
> making a rather confusing statement. You are probably referring to "RMI
> using JRMP as wire protocol". RMI != RMI/JRMP. RMI is an interface, of
> which RMI/IIOP, RMI/JRMP, RMI/SOAP, RMI/T3 are different
> implementations. Specification and implementation. Just as everything
> else in this wonderful world of Java. EJB relies on RMI (see EJB1.1
> specification, ch 13 "Support for distribution"). This does not say that
> it relies on RMI/JRMP.
>
> However, what you and Inprise et al, are saying is that we must restrict
> it to only use RMI/IIOP as wire-protocol in order to support server
> interoperability. What I am saying is that this is not a good solution.
> My previous posts have shown a better alternative, and also highlighted
> by example why choosing a wire-protocol would be a bad idea. IMHO, I
> have provided very strong arguments for my case. I have yet to see any
> arguments on why choosing a wire-protocol is a better solution. I have
> seen some attempts at showing why IIOP is good. Which is irrelevant. It
> is, currently, not the issue.
>
> I hereby invite you to provide arguments against an API-solution, and
> for a wire-protocol solution.
>
> /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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
