Yo
Per Bockman wrote:
> > 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.
Correct/agree.
> > 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!).
You're correct, although I think the added value of implementation
freedom outweighs the downside. Plus, this is Java, so dynamic
classloading would work (as it does with jBoss for example).
> 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...).
Agree.
> > 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.
*That* I agree with. What we are seeing in this argument in general (and
not only this particular discussion) is definitely a "cultural clash".
Two different ways of thinking.
> However to move to the original problem: How do we allow
> transaction to executed between different EJB-servers (and possible other
> "servers"/resources).
By using an API that can be used to pass tx contexts. The API can
defined what the context should look like (maybe implementation, maybe
just interface) and some way to pass it to the underlying protocol
handler.
> > > 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).
I don't have numbers, and this is hearsay (i.e. the CORBA people I have
talked to mention numbers that are higher than what the equivalent JRMP
numbers would be). Oh, btw, yes I know there was one guy that tested
different ORB's and compared with JRMP. JRMP was about half compared
with the best ORB if I remember correctly (i.e. 3ms/call on JRMP,
6ms/call with IIOP). Might be outdated though. Again, if you do some
testing that'd be cool ("HelloWorld" + complex data passing would be
relevant I think).
> The lesson to be drawn from this: clever design makes up for a crappy
> protocol;-)
Something like that :-)
> > 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.
I don't. Just pointing out the facts here, and yes, this is a EJB-spec
screwup in my mind.
> 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.
I might just do that some fine day ;-)
> 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).
I'm sure you're right :-) What you outline above seems to map pretty
well with how the jBoss container architecture works. Guess there's only
so many ways to boil good water.
> > 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!
Alright, fair enough. :-)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
