- EJBs are deployed on the server, not in the clients, so issuing a new
release of some business logic component requires only a release to the
server; all clients pick it up "by magic" the next time they request the
bean. Zero Deployment.

- EJBs can provide transactioning support across objects--you said this
already, but EJB can support transactions across ANY object, not just
database objects. Try implementing 2-pass transaction logic over an RPC call
*and* a DB transaction. Ick.

- EJBs can (although I'm not sure I like this) provide container-managed
persistence, thus alleviating you the developer from having to write SQL to
an RDBMS.

- EJBs can provide scalability by running in multiple JVMs/hosts without you
requiring a single code modification. What's more, there's no reason why an
EJB appserver has to be remote--nothing in the spec (that I've read, anyway)
prevents you from creating an EJB "server" that simply attaches to your JVM
directly, much as these "in-process" database servers are doing. You use
this lightweight server for development, and then you switch over to a
production release for actual release. Or not--the choice is up to you, and
that's precisely what EJB is trying to buy you: the ability to pick
best-of-breed products to best suit your needs.

You're right, there's nothing preventing you from going off and doing
everything EJB provides you--in fact, I just finished writing a book about
this ( http://www.manning.com/Neward3 )--but you have to understand the
risks you assume in choosing the "build" option in the "buy vs. build"
decision.

Ted Neward
Java Instructor, DevelopMentor ( http://www.develop.com )
http://www.javageeks.com/~tneward
-----Original Message-----
From: Darren Gibbons <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Sunday, February 13, 2000 9:52 PM
Subject: RE: Some Advice Requested.


>Hi all,
>
>Apologies again for a non-Orion specific post, but I think these issues are
>something that most of us have run into.
>
>It seems to me that EJB brings a lot of overhead, both from a development
>perspective and from a technical perspective.  From a performance
>standpoint, I'm guessing that a call to an EJB would be slower than
directly
>calling a bean/class to do the work.
>
>Here's what I understand about EJB strengths:
>
>- EJBs allow me to handle transactions among objects.
>This is true; however, I can also accomplish this at a database level,
which
>I assume will be a lot faster.  EJB does give me the choice though.
>
>- EJBs allow me to distribute the load across multiple servers -- ie one
>server for JSP, one for EJB, and one for database work.
>This is useful, however, I think a site would see better performance (and
>reliability) with one database server, and two web servers running the same
>JSP/bean application with load balancing between the two.
>
>- EJBs allow me to reuse the exact same business objects from different
>clients (ie. an Applet front end, and a servlet front end)
>While this is useful, there are many systems for which this just isn't an
>issue.
>
>- EJBs allow me to do database connection and object pooling
>DB pooling works for beans the same as for EJBs, and writing your own
object
>pooling is not very difficult.
>
>Anything else?
>
>I think everyone agrees that separating user interface code (ie JSP/HTML)
>from business logic is a good thing.  Putting business logic in beans is a
>very straightforward process, and you can easily focus on the busines
>problem, rather than writing interfaces, coding XML config files and
>deploying code.  EJB seems to make development much more of a chore.
>
>Please not that I am not against EJB, and I recognize that choice is good;
>I'm just not convinced it makes sense for the majority of web application
>development work out there.
>
>Comments?  What are people using, and what issues have you run into?
>
>Darren.
>
>
>--
>Darren Gibbons                                    [EMAIL PROTECTED]
>OpenRoad Communications                               ph: 604.681.0516
>Internet Application Development                     fax: 604.681.0916
>Vancouver, B.C.                                 http://www.openroad.ca
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Apap
>> Sent: Tuesday, February 15, 2000 3:10 PM
>> To: Orion-Interest
>> Subject: Some Advice Requested.
>>
>>
>> This mail is semi-OT.  But here it goes.  I have been using orion for
>> learning purposes and what not.  But I am planning with some friends to
>> build a pretty large scale ecommerce site.  We are going to need to
handle
>> pretty large amounts of hits, and frequent db access with semi large
db's.
>>
>> Could someone let me know their opinions on how orion can handle
>> this?  Also
>> any examples of sites running orion would be helpful.
>>
>> Beyond the webserver choice is my choice of wether or not to use EJB.
Has
>> any type of benchmarking been done showing how EJB compares to
>> regular JDBC
>> connections to db's?
>>
>> And finally, if I was to go with EJB, do you feel hSql is good
>> enough to run
>> a business off of? If not what would you recommend.
>>
>> Thank you for your time.
>>
>>
>> - Frank Apap
>>
>>
>

Reply via email to