> there should be no doubt that I'm coming from the CORBA-camp :-)
I am fully aware of your bias ;-)
> I did not misunderstand what Marc was saying in his first mail. I'd just
> like to see interoperability based on open working standards (CORBA, IIOP,
> OTS, DTP, XA) in jBoss. There is actually a world outside the EJB sphere
> with loads of "legacy " (i.e. working) systems (and wouldn't it be nice to
> use those XA-interfaces of your favorite RDBMS?).
We support XA JDBC drivers.
> It would also be nice to
> be access to access another EJB implementation (e.g. IAS) from jBoss.
You can. Just do it, since RMI/IIOP is part of the JDK. jBoss would just be
another client in this sense. And those servers should have no trouble
talking to jBoss, since we use RMI/JRMP which is part of all Java
installations.
> The EJB2.0 public draft 2 mandates IIOP-support and has transaction
> interoperability as an optional part.
For mainly political reasons, but true.
> If jBoss is going to support distributed TX at all (even if we're just
> talking about two jBoss server's in different JVMs) you'll need to come up
> with some kind of solution.
True, but it depends on what you need it for. If you simply want two jBoss
instances with different RDBM's to talk to each other, or want to use two
different RDBM's within one instance then 2PC support is required. However,
AFAIK this is already in the current TM implementation.
> I thought that neither RMI/JRMP (vendors like BEA had to hack JRMP to add
> support for TX-ctx propagation) nor SOAP/HTTP/SMTP/whatever supported
> (standardized) contexts? .
Correct, but they are not as clever as we are. ;-)
> Probably I'm wrong on this one as I have no
> RMI/JRMP experience:-)
It all depends on how clever you are. Since we have added our own wrappers
on top of JRMP there are literally no limits to what we can do.
> As for XML/HTTP I think it's not the way to go on the
> back-end side (i.e. once your inside the firewall).
I (and most of the people at the J2EE think tank I visited last week) would
tend to disagree with this. IIOP is a nice theory, but IMHO the XML/HTTP is
the best way to approach loosely coupled systems. If you look at the new
specs being created in this field, they are basically all created around the
XML/HTTP solutions.
> Not standardizing on a common on-the-wire protocol (with support for
> security and transaction context) will be a big mistake that's already
been
> done in CORBA 1.0 back in the early nineties. I guess that Rickard is
> against agreeing on a common protocol. I think if you want total freedom
> you're begging for isolation.
When this issue came up on the EJB-INTEREST list half a year ago, I asked if
an API-based solution would not be inherently better than a
wire-protocol-solution. You may be correct, but the number of *technical*
arguments raised for a wire-protocol solution in that discussion was zero
(0). I recently asked Mark Hapner (the EJB-spec guru) for any good technical
arguments for a wire-protocol solution, and he had none.
So, if you can provide me with the wisdom of the early CORBA 1.0 failures I
would be most interested. Really.
> There is no standard XML/HTTP/... protocol yet. SOAP lacks lots of
features.
> If you look at SOAP it should also be terrible slow in comparison with a
> binary protocol (like IIOP and I guess also JRMP?). I'll verify this in my
> soon to be finished performance test suite (PETS). I should just be a
matter
> of switching between ZOAP and JRMP - right?
Speed is not so relevant here. I think you fail to see that different
approaches apply on different levels of architecture. The XML/HTTP
integration is for "webservices" (=coarse-grained stateless application
services). The amount of interaction done with a webservice should be fairly
low, hence speed becomes a minor issue.
IIOP is also slow compared with JRMP. But it is not intended for the level
of application interaction as JRMP is. IIOP wants to be "the end-all
solution", i.e. use it always for all communication. But as usual this is
too rigid to really work well.
> One thing that both Ole and Rickard failed to recognize: In my scenario I
> used the term "multi" (should have written heterogeneous instead).
Whatever
> proprietary solution that you'll come up with won't do the job for me as
I'm
> seeking _interoperability_ between different implementations both on the
> client-side and on the server-side.
Yes, the heterogeneous nature of the term "multi" is very important, which
is also why IIOP is a dream and not a solution. Wanna install an ORB onto
your Palm? Don't think so...
> I think that Rickards argument that you could still use jBoss as a client
to
> a CORBA server is good. I think that this will be more common than writing
> CORBA clients against ugly RMIish IDL interfaces. However I still want to
> hear your EJB-EJB interoperability story (including support for
distributed
> TX across different vendors)...
I am not interested in writing a story that noone (/not enough) are really
interested in hearing. There are more important things to do. When/if that
changes we will see.
/Rickard
