the argument continues... I think that I'm missing something. Well I'm a
jBoss newbie so that would not be to surprising would it;-)
[blah blah]
> > 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. ;-)
>
Well - jBoss looks great;-)
[blah blah]
> > 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.
Why is everyone so hot on XML/HTTP? Even the OMG is moving towards XML for
instance with a RPF for CORBA/SOAP Interworking (doc no: orbos/00-09-07)
just issued...
What do you mean by "nice theory"? It seems to imply that IIOP shouldn't be
used to integrate systems. How come?
> > 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.
An API-based solution won't give me _interoperability_. Here is where I'm
totaly lost. If I want to send a message from jBoss to IAS there must be a
common protocol - how else would it work? An API would not help. To me API
would mean portability whereas PROTOCOL would mean interoperablity - so to
speak...
> So, if you can provide me with the wisdom of the early CORBA
> 1.0 failures I
> would be most interested. Really.
>
See previous comment. With no common protocol different implementations
could not speak to each other. If there had been a common protocol from
version 1 I guess that the CORBA market would have grown quicker and that we
have had better quality of the current IIOP-implementations (newer versions
of the major ORB:s are quite good by now but the first ones where kinda
crappy).
> > 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.
How much slower is a good quality IIOP-implementation as compared with JRMP?
Another issues is scalablity, e.g. when will the ditributed GC hurt you?
I don't think that IIOP is (or is meant to be) the only solution. It doesn't
have to be one solution (protocol). Yes, the CORBA spec mandates
IIOP-support but it leave the ground open for other protocols simultaneously
being supported by an ORB. Some examples: IONA:s 2.x and 3.x ORB:s speaks
both IIOP and a properitory protocol named POOP... IONA:s Orbix 2000
supports IIOP, SOAP, multicast and also has a plug-in api so that you can
swap protocols). And if you think about it IIOP which is based on something
called GIOP makes certain assumpions about the transport layer, e.g. that
it's connection oriented, so it's pretty obvios that it can't be IIOP
everywhere (IIOP BTW is GIOP for TCP/IP).
> > 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...
We seem to be talking about different things. Being able to speak IIOP from
my Palm does not imply that I have to install an ORB in it. The actually
protocol implemenation will fit in just a few KB:s (if memory is an issue -
of course if you wan't to be able to receive large blocks of data the
marshalling buffer might be a problem...).
> > 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.
