RE: [OT] RE: J2EE considered harmful

[Fernandez Martinez, Alejandro]

Hi Tim!

This is good news indeed: someone took the time to actually read a message
and respond to it, instead of sending 100's of nonsensical one-liners  ;)

Answer inline.

> -Mensaje original-
> De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> Hi Alex,
> 
> You ask why I think it's important to distinguish between the
> characteristics of a remote call and a local one.
> 
> One of the nicest things on this topic I found is a paper from Sun
> themselves -
> http://research.sun.com/technical-reports/1994/sml1_tr-94-29.pdf

Having just browsed over the document, it seems a bit (quite logically) out
of date. Nowadays, if you are running a web application, your users are used
to big delays and latencies, and so putting up with a few more milliseconds
will not bother them.

> From the date, I would think that Sun were in the initial 
> stages of thinking
> about how to do remote calls in java, and RMI was probably in 
> the gestation
> stage (anyone knowing the dates of all that better, please 
> correct me !).
> And I imagine that this paper, which is about the characteristics of
> distributed computing, and which makes a case for *not* trying to make
> remote calls transparent, was on the losing side of the argument. My
> suspicion is that it was marketing thinking that actually 
> pushed the remote
> model to where it is today.

As a matter of fact, NeXT had been doing remote proxies for a few years:
NeXT Computer, Inc. NeXTSTEP Object-Oriented Programming and the Objective C
Language, Release 3. Reading, Mass: Addison-Wesley, 1993.

The remote model was moving at full speed at the time.

> It's a while since I read the paper, and I remember feeling 
> it didn't go
> quite far enough: my own thoughts are that when you ask a 
> remote machine to
> do something, you don't necessarily want to suspend your 
> thread till it
> completes, and when the remote machine responds, it doesn't 
> necessarily want
> to have completed all the work involved in your request, nor 
> does it want to
> be restricted to responding just once, or with only a single 
> value. And it
> might want to queue your request up if it's busy. And if it 
> doesn't have the
> resources it needs to do what you asked, it might want to 
> tell you about
> different situations in different ways, without wanting to throw an
> Exception. Sort of subtler than a local call.

Most of this can be done if you use asynchronous messaging wisely, and do
synchronous calls only when necessary -- appropriate.

You can either expect just one result or a number of them; and you may
require an answer immediately or not. The mechanics of remote communication
might be something like this:

1 immediate answer: sync
1 delayed answer: async
n immediate answers: async
n delayed answers: async

Of course, asynchronous messaging introduces a host of new problems, but
they should be easier to deal with than having to code remote calls by hand.

> If you wanted that kind of subtlety locally, you'd at least 
> be able to widen
> the interface with some shared  memory/shared object 
> communication or even
> cheap additional calls. Remotely, every communication is expensive.

My book says: first make it work, then make it easy, finally make it cheap.

> Having the ability for free-running intelligent applications 
> to communicate
> by sending messages was always a simple and powerful 
> technique in many of
> the inter-machine situations I've programmed (long before the 
> WWW or CORBA
> or RMI was around), and RPC feels like a completely 
> unjustified restriction.

I take it that by RPC you mean the request-response thing?

> And I'd suspect the OMG as the hidden source of a lot of the twisted
> thinking that forced it on us ... a dream, that many bought into, that
> 'Objects' were the answer to everything, and a theory that 
> the only thing
> you can do to an object is invoke it, and another theory that 
> the object
> inside a program is the same as an object in another 
> continent, and they
> should all look the same and etcetera etcetera.

On the surface, they all look like reasonable ideas.

> Well, everything's an object, isn't it ? Kiss my object !

I seem to detect some hostility in this last part  :)

> - Tim
> 

Un saludo,

Alex.

Re: [OT] RE: J2EE considered harmful

[Tim Hyde]

Hi Alex,

You ask why I think it's important to distinguish between the
characteristics of a remote call and a local one.

One of the nicest things on this topic I found is a paper from Sun
themselves -
http://research.sun.com/technical-reports/1994/sml1_tr-94-29.pdf

>From the date, I would think that Sun were in the initial stages of thinking
about how to do remote calls in java, and RMI was probably in the gestation
stage (anyone knowing the dates of all that better, please correct me !).
And I imagine that this paper, which is about the characteristics of
distributed computing, and which makes a case for *not* trying to make
remote calls transparent, was on the losing side of the argument. My
suspicion is that it was marketing thinking that actually pushed the remote
model to where it is today.

It's a while since I read the paper, and I remember feeling it didn't go
quite far enough: my own thoughts are that when you ask a remote machine to
do something, you don't necessarily want to suspend your thread till it
completes, and when the remote machine responds, it doesn't necessarily want
to have completed all the work involved in your request, nor does it want to
be restricted to responding just once, or with only a single value. And it
might want to queue your request up if it's busy. And if it doesn't have the
resources it needs to do what you asked, it might want to tell you about
different situations in different ways, without wanting to throw an
Exception. Sort of subtler than a local call.

If you wanted that kind of subtlety locally, you'd at least be able to widen
the interface with some shared  memory/shared object communication or even
cheap additional calls. Remotely, every communication is expensive.

Having the ability for free-running intelligent applications to communicate
by sending messages was always a simple and powerful technique in many of
the inter-machine situations I've programmed (long before the WWW or CORBA
or RMI was around), and RPC feels like a completely unjustified restriction.

And I'd suspect the OMG as the hidden source of a lot of the twisted
thinking that forced it on us ... a dream, that many bought into, that
'Objects' were the answer to everything, and a theory that the only thing
you can do to an object is invoke it, and another theory that the object
inside a program is the same as an object in another continent, and they
should all look the same and etcetera etcetera.

Well, everything's an object, isn't it ? Kiss my object !

- Tim


- Original Message -
From: Fernandez Martinez, Alejandro <[EMAIL PROTECTED]>
To: 'Jakarta General List' <[EMAIL PROTECTED]>
Sent: 31 January 2002 12:49
Subject: [OT] RE: J2EE considered harmful


>
> Hi Tim.
>
> I agree with your point of view, we've been trying to avoid EJBs as much
as
> possible. But there's one thing I don't understand.
>
> > -Mensaje original-
> > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > 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.
>
> Why is it a mistake? I think a remote proxy is a great way to make remote
> calls, shielding the developer from the complexity of it all. The recent
> discussion about AltRMI has shown that there's a lot of interest in using
> proxies, but it was Sun's implementation (the Remote* stuff) that was
> flawed.
>
> Un saludo,
>
> Alex.
>




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

Re: [OT] RE: J2EE considered harmful

[James Strachan]

I agree Jeff; though for such a smart container to work in an elegant way
I'd prefer to develop the beans in a non-distributed manner and the smart
container do the rest - distributing what it thinks makes sense - along the
EOB / AltRMI lines. Not code to a server side componet API like EJB.

Though it seems EJB is going along the 'assume everythings remote and we'll
try optimise when things are local'. So maybe there's some sense in that.

James

- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> From: Steve Downey [mailto:[EMAIL PROTECTED]]
>
> Most objects don't work if they are made distributed without careful
> consideration.

I wonder if that has to be the case.  Right now, our distributed object
containers are blissfully stupid.  We (humans) can point at any
individual class or interface and say "remote thyself!" but that's as
far as it goes.  The container just does what we programmers tell it to.

Just like me, a hypothetical "smart container" could make some pretty
educated guesses about where and when a set of existing objects should
be remoted.  Furthermore, it could automatically learn, over time, not
only where the best boundaries are, but what are the best situations to
perform the remoting/migration.  Instead of deciding which classes
should be remote, a smart container could decide which *objects* should
be remote.  And it could "learn" the answers by watching object behavior
over time.

Of course, architecture would still have a big effect on performance -
but it does already, even in a single-machine environment.  We don't
hand-optimize our assembly anymore, and suspect that eventually we won't
be hand-optimizing our distributed systems, either.

JADE and Mobile Agents are not quite what I have in mind.  The "agent"
concept is very thread-centric, whereas this idea is object-centric.  It
sounds like EOB and AltRMI are closer to the mark.  I'm going to have to
take a long look, and maybe try to restart this discussion on one of
their mailing lists :-)

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[James Strachan]

Hey Jeff

- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> From: James Strachan [mailto:[EMAIL PROTECTED]]
>
> (*) One thing I've noticed with SOAP is that developers from the
different
> camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The
> web/MOM
> guys tend to think of SOAP as a universal message format so the same
> structured message can pass across many transports http/email/news/MOM
to
> connect anything to anything in a language, platform and transport
neutral
> way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its
> CORBA
> but using XML rather than IIOP and go off building stubs/proxies/IDL
> compilers etc just like with EJB/CORBA.

> I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies.

Agreed they are quite different. Though they both try to solve similar
problems like distributing your business logic, clustering or load
balancing. Some are better or worse at these kinds of things.

e.g. MOMs are usually much better at fault tolerance & real load balancing
than EJBs and Servlet engines are usually more scalable than EJB servers (in
my experience at least).


> The former are communication protocols, and the latter are (primarily)
> programming APIs.

They are both technologies that have their own APIs.
For example with web technologies we can use the Servlets API or JavaMail or
even the URL class. With MOM we can use JMS and with SOAP we can use JAXM or
JAX-RPC. So the web/MOM/SOAP technologies have APIs too.


> To emphasize this point, in the .NET universe, the
> remote invocation protocols are pluggable... you can write to their
> distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or
> just about anything else you can dream up.  For that matter, there is no
> reason why you couldn't create an EJB container which used HTTP/SOAP as
> the transport protocol.

Just like JAX-RPC can have any protocol underneath. I like the looks of JAXM
and JAX-RPC, neither are based on RMI or EJB at all but can be used to
implement asynchronous SOAP messaging or remote invocation respectively. Its
just a shame JAXM doesn't work with JMS yet.

So JAX-RPC is probably the closest thing around to the .NET remote
invocation protocols. Has nothing at all to do with EJBs though.
.

> I would compare EJB to the programming API for your SOAP or MOM
> implementation.

EJB is *totally* different from MOM. Though I agree some SOAP frameworks are
EJB-like or EJB-biased.


> Theoretically EJB (or any distributed object model)
> provides a high-level abstraction so you don't need to fuss with the
> complexity of all the protocols and mechanisms underneath.  Of course,
> the tradeoff is flexibility and performance.  The problem with EJB,
> IMHO, is that it has merely replaced the complexity of the underlying
> system with the even greater complexity of the EJB system, and still
> significantly inhibits your ability to write well-performing
> applications.

I'm arguing against 'distributed object models' really. Whether its DCOM,
CORBA, EJB or a SOAP framework that tries to implement 'distributed
objects'. I think the distributed object paradigm of stubs/skeletons &
distributed garbage collection doesn't work that well. I prefer to build
distributed systems using more messaging focussed techniques like web
technologies, HTTP/email/news/Servlets, SOAP messaging and MOM/JMS.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> 
> Most objects don't work if they are made distributed without careful
> consideration.

I wonder if that has to be the case.  Right now, our distributed object
containers are blissfully stupid.  We (humans) can point at any
individual class or interface and say "remote thyself!" but that's as
far as it goes.  The container just does what we programmers tell it to.

Just like me, a hypothetical "smart container" could make some pretty
educated guesses about where and when a set of existing objects should
be remoted.  Furthermore, it could automatically learn, over time, not
only where the best boundaries are, but what are the best situations to
perform the remoting/migration.  Instead of deciding which classes
should be remote, a smart container could decide which *objects* should
be remote.  And it could "learn" the answers by watching object behavior
over time.

Of course, architecture would still have a big effect on performance -
but it does already, even in a single-machine environment.  We don't
hand-optimize our assembly anymore, and suspect that eventually we won't
be hand-optimizing our distributed systems, either.
 
JADE and Mobile Agents are not quite what I have in mind.  The "agent"
concept is very thread-centric, whereas this idea is object-centric.  It
sounds like EOB and AltRMI are closer to the mark.  I'm going to have to
take a long look, and maybe try to restart this discussion on one of
their mailing lists :-)

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: James Strachan [mailto:[EMAIL PROTECTED]]
> 
> (*) One thing I've noticed with SOAP is that developers from the
different
> camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The
> web/MOM
> guys tend to think of SOAP as a universal message format so the same
> structured message can pass across many transports http/email/news/MOM
to
> connect anything to anything in a language, platform and transport
neutral
> way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its
> CORBA
> but using XML rather than IIOP and go off building stubs/proxies/IDL
> compilers etc just like with EJB/CORBA.

I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies.
The former are communication protocols, and the latter are (primarily)
programming APIs.  To emphasize this point, in the .NET universe, the
remote invocation protocols are pluggable... you can write to their
distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or
just about anything else you can dream up.  For that matter, there is no
reason why you couldn't create an EJB container which used HTTP/SOAP as
the transport protocol.

I would compare EJB to the programming API for your SOAP or MOM
implementation.  Theoretically EJB (or any distributed object model)
provides a high-level abstraction so you don't need to fuss with the
complexity of all the protocols and mechanisms underneath.  Of course,
the tradeoff is flexibility and performance.  The problem with EJB,
IMHO, is that it has merely replaced the complexity of the underlying
system with the even greater complexity of the EJB system, and still
significantly inhibits your ability to write well-performing
applications.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Re: J2EE considered harmful

[James Strachan]

From: "acoliver" <[EMAIL PROTECTED]>
> >On Fri, 1 Feb 2002 18:35:55 - "James Strachan"
> <[EMAIL PROTECTED]> wrote.
> >> JMS is not
> >> appropriate for a number of areas.
> >
> >Like what?
> >
>
> UI, guaranteed failure situations.

I don't follow. JMS/MOM is one of the only solutions where clients and
servers work in a connectionless way - clients and servers don't need to be
running at the same time. The system can handle failures gracefully, with
persistent messages, retry, reconciliation, load balancing, fault tolerance
etc.

>
> >> In truth I've not yet learned enough
> >> about SOAP to speak intelligently  about it
> >
> >All I'll say is I think SOAP has a much better future than EJBs.
> >
>
> From what I've read I'd tend to agree, though it looks...bulky.

Agreed - though its a universal messaging format that can pass across all
transports; which is kinda handy. So whether http/email/news/MOM is used you
can connect anything to anything across diverse transports.

> >I was just emphasizing that web applications are scalable - just add more
> >boxes - and often they require quite modest hardware. EJB systems on the
> >other hand can often need huge machines just to make quite simple
systems.
> >
>
> Agreed.  I have fully stated: EJB sucks.  However it would be nice to have
> something there where you can isolate your database resources into a pool
of
> *servers* such as with any transaction processing system (going back to
even
> DCE crap -- which did suck too, but served a purpose)

Totally agree. I think adding TP type abilities to web/MOM/SOAP would be
cool.

> So it looks like we basically agree. ;-)  We're very verbose guys ;-)

+10 ;-)

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[James Strachan]

- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> No EJBs suck.  I'm arguing we need something better.  I think you're
> thinking distributed systems as a whole are bad and perhaps we've worked
> in different problem areas so we've reached differing opinions on this.
> Distributed systems are NOT the answer for every system.  In fact MOST
> systems do not.  That being said, I've worked on plenty that used or
> needed a distributed approach regardless of whether they had one.
>
> I do thing CTMs are a good and necessary thing for some systems.  I just
> think the EJB implementation of one is very poor.

I've worked alot with CORBA, messaging middleware systems (MOM) , EJB
systems, web systems and more recently dabbled with SOAP (*). Each of these
main 'istributed system architectures have their own strengths & weaknesses
and approaches.

The interesting thing I've found wtih using all these technologies is that
at first, to an OO guy, CORBA and EJB seem kinda cool when you just start
looking at them (just like Object Databases too), - there's the 'wow,
everything looks like Objects and the network stuff gets hidden' feeling,
along with 'ooh, this is probably going to be the next big thing'. Then once
you've learnt and absorbed the technology, figured out how to use it and get
it to work well (which takes a very long time, much longer than you would
think for somthing that hides the network), there's a general feeling of
disappointment. That the emperor has no clothes - or maybe its just that the
object thing shouldn't pass across process boundaries ;-). The 'distributed
object' approach of distributed garbage collection, connection based
protocols, stubs and skeletons of CORBA and EJB just don't quite seem to
work properly, they're *very* complex, take many years to master properly,
require many patterns to use effectively and its far too easy to build slow,
unscalable, unperformant systems that take alot of time to build.

Now the interesting thing about MOM, web technologies and now SOAP is that
at first to an OO guy they seem, well, not very OO. They are all based on a
simple idea of message passing using MOM, HTTP/email/news or SOAP. Its
mostly passing data around though usually in a language andplatform neutral
way. All objects stay local, its just the messages that cross process
boundaries. You send a message/request to something, it does its thing and a
response may go somewhere, which may be back to you. You can layer on
synchronous programming if you wish, but often scalable & performant systems
often use asynchronous communication.

The web/MOM/SOAP approach is very easy to work wtih, its very easy to put
together a 'distributed system' that works well using various technologies
(look at the web).  Developers I work wtih tend to pick up the concepts
pretty fast. There's no hidden gotchas or huge books of patterns requjred to
describe how to build systems using 'messaging' since its pretty simple
stuff. The more you use them and work with them, the easier and more
powerful they seem. They feel 'right' in a worse is better approach.

They all pretty much have location transparency and are easy to implement
load balancing & fault tolerance but don't at all try to hide the network -
there's no magic you can pretty much dive in and see whats going on.

The interesting thing I find is that the web/MOM/SOAP approaches are all
pretty similar really. Both web and SOAP (JAXM) often use Servlets on the
Java Platform. The Commons Messenger project has some Servlets (and servlet
extensions called Messagelets) that processs MOM / JMS messages. i.e. the
only application server platform you require is a good servlet engine and
away you go (Aside: I should take a look at JAMES as well).


So you can probably guess my bias towards web/MOM/SOAP approaches for
distributed systems.
In terms of what's next in the distributed system arena, my own guess would
be more unification of the web / MOM / SOAP approaches (they are pretty
similar already) - maybe SOAP is this unification - with maybe a
consolidation of the platform/application server. Then maybe more tools on
top (AltRMI is one example) that put an object facade on top of the message
passing approach without making the same CORBA/EJB mistakes of connection
based protocols & distributed garbage collections.

Well thats my rather long & rambling 0.02 euros.

James

(*) One thing I've noticed with SOAP is that developers from the different
camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The web/MOM
guys tend to think of SOAP as a universal message format so the same
structured message can pass across many transports http/email/news/MOM to
connect anything to anything in a language, platform and transport neutral
way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its CORBA
but using XML rather than IIOP and go off building stubs/proxies/IDL
compilers etc just like with EJB/CORBA.

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

[David E. Jones]

I agree quite a lot with Andrew. In fact, I agree enough that I stopped using 
EJBs around the middle of last year because they are SUCH a pain to build and 
maintain, and because the performance sucks and there's nothing you can do 
about it, even if you pay the high premiums for "advanced" application 
servers.

So, since there aren't really many alternatives I decided to make one as part 
of my open source project Open For Business (www.ofbiz.org or 
sf.net/projects/ofbiz). It's called the Entity Engine. The main idea behind 
it is: have an XML file that describes you data layout, and then handle 
generic persistence functionality through a single class. The GenericValue 
object works just like a value object in the EJB design patterns context but 
is Generic so you don't have to create one for every database table or 
combination of tables. It also handles "View Entities" to combine tables and 
a few other nice features such as JTA transaction support.

The upside of it (which I was chasing) is that it is easy to change the data 
structure and have it update the database and the run-time data layout 
enforcement as well as immediately making new columns and such immediately 
available in the GenericValue objects. So, when you want to change something 
in the data layout, wham, it's done and you can move on to your application 
functionality.

I don't know if it will ever become a standard and replace EJBs, but talk 
about this kind of tool has been going around for a while, and here is one 
implementation of those ideas that is being used in commercial deployments 
and is available open source.

Even if it doesn't replace EJBs for everyone, it certainly has for me, and 
has saved me hundreds of hours and hundreds of thousands of lines of 
generated EJB code (no, I haven't written it by hand in a while, way too much 
work for stupid persistence code).

Later,
-David Jones

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [OT] RE: J2EE considered harmful

[Geir Magnusson Jr.]

On 2/1/02 8:57 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Perhaps the question to ask is how are real sites providing real
> scalabilty without resorting to Enterprise JavaBeans?
> 
> Take google.com and yahoo.com for example,
> 
> Yahoo offers a signficant number of remote, multi-user applications like
> the ones we would like to provide to our own clients. Are they using
> EJBs? If not, what do they use? How can we turn Yahoo's approach into a
> toolkit model that other developers can use?

Give them a C/C++ compiler?

> 
> Google is offering a single, read-only servvice, but at mind-bending
> speed. How does it serve so many users so quickly?

Lots and lots of computers?

> Again, how can we
> package that approach in a way that it accessible to other developers?

I think that the two cases are different (Yahoo and Google), and I think (I
don't know as I don't work for Google or Yahoo) it comes down to engineering
the solution to the problem, and then using existing tools that fit *your*
design solution, and building the parts you can't buy.

It appears to me that the App server approach is the opposite - "here is
your solution, can you bend the problem to fit?"

(Like a joke we used to have : "Unix, of course.  Now what was the
question?")

I am working on a rather large-ish, very complicated project that we are
going to implement in Java.  There are many J2EE technologies that we will
take advantage of such as JMS, JNDI, JTA, etc but the whole container
approach doesn't have any relevance other than we may be forced to run it to
get some of the services as an app client.  Dunno.


This does bring up an interesting question : could EJBs possibly work for
Yahoo?  (I bet not...)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Re: J2EE considered harmful

[acoliver]

>On Fri, 1 Feb 2002 18:35:55 - "James Strachan"
<[EMAIL PROTECTED]> wrote.
>From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
>> > #1 you don't need to use EJBs to distribute business logic If you do
>need to
>> > distribute business logic, then there are various alternatives open,
>from
>> > HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their
>merits,
>> > cost/benefits etc.
>> >
>>
>> True, I don't like the Servlet approach.  I tend to admire clean code
>> and a Servlet approach makes this less likely (assuming the team is more
>> than 1 guy and you have differing skill levels on the team).
>
>There are many ways to work with HTTP, servlets is just one. There are many
>others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon
>etc.
>

Of these I've used JSP, Struts and Cocoon.  There are a few contributions I
need to make to the other technologies documentation-wise before I'm
ready/able to use them.  From what I know of Velocity, Turbine, Avalon, they
look very promising and I plan to use them in the future.

>Incidentally having worked with various 'distributed models' such as CORBA
>and EJB I find Servlets the cleanest and best designed applicaiton server
>solution so far by quite some margin. There's a great open source
>implementation of the spec (Tomcat 4) and look at all the diversity in
>layers added on top to improve developer productivity.
>
>
>> JMS is not
>> appropriate for a number of areas.
>
>Like what?
>

UI, guaranteed failure situations.

>> In truth I've not yet learned enough
>> about SOAP to speak intelligently  about it
>
>All I'll say is I think SOAP has a much better future than EJBs.
>

>From what I've read I'd tend to agree, though it looks...bulky.

>> > #2 just because you may eventually distribute your business logic,
>assuming
>> > you're going to from the start (and assuming that means EJBs and then
>> > jumping through lots of EJB hoops & headeaches and paying a fortune to
>some
>> > EJB vendors) is bad XP practice IMHO
>> >
>>
>> I'm not into XP, but often the scalability concern happens over night.
>> There should be some framework in place for making it possible to do
>> this somewhat suddenly.
>
>There should be a strategy yes. Though this doesn't advocate EJBs. (Though
I
>don't think you are advocating them).
>

+1

>
>> I'd say you have about a weeks warning on most systems on just how much
>> you need to scale up after deployment.  Systems are make it or break
>> it.  You can apply techniques to make this more predictive, but a lot of
>> this happens outside my area of control most of the time.  (Political,
>> socio-economic and chaos theory are involved which often result in
>> unpredictable community size, and you must plan to be way off no matter
>> how careful or disciplined your approach)
>
>Agreed. Scalability needs to be thought about seriously.
>
>> > I prefer to take an XP approach, first build a web application that
>works,
>> > is performant and scalable then worry about whether business logic
needs
>to
>> > be distributed later. Afterall us Java folk are OO guys right? We can
>write
>> > our business logic in such a way that it could migrate to EJB later if
>we
>> > think thats the right thing to do.
>> >
>>
>> I'm more into a scalable version of the RUP.  In my opinion XP is a hack
>> of a methodology (the RUP actually covers most of its issues).  XP also
>> suffers from the misconception that programming is the most important
>> activity in software development (I would argue requirements gathering
>> as the most important activity in software development...programming is
>> easy, figuring out WHAT to program is hard This is not to say I'm
>> not into an iterative approach to this, only that I think XP is
>> lacking.  At least it admits its own lack of scalability.)
>>
>> One day I'll start a project to create a methodology that merges the
>> disciplined approach to software that I admire with the opensource
>> principles and approaches that I think are necessary for effective
>> teamwork.  (minus the flamewars ;-) ).
>>
>> > Or to put that another way - I'd prefer to focus on giving the customer
>what
>> > they want and making a good web application than grappling with EJBs
>just
>>
>> That is irrelevant to the issue.
>
>Not really but maybe I'm not expressing it properly. Using EJBs wastes
>*alot* of valuable developer time when they could be doing something more
>useful like adding new features, making things more scalable or making
>things more performant.
>

+1!  Like I said: EJB sucks.  We need something better, not *similar* but in
the same...space.  A few postings to this list have indicated such things
are in the works.  I'll be studying them once I achieve a lower level of
cycle utilization.

>
>> I would like to see an adequate
>> distributed system (which it looks like there are at least 2 in the
>> works within or slightly external to our community), and EJB does not
>> fit the definition.
>
>Agreed.
>

RE: [OT] RE: J2EE considered harmful

[Michael A. Smith]

On Fri, 1 Feb 2002, Alef Arendsen wrote:
> As far as I can remember Google has started out in a small shed using
> just personal computers. No big mainframes, serverfarms or whatever.
> Just a proprietary server platform.
> 
> What the status is right now, I don't now...

They still use PCs.  Thousands of them.

From: http://www.google.com/technology/index.html

"Google runs on a unique combination of advanced hardware and software.  
The speed you experience can be attributed in part to the efficiency of
our search algorithm and partly to the thousands of low cost PC's we've
networked together to create a superfast search engine."

regards,
michael


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[James Strachan]

From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> > #1 you don't need to use EJBs to distribute business logic If you do
need to
> > distribute business logic, then there are various alternatives open,
from
> > HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their
merits,
> > cost/benefits etc.
> >
>
> True, I don't like the Servlet approach.  I tend to admire clean code
> and a Servlet approach makes this less likely (assuming the team is more
> than 1 guy and you have differing skill levels on the team).

There are many ways to work with HTTP, servlets is just one. There are many
others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon
etc.

Incidentally having worked with various 'distributed models' such as CORBA
and EJB I find Servlets the cleanest and best designed applicaiton server
solution so far by quite some margin. There's a great open source
implementation of the spec (Tomcat 4) and look at all the diversity in
layers added on top to improve developer productivity.


> JMS is not
> appropriate for a number of areas.

Like what?

> In truth I've not yet learned enough
> about SOAP to speak intelligently  about it

All I'll say is I think SOAP has a much better future than EJBs.

> > #2 just because you may eventually distribute your business logic,
assuming
> > you're going to from the start (and assuming that means EJBs and then
> > jumping through lots of EJB hoops & headeaches and paying a fortune to
some
> > EJB vendors) is bad XP practice IMHO
> >
>
> I'm not into XP, but often the scalability concern happens over night.
> There should be some framework in place for making it possible to do
> this somewhat suddenly.

There should be a strategy yes. Though this doesn't advocate EJBs. (Though I
don't think you are advocating them).


> I'd say you have about a weeks warning on most systems on just how much
> you need to scale up after deployment.  Systems are make it or break
> it.  You can apply techniques to make this more predictive, but a lot of
> this happens outside my area of control most of the time.  (Political,
> socio-economic and chaos theory are involved which often result in
> unpredictable community size, and you must plan to be way off no matter
> how careful or disciplined your approach)

Agreed. Scalability needs to be thought about seriously.

> > I prefer to take an XP approach, first build a web application that
works,
> > is performant and scalable then worry about whether business logic needs
to
> > be distributed later. Afterall us Java folk are OO guys right? We can
write
> > our business logic in such a way that it could migrate to EJB later if
we
> > think thats the right thing to do.
> >
>
> I'm more into a scalable version of the RUP.  In my opinion XP is a hack
> of a methodology (the RUP actually covers most of its issues).  XP also
> suffers from the misconception that programming is the most important
> activity in software development (I would argue requirements gathering
> as the most important activity in software development...programming is
> easy, figuring out WHAT to program is hard This is not to say I'm
> not into an iterative approach to this, only that I think XP is
> lacking.  At least it admits its own lack of scalability.)
>
> One day I'll start a project to create a methodology that merges the
> disciplined approach to software that I admire with the opensource
> principles and approaches that I think are necessary for effective
> teamwork.  (minus the flamewars ;-) ).
>
> > Or to put that another way - I'd prefer to focus on giving the customer
what
> > they want and making a good web application than grappling with EJBs
just
>
> That is irrelevant to the issue.

Not really but maybe I'm not expressing it properly. Using EJBs wastes
*alot* of valuable developer time when they could be doing something more
useful like adding new features, making things more scalable or making
things more performant.


> I would like to see an adequate
> distributed system (which it looks like there are at least 2 in the
> works within or slightly external to our community), and EJB does not
> fit the definition.

Agreed.

> > because one day, maybe, under some conditions, I might want to
distribute
> > some of the business logic in the web app under the 'faith' that its the
> > right thing to do.
> >
>
> That doesn't mean you plug your fingers in your ears and say "na na na
> scalability I'll refactor later".

Agreed.

>  I find a balanced approach between
> planing for the future and refactoring later works best.  We do need an
> adequate distributed object system for some situations.

Agreed - but like I said, they are pretty easy to do with HTTP, SOAP, JMS
etc. It doesn't *have* to be EJB. That was my main point. Too many
developers start building a web application and *start* with the EJB parts -
rather than building the actual web application then seeing where EJB, JMS,
SOAP or HTTP servers might help to distribute some of

RE: [OT] RE: J2EE considered harmful

[Steve Downey]

A 10,000 node linux cluster. http://www.google.com/press/highlights.html


> -Original Message-
> From: Alef Arendsen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 10:58 AM
> To: Jakarta General List
> Subject: RE: [OT] RE: J2EE considered harmful
> 
> 
> As far as I can remember Google has started out in a small 
> shed using just personal computers. No big mainframes, 
> serverfarms or whatever. Just a proprietary server platform.
> 
> What the status is right now, I don't now...
> 
> alef
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, 01 February 2002 16:46
> > To: Jakarta General List
> > Subject: Re: [OT] RE: J2EE considered harmful
> > 
> > 
> > yahoo.com goes way beyond a search engine:
> > 
> > Email, address books, auctions, classified ads, file storage, 
> > calendars
> > and shared calendars, personalized portals for like 27 different sub
> > applications, the list goes on.
> > 
> > Yahoo is delivering a vast number of dynamic applications to an
> > incredible number of users, with excellent performance and 
> > reliabity. If
> > there a success story in IT, this is it.
> > 
> > I picked yahoo.com and google.com as two different examples of high
> > traffic Web sites that are delivering scalability. 
> > 
> > I only mentioned google.com since it is ~blazingly fast~, and 
> > represents
> > a very different best-of-breed right now. 
> > 
> > 
> > "Andrew C. Oliver" wrote:
> > > 
> > > Those are both search engines with non-critical data update 
> > issues.  You
> > > do need an example with more business-logic oriented type
> > > functionality.  I could mock something like those up with 
> > Lucene just
> > > with a few routers and pushing the indicies to the 
> mirrored systems.
> > > This doesn't answer the "enterprise system" question.  
> > Secondly we need
> > > examples on a more moderate basis.
> > > 
> > > (sorry, if that sounds critical, I don't mean to be, I 
> think you're
> > > heading the discussion the right direction, I just don't 
> think those
> > > examples do that)
> > > 
> > > On a more personal note.  Funny story: My wife went to 
> > high/grade school
> > > with the Google guy.  Small world eh?
> > > 
> > > -Andy
> > > 
> > > On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
> > > > Perhaps the question to ask is how are real sites providing real
> > > > scalabilty without resorting to Enterprise JavaBeans?
> > > >
> > > > Take google.com and yahoo.com for example,
> > > >
> > > > Yahoo offers a signficant number of remote, multi-user 
> > applications like
> > > > the ones we would like to provide to our own clients. Are 
> > they using
> > > > EJBs? If not, what do they use? How can we turn Yahoo's 
> > approach into a
> > > > toolkit model that other developers can use?
> > > >
> > > > Google is offering a single, read-only servvice, but at 
> > mind-bending
> > > > speed. How does it serve so many users so quickly? Again, 
> > how can we
> > > > package that approach in a way that it accessible to 
> > other developers?
> > > >
> > > > Sorry to be providing more queries than code, but to 
> > paraphrase Linus,
> > > > it often takes one person to articulate an issue, and 
> > another to resolve
> > > > it =:o)
> > > >
> > > >
> > > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > > -- Java Web Development with Struts.
> > > > -- Tel +1 585 737-3463.
> > > > -- Web http://www.husted.com/struts/
> > > >
> > > > --
> > > > To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> > >
> > --
> > www.superlinksoftware.com
> > www.sourceforge.net/projects/poi - port of Excel format to java
> > http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> > - fix java generics!
> > 
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> > For additional comm

RE: J2EE considered harmful

[Micael Padraig Og mac Grene]

Well, if you are considering building a new language that is based on a 
primordial focus on distributed programming, consider me in.  I would be 
happy to toil in that vineyard.  I think this is a grand idea.  The key is 
to come up with a nifty idea to make that "primordial focus" work.   My 
thinking cap is on.  I am not too knowledgeable about building a language, 
but am willing to learn anything.  The idea of having a language that does 
the distributed stuff and integrates easily with Java and .NET would be 
interesting?

I have copied a fellow I have met tangentially (on other matters) who 
builds languages,  viz. Craig Chambers with U. of Wash. computer science 
(engineering).  Maybe he has a couple thoughts, or more.

- micael

At 01:54 PM 1/31/02 -0800, you wrote:
> > From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> >
> > Are you just talking about creating a new language, or what?  What is
>your
> > idea?  I cannot tell.
>
>That's a good question, and ultimately one which would be determined by
>the constraints of the technology.  Prototyping would probably involve
>using an existing language and platform, and maybe we would ultimately
>discover that it is possible to build a system like this on top of a JVM
>(or CLR).  My suspicion is that it is not, and may be undesirable for
>legal reasons anyways.
>
>The later part of my diatribe was a hastily phrased way of approaching
>this subject:
>
>Unless you want to go back to the dark ages of C++, the future is
>shaping up to look like a choice between writing for the Sun platform or
>the Microsoft platform.  This does not make me comfortable, especially
>considering that Sun's approach to Java so far has been *wholly*
>anathema to the principals of Open Source.  At least Microsoft has
>submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*
>
>I am tantalized by the idea of a third choice:  the Apache platform.  I
>propose a discussion of just what that might be.
>
>Jeff Schnitzer
>[EMAIL PROTECTED]
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Steve Downey]

If you are _very_ lucky, the object is coarse grained enough, and has loose
enough performance requirements, that the rest of the system can tolerate
that calls to it will take 100 to 1000 times longer. 

I've never seen any system that lucky. 

Most objects don't work if they are made distributed without careful
consideration.

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 8:19 AM
> To: Jakarta General List
> Subject: RE: [OT] RE: J2EE considered harmful
> 
> 
> So what if you need to move an object that is defined as local to be
> load balanced across machines?  I think you're wrong on that one.  If
> you have to define it as local you loose scalability by definition
> unless you accept the hardware vendor's edition of scalability (buy an
> E1 instead and junk your old machine ;-) ).
> 
> On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote:
> > I do not think so. Handling in a proper way situations that are
> > specific to a remote call does not mean that the architecture of
> > the app must be less scalable.
> > 
> > 
> > Have fun,
> > Paulo
> > 
> > > -Original Message-
> > > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, February 01, 2002 7:03 AM
> > > To: Jakarta General List
> > > Subject: RE: [OT] RE: J2EE considered harmful
> > > 
> > > 
> > > Albeit at the expense of scalability
> > > 
> > > On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> > > > I think that the key bit is:
> > > >  > and it is a mistake to try to program 
> > > >  > as though a
> > > >  > remote call had the same characteristics as a local one.
> > > > 
> > > > Your app will always be more robust if you do NOT ignore the
> > > > specific issues of a remote call.
> > > > 
> > > > 
> > > > Have fun,
> > > > Paulo Gaspar
> > > > 
> > > > > -Original Message-
> > > > > From: Fernandez Martinez, Alejandro
> > > > > [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Thursday, January 31, 2002 1:50 PM
> > > > > To: 'Jakarta General List'
> > > > > Subject: [OT] RE: J2EE considered harmful
> > > > > 
> > > > > 
> > > > > Hi Tim.
> > > > > 
> > > > > I agree with your point of view, we've been trying to 
> avoid EJBs 
> > > > > as much as
> > > > > possible. But there's one thing I don't understand.
> > > > > 
> > > > > > -Mensaje original-
> > > > > > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > > > > > 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.
> > > > > 
> > > > > Why is it a mistake? I think a remote proxy is a great way to 
> > > make remote
> > > > > calls, shielding the developer from the complexity of it all. 
> > > The recent
> > > > > discussion about AltRMI has shown that there's a lot of 
> > > interest in using
> > > > > proxies, but it was Sun's implementation (the Remote* 
> stuff) that was
> > > > > flawed.
> > > > > 
> > > > > Un saludo,
> > > > > 
> > > > > Alex.
> > > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   
> > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail: 
> > > <mailto:[EMAIL PROTECTED]>
> > > > 
> > > -- 
> > > www.superlinksoftware.com
> > > www.sourceforge.net/projects/poi - port of Excel format to java
> > > 
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
> > >   - fix java generics!
> > > 
> > > 
> > > The avalanche has alr

Re: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

(too bad I'll be boycotting Yahoo soon because they use pop-up ads which
I consider SOoo unprofessional)

On Fri, 2002-02-01 at 11:00, Andrew C. Oliver wrote:
> On Fri, 2002-02-01 at 11:07, Ted Husted wrote:
> > "Andrew C. Oliver" wrote:
> > > 
> > > On Fri, 2002-02-01 at 10:46, Ted Husted wrote:
> > > > yahoo.com goes way beyond a search engine:
> > > >
> > > > Email, address books, auctions, classified ads, file storage, calendars
> > > > and shared calendars, personalized portals for like 27 different sub
> > > > applications, the list goes on.
> > > >
> > > > Yahoo is delivering a vast number of dynamic applications to an
> > > > incredible number of users, with excellent performance and reliabity. If
> > > > there a success story in IT, this is it.
> > > >
> > > 
> > > True, but it isn't particularly transactional in nature as far as the
> > > other features, more of a publishing type app.  Sure the email, but that
> > > even has isolated data interaction..  Am I making sense?
> > 
> > You need to consider that they are doing *everything*, including a very
> > complicated type of ecommerce through the auctions. That's the stunning
> > part. It's not just one banana, it's the whole bunch.
> > 
> Ahh, you know, you're right.  (I use all those things but forget they
> are there since they don't break often ;-)...come to think of it yahoo
> is a great example)
> 
> -Andy
> 
> 
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Java Web Development with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> -- 
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
>   - fix java generics!
> 
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 11:07, Ted Husted wrote:
> "Andrew C. Oliver" wrote:
> > 
> > On Fri, 2002-02-01 at 10:46, Ted Husted wrote:
> > > yahoo.com goes way beyond a search engine:
> > >
> > > Email, address books, auctions, classified ads, file storage, calendars
> > > and shared calendars, personalized portals for like 27 different sub
> > > applications, the list goes on.
> > >
> > > Yahoo is delivering a vast number of dynamic applications to an
> > > incredible number of users, with excellent performance and reliabity. If
> > > there a success story in IT, this is it.
> > >
> > 
> > True, but it isn't particularly transactional in nature as far as the
> > other features, more of a publishing type app.  Sure the email, but that
> > even has isolated data interaction..  Am I making sense?
> 
> You need to consider that they are doing *everything*, including a very
> complicated type of ecommerce through the auctions. That's the stunning
> part. It's not just one banana, it's the whole bunch.
> 
Ahh, you know, you're right.  (I use all those things but forget they
are there since they don't break often ;-)...come to think of it yahoo
is a great example)

-Andy


> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[Andrew C. Oliver]

They may indeed be.  I think the arguments drifted to methodology (as
far as whether distributed object technologies are even necessary which
was moot).  I'd really like to help with a case studies page.  Some
end-end Apache and Jakarta solutions.  We should be a bit more "project
agnostic" on this and include where HTTPD, or XML stuff was used.

There is only one problem with that.  We need some case studies.  Once
you get the resources up, let me know, I'll at least write a placeholder
page with a request.

Thanks,

Andy


On Fri, 2002-02-01 at 11:01, Ted Husted wrote:
> You know, since Apache is a member of the J2SE group at Apache, it would
> make a lot of sense for us to develop a resource page regarding J2SE
> scalability. 
> 
> I'd be very happy to start and maintain such a page here, as I do for
> Struts. 
> 
> http://husted.com/struts/resources.htm
> 
> If anyone has some starter links, send them along, and I'll get going.
> 
> More importantly, we should also not hesitate to pubish our own orignal
> material, such as case studies, if anyone here wants to pass one along
> :-)
> 
> Personally, like James, I think all the tools are already there, and
> much easier to deploy that bothering with EJBs. The vendor slove to say
> you get this-and-that for free, but the "hidden" costs are staggering,
> and in the end, it's obvious that you lose much more than you gain. Two
> steps forward, six steps back.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> 
> James Strachan wrote:
> > Agreed. Though I've 2 points to make.
> > 
> > #1 you don't need to use EJBs to distribute business logic If you do need to
> > distribute business logic, then there are various alternatives open, from
> > HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
> > cost/benefits etc.
> > 
> > #2 just because you may eventually distribute your business logic, assuming
> > you're going to from the start (and assuming that means EJBs and then
> > jumping through lots of EJB hoops & headeaches and paying a fortune to some
> > EJB vendors) is bad XP practice IMHO
> > 
> > I prefer to take an XP approach, first build a web application that works,
> > is performant and scalable then worry about whether business logic needs to
> > be distributed later. Afterall us Java folk are OO guys right? We can write
> > our business logic in such a way that it could migrate to EJB later if we
> > think thats the right thing to do.
> > 
> > Or to put that another way - I'd prefer to focus on giving the customer what
> > they want and making a good web application than grappling with EJBs just
> > because one day, maybe, under some conditions, I might want to distribute
> > some of the business logic in the web app under the 'faith' that its the
> > right thing to do.
> > 
> > Most business logic in most web applications is pretty minimal in terms of
> > computation and is often mostly database intensive so moving this code to
> > another process doesn't usually buy much in terms of scalability - if
> > anything its the reverse thats true - what with all that EJB distributed
> > garbage collection & connection based protocol stuff that needs to be done
> > scalability (and usually always performance) can go down.
> > 
> > > If your application will grow it is good to have a middle tier that
> > > can be moved and load balanced.  With Entity beans of course this is
> > > less possible.
> > 
> > (And stateful session beans ;-).
> > 
> > I think this is true of traditional GUIs, say a Swing client front end, a
> > middle tier server (say server side beans aka EJBs) and a database. I don't
> > think this is true of web applications as they are quite different things -
> > a servlet engine is not a 'GUI' client.
> > 
> > Servlet engines are a stable, performant and very scalable application
> > servers in their own right. Get a hardware load balancer and a farm of
> > servlet engines and your *way* scalable.
> > 
> > Arguing for the need for another, remote CORBA component-centric application
> > server based on mostly connection-based protocols, RMI, stubs and
> > distributed garbage collection to make your web-application more scalable
> > seems, well, strange.
> > 
> > In my experience web applications scale best when you have a big server farm
> > of servlet engines which are load balanced. A database at the back and
> > hopefully some kind of read only caching going on to take as much load off
> > the poor database as you can. Then you can distribute parts of your web
> > application into different server farms, get load balancing, shuffle things
> > around as load changes etc. Then pick the web technologies of your choice,
> > Struts, JSP, Velocity, Turbine etc. Away you go.
> > 
> > I still don't see the 'scalability' argument as in any way advocating that
> > EJBs are actually useful for web applications.
> > 
> > 

Re: J2EE considered harmful

[Ted Husted]

Obviously, I meant to say Apache is member of the J2SE group at Sun ...

Ted Husted wrote:
> 
> You know, since Apache is a member of the J2SE group at Apache, it would
> make a lot of sense for us to develop a resource page regarding J2SE
> scalability.
> 
> I'd be very happy to start and maintain such a page here, as I do for
> Struts.
> 
> http://husted.com/struts/resources.htm
> 
> If anyone has some starter links, send them along, and I'll get going.
> 
> More importantly, we should also not hesitate to pubish our own orignal
> material, such as case studies, if anyone here wants to pass one along
> :-)
> 
> Personally, like James, I think all the tools are already there, and
> much easier to deploy that bothering with EJBs. The vendor slove to say
> you get this-and-that for free, but the "hidden" costs are staggering,
> and in the end, it's obvious that you lose much more than you gain. Two
> steps forward, six steps back.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> James Strachan wrote:
> > Agreed. Though I've 2 points to make.
> >
> > #1 you don't need to use EJBs to distribute business logic If you do need to
> > distribute business logic, then there are various alternatives open, from
> > HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
> > cost/benefits etc.
> >
> > #2 just because you may eventually distribute your business logic, assuming
> > you're going to from the start (and assuming that means EJBs and then
> > jumping through lots of EJB hoops & headeaches and paying a fortune to some
> > EJB vendors) is bad XP practice IMHO
> >
> > I prefer to take an XP approach, first build a web application that works,
> > is performant and scalable then worry about whether business logic needs to
> > be distributed later. Afterall us Java folk are OO guys right? We can write
> > our business logic in such a way that it could migrate to EJB later if we
> > think thats the right thing to do.
> >
> > Or to put that another way - I'd prefer to focus on giving the customer what
> > they want and making a good web application than grappling with EJBs just
> > because one day, maybe, under some conditions, I might want to distribute
> > some of the business logic in the web app under the 'faith' that its the
> > right thing to do.
> >
> > Most business logic in most web applications is pretty minimal in terms of
> > computation and is often mostly database intensive so moving this code to
> > another process doesn't usually buy much in terms of scalability - if
> > anything its the reverse thats true - what with all that EJB distributed
> > garbage collection & connection based protocol stuff that needs to be done
> > scalability (and usually always performance) can go down.
> >
> > > If your application will grow it is good to have a middle tier that
> > > can be moved and load balanced.  With Entity beans of course this is
> > > less possible.
> >
> > (And stateful session beans ;-).
> >
> > I think this is true of traditional GUIs, say a Swing client front end, a
> > middle tier server (say server side beans aka EJBs) and a database. I don't
> > think this is true of web applications as they are quite different things -
> > a servlet engine is not a 'GUI' client.
> >
> > Servlet engines are a stable, performant and very scalable application
> > servers in their own right. Get a hardware load balancer and a farm of
> > servlet engines and your *way* scalable.
> >
> > Arguing for the need for another, remote CORBA component-centric application
> > server based on mostly connection-based protocols, RMI, stubs and
> > distributed garbage collection to make your web-application more scalable
> > seems, well, strange.
> >
> > In my experience web applications scale best when you have a big server farm
> > of servlet engines which are load balanced. A database at the back and
> > hopefully some kind of read only caching going on to take as much load off
> > the poor database as you can. Then you can distribute parts of your web
> > application into different server farms, get load balancing, shuffle things
> > around as load changes etc. Then pick the web technologies of your choice,
> > Struts, JSP, Velocity, Turbine etc. Away you go.
> >
> > I still don't see the 'scalability' argument as in any way advocating that
> > EJBs are actually useful for web applications.
> >
> > In fact this idea that EJBs are required to build scalable web applications
> > is plain false - probably marketing hype spread by the EJB vendors.
> >
> > James
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> 
> --
> To unsubscribe, e-mail:   

Re: [OT] RE: J2EE considered harmful

[Ted Husted]

"Andrew C. Oliver" wrote:
> 
> On Fri, 2002-02-01 at 10:46, Ted Husted wrote:
> > yahoo.com goes way beyond a search engine:
> >
> > Email, address books, auctions, classified ads, file storage, calendars
> > and shared calendars, personalized portals for like 27 different sub
> > applications, the list goes on.
> >
> > Yahoo is delivering a vast number of dynamic applications to an
> > incredible number of users, with excellent performance and reliabity. If
> > there a success story in IT, this is it.
> >
> 
> True, but it isn't particularly transactional in nature as far as the
> other features, more of a publishing type app.  Sure the email, but that
> even has isolated data interaction..  Am I making sense?

You need to consider that they are doing *everything*, including a very
complicated type of ecommerce through the auctions. That's the stunning
part. It's not just one banana, it's the whole bunch.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[Ted Husted]

You know, since Apache is a member of the J2SE group at Apache, it would
make a lot of sense for us to develop a resource page regarding J2SE
scalability. 

I'd be very happy to start and maintain such a page here, as I do for
Struts. 

http://husted.com/struts/resources.htm

If anyone has some starter links, send them along, and I'll get going.

More importantly, we should also not hesitate to pubish our own orignal
material, such as case studies, if anyone here wants to pass one along
:-)

Personally, like James, I think all the tools are already there, and
much easier to deploy that bothering with EJBs. The vendor slove to say
you get this-and-that for free, but the "hidden" costs are staggering,
and in the end, it's obvious that you lose much more than you gain. Two
steps forward, six steps back.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


James Strachan wrote:
> Agreed. Though I've 2 points to make.
> 
> #1 you don't need to use EJBs to distribute business logic If you do need to
> distribute business logic, then there are various alternatives open, from
> HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
> cost/benefits etc.
> 
> #2 just because you may eventually distribute your business logic, assuming
> you're going to from the start (and assuming that means EJBs and then
> jumping through lots of EJB hoops & headeaches and paying a fortune to some
> EJB vendors) is bad XP practice IMHO
> 
> I prefer to take an XP approach, first build a web application that works,
> is performant and scalable then worry about whether business logic needs to
> be distributed later. Afterall us Java folk are OO guys right? We can write
> our business logic in such a way that it could migrate to EJB later if we
> think thats the right thing to do.
> 
> Or to put that another way - I'd prefer to focus on giving the customer what
> they want and making a good web application than grappling with EJBs just
> because one day, maybe, under some conditions, I might want to distribute
> some of the business logic in the web app under the 'faith' that its the
> right thing to do.
> 
> Most business logic in most web applications is pretty minimal in terms of
> computation and is often mostly database intensive so moving this code to
> another process doesn't usually buy much in terms of scalability - if
> anything its the reverse thats true - what with all that EJB distributed
> garbage collection & connection based protocol stuff that needs to be done
> scalability (and usually always performance) can go down.
> 
> > If your application will grow it is good to have a middle tier that
> > can be moved and load balanced.  With Entity beans of course this is
> > less possible.
> 
> (And stateful session beans ;-).
> 
> I think this is true of traditional GUIs, say a Swing client front end, a
> middle tier server (say server side beans aka EJBs) and a database. I don't
> think this is true of web applications as they are quite different things -
> a servlet engine is not a 'GUI' client.
> 
> Servlet engines are a stable, performant and very scalable application
> servers in their own right. Get a hardware load balancer and a farm of
> servlet engines and your *way* scalable.
> 
> Arguing for the need for another, remote CORBA component-centric application
> server based on mostly connection-based protocols, RMI, stubs and
> distributed garbage collection to make your web-application more scalable
> seems, well, strange.
> 
> In my experience web applications scale best when you have a big server farm
> of servlet engines which are load balanced. A database at the back and
> hopefully some kind of read only caching going on to take as much load off
> the poor database as you can. Then you can distribute parts of your web
> application into different server farms, get load balancing, shuffle things
> around as load changes etc. Then pick the web technologies of your choice,
> Struts, JSP, Velocity, Turbine etc. Away you go.
> 
> I still don't see the 'scalability' argument as in any way advocating that
> EJBs are actually useful for web applications.
> 
> In fact this idea that EJBs are required to build scalable web applications
> is plain false - probably marketing hype spread by the EJB vendors.
> 
> James
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Alef Arendsen]

As far as I can remember Google has started out in a small shed using just personal 
computers. No big mainframes, serverfarms or whatever. Just a proprietary server 
platform.

What the status is right now, I don't now...

alef
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 01 February 2002 16:46
> To: Jakarta General List
> Subject: Re: [OT] RE: J2EE considered harmful
> 
> 
> yahoo.com goes way beyond a search engine:
> 
> Email, address books, auctions, classified ads, file storage, 
> calendars
> and shared calendars, personalized portals for like 27 different sub
> applications, the list goes on.
> 
> Yahoo is delivering a vast number of dynamic applications to an
> incredible number of users, with excellent performance and 
> reliabity. If
> there a success story in IT, this is it.
> 
> I picked yahoo.com and google.com as two different examples of high
> traffic Web sites that are delivering scalability. 
> 
> I only mentioned google.com since it is ~blazingly fast~, and 
> represents
> a very different best-of-breed right now. 
> 
> 
> "Andrew C. Oliver" wrote:
> > 
> > Those are both search engines with non-critical data update 
> issues.  You
> > do need an example with more business-logic oriented type
> > functionality.  I could mock something like those up with 
> Lucene just
> > with a few routers and pushing the indicies to the mirrored systems.
> > This doesn't answer the "enterprise system" question.  
> Secondly we need
> > examples on a more moderate basis.
> > 
> > (sorry, if that sounds critical, I don't mean to be, I think you're
> > heading the discussion the right direction, I just don't think those
> > examples do that)
> > 
> > On a more personal note.  Funny story: My wife went to 
> high/grade school
> > with the Google guy.  Small world eh?
> > 
> > -Andy
> > 
> > On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
> > > Perhaps the question to ask is how are real sites providing real
> > > scalabilty without resorting to Enterprise JavaBeans?
> > >
> > > Take google.com and yahoo.com for example,
> > >
> > > Yahoo offers a signficant number of remote, multi-user 
> applications like
> > > the ones we would like to provide to our own clients. Are 
> they using
> > > EJBs? If not, what do they use? How can we turn Yahoo's 
> approach into a
> > > toolkit model that other developers can use?
> > >
> > > Google is offering a single, read-only servvice, but at 
> mind-bending
> > > speed. How does it serve so many users so quickly? Again, 
> how can we
> > > package that approach in a way that it accessible to 
> other developers?
> > >
> > > Sorry to be providing more queries than code, but to 
> paraphrase Linus,
> > > it often takes one person to articulate an issue, and 
> another to resolve
> > > it =:o)
> > >
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Java Web Development with Struts.
> > > -- Tel +1 585 737-3463.
> > > -- Web http://www.husted.com/struts/
> > >
> > > --
> > > To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> --
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> - fix java generics!
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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


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

Re: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 10:46, Ted Husted wrote:
> yahoo.com goes way beyond a search engine:
> 
> Email, address books, auctions, classified ads, file storage, calendars
> and shared calendars, personalized portals for like 27 different sub
> applications, the list goes on.
> 
> Yahoo is delivering a vast number of dynamic applications to an
> incredible number of users, with excellent performance and reliabity. If
> there a success story in IT, this is it.
> 

True, but it isn't particularly transactional in nature as far as the
other features, more of a publishing type app.  Sure the email, but that
even has isolated data interaction..  Am I making sense?  

> I picked yahoo.com and google.com as two different examples of high
> traffic Web sites that are delivering scalability. 
> 
> I only mentioned google.com since it is ~blazingly fast~, and represents
> a very different best-of-breed right now. 
> 
> 
> "Andrew C. Oliver" wrote:
> > 
> > Those are both search engines with non-critical data update issues.  You
> > do need an example with more business-logic oriented type
> > functionality.  I could mock something like those up with Lucene just
> > with a few routers and pushing the indicies to the mirrored systems.
> > This doesn't answer the "enterprise system" question.  Secondly we need
> > examples on a more moderate basis.
> > 
> > (sorry, if that sounds critical, I don't mean to be, I think you're
> > heading the discussion the right direction, I just don't think those
> > examples do that)
> > 
> > On a more personal note.  Funny story: My wife went to high/grade school
> > with the Google guy.  Small world eh?
> > 
> > -Andy
> > 
> > On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
> > > Perhaps the question to ask is how are real sites providing real
> > > scalabilty without resorting to Enterprise JavaBeans?
> > >
> > > Take google.com and yahoo.com for example,
> > >
> > > Yahoo offers a signficant number of remote, multi-user applications like
> > > the ones we would like to provide to our own clients. Are they using
> > > EJBs? If not, what do they use? How can we turn Yahoo's approach into a
> > > toolkit model that other developers can use?
> > >
> > > Google is offering a single, read-only servvice, but at mind-bending
> > > speed. How does it serve so many users so quickly? Again, how can we
> > > package that approach in a way that it accessible to other developers?
> > >
> > > Sorry to be providing more queries than code, but to paraphrase Linus,
> > > it often takes one person to articulate an issue, and another to resolve
> > > it =:o)
> > >
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Java Web Development with Struts.
> > > -- Tel +1 585 737-3463.
> > > -- Web http://www.husted.com/struts/
> > >
> > > --
> > > To unsubscribe, e-mail:   
> > > For additional commands, e-mail: 
> > >
> > --
> > www.superlinksoftware.com
> > www.sourceforge.net/projects/poi - port of Excel format to java
> > http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> > - fix java generics!
> > 
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [OT] RE: J2EE considered harmful

[Ted Husted]

yahoo.com goes way beyond a search engine:

Email, address books, auctions, classified ads, file storage, calendars
and shared calendars, personalized portals for like 27 different sub
applications, the list goes on.

Yahoo is delivering a vast number of dynamic applications to an
incredible number of users, with excellent performance and reliabity. If
there a success story in IT, this is it.

I picked yahoo.com and google.com as two different examples of high
traffic Web sites that are delivering scalability. 

I only mentioned google.com since it is ~blazingly fast~, and represents
a very different best-of-breed right now. 


"Andrew C. Oliver" wrote:
> 
> Those are both search engines with non-critical data update issues.  You
> do need an example with more business-logic oriented type
> functionality.  I could mock something like those up with Lucene just
> with a few routers and pushing the indicies to the mirrored systems.
> This doesn't answer the "enterprise system" question.  Secondly we need
> examples on a more moderate basis.
> 
> (sorry, if that sounds critical, I don't mean to be, I think you're
> heading the discussion the right direction, I just don't think those
> examples do that)
> 
> On a more personal note.  Funny story: My wife went to high/grade school
> with the Google guy.  Small world eh?
> 
> -Andy
> 
> On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
> > Perhaps the question to ask is how are real sites providing real
> > scalabilty without resorting to Enterprise JavaBeans?
> >
> > Take google.com and yahoo.com for example,
> >
> > Yahoo offers a signficant number of remote, multi-user applications like
> > the ones we would like to provide to our own clients. Are they using
> > EJBs? If not, what do they use? How can we turn Yahoo's approach into a
> > toolkit model that other developers can use?
> >
> > Google is offering a single, read-only servvice, but at mind-bending
> > speed. How does it serve so many users so quickly? Again, how can we
> > package that approach in a way that it accessible to other developers?
> >
> > Sorry to be providing more queries than code, but to paraphrase Linus,
> > it often takes one person to articulate an issue, and another to resolve
> > it =:o)
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Java Web Development with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> --
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> - fix java generics!
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Fernandez Martinez, Alejandro]

Hi Jeff,

> -Mensaje original-
> De: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]

[...]

> I've been giving a lot of thought to distributed object models lately.
> I've worked with DCOM, CORBA, RMI, and EJB, and for the most 
> part it's a
> lot of the same.  Since networks are getting so fast these days, I'm
> starting to really wonder what it would be like to have a model in
> which:
> 
> * All objects are inherently remotable.
> * Objects transparently migrate for efficiency.

Welcome to the wonderful world of Mobile Agents. They suck.

In our experience, the security concerns far outweigh the advantages of
mobility. Anyways, that migration is only efficient in conditions of:
- limited processing power. Instead of making computations on a PDA,
you shift the agent to your server, perform the computations and then return
with the results. This sci-fi scenario is a bit absurd, since you can just
call a service that performs the same computations.

- limited bandwidth. You shift the agent to the machine that is
nearer to e.g. the database, so as to minimize communications. A good design
already takes care of this problem, and nowadays, bandwidth is much cheaper
than it used to be.

> I can think of many interesting, fairly revolutionary consequences of
> such a system and I'd love to discuss them.  Ultimately, if such a
> system ever made it out of research and into prototype, it could
> challenge both Java and .NET, and possibly stave off the 
> coming hegemony
> of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always 
> be people
> who enjoy working on nonvirtual machines, but they're crazy :-)

You can just check out JADE, it's a nice LGPL platform for mobile agents
that can be programmed in JESS or Java. IMHO, not worth the trouble.

> Does anyone think some variant of this idea to be worth 
> pursuing?  Or is
> everyone wedded to the idea of working on the proprietary Sun platform
> known as Java?

It's not 'with me or against me'. We can dislike J2EE, but not necessarily
be keen on building a J2EE replacement.

Un saludo,

Alex. 

RE: J2EE considered harmful

[Alef Arendsen]

 
> I'm more into a scalable version of the RUP.  In my opinion 
> XP is a hack
> of a methodology (the RUP actually covers most of its 
> issues).  XP also
> suffers from the misconception that programming is the most important
> activity in software development (I would argue requirements gathering
> as the most important activity in software 
> development...programming is
> easy, figuring out WHAT to program is hard This is not to say I'm
> not into an iterative approach to this, only that I think XP is
> lacking.  At least it admits its own lack of scalability.)

Hmmm... interesting. The nice thing about XP in my opinion is the fact that it's 
modular as hell and you can take whatever parts from it you want. We don't do XP - 
we're product-oriented - but use parts of it. A continuous integration process makes 
discovery of bugs much easier, in the interface part pair programming works perfectly 
and writing unit tests before you code can be extremely helpful when software has 
decent requirements...

man, this is way too off topic...

Alef Arendsen
SmartHaven 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 08:53, James Strachan wrote:
> Hey Andrew
> 
> Insteresting thread ;-)
> 

Thanks!  you too.



> Agreed. Though I've 2 points to make.
> 
> #1 you don't need to use EJBs to distribute business logic If you do need to
> distribute business logic, then there are various alternatives open, from
> HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
> cost/benefits etc.
> 

True, I don't like the Servlet approach.  I tend to admire clean code
and a Servlet approach makes this less likely (assuming the team is more
than 1 guy and you have differing skill levels on the team).  JMS is not
appropriate for a number of areas.  In truth I've not yet learned enough
about SOAP to speak intelligently  about it

> #2 just because you may eventually distribute your business logic, assuming
> you're going to from the start (and assuming that means EJBs and then
> jumping through lots of EJB hoops & headeaches and paying a fortune to some
> EJB vendors) is bad XP practice IMHO
> 

I'm not into XP, but often the scalability concern happens over night. 
There should be some framework in place for making it possible to do
this somewhat suddenly.

I'd say you have about a weeks warning on most systems on just how much
you need to scale up after deployment.  Systems are make it or break
it.  You can apply techniques to make this more predictive, but a lot of
this happens outside my area of control most of the time.  (Political,
socio-economic and chaos theory are involved which often result in
unpredictable community size, and you must plan to be way off no matter
how careful or disciplined your approach)

> I prefer to take an XP approach, first build a web application that works,
> is performant and scalable then worry about whether business logic needs to
> be distributed later. Afterall us Java folk are OO guys right? We can write
> our business logic in such a way that it could migrate to EJB later if we
> think thats the right thing to do.
> 

I'm more into a scalable version of the RUP.  In my opinion XP is a hack
of a methodology (the RUP actually covers most of its issues).  XP also
suffers from the misconception that programming is the most important
activity in software development (I would argue requirements gathering
as the most important activity in software development...programming is
easy, figuring out WHAT to program is hard This is not to say I'm
not into an iterative approach to this, only that I think XP is
lacking.  At least it admits its own lack of scalability.)

One day I'll start a project to create a methodology that merges the
disciplined approach to software that I admire with the opensource
principles and approaches that I think are necessary for effective
teamwork.  (minus the flamewars ;-) ). 

> Or to put that another way - I'd prefer to focus on giving the customer what
> they want and making a good web application than grappling with EJBs just

That is irrelevant to the issue.  I would like to see an adequate
distributed system (which it looks like there are at least 2 in the
works within or slightly external to our community), and EJB does not
fit the definition.

> because one day, maybe, under some conditions, I might want to distribute
> some of the business logic in the web app under the 'faith' that its the
> right thing to do.
> 

That doesn't mean you plug your fingers in your ears and say "na na na
scalability I'll refactor later".. I find a balanced approach between
planing for the future and refactoring later works best.  We do need an
adequate distributed object system for some situations. 

> Most business logic in most web applications is pretty minimal in terms of
> computation and is often mostly database intensive so moving this code to
> another process doesn't usually buy much in terms of scalability - if
> anything its the reverse thats true - what with all that EJB distributed
> garbage collection & connection based protocol stuff that needs to be done
> scalability (and usually always performance) can go down.
> 
> 

+1

> 
> > If your application will grow it is good to have a middle tier that
> > can be moved and load balanced.  With Entity beans of course this is
> > less possible.
> 
> (And stateful session beans ;-).
> 

yes.

> I think this is true of traditional GUIs, say a Swing client front end, a
> middle tier server (say server side beans aka EJBs) and a database. I don't
> think this is true of web applications as they are quite different things -
> a servlet engine is not a 'GUI' client.
> 
> Servlet engines are a stable, performant and very scalable application
> servers in their own right. Get a hardware load balancer and a farm of
> servlet engines and your *way* scalable.
> 

Its very difficult to assure data validity in this manner without some
rather complex logic for database management.

> Arguing for the need for another, remote CORBA component-centric application
> server based on mostly connection-ba

Re: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

Those are both search engines with non-critical data update issues.  You
do need an example with more business-logic oriented type
functionality.  I could mock something like those up with Lucene just
with a few routers and pushing the indicies to the mirrored systems. 
This doesn't answer the "enterprise system" question.  Secondly we need
examples on a more moderate basis.  

(sorry, if that sounds critical, I don't mean to be, I think you're
heading the discussion the right direction, I just don't think those
examples do that)

On a more personal note.  Funny story: My wife went to high/grade school
with the Google guy.  Small world eh? 

-Andy

On Fri, 2002-02-01 at 08:57, Ted Husted wrote:
> Perhaps the question to ask is how are real sites providing real
> scalabilty without resorting to Enterprise JavaBeans?
> 
> Take google.com and yahoo.com for example, 
> 
> Yahoo offers a signficant number of remote, multi-user applications like
> the ones we would like to provide to our own clients. Are they using
> EJBs? If not, what do they use? How can we turn Yahoo's approach into a
> toolkit model that other developers can use?
> 
> Google is offering a single, read-only servvice, but at mind-bending
> speed. How does it serve so many users so quickly? Again, how can we
> package that approach in a way that it accessible to other developers?
> 
> Sorry to be providing more queries than code, but to paraphrase Linus,
> it often takes one person to articulate an issue, and another to resolve
> it =:o)
> 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 08:59, Paulo Gaspar wrote:
> Paul already talked about a couple ways of tuning the use of remote
> calls without having to do it on a case by case basis.
> 

I'll reread the archive after I finish my coffee ;-)

> However, the thumb rule is that:
>  - Either you build the system to be scalable (which might make it
>a bit less efficient when having it working in a single machine
>when compared to a non scalable system);
> 

true.  There are *how much* issue though.  I mean the 400-500 times
slower rule of CMP Entity beans would go into the area of being
ridiculous. Sun is still a year and a half behind.  A year and a half
ago when hardware was dirt cheap and programmers were expensive perhaps
this would have made more sense.  But even then...bandwidth wasn't 

Always build some scalability.  You'll either fail or succeed.  This
means you'll either have too few users or too many.  If your system
can't take it then there is a self correcting mechanism in place (users
all get ticked and go back to whatever they did before you came along). 
So you always need some scalability.  Always plan to refactor of course,
and good design can protect you from some issues (facades for areas that
will likely be implemented otherwise later), but the system must be
inherently scalable.  (This doesn't mean you need a CTM for your low
volume 1 megabyte website, but you get the picture) 

>  - Or you use some "transparency" mechanism and you tend to loose
>robustness/control when compared to a system that is aware of
>possible communications issues and tries to handle them.
> 

I still think there is a way to at least make this *configurable*.  

> Some communications issues can be recovered from and some not. And
> sometimes the decision to try to recover or not depends on the
> kind of operation you are performing.
> 
> And I also agree with Paul that the RemoteException is NOT a bit
> help.
> 

That of course had nothing to do with my issue.

> Do you believe on magic bullets that work everywhere?

No but I do believe that location transparency is a good thing.

> We keep trying to get as close to having them as possible but...
> 
> 
> Have fun,
> Paulo Gaspar
> 
> > -Original Message-
> > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, February 01, 2002 2:19 PM
> > To: Jakarta General List
> > Subject: RE: [OT] RE: J2EE considered harmful
> >
> >
> > So what if you need to move an object that is defined as local to be
> > load balanced across machines?  I think you're wrong on that one.  If
> > you have to define it as local you loose scalability by definition
> > unless you accept the hardware vendor's edition of scalability (buy an
> > E1 instead and junk your old machine ;-) ).
> >
> > On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote:
> > > I do not think so. Handling in a proper way situations that are
> > > specific to a remote call does not mean that the architecture of
> > > the app must be less scalable.
> > >
> > >
> > > Have fun,
> > > Paulo
> > >
> > > > -Original Message-
> > > > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, February 01, 2002 7:03 AM
> > > > To: Jakarta General List
> > > > Subject: RE: [OT] RE: J2EE considered harmful
> > > >
> > > >
> > > > Albeit at the expense of scalability
> > > >
> > > > On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> > > > > I think that the key bit is:
> > > > >  > and it is a mistake to try to program
> > > > >  > as though a
> > > > >  > remote call had the same characteristics as a local one.
> > > > >
> > > > > Your app will always be more robust if you do NOT ignore the
> > > > > specific issues of a remote call.
> > > > >
> > > > >
> > > > > Have fun,
> > > > > Paulo Gaspar
> > > > >
> > > > > > -Original Message-
> > > > > > From: Fernandez Martinez, Alejandro
> > > > > > [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Thursday, January 31, 2002 1:50 PM
> > > > > > To: 'Jakarta General List'
> > > > > > Subject: [OT] RE: J2EE considered harmful
> > > > > >
> > > > > >
> > > > > > Hi Tim.
> > > > > >
> > > > > > I agree with your point of view, we've been trying t

Re: J2EE considered harmful

[James Strachan]

Hey Andrew

Insteresting thread ;-)

- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> On Fri, 2002-02-01 at 04:14, James Strachan wrote:
> > Hi Jeff
> >
> > I share your oppinions on EJB. Whenever I ask developers why they are
using
> > EJB the common answer I get from people is 'well I get transactions for
> > free'. When most of the time they don't do 2 phase commit with their
> > database anyways. And all that extra work just to get 'acceptable'
> > performance from EJB. Jeez this stuff is meant to help us not hinder us.
> >
> > I agree that EJB has shoved too many things together in one 'server side
> > component' framework. Perhaps working from core specs is better and just
> > choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal
bias
> > is to use 'local' object technologies such as Java Beans, Servlets,
JDBC,
> > JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS,
HTTP
> > or whatnot) when distribution is required. I try to avoid RMI if truth
be
> > told. It seems so 80s ;-)
> >
> > I'm still not convinced at all that EJBs are even worth considering when
> > when building web applications - why should be business logic be remote
in a
> > web-centric world? Why not deploy the business logic with the web
>
> I agree with everything but this.
>
> For scalability you should have the option but should not always use
> it.

Agreed. Though I've 2 points to make.

#1 you don't need to use EJBs to distribute business logic If you do need to
distribute business logic, then there are various alternatives open, from
HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
cost/benefits etc.

#2 just because you may eventually distribute your business logic, assuming
you're going to from the start (and assuming that means EJBs and then
jumping through lots of EJB hoops & headeaches and paying a fortune to some
EJB vendors) is bad XP practice IMHO

I prefer to take an XP approach, first build a web application that works,
is performant and scalable then worry about whether business logic needs to
be distributed later. Afterall us Java folk are OO guys right? We can write
our business logic in such a way that it could migrate to EJB later if we
think thats the right thing to do.

Or to put that another way - I'd prefer to focus on giving the customer what
they want and making a good web application than grappling with EJBs just
because one day, maybe, under some conditions, I might want to distribute
some of the business logic in the web app under the 'faith' that its the
right thing to do.

Most business logic in most web applications is pretty minimal in terms of
computation and is often mostly database intensive so moving this code to
another process doesn't usually buy much in terms of scalability - if
anything its the reverse thats true - what with all that EJB distributed
garbage collection & connection based protocol stuff that needs to be done
scalability (and usually always performance) can go down.



> If your application will grow it is good to have a middle tier that
> can be moved and load balanced.  With Entity beans of course this is
> less possible.

(And stateful session beans ;-).

I think this is true of traditional GUIs, say a Swing client front end, a
middle tier server (say server side beans aka EJBs) and a database. I don't
think this is true of web applications as they are quite different things -
a servlet engine is not a 'GUI' client.

Servlet engines are a stable, performant and very scalable application
servers in their own right. Get a hardware load balancer and a farm of
servlet engines and your *way* scalable.

Arguing for the need for another, remote CORBA component-centric application
server based on mostly connection-based protocols, RMI, stubs and
distributed garbage collection to make your web-application more scalable
seems, well, strange.

In my experience web applications scale best when you have a big server farm
of servlet engines which are load balanced. A database at the back and
hopefully some kind of read only caching going on to take as much load off
the poor database as you can. Then you can distribute parts of your web
application into different server farms, get load balancing, shuffle things
around as load changes etc. Then pick the web technologies of your choice,
Struts, JSP, Velocity, Turbine etc. Away you go.

I still don't see the 'scalability' argument as in any way advocating that
EJBs are actually useful for web applications.

In fact this idea that EJBs are required to build scalable web applications
is plain false - probably marketing hype spread by the EJB vendors.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [OT] RE: J2EE considered harmful

[Ted Husted]

Perhaps the question to ask is how are real sites providing real
scalabilty without resorting to Enterprise JavaBeans?

Take google.com and yahoo.com for example, 

Yahoo offers a signficant number of remote, multi-user applications like
the ones we would like to provide to our own clients. Are they using
EJBs? If not, what do they use? How can we turn Yahoo's approach into a
toolkit model that other developers can use?

Google is offering a single, read-only servvice, but at mind-bending
speed. How does it serve so many users so quickly? Again, how can we
package that approach in a way that it accessible to other developers?

Sorry to be providing more queries than code, but to paraphrase Linus,
it often takes one person to articulate an issue, and another to resolve
it =:o)


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Paulo Gaspar]

Paul already talked about a couple ways of tuning the use of remote
calls without having to do it on a case by case basis.

However, the thumb rule is that:
 - Either you build the system to be scalable (which might make it
   a bit less efficient when having it working in a single machine
   when compared to a non scalable system);

 - Or you use some "transparency" mechanism and you tend to loose
   robustness/control when compared to a system that is aware of
   possible communications issues and tries to handle them.

Some communications issues can be recovered from and some not. And
sometimes the decision to try to recover or not depends on the
kind of operation you are performing.

And I also agree with Paul that the RemoteException is NOT a bit
help.

Do you believe on magic bullets that work everywhere?
We keep trying to get as close to having them as possible but...


Have fun,
Paulo Gaspar

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 2:19 PM
> To: Jakarta General List
> Subject: RE: [OT] RE: J2EE considered harmful
>
>
> So what if you need to move an object that is defined as local to be
> load balanced across machines?  I think you're wrong on that one.  If
> you have to define it as local you loose scalability by definition
> unless you accept the hardware vendor's edition of scalability (buy an
> E1 instead and junk your old machine ;-) ).
>
> On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote:
> > I do not think so. Handling in a proper way situations that are
> > specific to a remote call does not mean that the architecture of
> > the app must be less scalable.
> >
> >
> > Have fun,
> > Paulo
> >
> > > -Original Message-
> > > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, February 01, 2002 7:03 AM
> > > To: Jakarta General List
> > > Subject: RE: [OT] RE: J2EE considered harmful
> > >
> > >
> > > Albeit at the expense of scalability
> > >
> > > On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> > > > I think that the key bit is:
> > > >  > and it is a mistake to try to program
> > > >  > as though a
> > > >  > remote call had the same characteristics as a local one.
> > > >
> > > > Your app will always be more robust if you do NOT ignore the
> > > > specific issues of a remote call.
> > > >
> > > >
> > > > Have fun,
> > > > Paulo Gaspar
> > > >
> > > > > -Original Message-
> > > > > From: Fernandez Martinez, Alejandro
> > > > > [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Thursday, January 31, 2002 1:50 PM
> > > > > To: 'Jakarta General List'
> > > > > Subject: [OT] RE: J2EE considered harmful
> > > > >
> > > > >
> > > > > Hi Tim.
> > > > >
> > > > > I agree with your point of view, we've been trying to avoid EJBs
> > > > > as much as
> > > > > possible. But there's one thing I don't understand.
> > > > >
> > > > > > -Mensaje original-
> > > > > > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > > > > > 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.
> > > > >
> > > > > Why is it a mistake? I think a remote proxy is a great way to
> > > make remote
> > > > > calls, shielding the developer from the complexity of it all.
> > > The recent
> > > > > discussion about AltRMI has shown that there's a lot of
> > > interest in using
> > > > > proxies, but it was Sun's implementation (the Remote*
> stuff) that was
> > > > > flawed.
> > > > >
> > > > > Un saludo,
> > > > >
> > > > > Alex.
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTEC

RE: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 08:27, Paulo Gaspar wrote:
> This is getting interesting and we have e lot of pieces for this kind
> of puzzle around Apache.
> 
> Why must standards be ruled just by the BigCo's???
> 
> De facto standards happen when a product is really good.
> 
> This reminds me how the then tiny dog Borland turned Turbo Pascal 
> into the de facto standard Pascal language in a couple of years. All 
> Pascal language related products wanted to be compatible with it and 
> not with whatever was the standard Pascal. All the big dogs had to 
> run away.
> 

+1

> 
> 
> Have fun,
> Paulo Gaspar
> 
> > -Original Message-
> > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 31, 2002 10:54 PM
> > To: Jakarta General List
> > Subject: RE: J2EE considered harmful
> > 
> > 
> > > From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> > > 
> > > Are you just talking about creating a new language, or what?  What is
> > your
> > > idea?  I cannot tell.
> > 
> > That's a good question, and ultimately one which would be determined by
> > the constraints of the technology.  Prototyping would probably involve
> > using an existing language and platform, and maybe we would ultimately
> > discover that it is possible to build a system like this on top of a JVM
> > (or CLR).  My suspicion is that it is not, and may be undesirable for
> > legal reasons anyways.
> > 
> > The later part of my diatribe was a hastily phrased way of approaching
> > this subject:
> > 
> > Unless you want to go back to the dark ages of C++, the future is
> > shaping up to look like a choice between writing for the Sun platform or
> > the Microsoft platform.  This does not make me comfortable, especially
> > considering that Sun's approach to Java so far has been *wholly*
> > anathema to the principals of Open Source.  At least Microsoft has
> > submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*
> > 
> > I am tantalized by the idea of a third choice:  the Apache platform.  I
> > propose a discussion of just what that might be.
> > 
> > Jeff Schnitzer
> > [EMAIL PROTECTED]
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

RE: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

So what if you need to move an object that is defined as local to be
load balanced across machines?  I think you're wrong on that one.  If
you have to define it as local you loose scalability by definition
unless you accept the hardware vendor's edition of scalability (buy an
E1 instead and junk your old machine ;-) ).

On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote:
> I do not think so. Handling in a proper way situations that are
> specific to a remote call does not mean that the architecture of
> the app must be less scalable.
> 
> 
> Have fun,
> Paulo
> 
> > -Original Message-
> > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, February 01, 2002 7:03 AM
> > To: Jakarta General List
> > Subject: RE: [OT] RE: J2EE considered harmful
> > 
> > 
> > Albeit at the expense of scalability
> > 
> > On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> > > I think that the key bit is:
> > >  > and it is a mistake to try to program 
> > >  > as though a
> > >  > remote call had the same characteristics as a local one.
> > > 
> > > Your app will always be more robust if you do NOT ignore the
> > > specific issues of a remote call.
> > > 
> > > 
> > > Have fun,
> > > Paulo Gaspar
> > > 
> > > > -Original Message-
> > > > From: Fernandez Martinez, Alejandro
> > > > [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, January 31, 2002 1:50 PM
> > > > To: 'Jakarta General List'
> > > > Subject: [OT] RE: J2EE considered harmful
> > > > 
> > > > 
> > > > Hi Tim.
> > > > 
> > > > I agree with your point of view, we've been trying to avoid EJBs 
> > > > as much as
> > > > possible. But there's one thing I don't understand.
> > > > 
> > > > > -Mensaje original-
> > > > > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > > > > 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.
> > > > 
> > > > Why is it a mistake? I think a remote proxy is a great way to 
> > make remote
> > > > calls, shielding the developer from the complexity of it all. 
> > The recent
> > > > discussion about AltRMI has shown that there's a lot of 
> > interest in using
> > > > proxies, but it was Sun's implementation (the Remote* stuff) that was
> > > > flawed.
> > > > 
> > > > Un saludo,
> > > > 
> > > > Alex.
> > > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> > > 
> > -- 
> > www.superlinksoftware.com
> > www.sourceforge.net/projects/poi - port of Excel format to java
> > http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
> > - fix java generics!
> > 
> > 
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

RE: J2EE considered harmful

[Andrew C. Oliver]

> of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
> who enjoy working on nonvirtual machines, but they're crazy :-)

I'm not completely sure I followed this.  I was cool up until the above
line.  Are you suggesting just a replacement for J2EE or Java itself. 
I'm fairly satisfied with Java as a language except for Sun's upcoming
half-assed implementation of "Java Generics", but not the J2EE stuff.  

On Thu, 2002-01-31 at 15:38, Jeff Schnitzer wrote:
> Amusingly enough, I've been considering writing an article with this
> exact same title.  I've implemented two medium-sized systems using EJBs
> (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
> been haunting the ejb-interest list for more than a year.  I was never
> ecstatic about the technology, but now I'm starting to feel downright
> disillusioned with it.
> 
> This is not coming from someone stumbling around with the technology.
> The first thing I did was read Richard Monson-Haefel's book
> cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
> implementation.  I've got most of the 2.0 spec memorized.  I have no
> trouble writing the deployment descriptors by hand.
> 
> The problem is, even after more than a year of this, I still find that
> writing software using EJBs is a steady progress of fighting the
> technology to make it do what you want.  It shouldn't be like this.
> 
> Having to write three or four different classes, plus an elaborate
> deployment descriptor for each object slows things down a bit.  Tools
> like xdoclet help, but it's still a complicated and painful process to
> refactor anything.
> 
> Basic software design patterns are agonizing or impossible to implement.
> Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
> Not in the framework... you have to set up an external RMI server.
> 
> Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
> entity beans are not remotely mature.  There is no support for
> relationship attributes or automatically generated primary keys.  The
> query language is constrictive, offering no support for ordering,
> aggregation functions, or retrieving data which spans more than a single
> class.  After 20+ years of research and advancement in RDBMS technology,
> this is a colossal step backwards, and the consequence is that entity
> beans radically underperform systems with more direct database access.
> I find that I must constantly sidestep the container with direct JDBC in
> order to meet performance or feature requirements, and it sounds like
> this is a common problem.
> 
> Overall, my feeling is that Sun tried to cram too many disparate
> technologies into a single API.  EJB!  It's a distributed object model,
> transaction model, security model, persistence model, component model,
> message queue, desert topping, and floor wax all rolled into one!  Some
> of it makes sense, but some of it (especially persistence) doesn't.
> 
> I'm surprised that people can build large applications with EJB.  My
> guess is that it's probably very effective for one particular class of
> problem - ecommerce apps.  I'm sure it's no accident that all the
> examples in the spec are Order, LineItem, etc.  Unfortunately, this
> doesn't help me, or any of the rest of the people who are working on
> applications that are actually interesting.  And my guess is that since
> ecommerce is 90% of the market for expensive app servers, Sun doesn't
> really care.
> 
> 
> Ok, enough whining.  What to do about it?  I really like the idea of an
> Apache community building a truly free competitor to J2EE.  I don't like
> being tied to technologies owned by a single company, so I'm already
> pretty nervous by the stranglehold that Sun has on Java and (especially)
> J2EE.  But it's not enough to build a marginal improvement over the
> existing system, even with Apache's mindshare.  Besides, who wants to
> copy a mediocre idea? :-)
> 
> I've been giving a lot of thought to distributed object models lately.
> I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a
> lot of the same.  Since networks are getting so fast these days, I'm
> starting to really wonder what it would be like to have a model in
> which:
> 
> * All objects are inherently remotable.
> * Objects transparently migrate for efficiency.
> 
> I can think of many interesting, fairly revolutionary consequences of
> such a system and I'd love to discuss them.  Ultimately, if such a
> system ever made it out of research and into prototype, it could
> challenge both Java and .NET, and possibly stave off the coming hegemony
> of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
> who enjoy working on nonvirtual machines, but they're crazy :-)
> 
> Does anyone think some variant of this idea to be worth pursuing?  Or is
> everyone wedded to the idea of working on the proprietary Sun platform
> known as Java?
> 
> Jeff Schnitzer
> [EMAIL PROTECTED]

RE: J2EE considered harmful

[Andrew C. Oliver]

On Thu, 2002-01-31 at 16:54, Jeff Schnitzer wrote:
> > From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> > 
> > Are you just talking about creating a new language, or what?  What is
> your
> > idea?  I cannot tell.
> 
> That's a good question, and ultimately one which would be determined by
> the constraints of the technology.  Prototyping would probably involve
> using an existing language and platform, and maybe we would ultimately
> discover that it is possible to build a system like this on top of a JVM
> (or CLR).  My suspicion is that it is not, and may be undesirable for
> legal reasons anyways.
> 
> The later part of my diatribe was a hastily phrased way of approaching
> this subject:
> 
> Unless you want to go back to the dark ages of C++, the future is
> shaping up to look like a choice between writing for the Sun platform or
> the Microsoft platform.  This does not make me comfortable, especially
> considering that Sun's approach to Java so far has been *wholly*
> anathema to the principals of Open Source.  At least Microsoft has
> submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*
> 

I'm kinda interested in this:

http://www.digitalmars.com/d/

-Andy 

> I am tantalized by the idea of a third choice:  the Apache platform.  I
> propose a discussion of just what that might be.
> 
> Jeff Schnitzer
> [EMAIL PROTECTED]
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Paulo Gaspar]

This is getting interesting and we have e lot of pieces for this kind
of puzzle around Apache.

Why must standards be ruled just by the BigCo's???

De facto standards happen when a product is really good.

This reminds me how the then tiny dog Borland turned Turbo Pascal 
into the de facto standard Pascal language in a couple of years. All 
Pascal language related products wanted to be compatible with it and 
not with whatever was the standard Pascal. All the big dogs had to 
run away.



Have fun,
Paulo Gaspar

> -Original Message-
> From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 31, 2002 10:54 PM
> To: Jakarta General List
> Subject: RE: J2EE considered harmful
> 
> 
> > From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> > 
> > Are you just talking about creating a new language, or what?  What is
> your
> > idea?  I cannot tell.
> 
> That's a good question, and ultimately one which would be determined by
> the constraints of the technology.  Prototyping would probably involve
> using an existing language and platform, and maybe we would ultimately
> discover that it is possible to build a system like this on top of a JVM
> (or CLR).  My suspicion is that it is not, and may be undesirable for
> legal reasons anyways.
> 
> The later part of my diatribe was a hastily phrased way of approaching
> this subject:
> 
> Unless you want to go back to the dark ages of C++, the future is
> shaping up to look like a choice between writing for the Sun platform or
> the Microsoft platform.  This does not make me comfortable, especially
> considering that Sun's approach to Java so far has been *wholly*
> anathema to the principals of Open Source.  At least Microsoft has
> submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*
> 
> I am tantalized by the idea of a third choice:  the Apache platform.  I
> propose a discussion of just what that might be.
> 
> Jeff Schnitzer
> [EMAIL PROTECTED]
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

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

Re: J2EE considered harmful

[Andrew C. Oliver]

On Fri, 2002-02-01 at 04:14, James Strachan wrote:
> Hi Jeff
> 
> I share your oppinions on EJB. Whenever I ask developers why they are using
> EJB the common answer I get from people is 'well I get transactions for
> free'. When most of the time they don't do 2 phase commit with their
> database anyways. And all that extra work just to get 'acceptable'
> performance from EJB. Jeez this stuff is meant to help us not hinder us.
> 
> I agree that EJB has shoved too many things together in one 'server side
> component' framework. Perhaps working from core specs is better and just
> choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias
> is to use 'local' object technologies such as Java Beans, Servlets, JDBC,
> JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP
> or whatnot) when distribution is required. I try to avoid RMI if truth be
> told. It seems so 80s ;-)
> 
> I'm still not convinced at all that EJBs are even worth considering when
> when building web applications - why should be business logic be remote in a
> web-centric world? Why not deploy the business logic with the web

I agree with everything but this.

For scalability you should have the option but should not always use
it.  If your application will grow it is good to have a middle tier that
can be moved and load balanced.  With Entity beans of course this is
less possible.  


> application and save all those costly synchronous RMI calls. You can have
> seperation of concerns without making things remote. You only have to look
> at MS's PetShop to see how simple and fast to develop web applications could
> be while still seperating business logic, persistence and presentation - or
> how slow and painful they can be if you follow the EJB path.
> 
> I do think a simple open source alternative to EJB would be a good thing.
> Already Jakarta has most of the bits almost in place, tying them all
> together would be cool.
> 

+1

> FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons
> which hopes to make RMI and the Remote stuff much easier.
> 
> James
> - Original Message -
> From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Thursday, January 31, 2002 8:38 PM
> Subject: RE: J2EE considered harmful
> 
> 
> Amusingly enough, I've been considering writing an article with this
> exact same title.  I've implemented two medium-sized systems using EJBs
> (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
> been haunting the ejb-interest list for more than a year.  I was never
> ecstatic about the technology, but now I'm starting to feel downright
> disillusioned with it.
> 
> This is not coming from someone stumbling around with the technology.
> The first thing I did was read Richard Monson-Haefel's book
> cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
> implementation.  I've got most of the 2.0 spec memorized.  I have no
> trouble writing the deployment descriptors by hand.
> 
> The problem is, even after more than a year of this, I still find that
> writing software using EJBs is a steady progress of fighting the
> technology to make it do what you want.  It shouldn't be like this.
> 
> Having to write three or four different classes, plus an elaborate
> deployment descriptor for each object slows things down a bit.  Tools
> like xdoclet help, but it's still a complicated and painful process to
> refactor anything.
> 
> Basic software design patterns are agonizing or impossible to implement.
> Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
> Not in the framework... you have to set up an external RMI server.
> 
> Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
> entity beans are not remotely mature.  There is no support for
> relationship attributes or automatically generated primary keys.  The
> query language is constrictive, offering no support for ordering,
> aggregation functions, or retrieving data which spans more than a single
> class.  After 20+ years of research and advancement in RDBMS technology,
> this is a colossal step backwards, and the consequence is that entity
> beans radically underperform systems with more direct database access.
> I find that I must constantly sidestep the container with direct JDBC in
> order to meet performance or feature requirements, and it sounds like
> this is a common problem.
> 
> Overall, my feeling is that Sun tried to cram too many disparate
> technologies into a single API.  EJB!  It's a distributed objec

RE: [OT] RE: J2EE considered harmful

[Paulo Gaspar]

I do not think so. Handling in a proper way situations that are
specific to a remote call does not mean that the architecture of
the app must be less scalable.


Have fun,
Paulo

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 7:03 AM
> To: Jakarta General List
> Subject: RE: [OT] RE: J2EE considered harmful
> 
> 
> Albeit at the expense of scalability
> 
> On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> > I think that the key bit is:
> >  > and it is a mistake to try to program 
> >  > as though a
> >  > remote call had the same characteristics as a local one.
> > 
> > Your app will always be more robust if you do NOT ignore the
> > specific issues of a remote call.
> > 
> > 
> > Have fun,
> > Paulo Gaspar
> > 
> > > -Original Message-
> > > From: Fernandez Martinez, Alejandro
> > > [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, January 31, 2002 1:50 PM
> > > To: 'Jakarta General List'
> > > Subject: [OT] RE: J2EE considered harmful
> > > 
> > > 
> > > Hi Tim.
> > > 
> > > I agree with your point of view, we've been trying to avoid EJBs 
> > > as much as
> > > possible. But there's one thing I don't understand.
> > > 
> > > > -Mensaje original-
> > > > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > > > 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.
> > > 
> > > Why is it a mistake? I think a remote proxy is a great way to 
> make remote
> > > calls, shielding the developer from the complexity of it all. 
> The recent
> > > discussion about AltRMI has shown that there's a lot of 
> interest in using
> > > proxies, but it was Sun's implementation (the Remote* stuff) that was
> > > flawed.
> > > 
> > > Un saludo,
> > > 
> > > Alex.
> > > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> > 
> -- 
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
>   - fix java generics!
> 
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

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

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> 
> Are you just talking about creating a new language, or what?  What is
your
> idea?  I cannot tell.

That's a good question, and ultimately one which would be determined by
the constraints of the technology.  Prototyping would probably involve
using an existing language and platform, and maybe we would ultimately
discover that it is possible to build a system like this on top of a JVM
(or CLR).  My suspicion is that it is not, and may be undesirable for
legal reasons anyways.

The later part of my diatribe was a hastily phrased way of approaching
this subject:

Unless you want to go back to the dark ages of C++, the future is
shaping up to look like a choice between writing for the Sun platform or
the Microsoft platform.  This does not make me comfortable, especially
considering that Sun's approach to Java so far has been *wholly*
anathema to the principals of Open Source.  At least Microsoft has
submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*

I am tantalized by the idea of a third choice:  the Apache platform.  I
propose a discussion of just what that might be.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: J2EE considered harmful

[James Strachan]

Hi Jeff

I share your oppinions on EJB. Whenever I ask developers why they are using
EJB the common answer I get from people is 'well I get transactions for
free'. When most of the time they don't do 2 phase commit with their
database anyways. And all that extra work just to get 'acceptable'
performance from EJB. Jeez this stuff is meant to help us not hinder us.

I agree that EJB has shoved too many things together in one 'server side
component' framework. Perhaps working from core specs is better and just
choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias
is to use 'local' object technologies such as Java Beans, Servlets, JDBC,
JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP
or whatnot) when distribution is required. I try to avoid RMI if truth be
told. It seems so 80s ;-)

I'm still not convinced at all that EJBs are even worth considering when
when building web applications - why should be business logic be remote in a
web-centric world? Why not deploy the business logic with the web
application and save all those costly synchronous RMI calls. You can have
seperation of concerns without making things remote. You only have to look
at MS's PetShop to see how simple and fast to develop web applications could
be while still seperating business logic, persistence and presentation - or
how slow and painful they can be if you follow the EJB path.

I do think a simple open source alternative to EJB would be a good thing.
Already Jakarta has most of the bits almost in place, tying them all
together would be cool.

FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons
which hopes to make RMI and the Remote stuff much easier.

James
- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, January 31, 2002 8:38 PM
Subject: RE: J2EE considered harmful


Amusingly enough, I've been considering writing an article with this
exact same title.  I've implemented two medium-sized systems using EJBs
(http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
been haunting the ejb-interest list for more than a year.  I was never
ecstatic about the technology, but now I'm starting to feel downright
disillusioned with it.

This is not coming from someone stumbling around with the technology.
The first thing I did was read Richard Monson-Haefel's book
cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
implementation.  I've got most of the 2.0 spec memorized.  I have no
trouble writing the deployment descriptors by hand.

The problem is, even after more than a year of this, I still find that
writing software using EJBs is a steady progress of fighting the
technology to make it do what you want.  It shouldn't be like this.

Having to write three or four different classes, plus an elaborate
deployment descriptor for each object slows things down a bit.  Tools
like xdoclet help, but it's still a complicated and painful process to
refactor anything.

Basic software design patterns are agonizing or impossible to implement.
Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
Not in the framework... you have to set up an external RMI server.

Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
entity beans are not remotely mature.  There is no support for
relationship attributes or automatically generated primary keys.  The
query language is constrictive, offering no support for ordering,
aggregation functions, or retrieving data which spans more than a single
class.  After 20+ years of research and advancement in RDBMS technology,
this is a colossal step backwards, and the consequence is that entity
beans radically underperform systems with more direct database access.
I find that I must constantly sidestep the container with direct JDBC in
order to meet performance or feature requirements, and it sounds like
this is a common problem.

Overall, my feeling is that Sun tried to cram too many disparate
technologies into a single API.  EJB!  It's a distributed object model,
transaction model, security model, persistence model, component model,
message queue, desert topping, and floor wax all rolled into one!  Some
of it makes sense, but some of it (especially persistence) doesn't.

I'm surprised that people can build large applications with EJB.  My
guess is that it's probably very effective for one particular class of
problem - ecommerce apps.  I'm sure it's no accident that all the
examples in the spec are Order, LineItem, etc.  Unfortunately, this
doesn't help me, or any of the rest of the people who are working on
applications that are actually interesting.  And my guess is that since
ecommerce is 90% of the market for expensive app servers, Sun d

RE: J2EE considered harmful

[Micael Padraig Og mac Grene]

Are you just talking about creating a new language, or what?  What is your 
idea?  I cannot tell.

At 12:38 PM 1/31/02 -0800, you wrote:
>Amusingly enough, I've been considering writing an article with this
>exact same title.  I've implemented two medium-sized systems using EJBs
>(http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
>been haunting the ejb-interest list for more than a year.  I was never
>ecstatic about the technology, but now I'm starting to feel downright
>disillusioned with it.
>Ok, enough whining.  What to do about it?  I really like the idea of an
>Apache community building a truly free competitor to J2EE.  I don't like
>being tied to technologies owned by a single company, so I'm already
>pretty nervous by the stranglehold that Sun has on Java and (especially)
>J2EE.  But it's not enough to build a marginal improvement over the
>existing system, even with Apache's mindshare.  Besides, who wants to
>copy a mediocre idea? :-)






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Jeff Schnitzer]

Amusingly enough, I've been considering writing an article with this
exact same title.  I've implemented two medium-sized systems using EJBs
(http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
been haunting the ejb-interest list for more than a year.  I was never
ecstatic about the technology, but now I'm starting to feel downright
disillusioned with it.

This is not coming from someone stumbling around with the technology.
The first thing I did was read Richard Monson-Haefel's book
cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
implementation.  I've got most of the 2.0 spec memorized.  I have no
trouble writing the deployment descriptors by hand.

The problem is, even after more than a year of this, I still find that
writing software using EJBs is a steady progress of fighting the
technology to make it do what you want.  It shouldn't be like this.

Having to write three or four different classes, plus an elaborate
deployment descriptor for each object slows things down a bit.  Tools
like xdoclet help, but it's still a complicated and painful process to
refactor anything.

Basic software design patterns are agonizing or impossible to implement.
Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
Not in the framework... you have to set up an external RMI server.

Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
entity beans are not remotely mature.  There is no support for
relationship attributes or automatically generated primary keys.  The
query language is constrictive, offering no support for ordering,
aggregation functions, or retrieving data which spans more than a single
class.  After 20+ years of research and advancement in RDBMS technology,
this is a colossal step backwards, and the consequence is that entity
beans radically underperform systems with more direct database access.
I find that I must constantly sidestep the container with direct JDBC in
order to meet performance or feature requirements, and it sounds like
this is a common problem.

Overall, my feeling is that Sun tried to cram too many disparate
technologies into a single API.  EJB!  It's a distributed object model,
transaction model, security model, persistence model, component model,
message queue, desert topping, and floor wax all rolled into one!  Some
of it makes sense, but some of it (especially persistence) doesn't.

I'm surprised that people can build large applications with EJB.  My
guess is that it's probably very effective for one particular class of
problem - ecommerce apps.  I'm sure it's no accident that all the
examples in the spec are Order, LineItem, etc.  Unfortunately, this
doesn't help me, or any of the rest of the people who are working on
applications that are actually interesting.  And my guess is that since
ecommerce is 90% of the market for expensive app servers, Sun doesn't
really care.


Ok, enough whining.  What to do about it?  I really like the idea of an
Apache community building a truly free competitor to J2EE.  I don't like
being tied to technologies owned by a single company, so I'm already
pretty nervous by the stranglehold that Sun has on Java and (especially)
J2EE.  But it's not enough to build a marginal improvement over the
existing system, even with Apache's mindshare.  Besides, who wants to
copy a mediocre idea? :-)

I've been giving a lot of thought to distributed object models lately.
I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a
lot of the same.  Since networks are getting so fast these days, I'm
starting to really wonder what it would be like to have a model in
which:

* All objects are inherently remotable.
* Objects transparently migrate for efficiency.

I can think of many interesting, fairly revolutionary consequences of
such a system and I'd love to discuss them.  Ultimately, if such a
system ever made it out of research and into prototype, it could
challenge both Java and .NET, and possibly stave off the coming hegemony
of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
who enjoy working on nonvirtual machines, but they're crazy :-)

Does anyone think some variant of this idea to be worth pursuing?  Or is
everyone wedded to the idea of working on the proprietary Sun platform
known as Java?

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Andrew C. Oliver]

Albeit at the expense of scalability

On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote:
> I think that the key bit is:
>  > and it is a mistake to try to program 
>  > as though a
>  > remote call had the same characteristics as a local one.
> 
> Your app will always be more robust if you do NOT ignore the
> specific issues of a remote call.
> 
> 
> Have fun,
> Paulo Gaspar
> 
> > -Original Message-
> > From: Fernandez Martinez, Alejandro
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 31, 2002 1:50 PM
> > To: 'Jakarta General List'
> > Subject: [OT] RE: J2EE considered harmful
> > 
> > 
> > Hi Tim.
> > 
> > I agree with your point of view, we've been trying to avoid EJBs 
> > as much as
> > possible. But there's one thing I don't understand.
> > 
> > > -Mensaje original-
> > > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > > 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.
> > 
> > Why is it a mistake? I think a remote proxy is a great way to make remote
> > calls, shielding the developer from the complexity of it all. The recent
> > discussion about AltRMI has shown that there's a lot of interest in using
> > proxies, but it was Sun's implementation (the Remote* stuff) that was
> > flawed.
> > 
> > Un saludo,
> > 
> > Alex.
> > 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
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])

[Daniel Rall]

Tim, BRAVO.

Daniel

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Paulo Gaspar]

A bit more of OT inline:
=;o)

> -Original Message-
> From: Andrus Adamchik [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 31, 2002 10:50 PM
> To: Jakarta General List
> Subject: RE: J2EE considered harmful
>
>
> At 09:11 PM 1/31/2002 +0100, Paulo Gaspar wrote:
> >  (1) Not using that kind of layer does NOT mean that you have to
> >  concatenate Strings;
>
> Yes, am pretty sure there are ways to make life easier with SQL,
> sorry for bad comparison.

No reason to be sorry. The traditional approach you pointed is a PITA.
I am just mentioning alternatives.


> See, despite all of the skepticism about O/R mechanisms, I
> believe in this
> approach for one reason - I used a good O/R tool for major
> development for
> about 4 years now. I am talking about WebObjects. I believe this was the
> first application server out there (I think before even the term was
> coined). Now it lives in a relative obscurity since NeXT (the inventor of
> it) was bought by Apple, and Apple has no reputation for "enterprise"
> solutions.

I always read good thinking about WebObjects. I am really getting
curious about it.

> The bottom line here is that developer productivity goes up
> significantly.
> Code produced is incomparably easier to understand and maintain. And
> performance price is not that big (definitely not comparable to
> the impact EJB would make).

UAU! Good performance too?

I did read a lot about its productivity but nothing about
performance.


> >  (2) The use of Javabeans is abused.
>
> Totally agree. Still does not make this pattern bad. One use is a
> transport
> mechanism for data between the application parts. Clean and easy
> to understand.

Yes, but I think javabeans should be reserved for complex business
logic where it shines on the clean & easy aspects.

For data transport a lot can be automated in Java using approaches
like the Dynabeans. I mean, code like this:

bean1.field1 = someOtherSource.getObject("field1");
bean1.field2 = someOtherSource.getObject("field2");
...
bean1.field47 = someOtherSource.getObject("field47");

is really dumb and painful.

>  Sorry for an OT post, this J2EE licensing discussion got a
> bit off hand.

A lot of interesting discussions go on OT all the time.
=;o)

> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> - Andrei (a.k.a. Andrus) Adamchik
> http://objectstyle.org
> list email: andrus-jk at objectstyle dot org
> personal email: andrus at objectstyle dot org

Have fun,
Paulo Gaspar


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

RE: J2EE considered harmful

[Andrus Adamchik]

At 09:11 PM 1/31/2002 +0100, Paulo Gaspar wrote:
>  (1) Not using that kind of layer does NOT mean that you have to
>  concatenate Strings;

Yes, am pretty sure there are ways to make life easier with SQL, sorry for 
bad comparison.

See, despite all of the skepticism about O/R mechanisms, I believe in this 
approach for one reason - I used a good O/R tool for major development for 
about 4 years now. I am talking about WebObjects. I believe this was the 
first application server out there (I think before even the term was 
coined). Now it lives in a relative obscurity since NeXT (the inventor of 
it) was bought by Apple, and Apple has no reputation for "enterprise" 
solutions.

The bottom line here is that developer productivity goes up significantly. 
Code produced is incomparably easier to understand and maintain. And 
performance price is not that big (definitely not comparable to the impact 
EJB would make).


>  (2) The use of Javabeans is abused.

Totally agree. Still does not make this pattern bad. One use is a transport 
mechanism for data between the application parts. Clean and easy to understand.

 Sorry for an OT post, this J2EE licensing discussion got a bit off hand.

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
- Andrei (a.k.a. Andrus) Adamchik
http://objectstyle.org
list email: andrus-jk at objectstyle dot org
personal email: andrus at objectstyle dot org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: J2EE considered harmful

[Paulo Gaspar]

*persistence transparency* <=> *waste of efficiency*

There are no good systems that solve that yet. It only works for very
simple schemas.

Besides,
 (1) Not using that kind of layer does NOT mean that you have to
 concatenate Strings;
 (2) The use of Javabeans is abused.

For (1) I use SQL generators for the most common operations and SQL
templates - defined in an XML file - for the others. Having SQL defined
outside the Java code often saves a lot of time and avoids the
concatenation mess.

For (2)... just go to the jakarta-commons mail archives and check the
discussions about the DynaBeans stuff.


Have fun,
Paulo Gaspar



> -Original Message-
> From: Andrus Adamchik [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 31, 2002 8:43 PM
> To: [EMAIL PROTECTED]
> Subject: RE: J2EE considered harmful
>
> ...
>
> Well, if EJB (or others) are doing it wrong, it doesn't mean that Object
> Relational approach is bad. I agree that objects mapped straight to the
> rows one to one are not of much use by themselves. But they provide
> something that you will need to build your less fine grained objects,
> namely *persistence transparency*. By the same token you can say that any
> objects that use Java Bean pattern are useless, since all they
> have is get
> and set methods.
>
> But well, some people may like to concatenate SQL strings every time they
> want to get some data written or read to/from the database. The keyword
> here is "productivity".
>
>
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> - Andrei (a.k.a. Andrus) Adamchik
> http://objectstyle.org
> list email: andrus-jk at objectstyle dot org
> personal email: andrus at objectstyle dot org
>


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

RE: J2EE considered harmful

[Andrus Adamchik]

At 12:36 PM 1/31/2002 -0500, Steve Downey wrote:
>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.

Well, if EJB (or others) are doing it wrong, it doesn't mean that Object 
Relational approach is bad. I agree that objects mapped straight to the 
rows one to one are not of much use by themselves. But they provide 
something that you will need to build your less fine grained objects, 
namely *persistence transparency*. By the same token you can say that any 
objects that use Java Bean pattern are useless, since all they have is get 
and set methods.

But well, some people may like to concatenate SQL strings every time they 
want to get some data written or read to/from the database. The keyword 
here is "productivity".


~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
- Andrei (a.k.a. Andrus) Adamchik
http://objectstyle.org
list email: andrus-jk at objectstyle dot org
personal email: andrus at objectstyle dot org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Steve Downey]

> 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:   
For additional commands, e-mail: 

RE: [OT] RE: J2EE considered harmful

[Paulo Gaspar]

I think that the key bit is:
 > and it is a mistake to try to program 
 > as though a
 > remote call had the same characteristics as a local one.

Your app will always be more robust if you do NOT ignore the
specific issues of a remote call.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Fernandez Martinez, Alejandro
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 31, 2002 1:50 PM
> To: 'Jakarta General List'
> Subject: [OT] RE: J2EE considered harmful
> 
> 
> Hi Tim.
> 
> I agree with your point of view, we've been trying to avoid EJBs 
> as much as
> possible. But there's one thing I don't understand.
> 
> > -Mensaje original-
> > De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> > 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.
> 
> Why is it a mistake? I think a remote proxy is a great way to make remote
> calls, shielding the developer from the complexity of it all. The recent
> discussion about AltRMI has shown that there's a lot of interest in using
> proxies, but it was Sun's implementation (the Remote* stuff) that was
> flawed.
> 
> Un saludo,
> 
> Alex.
> 

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

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

[Andrew C. Oliver]

On Thu, 2002-01-31 at 08:37, Santiago Gala wrote:
> 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.
> 

Right.  I'm not saying you CAN'T do a good EJB system.  You can also do
a good JSP system (which does suck...but what do you expect when Sun
takes a page from Microsoft).  

I'm just saying its not good enough.  And Entity beans DO completely
suck.  Sun obviously knows it to because they keep drastically changing
the specs.  

The idea of EJB is suppose to make things easier and time to deploy
faster.  I don't think it will EVER do that...nice thought but no pie.  

> 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.

Want to achieve like 500% performance improvement?  Trash your entity
beans, write some queries and poof.  So you spent a good mount of time
kludging EJB, then in the end performance sucks, and I dare predict that
scalability is not as good as you think it is.

So far even vendor presentations about how they designed apps in such a
short time using their new cool tools have failed the all important
question:  "And just how much hardware did you put behind that?".  EJB
is pushing the envelope.  News flash, programmers are becoming cheaper
than E 1 servers again. ;-)  Its cheaper to do a good
implementation.  Anyhow if you're happy with EJB, then great.  I for one
would like to see a better and more open vendor-neutral standard.

> - My main issue in the development were related with using JSP for the 
> interface (JSP sucks (c) Jon :) )
> 
+1

However, know there are some environments where the only thing worse
than JSP are the programmers that are using it.  Its appropriate for
"programmers" who don't know how to program.  Its also a bit better than
many of the other things in that problem area that were developed around
the same time.

> 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.
> 
> 

Like I said.  Even if I don't like it, I'll have to work in it.  I guess
I shouldn't pee in the river from which I drink, but I still think its a
very bad standard and poorly designed one.

-Andy

> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[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:   
For additional commands, e-mail: 

[OT] RE: J2EE considered harmful

[Fernandez Martinez, Alejandro]

Hi Tim.

I agree with your point of view, we've been trying to avoid EJBs as much as
possible. But there's one thing I don't understand.

> -Mensaje original-
> De: Tim Hyde [mailto:[EMAIL PROTECTED]]
> 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.

Why is it a mistake? I think a remote proxy is a great way to make remote
calls, shielding the developer from the complexity of it all. The recent
discussion about AltRMI has shown that there's a lot of interest in using
proxies, but it was Sun's implementation (the Remote* stuff) that was
flawed.

Un saludo,

Alex.

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

[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 anot