May I suggest an architecture that we are employing without using EJB, but
will easily adapt to moving to EJB if need be.
First, I can't agree more about getting rid of dealing with the persistence
layer. A Java developer generally doesn't want to worry about the SQL,
database issues, etc. It would be nice if we had simple methods that would
get one or more objects based on some search mask we supply, or store one or
more objects. I believe EJB is a step in the right direction to acheive
this, when dealing with CMP. However, CMP as I have read about it has
limitations, but at the same time allows the application server to make
performance enhancements. EJB 2.0 doesn't look very simple to work with and
I haven't given it much time as of yet. What I do suggest is something
fairly simple. Set up your class structure like so and use a Model 2
front-end archtecture. I have one readily available that handles XSLT
processing for you as well.
First, you will want to set up folders like so (as per my suggestion, you
can do it how you want)
com.mycompany.*
/src
/src/com
/src/com/mycompany
/src/com/mycompany/ejb
/src/com/mycompany/ejb/session
/src/com/mycompany/ejb/entity
/src/com/mycompany/core
/src/com/mycomapny/core/entity
/src/com/mycompany/presentation
/src/com/mycompany/presentation/actions
/src/com/mycompany/presentation/beans
/src/com/mycompany/presentation/servlets
The above is a start. The /ejb package doesn't necessarily mean EJB, but it
assumes EJB is the business logic of your code. Entity EJB package would
contain special "beans" that handle the load/store/find capabilities of
objects, including any one to one, one to many, and so on. We currently
write SQL in these beans and they would basically be BMP in the EJB domain.
By simply implementing two interfaces and adding some methods, you turn your
version of an entity bean into a CMP (or BMP) EJB entity bean. The
ejb/session package is where you put your session "business logic" classes.
These two can start off as normal classes, and be turned into EJB session
bean classes by implementing two interfaces and adding a few methods to the
main session class.
As for how you access the "logic"..its quite simple. With my front-end
framework or another one called Struts, you use a single entry
ControllerServlet for all requests, and call upon action classes (basically
servlets that are instantiated and kept in memory via the ControllerServlet)
to handle each incoming request. Each action class would create a new
stateless session class (before using EJB) or do a JNDI lookup on the EJB
session bean (if you move to EJB) to get a reference to a "logic" class. The
action class then calls methods of the session class, passing to it objects
(Strings, Integer, your own classes, etc) and getting results back. Keep in
mind, you should ALWAYS make sure everything you pass to a session class and
any results you get back are objects that implement Serializable, so that if
and when you do move to EJB, you don't have to figure out a reworking of any
given method or class so that it will work. EJB serailizes objects when
passing them to and from other classes (such as your front-end action
classes or a desktop client program for example).
You asked what you get by moving to EJB. If your a small company with a
small site, or doing your own stuff that is not very big, I don't think
you'll see a significant improvement in performance for your site, nor will
you find it as easy to develop with EJB's than if you just put the logic in
an action class, a servlet or directly in the JSP. However, what you do get
even if you are small, is what I consider "proper" development. You break
out your code into easily manageable tiers (and thus your packaging is
easier to find classes, organized, etc). You move any and all logic work
into a "session" class and ALL database access is done from this class. You
remove ALL back-end database ties from any JSP pages, servlets or action
classes. Thus, your front-end HTTP based stuff can now be plugged in to any
existing database back-end and any database without direct locks to one
database. Ofcourse, using JDBC pretty much does this for you too, but by
moving ALL database access to session beans (non-EJB parlance this would be
session/logic classes, EJB = session beans), you further simplify your
development process and a BIG advantage is IF your business grows, you now
have a much more manageable code base to hire more developers in to. You can
also more easily find problems. Is it a logic problem? Go to a session
class. IS it a front-end problem? Go to an action or servlet class.
Now, if your a larger organization, especially one that may be acquiring one
or more companies, having to work with legacy applications, and integrate
with other companies, you get a very nice advantage to moving to EJB. You
can now centrally locate ALL of your company's business logic in one place
(following the ASP model) and access it from anywhere in the world via any
type of client. Clients can be written in Java using RMI, or can be any
other language using CORBA and RMI over IIOP. You can create many web sites
that all use the same one central repository of business logic, which ends
up cutting down on time to market, and reuses code. If your integrating with
two (or more) organizations, you can all start leveraging the existing code
(or reworking it) so that two (or more) organizations can utilize the same
one code base for business logic, but have their own front-ends (whether
they be web sites, clients, or PDA devices). There is another thing about
moving business logic to a central repository in the wireless world. PDA
devices are limited on memory. Having "front-end" display on the PDA, but
all business logic in a central location, you can offer a lot more robust
applications for wireless devices, and again while utilizing the same
business logic that a very robust powerful application may also be using.
You get alot of things like transaction management, session and entity bean
pooling, connection pooling, two-faced commits, memory management,
clustering, fail-over and easy scalability. By using two (or more) servers
in a cluster (farm), you can easily add more servers to the farm. Just image
one server to a new one, plug it on to the network, and your pretty much set
up (with the exception of each vendor specific settings to add new servers,
usually not too difficult). If a cheap server isn't enough to handle it, buy
some more powerful servers. If your adding servers to handle the load, your
making money (or should be), which is what you are basically after.
Providing a scalable solution that can give a return on your investment.
There are numerous benefits to moving to EJB, and only a few that I see (my
personal opinion) as reasons not to move to EJB, or at least to consider.
First, the network traffic to EJB servers can be a bottleneck. However, with
giga-bit networks, and T3 or better back-bones at co-lo facilities, I don't
see this being a major problem. I have seen many wars on stateless EJB beans
and statefull EJB beans. Some favor one, some the other. I prefer stateless
beans because they are much lighter on the network side. Keep in mind, you
generally will have a front-end server for your web based stuff, and a
middle-tier server (or servers in a cluster) for your EJB stuff. To
communicate with your EJB, you will always use the network. For
high-bandwidth sites, this can be troublesome if you don't have enough
network bandwidth, which is why I mention gigabit networks, which are now
pretty affordable. Another downside I see is EJB development is a little bit
more involved. However, software like TopLinks can ease your use by managing
the creation of all EJB interfaces and classes for you while using a nice
UML view of your fields and database tables/rows/columns. I am not familiar
with it, only a brief read on it, but something that automates and maintains
the EJBs for you should ease your work. You would only then have to add in
the business logic implementation in the ejb methods. Descriptor
configuration files can be a pain if you start working with a lot of EJB's,
but again I think a package like TopLinks would handle that for you.
I use Ant 1.3 build scripts that build, jar, copy, move, delete and deploy
for me, so its pretty effortless once I get the script working.
Anyways, feel free to ask me some questions. I am working on some demo
applications when I get free time that will outline the use of my front-end
framework with using EJB and Orion App Server. I hope to have them done in a
few months or less.
Take care.
> -----Original Message-----
> From: Johan Lundberg [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 12:23 AM
> To: Orion-Interest
> Subject: Why Entity EJBs?
>
>
> Hi
>
> The more I study the J2EE technology, the more I
> wonder why I should use it.
>
> The main reasons why I would use it are these:
> - Forget about the database layer while only using CMP
> entity beans.
> - Faster.
> - Scalable.
> - Easier to manage transactions.
> - Clear separation between client-workflow-persistence
> (JSP - Session beans - Entity beans).
>
>
> In our current system we use simple JSP, JavaBeans and
> a few connections to our database.
> We have made a few mistakes but we envisage cleaning
> up the system by starting from scratch. It is
> important that we choose the right technology but I
> get more and more sceptical about the EJB technology.
>
> We have experienced, when doing listings from a search
> page, that reading from the database and instantiating
> a few beans (not EJBs) takes a long time. The fastest
> way is to loop the resultset in the JSP-page, but it
> does have a few drawbacks and I would prefer to use
> another architecture.
>
> I thought that the pooled entity beans would speed up
> the system and started to study EJB.
>
> Then, Richard Monson-Haefel states in his book that
> listings shall be done directly between the Session
> bean and the database. Otherwise it would be too slow.
> I don't want to bother with SQL anymore and I would
> like to forget about the database layer, but it seems
> very difficult to get away with this requirement.
>
> To communicate between the JSP, the Session beans and
> the Entity beans, I get advised to use Data Access
> Objects. If I were to ignore the Monson-Haefel advise
> I would first create a bunch of Entity beans from a
> finder method, instantiate a collection of DAOs and
> send them back to the requesting Session bean. I
> wonder what kind of performance I would get from this
> system? I guess that this can become very heavy
> weight.
> It will probably become even more heavy weight when
> n-m OR-mapping becomes available.
>
> This will force us into a solution were we would have
> to use clusters and the scalability features of EJB
> comes handy. Is this the strategy from Sun - to make
> us buy more SUN servers?
>
> Now, what did I miss? Is there something that I have
> completely misunderstood? Please tell me what strategy
> we should use while developing CMP entity beans with
> Orion's OR-mapping features.
>
> I have found that another paradigm and framework that
> will simplify the development and reduce the amount of
> SQL-coding.
>
> http://jrf.sourceforge.net/ejb.html
>
> http://jrf.sourceforge.net/
>
> Why shouldn't we use this framework?
>
> Best regards
>
> /johan
>
>
> _____________________________________________________
> Do You Yahoo!?
> [EMAIL PROTECTED] - skaffa en gratis mailadress på
http://mail.yahoo.se
