> > 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. ;-)


<no-more-mr-nice-guy>

hear, hear, f*ck em them still don't get the dynamic proxy beauty and that
was a f99king year ago...geeez us cry---set

fack m

</no0more0nomore-mr nice guy>

grumble

marc

>
> > 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
>
>
>
>


Reply via email to