Hey
> 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;-)
Yeah, could be ;-)
> 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?
Because it's a binary thing: either you're "in" or you're "out". With
XML/HTTP it is easier to integrate with just about anything. That's my
feeling anyway (and no, I am not an EAI expert).
> 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...
You porobably regularly use JDBC drivers to communicate with various
databases. The drivers conform to the JDBC API, and can use whatever
protocol they like (including smoke signals). Your software is both portable
and interoperable.
The same thing would work for J2EE servers: get the server "drivers" and
you're good to go. By only relying on an API for communication (just as with
JDBC) you allow for quite a lot of different ways to implement it. It could
be IIOP, JRMP, JMS-based, Jini-based, or XML/HTTP-based. Whatever you want.
This degree of freedom is not available if you rely on a wire protocol which
imposes too many unnecessary restrictions.
> 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).
As above. Valid problem, wrong solution. In the CORBA world it makes sense
because of the requirement to make N drivers for each servers (one for each
client language supported), but in the J2EE context it does not.
> How much slower is a good quality IIOP-implementation as compared with
JRMP?
Enough to make it a significant difference.
> Another issues is scalablity, e.g. when will the ditributed GC hurt you?
Depends on your server implementation. Since we don't have a lot of objects
GC is not so bad.
> 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.
But the EJB-spec doesn't. The return value of getEJBObject is undefined if
several protocols are used to interact with the same bean (i.e. What
protocol should the returned stub be able to speak? All protocols or just
one of them?). You can deploy the same bean twice with different protocols,
but that's not so nice either.
> 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).
As above. If it was possible to support several protocols simultaneously in
EJB that'd be cool. We still wouldn't be able to make any interesting
implementations since the JDK ORB is so limited currently (the JDK 1.4 one
is better since will have POA).
> 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 see. Good.
You have some good points, granted. I still don't see IIOP as the holy grail
though ;-)
regards,
Rickard
