let me chime in...
I predict the doom of EJB.
yes.
(Ok, past the boom effect). I was following a discussion on "why EJB" on
javalobby. Whereas the discussions mostly sucked, I found a interesting
common thread to most people. The feeling that 2 tier solutions (jsp+jdbc)
is "good enough" for most problems. Me? I agree.
The main value in EJB is the persistence, the real CMP that I like to talk
about so much, the one where "some day" (tm) people will ask what is a
schema, what is a DBA. For that to happen we need a real VB component model
on the server. We are building the infrastructure we still miss the tools
to make the assembly of components simple enough for consultants to just
snap together applications (a la VB or SAP's ABAP).
I look at the "spec requirement" from SUN and the big emphasis on on the
wire portability is "IN MY MIND" a lower priority than making the j2ee
stacks pervasive in tools. I believe the future of j2ee will be in
integrated stacks (such as jsp/tomcat + jboss for database automated
persistence). EJB2.0 is a step in the right direction (good intentions) but
still WAY to complex for the average users. I feel the step being
negociated is going the "corba" complexity way as opposed to the "VB
simplicity" way. you know my feelings on "ease of use" in this new world.
If the j2ee stacks are integrated then the "distribution" aspect of it is
almost secondary, in fact it is OUT of the picture, completely since you
exist under stacks that take the distribution. This is where the HTTP stuff
comes in, the fact is that I trust more my apache server to thread request
on the web and then present a "application" interface that is clean
(html/XML ;-) than "distributed applications" talking RMI/IIOP on
distributed container. Yes these applications exist, at least in theory,
but it smells like "Corba spirit" to me, i.e. they dream and and they dream
and ... they dream....
in short this is not a rant about RMI/IIOP, it is more a belief that web
application in their first primitive incarnation are going to exist in
3-tier with EJB, with an EJB container EMBEDDED (like what we do with
Tomcat/Resin) than standalone replacement of Corba stuff. It is a matter of
priority perhaps? To me the focus on anything else than "let's make EJB
transactional persistence the real value add of J2EE" is dangerous.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ole Husgaard
> Sent: Friday, September 29, 2000 5:41 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] TODOS for FINAL
>
>
> Rickard Oberg wrote:
> > The IIOP support in EJB 2.0 does not mandate distributed tx's.
> And having
> > talked in person to da man last week (Mark Hapner) I can tell
> you that not
> > even he sees that as a big priority: application integration is going to
> > happen through XML/HTTP, not IIOP. And I and Marc agree with that
> > conclusion.
>
> Sorry, I do not agree.
> While XML/HTTP will probably be used heavily for the frontend of systems,
> IIOP is already a standard for communication between servers. Almost all
> EJB vendors support it today. With XML your data is substantially larger
> in size and this means higher transfer latency. Thus, I find it very
> unlikely that vendors will throw away IIOP for XML/HTTP.
>
> > > I guess that the bottom line is that I think that IIOP-support is more
> > > important than support for distributed TX and that
> distributed TX could
> > > (should) be implemented over IIOP/CORBA OTS:-)
> >
> > Why is IIOP-support important? Do you have C or COBOL clients
> that you want
> > to communicate with jBoss?
>
> IIOP is the defacto standard for interoperability between EJB
> servers, even if jBoss does not support it.
> With IIOP you can create clients and servers in C, C++, Java, COBOL
> and Smalltalk. This means that if you find out that some service
> is too slow you can rewrite it in C++ without having to update your
> clients.
> And there is a lot of IIOP-based software around. For example,
> if we did not care about RMI, we could use an IIOP-based OTS
> implementation written in C++.
>
>
> Best Regards,
>
> Ole Husgaard.
>
>
