Databases Reference
In-Depth Information
One of the tenants of SOA is capturing best practices. If someone figures out
the best way to implement a shipping service, all applications can use that “best
in class” shipping service. Without SOA, that same code would have to be propa-
gated to all the applications that need to perform the shipping function. Building
a DSL allows you to capture best practices for data access within a data access ser-
vice so everyone in your company can benefit from it.
Although many of the tips provided in this topic also apply to your data access
code in SOA environments, here are a few that are particularly important for this
type of architecture:
•
Reusable services imply multiple users making many connections— the per-
fect scenario for connection pooling. Any service with many users that is
called often will fail to perform adequately without connection pooling. See
“Using Connection Pooling,” page 12, for more information.
•
Reusable services imply that the same statements are executed multiple
times—the perfect scenario for using statement pooling. See “Statement
Pooling,” page 29, for more information.
•
Be aware that each service that accesses the DSL may have different require-
ments. For example, one service may retrieve large objects and require tun-
ing for this use, whereas another may load bulk data into tables and require a
different tuning approach. Therefore, it's important for your database driver
to be tunable. See “Runtime Performance Tuning Options,” page 62, for
more information about what runtime performance tuning options to look
for in a database driver.
Most companies start implementing SOA slowly, designing simple services that
do simple things. For example, the scope of a first effort may be to design a ser-
vice that looks up an order using an order ID. As developers become more com-
fortable with SOA, they design services that are more complex. For example, a
