Haven't read such fun post for a while. I read it in my lunch time. In the
spirit of the fable-style, my work is exactly the same, so, perhaps I can
show my 2 cents.
Just to clearify a little bit first, I'm only a programmer, so ... ;-)
Please see the interleaved.
<[EMAIL PROTECTED]>
Sent by: To:
[EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
eforge.net Subject: OO Design in Java
: a tough question
05/10/2001 08:48 AM
Please respond to jboss-user
Hi userlist, hi David Jencks.
Well I think I have sufficiently done research now to come up with a
complete description of the problem and ask precise questions.
Try not thinking about jboss or any ejb server here. Here is what I try to
implement, how it will be realised best, is treated in a section further
below.
---------------------------------------------------------------
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.
==================> no, you have to implement a "workflow engine" to do
that -- "the request handler" below.
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
==================> the "request handler" should be a generic one, it is a
(simply?) workflow engine.
"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
===================> it is a Mbean, seems already there, quite sure but not
used it before.
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 !
===================> make it as a "general secretary" :-) --> that workflow
engine
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 ?
======================> what a greate reasoning! almost literally the doc
for all custom Mbeans !!!
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
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
