On 21 Mar 00, at 15:20, John O'Shea wrote:
> On a side note, if you are not an IIOP expert why do you feel
qualified
> to try discredit a protocol which an open consortium of 800+ of
the
> largest software and vertical industry companies in the world
defined
> and are happy with?
I've followed this debate with interest. There has been some
interesting technical discussion, but there have also been some ad
hominem arguments.
My understanding of the central issue under discussion: whether a
wire protocol or API solution to context propogation is superior.
IIOP's ability to do the job might be relevant here, but Rickard's last
post on this discussion (that I received--the listserv has been acting
up lately, I think) specifically disclaimed an attempt to discredit
IIOP:
<Rickard>
> 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.
</Rickard>
I am very interested in your arguments as to the superiority of a
protocol-based solution, and I mean that sincerely. I am not an
EJB vendor. I'm a software developer who is interested in the future
of EJB.
Your final point is more interesting to me, and probably to others
who subscribe to this list for solely for the technical discussions of
EJB-related matters. For instance:
> Can you clarify how others could interpret your contexts if you
use
> your way of putting them onto the wire and everyone else uses
theirs?
> i.e. how would another server know how to examine your
contexts?
Adherents of the API solution would need to address how another
server would know how to examine contexts. The article cited
earlier in this discussion (The End of Protocols:
http://developer.java.sun.com/developer/technicalArticles/jini/protoc
ols.html) seems to propose an answer to this. I'm no expert on
any of this...but it seems that the proposed solution involves a
downloaded java stub that presents a java interface to the client.
The stub would extract the context information from the container
in a standard way, and translate that into a format understood by
the server that provided that stub. For instance, a stub from a
CORBA-based server would extract transaction information and
translate it into the standard defined in the OTS Specification. This
would be understood by the CORBA-based server.
A stub from a server using RMI-JRMP would still extract
information from the container using a standard API, but it could
propogate the transaction in a proprietary way. This would not
effect interoperability.
But like I said, I have no reason apart from technical superiority to
root for one solution over another. I'm interested in a continuing
dialog that addresses technical issues.
-Dan
===========================================================================
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".
