Synchronous & Asynchronous framework

[Paul Rhoades]

My Objectives
-------------
* Develop a J2EE framework that enables me to execute functionality in both synchronous and
asynchronous manner

My Thoughts
-----------
* Instead of putting Business Operation (method) logic into Session Bean (SB) or Message Driven Beans (MDB) I could factor it out into standard Java classes (Business Objects).
* Now I could use Session Facade (Session Bean) and Service Activator (Message Driven Bean) patterns to enable access to the Business Objects. However, every time I add a new method I have to add methods to the Session Bean and message decode logic to the Message Driven Bean.
* So, how about having a single Session Bean and a single Message Driven Bean to act as the sychronous and asynchronous interfaces to the Business Objects?
I'm going to fall back on my experience of developing event based systems and EAI. So thinking of an event based system here comes some very sketchy Java...
----------------------
** Event Definition **
----------------------
abstract class EventDefn implements Serializable
{
private String mEventName;

// getters & setters
abstract public boolean validate ();
}
----------------------
** Event Processing **
----------------------
class EventProcessor
{
// This should be a SINGLETON, but I spare the code.
private Hashtable mEventHandlers = new Hashtable();
// ... contructor, initialisation, etc...
public void process (EventDefn pEvent)
{
EventHandlerBase lEventHandler = (EventHandlerBase) mEventHandlers.get (pEvent.getName());
if (lEventHandler != null)
{
lEventHandler.process (pEvent);
}
}
}
abstract class EventHandler
{
abstract public void process (EventDefn pEvent);
}
------------------------------
** Concrete implementations **
------------------------------
class AddOrderEventDefn extends EventDefn
{
private String mOrderName = null;
private Integer mOrderNumber = null;
// more attributes
// getters & setters
public boolean validate ()
{
// attribute validation logic
}
}
class AddOrderEventHandler extends EventHandler
{
public void process (EventDefn pEvent)
{
AddOrderEventDefn lAddOrderEventDefn = (AddOrderEventDefn) pEvent;
// business logic...
}
}
class ClientApp
{
...
public AddOrder (String pOrderName, Integer pOrderNumber)
{
AddOrderEventDefn lEvent = new AddOrderEventDefn ("AddOrder");
lEvent.setName (pOrderName);
lEvent.setNumber (pOrderNumber);
// etc.
if (lEvent.validate())
{
// processes synchronously
mSessionBeanRemote.process (lEvent);
// or process asynchronously
ObjectMessage msg = mQueueSession.createObjectMessage (lEvent);
mQueueSender.send (msg);
}
}
...
}
Obviously I've omitted the Session Bean and Message Bean implementations as these simply pass the Event object onto the EventProcessor singleton without any real processing.
FEATURES:
--------
* Each Business Operation requires two classes to be written that imherit from EventDefn and EventHandler.
* Each EventHandler / Business Operation can be executed synchronously or synchronously
* Only one Session Bean and one Message Driven Bean needs to be written to handle all Event / Business Operations, obviously multiple instances of these can be instantiated. Also additional such "interface / boundary" beans may be implemented to provide different priority channels, e.g. a Admin Session/Message "Interface" Bean allocated from a separate (small) pool could be used by admin clients only and therefore not be affected by pool depletion of general purpose "Interface" Beans.
* Addition of a new Business Operation requires a mapping to be added to the EventProcessor. This could be performed from an initialisation file whereby the EventHandler class are instantiated and add at startup or the EventHandler classname could be add to the EventDefn and instantiated (once) by the EventProcessor if an Event is recieved without a Handler in the Hashtable.
* I have used EJB's for providing my distributed application and for simplified thread control (via bean pools)
* Validation logic is within the EventDefn and can be executed by the client... more efficient.
* I can use Junior J2EE developers for the EventHandlers!!! They may be good at Java but are in the process of getting up to speed on J2EE.
ISSUES:
-------
* What about Transactions? Well the EventHandlers could be Session Beans as well if I want to use declarative transactions, and I can use efficient Local interfaces to execute them.
* What about return data? Well I could define an EventResultsDefn class which can either be the return type for the Session Bean process method or sent back to a return queue for the asynchronous processing. Any other suggestions?
* What about errors? Raise exceptions versus use EventResultsDefn - more of an application design issue.
* What about stateful sessions? Would a Stateful Session "Interface" Bean work alongside the Stateless Session Beans?
* What about security? I guess I've brushed aside declarative security so some custom scheme would be required.
* What about performance? Well I don't think it will be less performant than other patterns?
* Scalability and distribution of processing? Well the location of a Business Operation is now controlled by the "Interface" Beans as opposed to the deployment descriptors but this shouldn't be an issue if the EventHandler mapping is designed properly. Could use a client proxy to decided which "Interface" Bean to use for a specific Business Operation and let JNDI find it. More config data though.
CONS:
-----
* The big ones I see are that I'm moving away from using deployment descriptors for a process distribution (via EJB location) and security.
* HELP REQUIRED. THIS IS THE CRUNCH AREA. I CAN'T SEE ANY SHOWSTOPPERS SO COMMENTS WELCOME.
Regards
Paul.
[e-mail]
[e-mail]

[Tim Holloway]

The big question is: Where is it going to run? If you expect general Internet access, you're stuck with the synchronous HTTP protocol, since the JMS and RMI ports generally won't make it through the firewall gantlet.

[Byron Estes]

Why not use a command pattern instead? Keep with your original idea, but allow the SessionBean to have only one method execute(Mycommand command). Take a look at the GOf4 book, or other pattern book for more information. Sounds like a great place to use it.
Regards,

[Paul Rhoades]

Thanks for the replies, I'll answer each so far in turn.
Q: Where is it going to run?
A: If you consider a classic five tier architecture (client, presentation, busniess, integration and resource) I'm just looking at the Business layer. There will be something like Struts for the HTTP presentation tier and some Applets running on the internal network may utilise direct RMI calls.
Q: Why not use a command pattern instead?
A: If I understand this pattern correctly then my design isn't far different - I've split the Command object into data (EventDefn) and implementation (EventHandler) objects? One reason for this is that I want to keep a clean separation between client and "server" code, because:
a) The EventDefn may be transfered as XML and hence I need to instantiate the implementation on the "server" anyway.
b) I just know some muppet (I'm not very trusting) is going to call the Command.execute() method in the client app, which may compile but cause errors at runtime.
c) I want to have a clean build process, i.e. EventDefn included in Client and "Server" libraries while the EventHandler is only included in the "Server" library.
Cheers,
Paul.