The widespread adoption of XML as the common means of exchanging structured information on the Internet has made XML an ideal choice for connecting disparate information technologies. This in turn lays the groundwork for finally achieving the vision of distributed computing where information processing is seamless in a world of heterogeneous computing systems. Where previous distributed systems relied on specialized protocols and programming conventions, using XML as the common interchange format enables the creation of loosely coupled distributed systems that can be combined to deliver end-to-end customer solutions.
This is the underlying vision that drives Web services. It enables computing solutions that run on different platforms and originate from a variety of vendors (and possibly implemented using a variety of implementation approaches) to collaborate seamlessly. In this context, the evolving stack of Web service standards is primarily focused on ensuring the following:
The focus in all of these is the need to seamlessly connect distributed systems to automate business processes and related information processing needs.
Notice that as the Web services vision comes to be realized, structured XML documents become the means by which one invokes a desired information service and that the response from such a service in turn is an appropriately structured XML document. This is well suited for machine-to-machine interaction; in fact, it's the lack of structure in documents created for human consumption that has traditionally made the vision of completely automated business workflows difficult to achieve.
However, information that is well structured, rigorously validated , and ready for machine processing is often not well suited for human consumption. Although machines may communicate with one another to achieve a high degree of automation, at the end of the day these services, to be useful, need to be invoked by end users. The final response that such services deliver also needs to be presented in a form that is suitable for human consumption.
XForms plays a key role in providing this last mile in connecting humans to information technologies deployed as Web services. XForms enables the creation and editing of structured XML content within a familiar Web browser environment. The XForms processing model ensures that the content being manipulated by the end user is structurally valid and that the data being provided meets the various application constraints at all times. But the end user remains insulated from the syntactic details of ensuring that the XML being manipulated is structurally valid. The XForms components described in the previous part of this book work behind the scenes in presenting the user with an intuitive user interface that aids in the creation and management of the XML structure.
When the user is done manipulating the XML structure in question, XForms submit processing can take over to create a syntactically valid XML document that is ready for being passed on to the Web service that implements the desired processing. The final result of processing is returned by the Web service as an XML structure; binding an XForms user interface to this structure once again hides syntactic details, leaving the user free to focus on the information that is returned.
Thus, where the emerging stack of Web services standards focuses on ensuring a well-engineered machine-to-machine distributed system, XForms provides the icing on the cake by enabling end users to interact with the exciting possibilities presented by the promise of Web services (see Figure 9.1).
Figure 9.1. XForms puts a human face on Web services.
9.1.1 XForms Access to Weather Service
As an example, consider a Web service that provides weather forecasts by area code. The availability of such a service is published as a WSDL document; WSDL (Web Services Description Language) is a declarative means of specifying the calling convention for a Web service and the type of results that the service returns. To invoke this weather service, one sends an XML document that specifies the area code of interest; such XML messages are serialized using SOAP (Simple Object Access Protocol) and transmitted over HTTP . The SOAP message consists of a header and body; the message body carries information needed by the service being invoked, in this case, an XML document that specifies the area code.
To create a friendly browser-based interface to this weather service, we can create an XForms model that declares the type and structure of the XML document to be transmitted within the body of the SOAP message. Binding an XForms user interface allows the end user to specify the area code without having to work with the raw XML message. This user interface might be deployed to a variety of end-user devices; as an example, when deployed to a GPS-enabled mobile phone, the user interface might be initialized with the area code for the user's current location.  The mobile phone user can either accept the initial default or edit the area code; completing the area code might invoke an XForms submission that results in the specified area code being packaged into the appropriate SOAP message.
Notice that in this process, the end user never deals with raw XML. Ensuring that the area code being supplied is valid as specified by the weather service happens through the XForms model. As an example, if the user specifies an invalid area code in the process of editing the initially supplied default, the XForms user interface would provide appropriate feedback and allow the submission to proceed only after the error has been corrected.
Invoking the weather service results in a SOAP response whose body gives the weather forecast for the specified area. Updating the instance in the XForms model with the newly obtained data automatically refreshes the user interface. Once again, the end user works with the information in a form that is ready for human consumption, rather than the raw XML that was returned as a response. Notice, however, that the XML data that made up the weather forecast is not lost; it is present as structured XML in the model and is therefore available for further use. As a further example, the user might be able to pass portions of the weather forecast just received to a different service that locates areas that are experiencing better weather.