Hi Ruben,
Sounds like you're looking at trying to make some
business sense, not just looking for a knee-jerk
re-architecture opportunity. Your CORBA-based app
probably had a lot of business and software
architecture thought put into it already. So I
wouldn't want to sell you short in that area.
>From what I can tell, you probably have many business
scenarios (200?) so I would not automatically conclude
that you are misusing Session Beans. (ERP systems are
truly complex!) And because of that large number most
likely many of those are probably talking to the same
entities, my guess is maybe 40+% overlap (160 out of
400). In other words, you aren't providing one Session
Bean for every other entity, right? If that's the case
it is understandable why you could have 200 Session
Beans, although the number does seem high.
One thing that your post does not state is how many
concurrent users you will have. Can that be
determined? If it is relatively low, then it might not
be unreasonable to think that you could use CMP for
these. This is especially true if the relationships
(aggrigation or composition) are simplistic. But if
there are complex "joins" occuring, you may have to
use BMP, at least for some of the entities.
But the reason I bring up concurrent users, and
overlapping entity usage, is because of the way an EJB
container manages EJB instances in general. As a perk,
you are guarenteed that you will not have to write
thread-safe code, because every instance can have only
one client (in the case of entity EJBs, one Session
Bean instance) using it at one time. The container has
to create or otherwise allocate (pooling) an instance
for each concurrent client (server specific). So if
you have a high number of simultanious users, and all
of those users are accessing something like 40% of the
same *kinds* of entity beans at the same time, the
server can really bog down. Depending on the kind of
EJB you are using, your server can do a lot of
grinding in the swapper scheme (passivate/activate).
Also, something that the EJB 1.1 spec states about
entity beans is that 'not all database entities sould
have an entity bean. If you have Order and OrderItem,
Order would be an Entity Bean, but OrderItem will not
be.' That's great, but the 1.1 spec does not give us
any way to map "dependent objects." While you may not
be able to find any EJB *2.0* implementations ready
for production any time soon, the *2.0* spec does
explain dependent objects much more thoroughly. You
can get a flavor for how it *should* be done,
according to the spec team.
However, some have decided to completely side step the
whole issue and deal with entities on their own terms,
at least until EJB *2.0* clears this up. An out-of-box
solution is the TopLink O-R mapping tool. I am *not*
talking about TopLink EJB CMP, just regular ol'
TopLink backing Session Beans. From a very simplistic
approach (for illustration), you simply let TopLink
dump your serialized *simple* bean Java objects into
the database, and get them back out for you. I
personally know of another ERP *kind of* system being
developed with this approach for Web ASP model, and
the developers say if really screams. Transactions are
handled by the container or O-R mapping tool, so not
too much worry there. TopLink can really remove the
headaches of doing BMP.
Another alternate approach, which we are using right
now at a client site, is just doing the entity stuff
using simple Java classes doing SQL on their own.
There is no caching so not much to go wrong with that.
They can determine a relativelty limited number of
clients, so in their case this approach works out.
Since they are using Container-Managed Transactions,
again things are quite simple. You might think of this
as a sort of COM+ (Microsoft's DCOM and MTS) hybrid
approach. Again, Session Beans are used here to front
the entity activities.
One big disadvantage you have is the use of *Stateful*
session beans. Because of this you may also get into a
lot of passivation with a high number of users since
Stateful does not have pooling like Stateless. If
there is any way to do your stuff as Stateless, you'll
immediately eliminate a lot of container overhead.
Another thing you did not mention is the hardware
platform you are running on, and whether you are doing
Web or Swing GUI. Don't count on WinTel platforms to
handle a lot of entity bean instances. And if you are
doing a Swing GUI with a high number of users the
server (jboss anyway) may bog down with simultaneous
threads (RMI Reference Implementation is in use at
this time), one for each of the connections (as
opposed to a pool of threads to handle a fixed number
of connections and block all others until they can be
handled). Again, hardware will play in here. For a
huge Sun box, it may not really matter. jBoss has been
tested agains this (seems like E4500) with "5000"
simultaneous users. But don't count on WinTel giving
you that. Depending on the server load dealing with
bean instances, connection thread overhead will just
add to the overall load.
In any event, if you have the bucks and market to do
clustering of EJB servers on a kicking multiway Sun
box, yeah you can scale it no matter what. In that
case just buy the hardware and use CMP and get the app
out to users! But if that's not you, you'll have to
think about some of the other things I brought up.
Hope this helps. Thought it would be best to give you
some options rather than a docmatic viewpoint since I
don't really know your system. :-)
Vaughn
From: "Kenworthy, Edward"
<[EMAIL PROTECTED]> | Block address
To: 'jBoss' <[EMAIL PROTECTED]>
Subject: RE: [jBoss-User] jBoss: Can it cope with many
bean classes?
Date: Thu, 7 Dec 2000 08:38:59 -0000
Reply-to: "jBoss" <[EMAIL PROTECTED]>
Add Addresses
If you have 400 different entity beans then it sounds
like your entity
beans
are far too fine-grained (similarly for your session
beans).
[To give you a for instance, the system I am currently
working on has
of the
order of 100 entities, but only 8 EJB entity beans. It
has around 40
session
beans (session bean corresponds to use case in our
system, and I am of
the
Ivar Jacobson, *BIG*, ie proper, Use Case school - so
40 use case
system is
roughly an 40 man-year project, and multi-million
pound).]
The problem you will have is that to do anything
realistic with a
fine-grained system (eg 400 entities) will require the
instantiation of
many
EJB entities and that is expensive in terms of both
system resources
and the
app server having to manage all these teeny EJB
entities. It migh be
worth
reviewing your design and seeing if you can cluster
your entities
together.
Eg you may have Customer -->(many)Order -->
(many)Product. Is Order
really
separate from Customer ? Probably not, you probaly
only rarely (if
ever)
deal with it separately from Customer so perhaps Order
(entity) and
Customer
(entity) should be combined into a single EJB entity.
The mistake people often seem to make is mapping
classes 1:1 to EJBs.
EJBs
are *components*. The mapping, particularly for EJB
entities, I would
expect
to be many classes in one EJB.
A simple rule of thumb to find you EJB entities that
we've used is:
what's
the relationship ? association or aggregation, if the
latter then
you're
probably looking at two classes in one EJB entity
(doubly so if its a
containment aggregation.) That of course is a
technical way of saying
look
at the life-times and context. Is one ever used
(instantiated) without
the
other ?
Hope this helps :-) But probably not in the way you
had hoped.
Edward
PS
Oh and for all but the simplest systems, CMP is
completely inadequate.
it
leads to you defining hundreds of tiny EJB entities
that will perform
like a
dog :-) Use BMP.
-----Original Message-----
From: Bakker Ruben
[mailto:[EMAIL PROTECTED]]
Sent: 07 December 2000 07:43
To: '[EMAIL PROTECTED]'
Subject: [jBoss-User] jBoss: Can it cope with many
bean classes?
Hello everybody.
We've building a large ERP-System and like are planing
a transition
from a
custom CORBA App-Server to EJB. We currently have
about 400 different
EntityBeans and about 200 SessionBeans most of them
stateful. Can jBoss
cope
with this? Is EJB in general designed for such large
applications? Has
anybody experience in building large applications with
EJB (jBoss?)?
Any answer is very much appreciated...
Ruben
--
--------------------------------------------------------------
To subscribe:
[EMAIL PROTECTED]
To unsubscribe:
[EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe:
[EMAIL PROTECTED]
To unsubscribe:
[EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
