hi,
the "subject line" is getting out of date... I don't think that anyone is
suggesting IIOP-support as a TODO for the FINAL PROD-release.
> > 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).
"a binary thing" - that's fun. At the end of the day I guess that
everything's zeros and ones:-) I agree that it might be easier to do stuff
with a text based protocol. I guess that the main thing here is that you
don't rely on a particular object model in for instance SOAP.
> > 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.
Portable - yes ; interoperable - no. I will explicitly have to swap drivers
when I want to speak to another DB vendor. I'm ignoring JDBC-ODBC and other
simular solutions (ODBC would have allowed me to move the problem to the
ODBC-part of the control panel...). This doesn't mean that I dislike the way
Java deals with DB-drivers (in general the API and SPI stuff makes a lot of
sense!).
> 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.
Ehhmmmm, my call to the API will have to travel through the right stacks
(protocol). However I agree that you should not be locked into ONE protocol
(it is obviously not possible to use the same protocol for all existing and
to be existing transports, e.g. TCP/IP, UDP, my-home-brewed-stuff...).
> > 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.
I don't like the "Java-only" stuff. It's obvious that to cultures are
colliding. However to move to the original problem: How do we allow
transaction to executed between different EJB-servers (and possible other
"servers"/resources).
> > How much slower is a good quality IIOP-implementation as
> compared with
> JRMP?
>
> Enough to make it a significant difference.
Numbers please, i.e. is IIOP even 25% slower than JRMP or is it 10+ times
slower (as SOAP)? If you don't give some rough numbers I'll set up a simple
test (I've been busy programming PowerPoint lately).
> > 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.
>
The lesson to be drawn from this: clever design makes up for a crappy
protocol;-)
> > 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.
>
You can't really blame IIOP (or the OMG) for a SUN spec. BTW, a standard
CORBA object reference (an IOR - Interoperable Object Reference) has support
for multiple profiles each of which can support different protocols. Kinda
neat isn't it? Take a look at chapter 15(?) in the CORBA spec.
> > Some examples: IONA:s 2.x and 3.x ORB:s speaks
> > both IIOP and a proprietary 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).
If you want interoperability you have to agree on some protocol(s). Today
there is at least one choice - IIOP. SOAP isn't finished and it lacks built
in support for standard context and you still have to agree on a way sending
SOAP-messages (e.g. SMTP, HTTP, ...). I have only looked at the apache
implementation of SOAP and from what I can see It exposes loads of stuff in
the API that I'm not used to see or tell my favorite ORB: (target object
location, building argument lists explicitly having to check error code, no
compile time type checking etc..). I like the idea that once I have an
Object Reference I can call methods you it just as a normal Smalltalk
message, C++ virtual function or a Java method (i.e. hide the ugly stuff
from me).
The POA rocks! Implementing stuff like object pools and evictors is really a
piece of cake. You'd probably also want to look at Portable Interceptors (in
which you for instance could do all your fancy TX-ctx and security checks).
The PSS is also kinda cool as is TII (built in store-and-forward messaging).
[blah blah]
> You have some good points, granted. I still don't see IIOP as
> the holy grail
> though ;-)
Wow, I totally agree! Holy grails are really nothing to me as I'm not a
religious person. Just as I don't see XML as a holy grail I don't believe
that there should be IIOP-everywhere(tm). I think that IIOP can be really
useful once inside the firewall (most firewalls don't have an IIOP port and
many firewalls only allow traffic on port 80 with the HTTP protocol - as a
side note - yes I have tunneled IIOP through firewalls). I believe in
SOAPish protocol on the Net and binary, efficient, language neutral
protocols for application integration inside the FW. That all for now folks!
Regards,
Per
