<P>Note:  This file has moved to <A HREF="/notablog">notablog</A>.</P>

		  From puff Fri Jun 16 18:54:08 2000
Received: (from puff@localhost)
	by guild.net (8.9.1/8.9.1) id SAA08952;
	Fri, 16 Jun 2000 18:52:03 -0400
From: puff
Message-Id: <200006162252.SAA08952@guild.net>
Subject: Re: EJB and  JavaBeans
To: JSP-INTEREST@JAVA.SUN.COM
Date: Fri, 16 Jun 100 18:51:54 -0400 (EDT)
Cc: puff ()
In-Reply-To:  <200006162041.PAA18779@wadjet.cerner.com> from "Pasha,Asim" at Jun 16, 0 03:38:32 pm
Content-Type: text
Status: RO

Guys,

     For what it's worth, I don't entirely agree with the way Eddie
phrased his comments.  My initial reactions when I skimmed his post
(because I think the whole conversation falls in the realm of a
fundamental misunderstanding of EJBs which I don't have time to
respond to properly) was that he was incorrect.  I now think he was
simply using terminology and phrasing that are ambiguous and possibly
misleading.

     I also agree that the "JavaBean" name is confusing things; they
are related, but for practical purposes the fact that "Java Bean" is a
proper noun causes confusion that a more general term like "component"
wouldn't cause.  (Although "component" is so diluted by this point
that it might have caused its own problems).  But for the sake of
argument, if the terms were:

     Java Components
     Enterprise Java Components

     ...would we have this ambiguity?


     Look at it this way:

Q:  What's a java bean?  

A: Any java object you can pass into the JavaBean Introspector and get
back a BeanInfo object for it, which you can use with tools like the
BeanBox to interact with the object.

Now the details of how an object can be passed into the Introspector
and have a BeanInfo object generated are more complex, but they
essentially boil down to following various conventions for
getter/setter methods and other aspects of the class, OR to having an
appropriate method for generating a custom BeanInfo object.

Q: What's an ENTERPRISE java bean?

A: Any java object that's also a java bean, but beyond that follows a
more complex (and narrower) set of conventions that make it compatible
with a framework that takes care of a lot of the scaffolding you need
to build enterprise class applications.

Q: Then what the heck is an enterprise class application?

A: An ordinary, single-user, application has certain needs and
challenges.  You start it up, you run it, you do stuff in it, then you
shut it down.  Tomorrow you do it again.  

Next year a new version of the application comes out, you get it, you
install it, you maybe import some of your work files into it.  Then
you get on with your life.

Every now and then you have to deal with somebody who has an older
version of the product, so you import some of his/her files into your
version, or you export some of your files into their version.

Enterpise applications are used by an organization (i.e. a commercial
"enterprise").  They generally don't live that kind of life.  They run
for long periods of time, serve many users simultaneously, have to run
parts on different machines and have to deal with very large scale
problems (to the point where the scale changes the nature of the
problem), not to mention having to deal with a lot of different
problems in the same context - think of Microsoft Office expanded to
be used by a whole company at once.

Moving to a new version of the enterprise application is a lot
trickier.  For one thing, you're a lot less likely to tackle changing
the solutions to all of the problems at the same time.  For another,
you can't just ignore the problem of getting everybody upgraded at
once.  For yet another, there's a ton of things going on at any given
moment in an enterprise system, so you can't just wait until the user
isn't using it and install a new version.

Q: What was that about scaffolding?

A: Java has a lot of really nifty, cool stuff built into it, like RMI,
reflection, serialization.  However, building a complex enterprise
application that takes advantage of this nifty stuff is not easy.  You
end up building a lot of scaffolding on top of it.

For example, RMI takes care of a lot of the low level details of
having two java programs communicate with each other across a network.
But you have to build a lot of gruntwork code to open the connection,
make sure the connection is there, deal with problems when they
inevitably happen in the connection, keep track of what part of the
program you're dealing with on the other side of the connection, etc.

Not only is this a pain in the ass, it's complicated.  Not everybody
is good at solving this kind of problem.  Not everybody is going
to make the same choices in solving the problem.  When you do run into
another system that somebody built, you're going to have all sorts of
problems making them match up.

Can you see where this is leading?

Okay, moving along...

Eddie Sheffield writes:
> Other than having "JavaBean" in the name, they are totally different things
> with different purposes. Ordinary JavaBeans are more client-side technology,
> either visual (like some kind of GUI widget) or non-visual (a timer bean
> e.g.) Even beans used in JSPs and Servlets are in most respect client-type
> beans (clients to a database server or an EJB, perhaps).
 
Jim Preston writes:
> I don't want to start an argument, but I don't see how you can call
> ordinary beans a client-side technology. When a JSP uses a bean for
> data access or storage, that's all strictly server-side. You may be
> storing client-related data in the bean, but the bean exists and is
> used only on the server. I'd call that a server-side usage
> myself. 

I think you're both talking about the same thing; most of the
disagreement seems to be in the terms you're using.  

Eddie seems to be talking about client/server in the original, more
generic sense of the word.  In that sense, client/server describes a
relationship.  A program - or a machine - is neither a client nor a
server, it merely acts in a client role or a server role.  A program
in a server role in one relationship can turn around and act in a
client role in another relationship.  And vice versa.  Jim gives a good
example of this when he talks about having the database and web server
beng on different machines.  The browser is a client to the web server,
the web server is a client to the database server.

Eddie further confused things by mentioning visual javabeans in the
same breath :-).

Jim seems to be using client and server in the more modern usage,
where a client is a user machine (i.e. a really smart terminal) and a
server is a big machine that the user machines connect to for
services.  However, Jim's further comments show he has a good
understanding of all the issues involved.

> I don't see that it's the purpose that distinguishes EJBs from
> ordinary beans, it's the environment in which they're used.

     I think it's a little bit of both; both the purpose and the
environment are implicit in the "enterprise" term.

> JavaBeans are a component model. EJBs are a distributed component
> model. The basic purpose of both is to encapsulate business logic,
> to keep it separate from presentation. If you're working in a simple
> environment, with one web server and a database server (and your
> database interactions are simple queries and updates), you have no
> real need for EJBs; ordinary beans can do the job just fine.

     A lot of the utility of EJBs is in the distribution stuff, so of
course it gets a lot easier to say "you don't really need EJB" once
you take distribution out of the picture.  But a lot of the challenge
of an enterprise program is in the distribution as well.

Steven J. Owens
puff@guild.net