- Should You Consider SOAP?
- When Should You SOAP?
- Conclusion
- Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When Should You SOAP?
I can think of only two drawbacks to SOAP, but they can be significant, depending on the project. First, SOAP is not an official standard yet. The W3C has launched its own Protocol Activity, and is working on SOAP 1.2, but that's still some time in the future.
Second, SOAP is new, and it lacks some of the tools common for CORBA or DCOM. In particular, there is no transaction management with SOAP. This is not an inherent limitation of SOAP; I'm sure transaction managers will eventually appear on the market, but they are not available yet.
Currently, SOAP is ideal for distributed applications that need lightweight remote procedure calls. I realize that there is no hard definition for "lightweight," but essentially it means that the requests should not depend on object-oriented concepts such as inheritance or transaction management.
I recently ran into a project that started as a textbook example for CORBA, but it ended up as a SOAP project. I'll share the main issues with you to help you evaluate SOAP.
The project is a classic three-tier application: There is an Oracle database server, business objects reside on a middle-tier server, and the user interface is written with Java servlets. The servlets use a combination of XML and XSLT, as I explained in "Making Teams Work via XML and XSL" see "Resources" at end of article.)
The customer originally wanted to deploy CORBA between the business object server and the presentation servlets. However, we hit two problems: cost and lack of training. The ORB, the CORBA run-time, is expensive and will limit our ability to deploy the application. Also, while the development team has lots of experience with Web development, they are new to CORBA.
As we refined our analyses, we realized that the communication between the presentation and middle tiers were simple remote procedure calls (for example, lists of products or product details). Given that the presentation servlets depend on XML, we came to the conclusion that SOAP would be a more elegant solution than CORBA. The SOAP response (in XML) can be fed directly to the XSLT processor.
As it turned out, the case for SOAP is compelling. Not only did we save on the CORBA licenses and training, but we deployed a Web server on both the middle and presentation tiers. That means we could draw from the same experience to fine-tune the servers.