But how does this work within an enterprise? Let's leave aside the public Internet for the purpose of discussion, and just consider internal use on the enterprise intranet. For every application system, regardless of platform, we provide a messaging interface that is Web Services compliant. This means in practice that there will be an XML schema defining the data tags and transaction data structure for each request message and each response message, and a URL to which to send an XML formatted request message that could be validated against that schema. The XML message will be sent in a SOAP envelope. The XML schema will be used to define the WSDL used for entry in a private UDDI repository.

Omit the UDDI repository and the SOAP interface, and it will no longer meet the definition of Web Services, but it will work just fine. However, if you don't go all the way and start to build up your repository from the beginning and the infrastructure and standards to make use of it, you are not just postponing work but also significantly increasing the work that will have to be done now and in the future. Some organizations are being proactive about this to the point of exposing all existing business logic as Web Services – regardless of any immediate need for them on a specific project – to aid in logic reuse across the enterprise.

Most of the work is going to be in creating the XML messaging interface to existing applications and ensuring stateless transactions. Where there are existing non-mainframe applications built using either Microsoft COM/DCOM models or OMG's CORBA specification, the formal definitions allow the extraction of WSDL definitions and the automatic construction of client interfaces. These clients provide all the protocol translation necessary for accessing these tightly coupled applications as Web Services. EJBs are accommodated in a similar manner. Less formally constructed client/server applications require an XML request/response interface, but given that they can be readily extended into a Web Service.

For mainframes, the tightly coupled nature of most client server systems is a non-issue, so providing an XML interface is the key problem to be solved. Legacy transactions can be XML enabled either through middleware or through native logic. Middleware implementations, particularly those based on screen scrapers, have a bad reputation because they are fragile and expensive to maintain. The best implementations are usually with native logic because it is simpler, lower overhead, more robust, and less expensive. However, there will be some applications for which a middleware solution will prove to be the best choice. For these we recommend a middleware solution that is not based on a screen scraper methodology.

Two architectural issues will likely come to the fore when your mainframes are to be linked to the Web: access to batch systems and converting stateful transactions to stateless. There is no simple answer to batch access, as the batch-processing paradigm is inherently different from the online, real-time nature of transaction processing. Programming will be required, possibly including providing a query interface into the database, and the capture of batch transactions for later processing. A related issue is likely to be applications that have a cycle of on-line, real-time transaction processing and off-line, batch processing. This will mean that its Web Services will be available during some parts of the day but not at other times. The application will meet the definition of a Web Service, but violate the spirit of the 24x365 nature of the Internet.

Statefulness of transactions is a term that may not be familiar to many mainframe programmers. A traditional mainframe application will typically maintain state information of some type between processing each step of a multi-step transaction. Put this way, temporary data storage is certainly familiar, but why it is a problem with Web Services may not be obvious. Consider two simple examples.