- Posted by: Kelly Vista
- Posted on: January 18 2005 11:18 EST
I am debating using the Command pattern as my primary strategy for implementing my enterprise app business logic. The general idea is to have only a few types of abstract commands (with various types of transactional integrity) and implement each use case as a command. I guess the popular alternative (or, more correctly, the norm) is to implement session facades for this.
However, I am attracted to the Command pattern because of its simplicity, it's rapid application development angle, its disconnected-ness from EJB (e.g., a modification to a command does not mean touching any EJB at all, just the command class), and the ability for implementing cross-cutting features.
I am also familiar with it's drawbacks (e.g., maintainability for large numbers of commands, per the Marinescu 2002 EJB Patterns book).
Nevertheless, I have never tried this approach and was curious if others had feedback or case studies.
Best regards --
Forgot to add that the result of my design will be a small set of stateless session beans with an execute() interface.
No entity beans (will use Hibernate) and may very well eventually implement a Message bean interface with a similar executeAsynchronously() type method.
So, very few stateless session beans -- mainly there for remote client acceessibility.
Best regards --
I've done something similar in the past. It was in Tuxedo, but the premis is the same. We had a tuxedo service (comparable to a SLSB) and that tuxedo service used the parameters passed into it as parameterd to a Factory Singleton which created a concrete strategy object based on the request that was coming in. (see strategy pattern from GOF http://www.dofactory.com/Patterns/PatternStrategy.aspx)
This allowed us to separate the various ways of processing a response into logical strategies. E.G. if a credit card charge response is positive then you will do something entirely diffent that if it was not.
This was good for a single initiator of a transaction that could possibly do different things. The caveat is the API to this setup must be constant. if you are using this for too many different types of transactions then it will get confusing.
I've also seen something similar before the tuxedo thing. We had a single service with a generic way of passing parameters exposed through DCOM. The service would inspect the parameters to determine which sub-service to call. It may have been a nice solution, but the pattern was bastardized for simplicity sake by putting business logic in the main service and it quickly grew in to a maintenance nightmare.
It's an interesting concept to try to initiate every transaction from a single API/EJB. If the cost of implementing a SLSB EJB was high, then I might consider this methodology. Since its not, I think I would prefer the traditional approach of SLSBs for each transaction with the use of a strategy where appropriate. Besides, using this approach might elimiate some of the features of using SLSB like having different pooling strategies for various SLSBs.
In my project I need to use Tuxedo services in the same way as you did (with a tuxedo service facade). Can you give me more information about how was constructed your solution!?
I'm not sure what you're actually looking for, but here's a brain dump:
The tuxedo API we used as FML. In some cases we used views. Either way we packaged the data passed to the service into an object named Request.
We then used a factory which took the Request as a parameter. The factory inspected the Request and created the class which implemented the business transaction that should be used to process that request. The API to the business transaction simply took the Request as a Parameter.
You can then have as many specialized implementations of the business transaction implementation as necessary to process the various types of requests. You keep logic common to all business transactions in a base class, but be weary of how much you try to stuff in a base class. The cost of making some logic generic may overpower the benifit of having it in one place instead of many.
In most of the situations we used this patter, the response consited of just the tuxedo service error code (pass or fail). If you need to actually pass back data you will need to consider that into your design.
Keep in mind, these Requests were all related (e.g. we were always processing a credit card response or a response from a request to ship some product, but there were a multitude of various response types and different ways to handle them. You don't want to fall into the trap of having 1 Tuxedo service to process all requests (which I've seen before).