> 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.
I'm not following you. Your second sentence above says that choosing
IIOP as wire-protocol is the way to do server interop. Your third
sentence says that using an API for extracting this info would be good
(as I have been proposing since the beginning). And your fourth sentence
says that, hey, SOAP supports this, cool. But number 4 and number 2 are
direct contradictions. What is your standpoint: 1 or several
wire-protocols?
> 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.
Again, I have no idea what you're talking about. What is "RMI-RMI" and
what is "IIOP-IIOP"? I have never seen this use of these terms before.
<click/>
Ok, now I am beginning to understand what you're trying to say. You're
describing what's on the two endpoints. I believe you have missed an
important point. To begin with, you should read the Jini article which
explains how the sending point gets the wire-protocol implementation
from the receiver. Once you have done that it should be clear what I am
proposing. If it's not here we go:
* Server A has a Bean Foo which wants to talk to Bean Bar in Server B.
* Case 1: B does not support dynamic downloading of classes to client (a
la RMI/JRMP) -> Client classes for Server B are preinstalled on Server A
Case 2: B supports dynamic downloading of classes to client (a la
RMI/JRMP) - > no pre-installation of classes on Server A
* Bean Foo looks up Bean Bar. It receives stubs whose implementation is
done by Server B.
* Bean Foo calls a method on Bean Bar stub. The stub extracts context
information using a known API, and forwards the call to Bar in Server B,
using a custom wire-protocol not known to Server A other than the fact
that it has Server B's classes installed/downloaded.
This is how I want to support server interoperability. Maximum
flexibility. Any A can support any B using any wire-protocol.
> 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.
Well, RMI/JRMP actually supports implicit context information as of
JDK1.2. However, the API is not open yet (see
sun.rmi.server.UnicastRef/UnicastServerRef), so any use of it would be
proprietary. I explain how this could be used in this article:
http://www.dreambean.com/articles.html -> "Contextual parameters in RMI"
> 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.
The stubs is an implementation. Defining an API which the stubs (ANY
stubs) could use to extract information, would be 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.
You're doing the same mistake as Inprise: not seeing the forest for all
the trees. There's no need for a wire-protocol. You only need an API to
get the information.
/Rickard, we're getting there :-)
--
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".
