Tech Brief

.NET-Based Data Access in SOA

Simplify your development of common data-access functionality.

• By Jonathan Bruce
• 10/15/2008

Developers and IT architects involved in implementing service-oriented architecture (SOA) in complex enterprise environments spend a lot of time on data-access issues. Up-leveling resources to SOA environments requires time spent repeating basic data-access tasks for common scenarios, with the same boilerplate code to wire everything together.

Properly architected, SOA presents business functionality and data as "loosely coupled" services. If data access is abstracted as data services, and the access code is moved into supporting client infrastructure, then ideally developers can address problems and changes throughout the environment in a more flexible manner. Data Access Layer (DAL) patterns deliver a single abstracted point of access for all data-access operations, providing a consistent view of the data model and packaging its persistence operations.

Application Blocks
One useful technology is the Data Access Application Block (DAAB) pattern that simplifies development of common data-access functionality in .NET apps without sacrificing the functionality provided by the underlying database. It's a step above a simple DAL, which allows developers to focus completely on business logic rather than data-access logic arrived at with the ADO.NET Entity Framework.

The DAAB is one of multiple application blocks included in Microsoft's Patterns & Practices Enterprise Libraries-collections of reusable software components designed to assist developers with common enterprise-development challenges and serve as guidance. While the DAAB is one of the most popular app blocks, many are unaware of what it is and how useful it can be.

The raison d'étre for the DAAB is actually twofold. It reduces boilerplate code while protecting your database infrastructure from unwieldy code or unpredictable methodologies. Importantly, the DAAB delivers access to the most powerful features of ADO.NET, exposing them through easily used classes. The DAAB lends itself well to simple DAL in SOA contexts, therefore allowing the creation of a Data Access Service (DAS) that readily utilizes the DAAB and ADO.NET's inherent scalability, ease of deployment and reusability.

While the DAAB wasn't specifically designed to work with the ADO.NET Entity Framework, it may be the right approach if you have legacy .NET solutions or will be using different database vendors for the same business solution. Add to the mix the ease of ADO.NET Data Services, and developers can work with data in the form of domain-specific objects and properties without concerning themselves with the underlying schema of this data. The drive to raise the level of abstraction at which developers can work when they deal with data delivers the potential for reducing the lead time to generate the code that's required to create and maintain data-oriented apps.

Data Server Layer

[click image for larger view]

Data Access Layer patterns deliver a single abstracted point for all data-access operations, providing a consistent view of the data model and packaging its persistence operations.

Data Access Services
One trend within IT has organizations reducing system complexity by standardizing and consolidating systems down to as few as possible. A better approach to dealing with heterogeneous environments is to optimize, particularly if the existing system works and is complex.

Optimizing disparate applications and data sources can be achieved through the use of a DAS. With a DAS, app services can access any data source through a common set of services. Support of each new data source can be easily added through integration of additional high-quality database middleware to the DAS, which may in turn be exposed to ADO.NET Data Services, entities or even cloud-computing contexts. As time passes and the system changes, the data center can adapt simply by adding to an infrastructure rather than by trying to adapt something new to fit the existing, standardized paradigm.

Managed-Code Providers
Without use of high-quality database middleware, the ability to build a robust DAS is compromised, along with any of the SOA-enabled application services that rely upon it.

Too often architects will rely on whatever is available-typically ADO.NET drivers bundled with a given Oracle database. But in order to leverage many security and performance-enhancing benefits that Microsoft has built into .NET Framework, all components-including the ADO.NET connectivity software-must consist of code that runs entirely within the .NET CLR.

ADO.NET data providers can also supply important functionality to compensate for SQL and database semantic deficiencies in the DAAB itself. The DAAB provides API leveling across multiple databases; however, it does little to shield developers from variances of SQL syntax.