Playing Together Nicely: Getting REST and SOAP to Share Each Other's Toys
Pages: 1, 2, 3, 4

SOAP Interface #3: Buzzword Compliance

The doGet method of soap.py is the final piece of the interfacing puzzle. It is used to deliver a WSDL definition for each of the services mapped by the system. For example, Figure 2 shows the results of browsing to http://localhost:8080/test/soap/wsdl/GetBasket.wsdl.

Because both my definitions and the responses from a REST request are generally quite limited, this WSDL file is not as complicated as it could be. Although the rather pedantic nature of validating WSDLs (missing "/" anyone?) means slight changes can have significant impacts on validation, and I'm only guessing (because I have yet to fully test this final feature) as to its ultimate usability.

Figure 2. Browsing the WSDL

Running/Testing the Services

In the resource file for this article, I've included a number of Jython scripts for testing the various services, which can be found in the source directory.

The scripts test-put.py, test-get.py, test-options.py, and test-delete.py can all be used for calling the REST resource directly, while soaptest-PutBasket.py, soaptest-GetBasket.py, soaptest-GetBasket-invalid.py, and soaptest-DeleteBasket.py can be used for the SOAP services. To run a test, from a command prompt change to the WEB-INF/source directory for the project and execute jython test-put.py (for example). Figure 3 shows the results of executing GetBasket, after PutBasket has been run.

Figure 3. Testing GetBasket

Conclusion

In this article, I've presented one method of creating a SOAP service that can communicate with REST resources, for client applications that are unable (or unwilling) to talk to those resources directly. However, this is really only a starting point: it didn't discuss security (authentication, authorization, securing transmissions, and so on), which is a major component of any web services application, but is in this case, of course, very dependent upon what approach you take when developing the RESTful components. This functionality needs to be addressed for the SOAP interface to be a valid solution. My initial thoughts are that, at least for the authentication functionality, a pluggable structure will be required for the SOAP interface to handle different authentication protocols (at least where this is driven by the client/caller of the service).

Other features (how many billion WS-* specifications are there now?) may also be client-driven, or dictated by the business, and affect the extent to which you can successfully design and implement your SOA as a useful and flexible collection of REST resources. In the end, a RESTful design differs significantly enough from SOAP that these requirements may force you down the SOAP avenue, whether you intend it or not. For those with a choice, hopefully this provides a starting point.

Resources

• The code for this article can be found here. The following resources are also required in order to compile and run the web application:
  
  • The Jython 2.1 distribution, found here.
  • JAXB can be found in the Java Web Services Developer Pack.
• Some related reading about REST and SOAP, written by Sam Ruby, can be found at intertwingly.net.
• Paul Prescod's excellent site is also a good place to go for reference material.
• O'Reilly's XML.com has numerous articles about REST, including:
  
  1. "Implementing REST Web Services: Best Practices and Guidelines"
  2. "How to Create a REST Protocol"
  3. "The Beauty of REST"
• The WSDL primer can be found at the W3 website, along with the SOAP primer.
• The original (unmangled) XML schema for a SOAP envelope can be found here.

Jason R. Briggs is an architect/developer working in the United Kingdom.

---

Return to ONJava.com.