Last month we built a simple client for the Google API. In this month\'s column we\'ll look at how SOAP headers can be used to talk to an intermediate server that adds value to the basic search service. The value-add is actually pretty silly: we\'ll send the query, pick one of the results at random to return, and send it back as an HTML page in Pig Latin. Our goal, however, is to understand how to process SOAP headers, and why you\'d want to do so.
As you may know by now, SOAP 1.2 has reached Proposed Recommendation (PR) status, which means that the XML Protocol Working Group believes that it\'s done. A few PR issues have been raised. It can be fun to look at the list, as the issues range from \"I found a typ\" to \"this isn\'t full XML, send it back to the committee\". If you\'re pedantically inclined -- and everyone in the computer field must have at least some inclination in that direction -- now is the time to break out the coffee and the reading glasses in order to find issues of your own.
Web Services provide an excellent way to talk between distributed systems using HTTP GET, HTTP POST, or SOAP. However, all of these communication schemes send data as clear text by default, which can present a problem when the data needs to be encrypted to protect sensitive information. There are several ways to handle encryption, including using Secure Sockets Layer (SSL), custom encryption, and a variety of up and coming standards such as WS-Security and XML Encryption.
