Question 1
----------
My understand is that one of the goals of EJB is scalability. EJB
achieves this by (1) object pooling with object activation/passivation
and (2) distributing load across multiple machines (eg. having Person
beans run on machine A and Account beans run on machine B.)
But what i don't understand is how practical in EJB it is to
distribute the load.
An example: let say I have an entity bean called Portfolio which
represents an investment portfolio for an client. There's a method
Portfolio.evaluateRisk() which performs a very complex CPU-intensive
algorithm to estimate the risk of this Portfolio. Let's further assume
that, from a logical design perspective, it's not sensible to
decompose this method further.
Now, because all Portfolio instances have to live in the same VM as
the PortfolioHome, all those CPU-intensive Portfolio.evaluateRisk()
calls must run on the same box. It is impossible to do distribute the
calls to do load-balancing...
Do I miss something? Does JNDI allow you to register more than one
servant for the same EJBHome and provide certain load-balancing
mechanism to decide which EJBHome to return to you when you do a
lookup?
Question 2
----------
Since each call to an bean is a remote call (ignore co-located clients
for the sake of this discussion), we should not model our business
objects by too fine grain entity beans and methods if performance is a
concern. But, doesn't that mean the EJB architecture imposes artifical
constraints onto your Implementation Object Model? ie. If you have
fine grain objects in your Design Model, you are forced to have a very
different Implementation Model?
I think one of the 'virtues' of OO is your Domain Model, Design Model
and Implementation Model can be very similar to each other. But now,
when you map your Design Model to Implementation Model in EJB, EJB
imposes you this "no fine grain objects and methods" constraint...
Background
----------
A few words about where I come from may help you understand why I'm
asking these dumb questions.
Our company has a distributed framework, MSF. But MSF's paradigm is
nothing similar to EJB's. In simple terms, when a client connects to
MSF, MSF finds a machine (with the lowest load) to create a
'workspace' for the client. Workspaces are not shared and each client
has its own workspace. Business objects are loaded from DB onto the
client's workspace upon request. (Yes, workspaces look like stateful
session beans in EJB.) Then, the client can play with the business
objects as long as it likes. At the end, the client asks the workspace
to commit the changes back to the DB. Concurrent modification is
prevented by co-operative locking.
Since MSF can create a workspace on any machine, MSF doesn't have
problem #1 I mentioned above. Besides, in MSF, business objects are
not remote objects, only the workspaces are remote objects. That means
I can retain the fine grain business object model if I want.
We are currently exploring the possibility to port our applications
onto Jonas. But we're puzzled about the questions I mentioned above.
--
John
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
