Best Practices for SOA: Building a Data Services Layer
Choosing best-of-breed data access middleware is an important enabler of SOA
Jun. 23, 2008 12:30 PM
These days nearly every sizable organization has either implemented some form of SOA or has it on their roadmap. They quickly find that SOA efforts tend to expand like spider webs, eventually touching every corner of IT as well as the business itself. Due to the vital role that data plays both in business and systems operations, database architects, information specialists, data integration experts, and anyone responsible for data persistence in an organization are increasingly being called on to contribute to their organization’s SOA initiatives – whether or not this was intended at the onset.
Information locked away inside monolithic application silos has proven to be a stubborn obstacle to the flexibility that modern businesses require. If businesses are to have any hope of building flexible services that offer the performance and agility needed to succeed with SOA, those businesses must solve the technical challenge of accessing information – that is, data – across application platforms and their organization as a whole.
System architects who fail to devote sufficient planning to data access issues and attempt to layer a service-oriented approach on top of their existing data sources often find that providing flexibility above the service abstraction requires complex changes at the data source level, impeding the agility they sought and thereby undermining one of the core rationales for implementing SOAs in the first place.
In traditional distributed architectures, developers write a data access code, which they might then seek to make reusable. However, if a problem exists with this data access code, that problem essentially becomes propagated with adverse impact on any application that requires access to that particular data source. Furthermore, whenever anything changes — including the underlying database, the data model, or the version of the coding environment being used — the data access code must be updated everywhere it appears.
Considering that data sources can range from all kinds of structured data stores (such as relational databases, mainframe data sources, and enterprise applications) to semi- or unstructured data such as Web pages, PDF documents, office application files, XML documents, e-mail, media content, print streams, or a wide variety of content and data feeds and formats, it becomes clear that accessing and processing all these disparate types of information from so many disparate sources via the tightly coupled approach of traditional distributed data access would constitute a technical support challenge of monumental proportions.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week