How important are data considerations to service-oriented architectures (SOA) vending Web services? Consider the following definition of Web services from AMR Research: "Web services have been commonly defined as a standardized way of integrating applications using Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), and Universal Description, Discovery and Integration (UDDI) standards. XML is used to tag the data; SOAP is used to transfer the data; WSDL is used for describing the services available; and UDDI is used for listing what services are available." (All the emphasis is mine).

In other words, we use technologies such as UDDI, WSDL, SOAP, and XML to find, understand, package, and format Web services - but the services themselves are all about managing data and providing data-based behavior. Now, this is neither the time nor the place to get into a "process v/s data" war. The point is simply that in order for service-oriented architecture to deliver up to expectations, there must be serious consideration of data-related factors. What are these factors? From the perspective of data management, interestingly enough, these factors are essentially no different for Web services architecture than for other application architectures, such as a client/server application or a conventional Web-based transaction processing application. (Conventional and Web-based together? How the times have changed.) A note to the purists: for the purposes of this article, "service-oriented architecture" and "Web services" are used interchangeably - in truth, of course, any loosely coupled, layered architecture where one or more layers exposes its functionality in the form of callable services may be deemed as a "service-oriented architecture."

Data Integration
Perhaps the most important aspect of data management is the integration of various components and layers of data. The greatest threat to the success of SOA lies here: fail to integrate all your data, and the application may tend to get increasingly disservice-oriented. As our information systems move from being soloists to joining ensembles, chorus and symphony are the name of the game. It is no longer sufficient that an application or a component of a large architecture manages its data correctly - though let's face it, even this is often no ordinary task. In addition, the component data must stay coordinated and "march in step" with other components. In a research paper on IT Trends 2004, Philip Russom of Giga Research (a wholly owned subsidiary of Forrester Research), identified the following key trends in data integration. In the paper, Mr. Russom discusses "data integration" from a more classical and thus somewhat different perspective than I have in mind; hence, although the bullet titles are borrowed from the paper, the ordering, interpretation, and corresponding descriptions are my own.