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: [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: [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: [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: [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: [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: [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: [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: [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: [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: [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: [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: [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: [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]>

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