As service-oriented architectures move from design into implementation and testing, and then into everyday use, it's inevitable that certain gaps will emerge between or among some systems and services. These may be legacy infrastructure elements that have long been isolated from well-trodden pathways for data in the organization, or they just might be the result of well-intentioned and potentially valuable design changes that seek to have systems or services exchange data or participate in common workflows that heretofore had nothing to do with one another.
One traditional method for dealing with such situations has been to create custom programs that understand data representations, transaction semantics and communications capabilities for elements on both sides of a "missing link" so as to bring previously disconnected elements together in a more or less convivial fashion. This approach is workable, but hides numerous potential headaches in that those who think they understand both sides of such links very well inevitably end up understanding one side better than the other and functionality sometimes suffers as a consequence. Then, too, there are the added maintenance and update headaches that come from such work: when programs or services that must remain interconnected change, the code that makes the connection work must also change as well. The more such gaps the IT organization has to bridge, the less likely they are to be able to build and keep up with all of them. Hopefully by now, you're thinking the same thing I am: "There's got to be a better way."
In fact, there are many better ways to handle this kind of thing, but nearly all of them involve XML somewhere in the resulting solutions. That's because XML's outstanding ability to capture data representations, transform content and handle complex semantics, makes it a natural candidate for building bridges between or among applications and services. There may also be cases where SOA must maintain the polite fiction that connectivity among all actors is constantly maintained, when in fact it may occur only from time to time.
As an example, think about mobile sales and service forces out in the field, happily taking orders and handling on-site activities. Business policy may be to keep all databases constantly synchronized, but communications will be working only some of the time for some of that staff in the field. Another common scenario where unity is a polite fiction that occurs only when databases and other systems from multiple vendors get welded together under an SOA umbrella. In these cases, some time will be necessary to enable data to percolate throughout the whole infrastructure so that what is presumed to be a single, unified set of data in fact behaves like a single, unified set of data.
Microsoft's ADO.NET can help to establish mechanisms for data transfer between and among disjointed infrastructure components and it can also help to manage issues related to versioning ("is this the most current version?") and concurrency (keeping track of who's reading from, and more importantly, writing to the data, and preventing incomplete or incorrect updates from occurring). Snapshot mechanisms also come into play in that when applications access data they begin by snapshotting the data before working against it: when they're finished working, the original snapshot is compared to the state of the master set at the time of completion. If both remain identical, updates may be committed. If not, a new snapshot is taken and the update process is restarted.
ADO.NET uses XML to enable transfer of datasets between communicating SOA elements. This means that as long as both sender and receiver are XML aware, both can be sure that data is represented properly and accurately and can be exchanged on the basis of an explicit, shared understanding ( XML Schema, DTD or whatever meta-data description is shared between them. Because ADO.NET works in this manner, both parties to any such exchange don't have to implement ADO.NET. As long as all parties can accept XML as input, and create XML as output, data exchange can proceed.
Service Data Objects, or SDO, provides a way to abstract data access for manipulation in an SOA. ADO.NET works well when databases act as data sources and sinks, but SDO isn't limited to specific types of data sources. SDO defines a loosely-coupled architecture, in that clients need not maintain an active connection to a data source while they manipulate source content. SDO is often used to define standard mechanisms with Service Component Architecture, a service component assembly model. Their approach is to grab a working set of data, create a graph of the interrelated data objects they're using and keep track of changes made, as well as the original state for all nodes in that graph. This is called a change summary, which is essentially an audit trail of all actions undertaken and changes made. The same graph approach also lets the client limit its communications with data sources to touch only items it needs and provides a concurrency mechanism to determine if changes may be committed or not.
Like ADO.NET, SDO also depends on XML to represent the substance of communications. The mechanisms for representing the data graph, navigating its structure, dealing with value comparisons, handling updates and committing changes are all based on explicit, well-documented XML. Here again, any service, process or application that can take XML as input and produce XML as output should be able to deal with SDO as well.
This approach sidesteps the issues inherent in working with specific programming languages such as Java or C#, which depend on shared runtime environments in all communicating parties. The XML basis for ADO.NET and SDO lets developers concentrate on meaningful data exchanges and helps them deal with the issues inherent in intermittently-available or –connected SOA infrastructures. It's no panacea for issues involved in making sure data is available when needed and always clean, current and correct, but it does offer a means whereby far-flung disparate systems and components can be welded together into a working SOA.
For more information:
The Middleware Company, 8/2004, "SOA Blueprints: Occasionally Collected Profile"
IBM Corp and BEA Systems, Inc., November 2003, "Service Data Objects"
Microsoft Corp, undated, Benefits of ADO.NET"
Microsoft Corp, April 2003, "Web Services and Datasets"
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. Among his many XML projects are XML For Dummies, 4th edition, (Wylie, 2005) and the Shaum's Easy Outline of XML (McGraw-Hill, 2004). E-mail Ed at etittel@techtarget.com with comments, questions or suggested topics or tools for review.
