Spring is going Webservices! Or a bit more specific, Spring is going SOAP. Arjen Poutsma has sent this message to the world during the last NL-JUG J-Fall conference. On his blog you can find the nitty gritty details.
Personally I think it is a good idea to build a Spring based framework and not be dependant on special web service containers. But I can’t see the point of focusing on SOAP only. I know SOAP is the de-facto standard for building message based remote services. And I also see the point he’s making about the difference between message based and rpc-style invocation. But I do not see the reason to ignore other protocols. To express this, REST is mentioned in one of Arjens blogs: REST services seem to have very little common functionality that cannot already be captured with Java classes like the HttpServlet.
Okay, agree. But so what? Maybe I need to publish my beans as both SOAP and REST service? Maybe I’m stuck with a legacy message format? Maybe, for performance reason, I do not want to use SOAP? Maybe I’m not running on a servlet container but behind my own socket? And maybe I can come up with a lot more maybe’s? Both SOAP and REST are message driven protocols that share some common similarities. And those similarities can be expressed in a common interface or abstract set of classes. Loose coupling is one of the paradigma’s lite weight application design has been build upon! So, either convince me I’m wrong or extend your horizon in order to do remote invocation beyond SOAP.
By the way, a little side-step into API design. Suppose you have two interfaces specifying a method with the same name but a different return type, how on earth are you going to implement it in one class? So SOAPMessage invoke(SOAPMessage request) throws Exception in MessageEndpoint and Source invoke(Source request) throws Exception in PayloadEndpoint is maybe not a good idea. I know chances a rare in this case but you’ll never know how the dices will be thrown when you start playing.
[editorial note, I need to re-pass Sun certification. Please visit the comments section for clarification]
But, no matter if the people behind Spring-WS are going to change the previous mentioned points or not, I think Spring-WS is a good addition to the stack of available Spring modules. And definately worth the try!
October 31st, 2005 at 9:43 pm
Thanks for the post on Spring-WS! Just some remarks & clarifications for you:
First, the focus on SOAP is (at least) for the 1.0 release. We have limited time, and we need to focus. SOAP is simply be widest accepted, industry standard way to do XML-based messaging. To view it as just another “remote invocation” framework, however, is just a little bit to simple, especially with the upcoming WS-* standards. You need to decide how to route the message, how to handle them, how to do error handling, and if and where to do XML marshalling. So, we decided to design a framework which tackles these problems, not by making the decision for you, but by making it possible to choose whatever suits you.
Second, perhaps I don’t understand the problem with API-design. Isn’t it perfectly possible to implement both SOAPMessage invoke(SOAPMessage request) and Source invoke(Source request) in one class? Since they have different parameters, this is simply an overloaded invoke method, right? That said, while it is possible, I don’t think it is very likely that you will do this: each endpoint is responsible for handling a specific kind of request. For handling multiple requests in one class (i.e. one per method), there are other, nicer patterns in Spring-WS. I’ll talk about these in a future post on my blog.
Cheers,
Arjen
November 1st, 2005 at 12:38 am
Arjen, Guess I need to re-pass my programmers exam
. Tried it and have to say, yep you’re right. I’ll add an editorial excuse on the original post. That said, I still do not like methods using the same name but returning a different (not related by class hierarchies) type of result. But it’s personal and related to programming style. Still, and that’s what my original argument was more about, I do not like ‘general’ method names in interfaces. ‘invoke’ Can be used in more than one semantic context. Why not call it remoteInvokeBySOAP? Auto-completion in your favourite IDE will take care of the cumbersome name.
About the focus on SOAP. I Understand it’s limited by time. But early decisions always impact future development. Decouple as soon as you can because as soon as an API gets adopted by more than one programmer, its hard to deprecate. And I bet the Spring-WS API will be adopted by more than one enthusiast and delighted attic based java coder.