Originally posted by William Brogden:
So what do you see as the main sticking points that are forcing this move? Are people giving up on the basic SOAP premise or what?
Bill
No. It just means that the focus of today�s SOAP is quite different from the original "Simple Object Access Protocol" which introduced RPC/encoded. Today�s SOAP focuses on specifying extensible rules for ferrying XML documents (potentially) over multiple SOAP-intermediaries and what to do in the face of failure. Now admittedly this is overkill for most point-to-point transmissions of XML documents as the REST movement is quick to point out. However the SOAP and WSDL specifications readily lent themselves to tooling (with mixed results) which explains their current prevalent role in XML over HTTP transmission.
SOAP's complexity is necessary to support SOA as defined by IBM:
An enterprise-scale IT architecture for linking resources on demand. They are talking about
dynamically (in effect on a whim) reconfiguring how a business' services interact. (A SOAP client doesn't care whether the node it's sending the message to is actually a SOAP intermediary or the SOAP receiver.) No wonder they are warning that the business must
establish hype-free SOA value propositions which can be accomplished by identifying and describing how SOA addresses client-specific pain points or business challenges.
The ultimate question is: How many businesses need to "link resources on demand" to "address client-specific pain points or business challenges"? Please lets not go through the early days of the
EJB architecture again (only this time under the banner of SOA) that addressed the needs of a specific niche of customers but failed to address the needs of the majority of corporate and institutional infrastructures.
RPC style Web Services are currently overused � they are prone to become instances of the "Tiny Service", "Client Completes Service", and/or "Fine-Grained/Chatty Web Service" anti-patterns. Parts of EJB attracted excessive criticism because some developers insisted on exposing class/object level interfaces with a technology that was designed to expose component level interfaces � there was a failure to appreciate the appropriate level of granularity. The same thing seems to be happening to RPC style Web Services and Web Services in general may draw excessive criticism as a result. In some cases the use of RPC style Web Services is appropriate but I suspect that in many cases RPC style Web Services just don�t "accomplish enough" to warrant the serialize-to-XML/envelope-in-SOAP/client-handler-chain/server-handler-chain/extract-from-SOAP/deserialize-from-XML overhead � however the current generation of tools makes it deceptively convenient (rather than just using something like Hessian or Burlap). Web services are called "services" for a reason, their granularity is supposed to be coarser than the component-level, both of which are supposed to be coarser than the class/object level.
When interoperability is a concern, dematerializing objects on one end and rematerializing them in a compatible manner on the other end is a pipe-dream because platforms can be very different. Hence the move towards document/literal � no platform should have any problem with XML-text - what they do with it is their business. (This doesn�t mean you shouldn't consider your clients � if your "service" serves (mainly) JavaScript clients maybe your should be serializing to JSON instead of/in addition to XML).
Ted Neward:
this is a message, andit�s in XML, because wanting to take your code and seamlessly turning it into objects and back again, [�] that�s just not going to work. It�s not going to happen.
