The Context of Service-Oriented Architecture
It’s virtually impossible to be in an enterprise IT shop these days without having some involvement with Service-Oriented Architecture (SOA). It seems that every large organization has SOA on their roadmap somewhere, and furthermore, SOA efforts tend to grow like spider webs, eventually touching every corner of IT, as well as the business. Case in point: SOA efforts are now impacting the teams responsible for data persistence in the organization. Database architects and operators, information specialists, data integration experts and others are now being called upon to contribute to their enterprise’s SOA initiatives. As it turns out, the relationship between data and SOA is multifaceted. On the one hand, Services depend upon data persistence like all software. But on the other hand, SOA requires that companies address particular challenges that rely upon the data team’s expertise to solve. After all, virtually all enterprises face the challenge of accessing information in the organization. Information locked away inside monolithic application silos has proven a stubborn obstacle to providing the flexibility the business requires. For organizations to be successful with SOA, therefore, they must solve the technical challenges of accessing data across their organization, if they have any hope of building flexible Services that offer the performance and agility the business requires.
It’s also important to remember that while many organizations look to SOA for both increased agility as well as reusability of existing assets, poor choices in data access middleware can actually limit both agility and reusability. When architects fail to pay sufficient attention to data access issues and attempt to layer a Service oriented approach on top of their existing data sources, they often find that providing flexibility above the Service abstraction requires complex changes at the data source level, thus preventing the agility they require, as shown in the figure below.
In the figure above, an organization has implemented Web Service interfaces as part of a SOA initiative, and yet, they haven’t properly addressed the data access issues that underlie those Services. Instead, it’s critical to address data access— the technology that enables applications, Service implementations, and other software to access heterogeneous data sources—by leveraging data access middleware that provides the performance, reliability, and flexibility necessary to support the agility and reuse benefits of SOA. The bottom line is that regardless of the abstraction and persistence technology that make up the SOA infrastructure, data access remains a key building block technology for SOA, for example, an organization using Hibernate to abstract data will suffer performance penalties if the underlying JDBC driver is not fast and scalable.
The role of data in SOA
Service-Oriented Architecture (SOA) is an approach to distributed computing that treats software resources as Services available on the network, where people can compose those Services into business processes to meet business requirements in a flexible, agile manner. Consumers of these Services (the software that accesses the Services) can find and connect to the desired Service providers (the software that offers the Services) in a loosely coupled fashion, meaning that the Service providers can be independently created, controlled, developed, and managed from the Service consumers.
From the business perspective, Services represent functionality and data the organization requires to run its processes and thus meet the needs of the business. Business people don’t care if some capability consists of application functionality while another actually represents a data operation, and furthermore, it’s also not relevant to the business whether data are structured or unstructured, or where those data are stored or how they get to the user. Business users simply want Services to work as advertised.
The data challenge for the enterprise as it implements SOA, therefore, focuses on dealing with the various types and sources of data in the organization transparently to the business user. Implementing SOA depends upon exposing information and processes as self-contained Services that can communicate and interoperate with each other in a standard way, enabling the business to build flexible compositions of Services that implement business processes. Addressing this SOA data challenge requires the appropriate use of Data Services. A Data Service is a contracted, composable representation of a data query or a combination of data queries.
