I've been reading this thread with a fair amount of interest. While I'm
distressed at the tone the discussion has taken, I do believe that this is a
reasonable forum for discussing different vendor's implementation of the
standard. It provides EJB developers useful market information about the tools
available to them, and it provides feedback to vendors and spec creators to use
in future versions. Techies will be techies, and I expect a certain amout of
sharp language to be used in these spaces, but it would make for a more better
read if we could all keep a more civil tone.
It seems to me that there are actually two parallel issue being debated in this
thread. One is whether all container vendors should support a common wire
protocol so that containers can freely inter-operate. The second is whether
RMI/IIOP is a good protocol for a common wire protocol because of it's network
and API characteristics.
On the first I feel very strongly that containers should be able to
inter-operate at spec levels. That is, a client shouldn't need to know the
vendor of the container. It doesn't matter if the client is an Applet,
application, Servlet, JSP, EJB or a daemon process. The whole thrust of a
component standard is to permit developer's to write business logic, and permit
the deployer to select the container that offers the features that best meet the
situation. So, any vendor-specific extensions should in my mind be limited to
information read from deployment descriptors, and acted upon by the container.
If I have an EJB client that accesses beans, and if I have to re-write the
client just because I've moved the bean from one container to another, then I
think that one of those container vendors has violated the EJB design goals
(Caveat: If I decide to make use of proprietary features that require client
code, all bets are off).
Similarly, if I need to change code in a bean class because I've moved the bean
from one container to another, then a spec violation has occurred. This one is
probably even more important if a market in third-party EJBs is ever going to
develop,
The conclusion I derive from this argument is that if there isn't a common wire
protocol, I can't freely move beans around from one container to another, which
makes containers that don't support the common wire protocol useless to me,
IMHO. It doesn't forbid extensions that other containers can ignore.
Conversely, the extensions must be ignoreable.
As far as what the wire protocol should be, I'm a lot more agnostic about that.
As I read Jonathan Weedon's take on the matter IIOP permits the propagation of
transaction contexts, which simple JRMP doesn't do in a standardized manner to
my knowledge (not that is couldn't, but that there isn't an agreed-upon standard
for doing it), which would be a good thing. Keeping transaction and identity
state would be an important part of interoperability. Unfortunately, it looks
like there isn't a wire protocol that can manage that.
Usually the things that drive me up a wall however are what I call "partially
complete" implementations of a standard. That is when the salesperson first
tells you something like: "We support IIOP", and after two sales pitchy phone
calls, and an on-site visit you discover that there's some intresting quirk,
like no POA support. If no vendor pulled that one on me again, I would be
content.
my $0.02,
Matt Kleiderman
Acurion
===========================================================================
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".
