Re: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])

2002-01-31 Thread Tim Hyde

I've been lurking on this list for several years, and not speaking about
things I'm not contributing to.

But Andy's comment here about EJB  J2EE goes right to the point, and
triggers my passion ...

As an architect, I've been in 5 projects in the last 2.5 years where EJBs
were on the table, and in every case but one there have been overwhelming
reasons to avoid getting involved with that kind of technology. And in the
remaining case, it was already live when I came on board but thankfully the
designer had not used Entity Beans, which made it almost tolerable.

In the last project (a major customer-care callcenter app), they had used
Entity Beans, and Websphere, and there were 500 EJBs, and 4700 distinct
application classes. It took 2 days of continuous processing just to
'deploy' the beans, and I was called in when they found they couldn't meet
adequate performance. Related, of course to the modelling of the database
through Entity Beans. I won't go into the details, but believe me there were
big problems in just about every area I looked at, not least developer
productivity with the toolsets.

My advice was unreservedly to junk both EJB and Websphere, since any
competent designer could implement a solution with about a tenth of the
complexity involved, and with no need for these opaque tools that you can't
control.

Yes, EJB is a complete bodge of a design, and RPC invocation techniques
would only be acceptable if they were completely transparent, instead of
requiring you to do so much plumbing yourself. But personally, I think RPC
is entirely overrated, and it is a mistake to try to program as though a
remote call had the same characteristics as a local one.

The Pointy Haired Management are influenced by other views of the
marketplace, of course, but they don't really make any sense if you can see
where technology like this is likely to end up in the longer term. (i.e.
replaced by something better).

The rest of J2EE ? Well, Servlets is great, JSP is just about OK, (but of
course you really wanted a templating engine). And among the rest of the
APIs, there seem to be some that are OK, but an awful lot of it is pretty
mediocre. Overall, it is Java *not* living up to its early promise.

In summary, after a couple of years wondering 'Why am I the only person to
see this ?' it's a relief to see Andy's post.

I also remember seeing Jon's comment 'WAKE UP PEOPLE' a few weeks back
(before Outlook trashed my mailbase) and though I think he is commenting on
Sun's military strategy rather than the technicalities of EJB (am I right
there ?) I do think that we need a much more public protest about the
weakness of the technologies on offer - too many companies are forcing
developers down the J2EE path. DotNet doesn't have to be the winner from
such a protest, either.

There are much better ways to do things, and at present customised solutions
win hands-down on every count except 'common culture'.

I know this is not much Jakarta related (unless Jakarta can take on J2EE
directly ?), but it does seem a very important issue in the context of
server-side Java.

How much support exists for this point of view ? Does anyone have pointers
for areas where rational discontent is brewing in a less 'humble' form ?

- Tim

- Original Message -
From: Andrew C. Oliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 31 January 2002 01:58
Subject: Re: [Fwd: cvs commit: jakarta-site2/xdocs index.xml]



 On Wed, 2002-01-30 at 19:54, Jon Scott Stevens wrote:
  on 2002.1.30 4:15 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote:
 
   My only issue and I guess this is directed more at you Jon, is it
   doesn't give me a clear idea about what we want.  Can you give me a
   good idea and I'll be glad to submit a patch to that effect.  It just
   seems like we should be asking for something and being specific.
  
   -Andy
 
  That is a very good point. However, privately, Sun knows exactly what we
  want.
 
  There is still some stuff that goes on behind the scenes around here
that
  unfortunately isn't exposed. Needless to say, discussions about opening
some
  of that up (including posting what we want to the public site) are going
on
  now.
 

 For starters:
 I think the J2EE stuff should be under at least the same license as the
 rest of the JDK.

 Personally I'm having a hard time getting particularly in uproar as I
 think the central core of J2EE - Enterprise Java Beans is such a poor
 standard, that I'm not particularly upset that its not *free*.  I should
 not say these things publicly, as I still have to work in these things,
 but in truth EJB and particularly Entity beans is a less that elegant
 kludge.

 In truth J2EE is kind of a scam.  It claims to be aiming for
 compatibility and universality but the truth is the vendors play too big
 of a role in it.  They want to have lots of room for proprietary
 extensions.  Its market one thing but actually sell another.

 I'd rather see someone come up with an opensource standard 

Re: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])

2002-01-31 Thread Santiago Gala

Andrew C. Oliver wrote:

To be fair, WebSphere is probably more troublesome then the other
containers (at least thats been my experience with it).  I do think 
there is a time and place for RPC.  I however think better support for
location independence is required. 

(snip)


I would suggest gaining experience with other containers (BEA and jBoss
for starters, you can download a trial of the former and the latter is
opensource) so that you can discriminate the problems that are exist in
WebSphere from those in EJBs as a whole.  Not because you want to just
do not-ejb but so that you don't repeat the same mistakes.

I have implemented a system using Container Managed EntityBeans that 
worked fairly well. I used Jonas (it was some time ago). It was smaller 
than the original poster example (about 20 entity classes, tens of 
thousands of instances). I spent a lot of time getting the entity design 
right. From the original description, it looks like the problems in the 
quoted project came from bad system design, more than from EJB 
technology as such.

Comments on my experience:

- The location and engine independence was a true marvel. I was 
developing with postgres/linux and deploying under MSSQLServer/NT with 
the same source code. Only small diffs in configuration needed.
- Performance was not good, but scalability was.
- Leaving transaction and persistence management to the container proved 
good at the end.
- My main issue in the development were related with using JSP for the 
interface (JSP sucks (c) Jon :) )

So, while I agree with political/licensing issues being of concern, I 
would not disqualify EJB as a whole from a technological point of view. 
YMMV.




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])

2002-01-31 Thread Steve Downey


snip

 I have implemented a system using Container Managed EntityBeans that 
 worked fairly well. I used Jonas (it was some time ago). It 
 was smaller 
 than the original poster example (about 20 entity classes, tens of 
 thousands of instances). I spent a lot of time getting the 
 entity design 
 right. From the original description, it looks like the 
 problems in the 
 quoted project came from bad system design, more than from EJB 
 technology as such.
 
 Comments on my experience:
 
 - The location and engine independence was a true marvel. I was 
 developing with postgres/linux and deploying under 
 MSSQLServer/NT with 
 the same source code. Only small diffs in configuration needed.
 - Performance was not good, but scalability was.
 - Leaving transaction and persistence management to the 
 container proved 
 good at the end.
 - My main issue in the development were related with using 
 JSP for the 
 interface (JSP sucks (c) Jon :) )
 
 So, while I agree with political/licensing issues being of concern, I 
 would not disqualify EJB as a whole from a technological 
 point of view. 
 YMMV.
 

My experience with Distributed Object Systems goes back to early CORBA and
DCOM. I've seen about as many failures in just about every distributed
system, regardless of technology flavour. EJB is just the latest, and as
seems usual in our industry, lots of people are coming in, treating it as
green field development, and are making the same mistakes.

Mostly, they ignore that the choice of making a system distributed is
fundamental. You can not take an Object Model and arbitrarily cleave it and
produce a good Distributed Object Model. The worst case of this I ever saw
was a system that had String as a CORBA object. 

EJB also brings to the table all of the problems of the Object/Relational
impedance mismatch. It's an empirical fact at this point that rows in a
table are bad objects. They're data, and have no behavior. Turning them into
objects with container managed persistence doesn't make them good objects.
Objects are composed out of many rows spanning several tables. That's hard
to do with CMP.

Just my $0.02.

This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]