Ruminating on SOAP
It seems that lot of people are starting to move their CORBA/DCOM/RPC/RMI/etc designs to us SOAP instead. To me, that seems to miss the point. SOAP can be used as a replacement for the various RPC technologies that already exist, sure. In my mind, there are 2 key reasons for SOAP rather than RPC(etc).
The first point speaks to the fact that most RPC-like technologies are around passing some parameters to a virtualized function call, and returning the result. What if I want to capture a snapshot of a set of tables, or a varied collection of data (all the updates to my inbox status, for example). In a loosely coupled world, where a remote action invocation may take some time, you want to package as much information as possible into a single message. This tends to be quite awkward with the RPC style technologies, which is not to say it is impossible, just unpleasant. That SOAP allows an arbitrary payload of XML provides a perfect workaround to that problem. XML may not be a perfect solution, but it is the best public standard for this kind of thing that we have today.
The 2nd point was hit home to me some years ago when talking to developers building web front-ends on disjoint back-end functionality where each back-end was owned by a different team. It was much easier to convince them to expose an ASP/CGI/etc that returned text/xml, than it was to convince the other teams to expose their databases directly. If the front-end was tightly dependent on implementation details (database vendor, machine name, database schema, etc), that restricted how much the back-end teams could adjust their designs over time. By putting a simple SOAP(ish) access point, the back-end teams now had much more freedom. The front-end didn’t care what database was used, or what the schema was. All of that was carefully isolated behind a simple, clearly defined API, which was not tied to any implementation technology. (well… almost)
All the SOAP stacks I see today are all based around just repeating the old RPC infrastructure, but with SOAP in the middle. What is the plan for supporting implementation abstraction? Each side is using the tools to serialize the SOAP data to/from objects, and then working off those objects. What happens in V2, when you change your back-end and it no longer matches your protocol 1-to-1? It is great to see tools that make it easy to build a web-service, but these tools do not seem to be doing a good job with planning for the future. Is the theory that as soon as you break the 1-to-1 mapping, everyone will have to hand code their SOAP listeners? It is good to see that people are thinking about designing XSD schemas to support evolution of the data on the wire, but what about evolution of the code at either end of the wire?
- Sending larger, potentially irregular or semi-structured units of data.
- Abstracting from the exact details of the current classes/data-structures
The first point speaks to the fact that most RPC-like technologies are around passing some parameters to a virtualized function call, and returning the result. What if I want to capture a snapshot of a set of tables, or a varied collection of data (all the updates to my inbox status, for example). In a loosely coupled world, where a remote action invocation may take some time, you want to package as much information as possible into a single message. This tends to be quite awkward with the RPC style technologies, which is not to say it is impossible, just unpleasant. That SOAP allows an arbitrary payload of XML provides a perfect workaround to that problem. XML may not be a perfect solution, but it is the best public standard for this kind of thing that we have today.
The 2nd point was hit home to me some years ago when talking to developers building web front-ends on disjoint back-end functionality where each back-end was owned by a different team. It was much easier to convince them to expose an ASP/CGI/etc that returned text/xml, than it was to convince the other teams to expose their databases directly. If the front-end was tightly dependent on implementation details (database vendor, machine name, database schema, etc), that restricted how much the back-end teams could adjust their designs over time. By putting a simple SOAP(ish) access point, the back-end teams now had much more freedom. The front-end didn’t care what database was used, or what the schema was. All of that was carefully isolated behind a simple, clearly defined API, which was not tied to any implementation technology. (well… almost)
All the SOAP stacks I see today are all based around just repeating the old RPC infrastructure, but with SOAP in the middle. What is the plan for supporting implementation abstraction? Each side is using the tools to serialize the SOAP data to/from objects, and then working off those objects. What happens in V2, when you change your back-end and it no longer matches your protocol 1-to-1? It is great to see tools that make it easy to build a web-service, but these tools do not seem to be doing a good job with planning for the future. Is the theory that as soon as you break the 1-to-1 mapping, everyone will have to hand code their SOAP listeners? It is good to see that people are thinking about designing XSD schemas to support evolution of the data on the wire, but what about evolution of the code at either end of the wire?
posted by derek at 5:51 PM
0 Comments:
Post a Comment
<< Home