Introduction
Traditional applications using relational data sources such as Oracle, SQL Server and DB2 to expose their business logic to external world in a tightly coupled manner. This tightly coupled approach leads to the performance\scalability issues. This post discusses the Designing a SOA enabled DAL with example.
Traditional Service Data Access
Above figure shows the set of web services accessing the same relational database. Every request from the client requires data access which creates the performance issue when multiple concurrent users are trying to access the database.
Traditional applications having their own databases and when we migrate to the SOA data integrity issues will arise.
SOA Model Data Access
SOA model represents the loosely coupled architecture where business logic and Data access logic are no longer integrated. We are using LINQ-SQL as an interface for the SOA DAL.
SOA DAL only exposes the DTO’s[Data Transfer Objects] to the services
DTO representing the Employee looks like the following
Data Transfer Objects
This DAL is a provider independent and can be pluggable to different databases by reading the provider from the configuration file.
The Data provider using LINQ to SQL looks as follows
Data Provider
The DataService that exposed through service layer looks like
Now You can call the above service in windows or web application. We have seen how we decoupled the application from data access logic.
More information on building the SOA data access at http://msdn.microsoft.com/en-gb/magazine/dd263098.aspx.
| Share this post : |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
