You probably already know a service-oriented architecture (SOA) can help your customers cut costs and gain a competitive advantage by streamlining business processes. You may even be investigating SOA for a possible future implementation. But how do you ensure data standardization across the Web services components that use it?
There are two possible approaches to data standardization for SOA:
SDO includes three main components: the data object, the data graph and data access services. Combined they are a powerful tool to view and manipulate data from a variety of sources.
The data object is a representation of a business entity and is not tied to any data store. This object can be defined either statically or dynamically, as there are benefits to both. If you know the structure of the data object at the time of development, you should use static access to increase performance. However, if the object structure is not known or is dynamic based off a database query or configuration file, access to the object is still possible. Contained in the data object is a set of properties -- either primitive types or references to other data objects. The data object also contains metadata that allows introspection of the object.
The data graph is a structured collection of data objects. This graph consists of a single root data object that, when traversed, contains all other data objects that represent the business entity. Data graphs also have the capability to track changed history throughout the process. These changes can then be processed by a Data Access Service, or DAS.
A DAS is the standard way to populate data graphs from various data stores. The DAS is also used to store any changes made to the data graph throughout the life cycle. When persisting -- the storing of the data in question in a file or database -- the changes made to the data graph, it is the DAS's job to inspect the data and notify the user of any conflicts that may arise during persistence.
For example, think of the data object as a product. The data graph would represent an order with data objects (customers, products, etc.) and the DAS will store and retrieve this information. The whole process is what makes the data consistent as it standardizes the retrieval and transformation of the data for each and every company. This happens regardless of who is asking for or giving the data.
At a high level, the three components used together will represent a full lifecycle service. With such a service, a request is made, usually by Web services, remote procedure calls or a variety of other sources, in which the DAS will retrieve the data requested and create one or more data objects that are represented in a data graph. This graph is then serialized and sent via one of various protocols to the client. The client can manipulate the data and send it to any service that requests information on the changes made. This information can then be persisted based on the change history stored in the data graph.
By adopting SDO tools, systems integrators can help customers achieve the loosely coupled interactions among the different systems that SOA promises. By moving to the SDO standard an integrator will greatly reduce the complexity in deploying and maintaining services. It will help keep a company agile and reduce the cost of change. With SDOs, an organization can ensure data standardization across multiple services.
About the Author:
Steve Karlovitz is an enterprise architect with over 10 years of experience in business process implementation, information systems development, instructional design and team leadership. Steve is also co-founder of Synegen Inc., a premier provider of enterprise information technology and business strategy services.
This was first published in November 2007