Error handling should part the web service applications schema

SOAP does come with its own overhead and learning curve. For SOAP to be used, both client and server applications must have SOAP processors, and if development needs to be done, developers must be familiar with SOAP. Presented here is a simple lightweight model that is easily accomplished. It introduces you to the Web services fundamentals on which SOAP is based, so if you need to move on you’ll be ready.

Architecture

</ROW>
</ROWSET>

<ROWSET>
<ROW>
....

</ROW>
</ROW>
....

In both cases, you perform XML-to-XML transformations, which are covered in the next section. The application can also send standard HTTP parameters to your XSQL app. Your application can interpret them just as they are interpreted for Web browser-based applications. An XSQL Web services application works very much like a tradi-tional Web application, with the following key differences:

■■ Instead of transforming to HTML, you transform to some particular XML schema. This isn’t necessarily easier or more difficult. If the Web services appli-cation works with a simple schema, it could be easier. But while HTML is always the same, XML schemas will probably change from application to application.

These points not withstanding, the lessons you’ve learned so far apply. You use the same actions and have to make the same decisions as to when to use action handlers and stored procedures. You should still try to modularize your XSQL and your XSLT as much as possible. In general, developing Web services is like developing traditional Web applications, except you’ll probably get more input in the request. You output some particular flavor of XML rather than HTML, and the user is much stricter about what you send.