[LCP]help needed !!!!!!!!!!!!

[Mike and/or Penny Novack]

 Aditya,
   
    Let me give a LITTLE more help. The first thing you need to do is 
complete the process specification. Don't begin design till you have a 
"corrected" specification.

    That's right, as it satnds, the specification for this porcess is 
incomplete. It's incomplete in the same way that analysts always begin 
with incomplete specifications because those giving us those 
specifications think only about how the process in terms of "when 
everything works". They do NOT stop to consider what this process should 
do if one or more things has gone wrong.

    For example, the overall process depends upon communications between 
independent processors and these communications can fail, one or more of 
the processors can be dead and not responding. A robust real world 
solution must take that into account. Thus......

Suppose the broker is unable to communicate with one of the producer 
processes. What should happen? Obviously the overall process could 
continue at reduced capacity and that's probably what would be desired. 
But maybe  something else also (like should the "broker" send a message 
to the support console informing a human "producer process ID=xyz 
appears to be dead").

Suppose a producer process is unable to communicate with the broker. 
Should it just sit there waiting to get through? Or more likely, since 
it has a queue of tasks waiting (remember, least loaded producer doesn't 
mean UNloaded producer) should it queue the "task completed" report for 
sending later and meanwhile get on with the next task (and wait only if 
its task queue is empty).

    Look at the (initial) specification carefully for all these "holes" 
that need to be plugged. In the real world, after coming up with 
reasonable alternatives, you would call a meeting of the "business 
clients" who gave you this task to get their decision/approval 
onexpansion  the specification of the behavior of the distributed 
process covering all these "unforseen events" << if you are an 
experienced analyst they will like YOUR proposals about "what to do 
if..." but ultimately that's their call -- and it's wrong to blame THEM 
for not having noticed these gaps in the specification -- your job is 
not just to "do what the customer asked for" but to be their ANALYST >>

    If this is a class project, the teacher may be waiting for you to 
have noticed "something missing in the specification" and may then tell 
you the "what to do ifs" (and maybe only students who notice the problem 
and ask get them). Or quite possibly might tell you "just do something 
reasonable" letting you pick. A lot depends on the teaching style.

    The reason I am pointing this out to you is that design omissions of 
this sort are quite difficult (expensive) to fix once coding has begun. 
You do NOT want to discover during testing of your process that it locks 
up and you have to redesign handling of what you thought were single 
objects into processing of a queue, decide on wait times, insert 
confirmations of "message recieved" (look up "The Two General Problem"), 
etc. A lot has been left out of the specification as you have it now. 
Fill in those details because that WILL affect your implementation choices.

Michael