Message Broker

Event Broker based on RMI
1. EB Server(RMI Server) provides publish/subscribe/unSubscribe remote interfaces
   for publish interface, take one argument:EventMessage object. EventMessage encapsulates messageBody,messageType,etc.
  
   for subscribe interface, take two arguments:
   first is filter, using when publishing a message, we'll find the subscriber impacted
   second is SubscriberInterface, which is also a remote interface reside in client side. when subscribing an event,
   this interface provides a callback function. So when the event occurs(e.g. someone publishes the event),
   the callback method will be invoked on the client side just like a listener.

   for unSubscribe interface, only take one argument:SubscriberInterface. The EB Server
will maintain a subscription(subscription encapsulates SubscriberInterface and filter) list.
   this interface will remove the specific Subscriber(acctually it is the subscriberInterface, that is, a subscriber)

2. one of the EB Client(RMI client) locates the EB Server(RMI Server), construct your own
   filter & listener(SubscriberInterface) and subscribe events.
  
   for the implementation of subScribe behind the scene,
        first we'll create a new taskThread from ThreadPoolManager, and store the taskThread,
together with a taskQueue, to the hashtable in the ThreadPoolManager. Acctually, the taskThread
only processes the tasks associated with it, that is, every taskThread has its own taskQueue.
        then, construct a Subscription object and encapsulate filter,subscriber. The
Subscription object will kept in the EB server.
 

3. one of the EB Client(RMI client) locates the EB Server(RMI Server), then publish an EventMessage

4. EB server puts the EventMessage in a Event Pool

5. Acctually, except the creation of the ThreadPoolManager during initializing EB Server,
   a PublishThread also created. Once acquire an EventMessage from EventPool generated  in step 4,
   publish thread first filters the subscription list maintained in the EB Server, then
   enclose the intended subscription as a senderTask to the right taskThread. The senderTask
   has a interface such as run or execute which will be scheduled and invoked by taskThread.

6. for TheadPoolManager, also provides some other interfaces except creating taskThread for every subscriber.
   6.1 getNextTask: cause the taskThread will poll the taskQueue associated, after one task completes, taskThread
                will acquire the next task and execute
   6.2 addTask:pls refer to step 5, add senderTask to taskQueue associated with taskThread
   6.3 releaseTask: when unsubscribe or get error durring message informing, this method
       will be invoked and taskThread will stopped and related tasks will be released.