XML & Web services: Using command pattern with web service
We have a session bean that implements a command pattern. I.e. it has a single remote method, invoke(Command theCommand).
- Posted by: scot mcphee
- Posted on: May 07 2004 02:48 EDT
Command is an interface and has a single method; invoke(). The client requests a specific command be invoked via a delegate and gives teh delegate the data object to work with (the receiver in command pattern jargon). The delegate invokes the command on the session bean.
Has anyone got any experience with coding this sort of solution in webservices. What we don't want to do is create a separate webservice for every command we wish to invoke -- we want to do it in a general way. The only way that I can see is to encode the command-specific data with an anyType element like this;
<element name="receiver" type="anyType"/>
But how do we acheive the mapping in wsdl between this anyType and the specific type we require for that particular command?
Any other suggestions welcome.
- Using command pattern with web service by Paul Strack on May 07 2004 10:53 EDT
- Using command pattern with web service by E. A. Graham Jr. on May 08 2004 14:44 EDT
The advantage of the Command pattern for Session beans is that you can pass your operation encoded in an command object. This works well because you objects between Java programs over RMI/IIOP.
With web services, you can only pass data, not objects. Trying to apply the Command pattern to Web Services is a bad idea. After all, how would your Java web service interpret a command written in C#?
paul, first the command pattern is already implemented, the question is how to put web services onto it.
second, the command pattern forms part of the business logic. so, the 'command' is in effect the service which is being called -- in the case of the webservices the ejb would have to instantiate the command object. the data, is simply the business' domain data wrapped up in a message format (a command data class in this particular design), which is carried by the command class to the execution layer. But in the case of the web service client, they just have to send the command data in xml form which is defined as part of the domain model and the info about the command, i.e. a string representing which command is to be called.
what I don't want to have is a webservices layer that has five hundred service interfaces when from the point of view of a pure java client there is only one service - command processor - and a bunch of domain and business objects.
so from the C# viewpoint the 'command' is a string and the rest of it's payload is the contract of the XML it has to send.
This may or may not help you directly, but it could be of use to others who are investigating such an architecture: Fluidlogic.
It does a lot of what you are talking about, although it doesn't do SOAP-style web services directly. It is more 'RESTy' than 'SOAPy', and doesn't have as high of a coordination overhead as with Web Services.
Fluidlogic is a service abstraction that lets developers create abstract commands that are sent to a [local or remote] server that executes the concrete version of the command. The concrete command is basically the abstract command combined with a ServiceDefinition implementation which does the real work of the service.
It eliminates binding to a remote interface, allows for InProcess, SLSB EJB, RMI, and Servlet servers [and the ability to switch servers easily], facilitates transactions, caching, security, and a whole host of enterprise services. It makes a J2EE server optional, but it can be deployed and benefit from J2EE.
The source is available on a free-to-evaluate license, you only pay if you deploy an application.
Actually, doing the Command Pattern should be quite easily done with WebServices - after all, that's what the WebSerivces provider is doing for you. All you need to do is write a custom Handler that intercepts the WebServices call, parse/extract the SOAPElement that implements the RPC and send it off to the back-end in the format the back-end accepts. You don't even need to implement the "end-point" class (servlet, POJO, EJB) - just the Handler.
mr graham, thanks i will investigate this design. in general, how do webservices deal with services that have an interface, and not a concrete class, defined as the parameters?