My oh my. What a can of worms I seem to have opened. So I'll just make a few
comments to try and keep you guys from thinking I'm way out in left field
somewhere, since I find I agree with just about everything that has been
written in response to my original message. Maybe I've already done so with
my previous followup to Jim since no one seemed to reply to that, so I
promise this will be my last word on the subject. If anyone wants to further
discuss this off-list, please feel free.
> I now think he was
> simply using terminology and phrasing that are ambiguous and possibly
> misleading.
Alas, that looks to be the case. Which is very disturbing to be since I
spent quite a while writing that and editing it to make it as precise as
possible, but it seems that what I thought was carefully chosen terminology
is apparently "out of style" now.
> 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?
AMEN! I've complained about the abiguous naming since I first started
studying EJBs when the spec first came out.
>
> 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 the
> 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.
Or from the JavaBean spec http://java.sun.com/beans/docs/beans.101.pdf (page
9):
"A Java Bean is a reusable software component that can be manipulated
visually in a builder tool."
and
"Individual Java Beans will vary in the functionality they support, but the
typical unifying features that distinguish a Java Bean are:
- Support for "introspection" so that a builder tool can analyze how a bean
works
- Support for "customization" so that when using an application builder a
user can customize the appearance and behaviour of a bean.
- Support for "events" as a simple communication metaphor than can be used
to connect up beans.
- Support for "properties", both for customization and for programmatic use.
- Support for persistence, so that a bean can be customized in an
application builder and then have its customized state saved away and
reloaded later."
> 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.
Yep, that's what I thought.
> 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 :-).
But I would hope not much more confusing than the spec. I mentioned them in
the same sentence, spec mentions them in consecutive sentences, same
paragraph:
"Some Java Beans may be simple GUI elements such as buttons and sliders.
Other Java Beans
may be sophisticated visual software components such as database viewers, or
data feeds.
Some Java Beans may have no GUI appearance of their own, but may still be
composed togeth-er
visually using an application builder."
> 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.
This is probably the only thing in here I somewhat disagree with. Yes, it
may be more common to use "client" and "server" to refer to the physical
machines in this way, but it is very imprecise when discussing a distributed
architecture. I know because I worked for a couple of years on a CORBA
project that used callback object on the client machines in applets. From
the CORBA point of view, these were were servers and there were various
security problems that had to be dealt with because of that. It was very
difficult explaining these problems to others who couldn't get past the
"modern" usage. But I apologize for the confusion.
> > 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.
Well said!
> > 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.
Actually, they make things a lot easier even for simple stuff, once you get
used to it and if you have the server available. For example, I recently
wrote a J2EE application using JSP, servlets, and EJBs. And yes, I used
regular javabeans to front the EJBs. But it was pretty simple. I didn't use
distribution (assuming by that you mean separate parts of the app running on
separate server machines) it was all on one machine. But EJB still helped
quite a bit. By using container managed entity EJBs, I didn't have to deal
with JDBC at all, and the only SQL I had to write was to fill out a custom
finder method. Transactions were covered as well, and all I had to do was
tell which methods required transactions. I didn't need to use the security
features, but they are not much more complex to use. Yes, the distribution
is a big part, but not the only part, nor the only reason to use EJBs.
But really, after all this all I was really trying to do was respond to this
earlier message:
----- Original Message -----
From: "Apollo Mcowiti" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 05, 2000 7:43 PM
Subject: Re: EJB and JavaBeans
> True, but
> I still tend to think that with the neat way EJB envisions(spelling?) to
> solve the distributed computing problem, it is here to stay for a long
time.
> And when there have been well defined core EJBs for most enterprises(don't
> they all use similar business logic?)we should achieve OO's dream of (a
high
> percentage ) code reuse,and then ordinary beans should really die.
>
> apollo
>
by showing examples of JavaBean usage that could not be filled by EJB, and
GUI was the most obvious. I was DEFENDING the use of JavaBeans, but because
I emphasized the client usage I apparently gave the impression that I didn't
know what I was talking about or was belittling them. Perhaps that was a bad
choice given that since this is the JSP list, the JavaBeans being referred
to are almost always non-GUI. But the statement "then ordinary beans should
really die" is very broad, and even if the statement had been "then ordinary
non-GUI beans on the server should really die" I would still have disagreed,
but used a different example.
OK, I'll stop now. Sorry for drawing this out and thank you for your
patience.
Eddie Sheffield
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
