Databases Reference
In-Depth Information
Language (WSDL), and Universal Description, Discovery and Integration
(UDDI). For example, if the scenario shown in Figure 11-1 was implemented
using Web Services, the Teller application would request the Withdrawal or
Deposit service using a SOAP message, and data passed between services would
be exchanged in XML. Each service in this scenario would publish its details in a
SOA registry using WSDL/UDDI.
Do the following to ensure your database applications perform well in SOA envi-
ronments:
•
Involve data experts in addition to SOA experts.
•
Decouple data access from business logic.
•
Design and tune for performance.
•
Consider data integration.
SOA guidelines are defined by SOA architects, who do a good job of creating and
managing reusable services that represent business logic. But SOA architects
aren't experts at databases or data access. As explained earlier, SOA is about busi-
ness agility. SOA helps achieve agility by allowing you to build services that mul-
tiple applications can reuse.
For example, suppose you design a service to be used in an application that
typically has no more than 50 users. When the application is deployed, the per-
formance of the service remains good until other applications are deployed that
start to use that same service. Quickly, there are 500% more users than the service
was designed for, and performance takes a nosedive.
This is a problem we've seen over and over in real-world SOA service
design—the performance of a service that performed well when it was first
deployed breaks down as other applications begin to use that service. Designing a
service that performs well for 500 users is different than designing one that per-
forms well for 50 users. The performance guidelines discussed in previous chap-
ters of this topic will help you reach your scalability goals.
Performance Tip
To achieve the full promise of SOA, you need data access experts, not
just SOA experts, involved in the design of services that access data.
