Hi people,
this is a tough abstract question.
The technology I intended to use was EJB initially, but try not to think
about EJB here.
Here is what I try to implement, how it will be realized best, is treated in
a section further below.
1) The problem :
several organizational units have to be running a giant enterprise. These
units can be seen as humans. Each of them has a profession, and an office.
Together they all form a big enterprise. The structure of the enterprise is
the best an enterprise can have : every "employee" sees himself as an
enterprise within the enterprise. An "intrapreneur".
So every employee has its office, it's communication channels, it's decisive
power, and it's own "personality" – try not to focus on the
“personality” here, peronality will not be implemented,
don’t worry.
Example : Paul is an employee who gets a regular salary and enjoys a sure
job: he takes decisions in favor of the enterprise as a whole. Whereas Tom
is a guy who may profit from the enterprise's growth, but is more
independent than Paul. He needs big deals, and he's paid by the number of
deals he is making, and the size of his deals.
If Paul is getting the following requests within the time of 1 hour:
1) +10:00AM "I need a big machine with great CPU Power"
2) +10:30AM "I need a small machine affordable for less than 1000$",
he will chose the small request and handle it. Why ? Because Paul knows that
Marc is an expert for big machines, and he will be able to handle the
request better. So he will chose request 2 and communicate request 1 to
Marc.
Whereas if Tom would have gotten this requests, his behaviour would have
been :
1) +10:00AM "I need a big machine with great CPU Power"
Tom accepts it - it's his BIG Deal man !!
2) +10:30AM "I need a small machine affordable for less than 1000$",
Tom is busy and refuses the order, communicates it to Paul.
These guys react upon messages that may be interesting to them.
Additionally, they may have "deadlines" - like - Tom needs to make at least
one decision every hour.
If at 11:00AM there's no deals, he may set some actions.
So Tom will "activate" himself hourly and see for a decision, if none has
been made - am I right here ? Well - I even think there would have to be
some activation scheduling mechanism here or what would you say ?
I could have realised an enterprise scenario in a synchronous way with
classic EJB.
I chose async for reasons of load balancing and because of more independence
between the objects, which are not just "slaves", but maybe later will get
their own "life" in there, and act as masters AND slaves.
The questions are :
1) what about transactions in a message driven solution ? suppose we have a
request which needs the acknowledgement of 10 employees who could complete
the task together for the customer. We could implement transactions in
including the "OK"'s in the message or issuing "Acknowledge" requests to
every employee involved. But maybe there is already a transaction mechanism
more simple and efficient within the EJB2.0 specification for a
message-oriented application.
2) suppose we realise this scenario in message-driven EJB : then I would
have to have a messagedriven bean acting as request handler for Paul e.g.
The messagedriven "PaulSecretary" bean consumes a request message for Paul,
and invokes the method "checkYourDesk" for Paul. Paul is a stateful session
bean, which has gathered state information over time. It's "checkYourDesk"
method brings Paul back to life, he checks the new state and makes
decisions. The decisions taken are returned to PaulSecretary, and the
secretary will then write a response to a topic or queue, or maybe do
nothing, based upon Paul's answer.
So far, so good. But now comes the big deal : Paul needs to check his desk
every hour at least. No matter if anything in the outside world has changed
or not, no matter if any new message of interest for him pending, he needs
to get back to life every hour, and check his situation : why ? Because his
state has changed ? Why has his state changed. Because one hour has passed
and nothing's been published. He will have to take a decision now, and maybe
he will do nothing, or maybe he will contact somebody and tell him "there's
nothing going on, what should I do ?"
So - I guess what I would need know for Paul would be a SchedulingManager
which activates Paul every hour e.g. The SchedulingManager would contact
Paul's Secretary by generating a message directed to Paul every hour. This
would wake up his secretary who would wake up Paul etc.
Additionally : Paul is an employee, he acts like 100 other employees in the
enterprise who are active all day. Those employees of his department inherit
from a general employee class. But TOM is a company within the company. He
has a very specific behaviour, but inherits behaviour from Paul's department
too.
The workers in Paul's department are all doing the same job with the same
behaviour. So some of the incoming information for the department could be
treated by any employee in the department. But nevertheless, some of the
incoming information is addressed to one specific employee in the
department. The employees of the department need to maintain state
information of their own, because they all accepted different requests and
have a history based upon which they will react. Let's say the workers in
Pauls department should listen to the topic "Computer Sales Requests".
Additionally they have to generate some action every 2 hours. The workers
maintain state.
Tom is a special case and has it's own EJBs running there and listening to
topics.
How should one be running this in an EJB context ? There are some
possibilities :
1) all of the employees of Pauls department listen to one topic. They are
messagedriven beans. They get a method invoked, do something, and return. To
do something, they have to rely on state information. One way to resolve
this is to maintain state in a store (database, file, javaspace etc.)
somewhere. Another solution is to model state in a stateful session bean,
one for each employee.
a) state in a store : the messagedriven bean retrieves state from the
store and does it's task and completes. Scheduling is still done with a
SchedulingManager. One for each employee in the department, or one for the
whole department, generating "Wakeup" messages.
b) state in stateful session beans : same thing, but : per employee, we
now have a messagedriven secretary and a stateful session bean. What about
the performance impact here - imagine we have 2000 employees of the same
behaviour - that would mean 2000 secretarybeans and 2000 stateful session
beans !
Personally I think it would make no big difference.
In this possibility, "Tom" would be just another messagedriven component,
with it's own behaviour, but inheriting some things from Paul's department
employees. But he would have his own SchedulingManager I guess. The
scheduling is giving me headaches, as scheduling is very close to individual
behaviour.
I would have liked to model everything specific to the employee in 1 or 2
beans, but not 3 of them !!
Ok and now there's the other question : how would you design the Scheduling
beans ? They would have to be running all the time wouldn't they ? So they
would have to be invoked once, and then execute a "Schedule" method all the
time of their life. Is this feasible at all ? Would I never risk they would
get passivated ? How would you design them ? And more globally, how would
you design scheduling ?
2) the second possibility is to "group" some of the beans of the 1st design
alternative into one. I guess there are many possibilities for this to be
done, so I don't outline everything here. I would nevertheless be interested
how would do it.
Well, to me this design seems unnecessarily complex. What would you say ?
How would YOU design the handling of such "beings" ?
Would you use EJB ?
Best regards, Jubin
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
