dcsimg
Fascinating but tough : OO Design
0 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   jubin_zawar
Posted On:   Thursday, May 10, 2001 08:40 AM

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 realised best, is treated in a section further below. 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 pow   More>>

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 realised best, is treated in a section further below.

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 Zawar

   <<Less
About | Sitemap | Contact