The final pattern in EJB Design Patterns book catalogue has been posted for public review. The EJB Command Pattern is lightweight alternative to the Session Facade pattern that decouples the client from the server, while executing business logic in one network call and transaction.
- Posted by: Floyd Marinescu
- Posted on: September 26 2001 23:51 EDT
Unless the community suggests particular patterns which the EJB patterns book should have, this is it folks! Its been a great journey and I thank all TSS members who submitted reviews of my patterns.
Feel free to continue submitting reviews of existing patterns. In the meantime, pre-edited, pre-final versions of existing work will be posted online in the coming weeks, as well as 4 more chapters: EJB Design Strategies, Patterns Driven Design, EJB Implementation Process and a chapter on using Session beans with JDO.
Check out EJB Command Pattern.
- EJB Command Pattern posted for public review by Rickard Oberg on September 27 2001 02:26 EDT
- JSR 89 - OSS Service Activation by Ben Eng on September 27 2001 09:52 EDT
- EJB Command Pattern posted for public review by Timothy Rawson on September 27 2001 13:57 EDT
- EJB Command Pattern posted for public review by Reginald Wasson on October 28 2001 01:34 EDT
- Command pattern in big projects. by Halle G on November 28 2003 09:22 EST
This is a very cool pattern, and also happens to be the main pattern of the WebWork web application framework. All code is encapsulated in Action's, which look exactly the way they're described in Floyd's chapter. These actions are called from form submissions or HTML link traversals, and can do whatever they need by using EJB's and such.
Lately I've added a client/servlet dispatcher to WebWork, which allows for the remote execution described, but using a servlet as the action dispatcher. This allow clients (such as applets) to create actions, populate with data through setters, and then serialize them to the server by POST-ing them to a servlet. The servlet executes it, and the action now has full access to the "local" environment which means that it can lookup any EJB's or resources it needs. It can do as fine-grained calls as it wants, since there is virtually no overhead involved. The servlet then returns it to the client which can use getters to display the result data.
The cool thing about this is that no matter how complicated the process that is being executed is, there is only one network call. The client, e.g. applet, also doesn't have to know anything about EJB or similar. All it needs is a wrapper class that serializes/deserializes the action using HTTP. This drastically minimizes the number of classes needed, hence reducing the applet's size to a minimum.
For more info about WebWork, please see http://sf.net/projects/webwork.
Turns out that the book only has 19 EJB patterns, and I would like to write one more. Any ideas on a fundamental pattern that is missing?
Glad to see you hanging around TSS more often. :) How does presentation logic fit into web work - ie: parsing of attributes from the Servlet Request and/or client side validation?
What is the status of webwork, are you now recommending it for project use?
How does presentation logic fit into web work -
> ie: parsing of attributes from the Servlet Request
> and/or client side validation?
Parsing of attributes can be done in PropertyEditors or in the action itself. For this particular pattern where there is an client/applet and a server involved you'd do some client side validation outside of the actual action. This will allow you to do some basic reality checks before doing the network call. Most of the validation would be done (by the action) on the server side though, such as semantic checking since that often involves using the object model or similar.
> What is the status of webwork, are you now
> recommending it for project use?
We just released 1.0-RC2 and functionality wise it's pretty solid, and waaaaay improved since 0.95. It's almost two entirely different beasts. What's missing, mostly, is docs, although work on that has begun. There are loads of examples though, which should get most people going pretty fast. The mailing list is good too :-)
Interesting question, as I was wondering about contributing a chapter. I have some thoughts based on work I'm doing now. Please email me at dhale at longaberger dot com and we can discuss it some more.
i just took a look at Floyd Marinescu's example implementation of the command.
It seem he uses remote interfaces, althought local interfaces could be used.
Now i'm confused, what should be used?
You might also take a look at JSR 89 (OSS Service Activation). This specification is very similar to the EJB Command Pattern that is proposed here. It extends this pattern to support asynchronous execution of the business logic, polled monitoring of progress, and events (JMS). There is both a Session Facade and a Message Facade according to the isomorphic transformation defined for the OSS through Java Initiative. (http://java.sun.com/products/oss)
Command pattern in general very powerful for distributed systems in general. Makes it easy to insert layers into communication channel without impacting code depending on the command. For instance, had a java web start app running in Sun JVM 1.3+ talking to Websphere 3.5. IBM's RMI/IIOP & JNDI doesn't play nice with other jvm's, therefore had to insert a servlet to tunnel. Modified command target to use tunnel transparently to the app. Also, central point for tracing communication. Also allows one to blend systems (user RMI command target for one command, override as abstract base as needed)
But, back to main focus, very good for ejb as the command executor demarks the transaction and the pattern is flexible to optimization and customization in a consistent manner. Only lightly read over document, did it talk about the natural support in the concept to support undo operations? Also wrapping commands with other commands.
In regards to the comment about a last possible section, maybe a summarization of scale/scope of EJB project and which patterns fit well. I realize that performance tuning is a whole different realm, but perhaps a methodology of recognizing where designs are failing or what isolating hotspots.
Nice woork! Great to see GOF applicability with ejb. Like others I did the same with servlets. Now I see ideas for ejb use as well
After working in a project using command pattern I have made following conclutions (they are my personal). I've used facade earlier.
- Its difficult to reuse logic between commands. You have to create a common subclass or support classes.
- You end upp with many "almost the same" commands.
- The facades together with javadoc give you a good overview documentation of the system. With commands that more difficult.
Maybe some kind of combination of this two would do the trick.
can u guys please give me a parctical example where this pattern would be used