SOAPOX
Sanjiva Weerawarana writes:
So why do we have all this debate? Its because WS-* implementors (including myself until we did WSO2 Tungsten and Apache Axis2), took the view that REST is not important and ignored it. Duh. We were wrong. Sorry. A thousand apologies. So now, we have a solution: both can be done using one middleware, one programming model and one set of tools.
Which I believe is wrong. Paraphrasing my own comment from the service-orientated architecture mailing list: Similarly to SCA, this approach seem to ignore that there is a larger difference between REST and SOAP than it might seem to a WS proponent at first sight. In REST, you have lots and lots of resources all supporting the same interface; in SOA(P) (at least the wide-spread paradigm), you have few endpoints all supporting different interfaces. In other words, the different is much bigger than just adding a (virtual) SOAP envelope and turning a GET request into XML.
Eloquently put. The “nature” of the service(s) should drive the “architectural” style used. Mixing them both up in the same middleware makes it all the more confusing and complex.
You are really only talking about an implementation detail of how messages are dispatched to handlers. Hence I disagree with you.
Exposing resources rather than endpoints is a difference that is very visible on the wire (as you’re posting to different URIs that might be served by different applications.) I can’t see how this could be viewed as an implementation detail.
… because namespaces their visibility on the wire are an illusion, Stefan. How I create that illusion is an implementaton detail. REST is precisely not about “this stuff sits here” but about “this stuff is mapped here”.
I don’t get this point, Clemens. Can you elaborate? Or have you maybe done so in one of your blog entries and I missed it?
Or are you arguing a different point? What I’m criticizing in the approach taken by Axis2 is that it promotes a POX programming model and calls it REST. I’m not saying that you can’t use similar programming models for POX, REST, and SOAP, just that a RESTful application is so different from a SOAPful one that you can’t hide that behind a common programming model as a detail. In other words, none of the approaches I’ve seen so far enable the exact same source code to be used for a both a Web services-based and a RESTful approach.
Stefan,
I’ve actual done something similar where I developed both a REST and SOAP interface to a Work Manager Service. I developed the work manager component in Java and then overlayed a SOAP and REST layer on top of that.
Is that what you’re talking about?
cheers
Jim - I have no way to tell without more detail :-) I think overlaying both a REST and a SOAP/WSDL layer over the same business logic is certainly possible. Both will, IMO, look pretty different. Did yours?
Not so different. They both mapped to the same underlying OO component model. The skeletons looked different because of the different abstractions (sevice-based and resource based).