Java EE design pattern for MDB_问答_开发者_运维开发者技术经验分享

We are designing an application in which MDBs will pick up incoming messages and do a series of tasks.

Some of these are functional like XML validation and some are like aspects such as logging, MIS entries etc.

Edit:

Message Types can be different based on the functionality such as Ordering or Raising Faults or Information Services like Postcode 开发者_运维知识库Lookups. These also vary on the Caller so an Order for Caller A is different from B, but mostly the XML structure should be the same.

Each will go through functional units of work such as Validation of Sender, Validation of product codes (if placing an order), Security checks (IP based), Registration into our DB if valid, Error Queue if not and so on.

My question is since we want to make the functional bits modular such that we can build one MDB which does functions A,B,C and another MDB to do B,C,D and so on based on what type of message it is - and based on which tasks are common across all the message types.

What design pattern should I be using for this?

Secondly, is there a way for me to configure these functions in an XML file, so that the MDB reads the XML to see which functions it has to execute and in what sequence? This is as an alternative to having the modules in Helper POJOs or Session Beans which are linked from the main MDB which is what we currently thought of.

@shinynewbike: for your problem, it would be better to use MDB to just read the message and determine the type of message and then MDB can consult a factory class to return a list of handlers implementing same interface and which MDB can iterate over to call...so basically a command design pattern. A sample XML configuration:-

<configuration>
<handler name="A" class="A"/>
<handler name="B" class="B"/>
...


<handlers-stack name="stack1">
 <handler ref="A">
 <handler ref="c">
</handlers>

<message type="X" handlers-ref="stack1"/>
<message type="Y" handlers-ref="stack2"/>
</configuration>

Strategy, probably, with the quirk that each MDB can have several strategies. If you want to configure the set of strategies that a bean uses in a file (or an env-entry or similar), then you'll have to obtain references to the strategies via JNDI, rather than having them injected, which is a minor pain.

In a non-EJB world, i would suggest Observer, but with EJBs, i think it's rather hard to have one component give another a long-lived reference to itself. Unless they're @Singleton, which MDBs aren't.

Pattern terms aside, we have strived at our company to keep business logic out of the MDB class itself. This works really well for what you are trying to build here, which almost sounds more like an Enterprise Service Bus (ESB) Service Gateway pattern. Check out the following links from MSDN (good page even though it isnt Java) and Martin Fowler.

I would recommend allowing the MDB to take in the messages. Then you could use other patterns (Command, Strategy, Factory, etc) to do the actual work. Or, the main MDB could figure out where the message should be forwarded to and then forward the message to a queue dedicated to a particular type of function.

This does add some administrative and resource overhead from the perspective of more queues and MDB's. But it also adds a bit more separation between the different logic for the differing messages (ie, separation of concerns). And it also gives you the ability to throttle the differing "implementation" queues differently depending on performance needs, rather than having one queue be the bottleneck for all.

There are performance considerations to adding new queues. I wish I could give you a concrete answer as to "how much", but I can't really as it depends on what you choose to use for your application server and your JMS and/or messaging provider. And unfortunately, there is no magic "number" for what is right. You really have to sit down and discuss with other architects how many queues you need. It is best to do this upfront with your design. This will hammer out any number of queues. Next try to figure out the load on the system. How big will your messages be? 100KB? 1MB? 5MB? larger? smaller? And then how many messages will be coming through the system at a time? With numbers like these you can revisit your decision on the number of queues and see if it still makes sense. You can also have your application server/messaging admins (or you if that happens to be you) throttle the queues with the different configuration settings so as to allow for smoother messaging through your system. (You may also need to tune the application/messaging servers JVM heap settings too depending on what you encounter).

Sadly, the best way to gain performance by throttling your application server is by reading, reading, reading whatever documentation and forums say about it. And also by experience of working it yourself.

But even with that. The most important thing is good and yet simplistic design. If you go overboard and make a queue for everything you may impact performance. But then again you may not. But you might over-complicate your application and make it harder to troubleshoot.

I'll try to find some more links for you, but honestly take what we all say here and discuss it with your fellow developers.

And if you could alter your question to mention how many message types you might deal with or their purpose, we all could give you a better recommendation along the design, number of queues, etc.

While I realize that this does not squarely answer your question, you might want to have a look at the apache commons chain