Distributed Applications Architecture and XML

This article describes a possible generic solution for a distributed Internet application which must acquire data from remote users.

The remote users may be running either a conventional browser, or a third-party software package capable of generating XML documents. There are two routes to the application server.

The first is by direct XML connection. This is analogous to the XmlSql protocol described in the previous article. A Document Type Definition (DTD) will be published by the owners of the application server to allow third-party software providers to implement this communication. The remote user will use this third-party package to prepare the data and provide the appropriate authentication information, and the package will then upload the data and process XML responses from the server and feed them back to the user.

The second route is via a conventional interactive web application. This runs on an intermediate server, and would typically be a CGI- or servlet-type development. It would communicate with the remote user using web forms, to authenticate that user and then allow them to enter their data. It would then open an XML communication with the primary application server and submit that data just as in the direct XML connection case. Hence this would act as a sophisticated proxy agent for the purposes of submitting the transaction. It would also act as a "reference application" produced by the owners of the application server for developing the DTD and the XML server side of the application.

Regardless of the route into it, the main application server must handle the incoming XML correctly, and extract the data from it, validate and process it, and then generate a response message and send it to the client.

• A suitable interface for reading and writing data from or to a URL connection. This is needed to read the incoming XML documents and send out the generated responses.
• A suitable interface for reading and validating the incoming XML document against the DTD, and converting it into the necessary business objects.
• Code to process the business information produced, perform all necessary steps, and then encode the results into appropriate business objects.
• A suitable interface for converting these business objects into a new XML document ready for transmission.

• A suitable interface for reading and writing data from or to a URL connection, as for the main application server.
• A standard forms based server side application to acquire the data from the client and convert it into appropriate business objects.
• A suitable interface for converting these business objects into a new XML document ready for transmission to the main server.
• A suitable interface for reading and validating the incoming XML response document against the DTD, converting it into the necessary business objects.
• Code to process this response and report to the user via the web interface.

• A suitable interface for reading and writing data from or to a URL connection. This is needed to transmit the generated XML documents containing the client data to the main application server, and read the responses.
• Code to obtain data locally from the client, and encode it as an XML message according to the DTD.
• Code to translate the responses from the main application server and relay them to the client.

The DTD will need to be available for all services for validating and generating XML documents for use in the exchanges. This therefore should only reside in one location to ensure consistency, and typically this would be on the server acting as the intermediate web server, because from there it would also be available both externally and internally.