This pattern is a specialization of the SessionFacade pattern developed to further lower the amount of remote calls between a remote client (such as a bunch of servlets ) and the appserver. This pattern is useful only for EJB 2.0 as it makes extensive use of Local interfaces. It also assumes the usage of the Value Object pattern to move data across the network.
I developed an application using this pattern in certain places and realized that other people might be interested in this. As far as I can tell nobody else has written a description of this, so here I go.
We have a web application in which we have a rather complex and datadriven interface (meaning both parts of the UI and the actual data presentation is based upon information from the application server). I noted a rather heavy network usuage would ensue even if we used the coarse-grained interfaces Stateless SessionBean based upon the SessionFacade pattern, so would either have to write further more specialized (and trivial) Facade beans or we could write a EJB call batcher akin to what we used in database access/updates years ago. I realized as we had already chosen to use Value Objects as the only data transported and only allow calls to the Local interfaces of EntityBeans and other beans in the system, then this could be useful as our system saw alot of the page construction as a few single consolidated actions (we have a MVC like WebUI construction akin to Struts and Webwork running).
So we wrote a system of dataobjects and a single Stateless SessionBean. The actual way it operates through reflection and naming is irrelevant, but it works by the client consolidating several descriptions of locals EJB calls and Home lookups into a collection which is then sent to the batchbean, which executes the proper lookups and calls, batches together the results and then finally returning the collection of result to the calling action. Of course some casting and overhead for reflection exists in this system, but so far the benefits have outweighed the failings of the pattern.
The reason I call it a pattern is that I have seen both more general (allowing for finder, home-method batching) and more specialized versions of this.
BTW. As for database like features, wanna bet me when someone comes up with a EJB-QL work alike for client side calling of EJBs and business objects.
Mikael Helbo Kjaer
Software Developer @ TSE as
Is what you are saying an application of the "command pattern". Your client is issuing a set of "commands" that are being carried out by your session bean, no?
Yes in a way it is like the Command pattern. I hadn't considered that though :) Figures that I hadn't stumbled on something new just a version. Anyway it applies cleanly to EJB (and in combination with several other patterns). I even have a prototype with caching of reflections, home interfaces and the like.
I'd agree that this sounds a lot like command pattern and maybe command composition. You might say that the command itself encapsulates a unit of work. A composite command might compose multiple disconnected units of work each encapsulated by a command that can itself be executed in a single network round trip. IBM provides a well-designed command framework with WebSphere that we are using. The pattern and framework are described on developerWorks:
I had done a similiar data grouping or batch pattern but the data passing is in XML. The system will be a bit slow but data passing will have a common format...which makes us remove a lot of small objects floating around especially when itt comes to maintanence...Any expert comments on the above startegy...
Doesn't this produce alot of line bloat? I mean XML is more wordy and bloated than serialized objects in my experience and then there is the parsing overhead on top. That weighs a bit to heavy for my taste in using this pattern. Of course if the application clients use the xml raw or XML is of the essence for the entire system then it makes sense. Otherwise it would make sense if you're communicating with strange clients, but let's not forget that that the communication style would be either: IIOP, JRMP or some other propreitary format. So you're essentially laying XML on top of a heavy communication format.
I agree that XML can be "too wordy" and "slow". But if one actually has the misfortune of having to deploy an application when it is only 10% done, it is the logical choice.
One can always be a little creative and use name value pairs it it makes one's life easier. But yes, for a well defined command structure there is no particular need to use XML. Unless you want to be chic of course ;-)
I think there was an article in the now extinct Java Report. I believe the author was doing something very similar to what you are proposing. I am trying to quote from memory here, so pleae bear with me.
The objective there was to enable mobile devices to be able to send "commands" to the backend enabling new features "auto-magically"
For instance, there is a command to fetch the different kinds of commands supported by the WAP Server. This is essentially metadata. This enables discovery. The mobile device would then use this metadata and user supplied input to send the actual command to the server.
I'll post the actual issue year/month if I can find it. Perhaps it might stimulate more discussion on the subject.
I think I remember seeing that. Are you taling about the one about a sort of EJB strategy pattern? I had some questions about that one. If I remember right the idea was that the byte code for the strategy was automatically uploaded to the server from the client.
Yes I think we are talking about the same article (I forgot to look it up in my library). I think what happens is the "metadata" actually returns information about the EJB interface to the mobile client. And the stub is downloaded on demand at the client. At least that's what the author professed if I recall correctly.
P.S. I will make it a point to post the article reference ASAP.
I actually found the article online. Perhaps the article does not explore what we were talking about originally. I made certain assumptions on what the article is suggesting. In retrospect, I was voicing how I thought THAT pattern would really be useful.
The example the author cites does not seem too legit. I am hard pressed to find clients providing implementations for server side actions. I would rather have the server provide metadad information on what NEW actions the server can process and what it expects from the client in order to perform them. I say this in the context of being able to communicate new functionality to the client not available when it was deployed.
Finally one's perception on the article idea may change depending on how you interpret "local interface" in the context of EJB 2.0. However the idea is worth exploring IMHO.
Here is the link
EJB clients with Mobile Actions
It is not really about uploading byte code to the appserver. The bytes used (and cached in my implementation) are the LocalHome and Local interfaces on the appserver. This means that the Batcher gets the advantage of using local speed interfaces while the calls to the Batcher itself is properly load balanced (at least if you use an implementation of J2EE which has and uses this). All that is transferred between client and server is dataobjects wrapped in a wrapper. It is important to note that I exclusivly use a single transaction for an entire call batch even if it isn't inconcievable to have metadata in the call batch to signify beginning and ending of transaction and a record of their result.
Mikael Helbo Kjær