I would have to respectfully disagree on the development prespective point. I
personally think that using EJB speeds up my development, especially if you use
CMP. J2EE is the ultimate Enterprise class RAD tool. Using EJB(w/CMP) and JSP,
you can create database driven apps in hours. Deployment is annoying at first,
but once you get the hang of it, it's not really that big of a deal. EJB/JSP
allows me to build web-apps MUCH faster than when I was using JServ(yuck).

Just my $.02,

Noah Nordrum
[EMAIL PROTECTED]
Hyperride Technologies


----- Original Message -----
From: "Darren Gibbons" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, February 15, 2000 9:20 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