Enterprise Rails

Why SOA?

Many scenarios lead naturally to the need for a service-oriented design. Some scenarios, like a shared resource, demand it. Other scenarios, like the need for massive scaling, can be helped by a service-oriented architecture because a SOA design naturally segments databases. It also reduces local complexity, which can make a caching scheme easier to implement, further enhancing scalability. The notion of reducing local complexity can be a goal in and of itself, for which SOA is the means. In this section, each of these scenarios is explored in detail.

Shared Resources

Imagine that you are building a site that sells widgets. For that site, you’d have a database full of sales data, both products and orders. Next imagine that you took my advice in Chapter 4 and did not attempt to report directly out of the sales database. Instead, you created a separate data warehouse database, which transformed the 3NF or DK/NF sales and orders tables suited for Online Transaction Processing (OLTP) into a star schema, which is better-suited for Online Analytical Processing (OLAP). This setup is shown in Figure 13-3. Each of these databases has a front-end interface for employees to access the contained data, be it sales data in the sales administration website or aggregate reports in the reporting website.

Figure 13-3. Two databases in our system

There’s an additional wrinkle, though. Each front-end ...