Databases Reference
In-Depth Information
In both traditional architectures (such as object-oriented architectures) and SOA
architectures, applications depend on technologies such as ODBC, JDBC, and
ADO.NET for access to data stored in databases. In traditional architectures, data
access code is contained within the application. Even when using an object-rela-
tional mapping tool such as Hibernate to abstract the data layer, data access code
remains within the application. This
tightly coupled
method works because the
applications aren't designed to share components with other applications
(although code is routinely copied and propagated to other applications). When
changes occur that affect data access, the code must be updated everywhere it
appears.
In SOA environments, services are designed to be reusable, but we often find
that data access has been implemented in the same way it always has, using the
familiar, tightly coupled method shown in Figure 11-2. Data access code is built
into each service that requires access to the database.
Invoice
Service
Shipping
Service
Contracts
Service
ODBC
JDBC
ADO.NET
Figure 11-2
Tightly coupled: data access built into SOA services
Building data access dependencies into services produces the following bad
side effects:
•
It forces your business logic experts to become data access experts.
•
It results in complicated deployment scenarios that are hard to maintain.
•
It reduces scalability and performance.
Suppose that, as you read this topic, you discover a tip that will speed up the
performance of a service you've been developing. The next day, you go into work
