Scaling Service Oriented Architecture

by Philip Wik

A look at how Oracle solutions fit into a scalable Service Oriented Architecture

August 2012

Introduction

Globalization has pressured enterprises to look for SOA scalability solutions. Smaller companies are also looking for ways to stretch their SOA capabilities but without increasing sunk costs.

The purpose of this article is to show how Oracle solutions fit into a scalable SOA. It seeks to answer this question: Given the Oracle technology that exists today, how can we optimize SOA scalability? The first part of this article explores what scaling is and what it means to an SOA. The second part of the article proposes Oracle-based solutions to SOA scaling and an Oracle-based SOA scaling roadmap.

What Scaling Is

Scaling is the ability of a system to handle elastic demand. It allows our systems to handle heavier or lighter loads. A load could mean users, queries, transactions, servers, or services. A scalable system has functionality that improves as capability is added or functionality that erodes as capability is reduced.

What Scaling Is Not

Scaling is not just adding capacity to handle increased throughput. It's more than adding CPU, RAM, job threads, and disk storage. And scaling isn't extrapolation. It doesn't follow that because we can process ten million rows in an hour on four CPUs, we can also process twenty million rows in an hour on eight CPUs. A scaled solution is not just about scaling out. We must also scale in. Scaling has nothing to do with quality, as scaling can amplify errors. We gain nothing by going from a gigabyte per hour on an Extract Transform and Load process to a terabyte per hour ETL if the percentage of insert failures is the same. Scaling isn't tuning alone. Like an efficiently-running taxi without fares, a SOA can run perfectly but deliver no value. Finally, scaling isn't potential performance. Having an Oracle Exadata Database Machine can no more ensure scalability than having a V6 turbocharged formula race car can ensure speed. Just as a broken gasket can kill car performance, a degraded network can kill system performance.

A Scaling Model

Let's use a tesseract to represent scaling.

Figure 1: A scaling model

We can view the way we manage resources as a cube within a cube. A resource can be any deliverable asset, such as infrastructure, memory, storage, or services. The inner cube represents resource consumption that is required at any point in time. The outer cube represents potential resource deployment as constrained by an enterprise's budget. It's the upper bounds of what the enterprise can afford or do. These constraints will grow or shrink as a percentage of the gross revenues of the enterprise. System demands will determine the flux of the inner cube. As the demands for resources change, the inner cube's volume will expand or shrink in four dimensions: horizontally, vertically, in depth, and over time.

Multidimensional Scaling

A coordinate model decomposes scaling on three axes. The X axis is scaling by capability or depth and the Y and Z axes are horizontal and vertical scaling. We can apply this model to hardware, software, slushware (where hardware and software are tightly coupled), and services scaling.

Figure 2: Decomposing scale in terms of a better or worse (X), more or less (Y), and larger or smaller (Z).

Horizontal Scaling

Horizontal scaling refers to adding or removing resources of the same type, such as servers.

Figure 3: The first server is scaled horizontally with the addition of two more servers.

Vertical scaling refers to adding or removing resources to a single node in a system. In the example below, an existing server is replaced by another server that has a higher capacity. Node multiplexing is a form of network vertical scaling.

Figure 4: The ten terabyte server is scaled vertically by replacing it with a fifty terabyte server

Scaling By Capability

Capability scaling is reflected as depth. In SOA terms, it's the ability to add or remove services or service capabilities. Such services can reside in a services inventory or can be rendered from a cloud as software (SaaS), infrastructure (Iaas), or as a platform (PaaS) [REF-1]). A SOA can have broad vertical and horizontal scaling but shallow capabilities. The goal is to scale in all dimensions so as to deliver coarse-grained, high value services.

Figure 5: In time zero, system capability is a simple business process. In time one, a service inventory holds discoverable and composable services with multiple business processes.

Capacity isn't capability. Just as bright people can be average performers, highly engineered systems can have mediocre results. This isn't because those tools cannot deliver superior results. Rather, bad conditions constrict good results. Among those conditions are configuration, tuning, understanding, management, and governance. Using the Oracle Business Intelligence Enterprise Edition for naïve reporting is an example of high capacity and low capability.

Tuning can deepen scaling capabilities. Here's a summary of a few of the many techniques that can help extend our SOA:

Database Tuning

• For reporting systems, consider denormalizing and storing the data as it is queried. Eliminate logical reads and trips to the database.
• Use Automatic Statistics Gathering to keep optimization statistics updated.
• Tune parameter files, especially the System Global Area, and segregate segments by application, usage, static, or high volume Data Manipulation Language.

SQL Tuning

• Tune the problem queries and the heavy hitters using the Automatic SQL Tuning Advisor.
• Use hash clustering and bitmap indexes for warehousing.
• Use explicit cursors and add or suppress indexes and hints.

Memory Usage Tuning

• Allocate enough memory to Oracle.
• Get data cached in memory.
• Use the full menu of tools to optimize Oracle databases including Automatic Workload Repository, Automatic Storage Management (ASM), Automatic Undo Management, Automatic Shared Memory Management, Automatic Diagnostic Repository (ADR), and the Automatic Database Diagnostic Monitor.

Data Manipulation Tuning

• Improve query performance by partitioning and by accessing a subset of those partitions. Partition pruning can provide order-of-magnitude gains in performance.
• Use parallelization techniques, such as Parallel Query, Parallel DML, DBMS_JOBS, parallel index rebuilds, and global temporary tables.
• RAID-enabled RACs also provides fault-tolerant parallelization.

Network Traffic Tuning

• Use materialized views to replicate data to non-master sites in a replication environment and to cache expensive queries in a data warehouse environment.
• Track and resolve disk usage, CPU use, worst users, and disk I/O anomalies. Graphical interfaces that integrate with the Oracle Enterprise Manager have replaced the standard UNIX server commands of du, sar, top, iostat, and vmstat.
• Reduce traffic to return codes, use packets from views to reduce traffic, and use thread pooling and piping. Use the BitTorrent protocol to reduce the server and network impact of distributing large files.

Scaling Over Time

Scaling is also managed over time. Seasonal changes, organizational changes, and market demand changes will provide undulations or spikes in provisioning requirements. Clouds provide just-in-time resources, rather than providing resources as we assume they are needed. On-site scaling and on-demand scaling are similar, although on-site scaling has consumption inefficiencies resulting in waste or opportunity costs.

Scaling Limitations

Technology is physically limiting. Storage capacity and network speed constrain service oriented solutions. Physical limitations to infrastructure scaling include the natural laws of physics, such as the speed of light and size of atoms. Technical limitations also include the rate of chip miniaturization and the development of innovation.

Service limitations include callback statefulness, audit information, transactionality, and singleton-type usage. The more stateless the service landscape is, the easier it is to scale, as it lets us initiate additional instances of the services to handle increased load without respect to memory consumption. The more BPEL/BPMN process-based service implementations we have, the more state and state resolution upon callbacks to correlate messages back to the originator comes into play, requiring complex database operations. The more audit information we need, the more that information will need to be stored and accessed. For transactional propagation, two-phase commits will limit scale. In contrast, compensation allows actions to be performed when not all corresponding updates of different systems succeed. For singleton-type usage, if we need to ensure that a file is read only once (even on a scaled out cluster), we will need a coordinator . In many cases, this is accomplished by deactivating an input on all other nodes, which harms scalability.

Oracle-Driven SOA and Scaling

The relationship between the Oracle SOA Suite and an optimally scaled Oracle-driven SOA is the same as the relationship between bricks and blueprints and a skyscraper. The Oracle SOA Suite can craft an SOA at any scale. But, to address scaling limitations and to fully release value from the Oracle SOA Suite, we must plan more holistically and eclectically.

Inherent Scalability

The Oracle SOA Suite is inherently scalable as it contains all of the components to achieve SOA federation at any enterprise-mandated level. Baked into the Oracle SOA Suite are capabilities to ensure high availability and scalability with traffic throttling, prioritization, caching, partitioning, and paralleling. Scaling capabilities include the Service Result Cache and Automated Lifecycle Service Governance, as well as improved performance and availability for enterprises that use datacenters or private and hybrid cloud environments. The Service Result Cache eliminates latency times associated with frequent access of static back-end data by directly embedding and integrating with Oracle Coherence's in-memory data grid.

Oracle SOA Scaling Solutions

Cloud computing is a value proposition for scaling. On-site scaling requires more management, technical effort, and interaction, but it can also provide better performance and security. As clouds can share the same SOA layers as on-site systems, on-site and on-demand scaling problems and solutions will overlap.

We can address limitations to SOA scaling by designing for statelessness, multiplexing nodes, scaling the middle tier, scaling the database, throttling, and using asynchronous messages. Oracle technology that can promote SOA scaling includes using Oracle Optimal Flexible Architecture (OFA), Oracle Enterprise Manager Grid Control, the Oracle Exadata Machine, and Oracle Real Application Clusters (RAC).

Horizontal scaling can be accomplished by using the Oracle OFA to help eliminate fragmentation of free space in the data dictionary, isolate other fragmentation, and minimize resource contention. Grid Control is another horizontal scaling tool that allows management of multiple instances of deployment platforms.

Vertical scaling using RACs allow multiple computers to run RDBMS software simultaneously while accessing a single database file, thus providing a clustered database. The Cache Fusion capability within RAC provides the ability to fuse the in-memory data cached separately on each computer into a single, global cache.

In-depth scaling can be accomplished with the Oracle Exadata Database Machine, as it combines hardware and software to facilitate performance. Storage cells can be added to the Database Machine to promote vertical scaling. The Smart Scan, Smart Flash Caching, and Columnar Compression features will promote throughput. Smart Scan processes queries at the storage layer, returning only relevant rows and columns to the database server. Smart Flash Caching transparently caches frequently accessed data to fast solid-state storage. Hybrid Columnar Compression can significantly reduce the size of data warehousing tables and archive tables.

An Oracle-Driven SOA Scaling Model

Let's view an Oracle SOA with three layers. These layers are blended abstractions rather than physical domains.

Upperware has capabilities that are closest to the customer. The customer could be an internal client (such as an executive or a developer), an external client (such as a vendor or a customer), or another system or machine.

The middle tier includes Oracle middleware such as Oracle Business Process Management Suite, Oracle Service Bus, and Oracle SOA Suite.

Lowerware is the layer closest to the processing of data through network hardware. It's also where we store operational and analytic data and tune the network and messaging queues.

Figure 6: Three Architectural Tiers

Superimposed on these tiers are layers of services that Oracle SOA Suite can orchestrate and choreograph within and across business domains and architectural tiers.

Figure 7: Three Service Tiers

The highest layer consists of presentation, the semantic web, governance, and lifecycle and change management.

The middle layer has agnostic and composite services, business process value chains, core business services, application services, repositories, implementation profiles, rules, and logistic, financial, and decision support systems.

While Oracle Enterprise Resource Planning (ERP) and Oracle Business Intelligence Enterprise Edition (OBIEE) have a presentation layer facing, they are placed in this lowest tier because of their integration with the data services layer. The lowest tier also has other tiers within tiers, such as messaging and queuing, network, infrastructure, data, entity, and analytics services. Here we clean dirty data and store operational and aggregated data, using divide-and-conquer techniques such as partitioning, materialized views, and parallelism.

Figure 8: Three Oracle Architecture Tiers

An Enterprise Information Integration (EII) layer provides uniform data access to heterogeneous data sources. EII is a powerful tool for promoting multidimensional scaling, as it shatters silos between disparate data sources across the enterprise.

While these technologies turbo-charge scale, they don't maximize scale. That must be done at the conceptual level with an Oracle-driven SOA scaling roadmap.

An Oracle-Driven SOA Scaling Roadmap

This Oracle-driven SOA scaling roadmap is intended to confederate different scaling solutions under an integrated Oracle stack that will provide a highly scalable, technology-neutral, high-performance platform using the following five steps.

1. Aspire to Infinite Scalability
   Infinite scalability is our roadmap objective. The word infinity has meaning in two areas of scaling. One area is in the marketplace where our goal is to build a SOA that can respond to an infinity of service demands. The other area is in the conceptual realm, where the vision to look for technical solutions to meet real-world needs is also infinite, unbounded by the imaginative application of techniques and technologies. An infinitely scalable SOA, therefore, is an SOA that is market and service-driven within an enterprise that fosters innovation to blend together any number of solutions to meet any present or future service need.
2. Scale Middleware from the Upper Tier
   A strategic approach to scaling advocates a pincer between the upper and the lower tiers to scale services from the Oracle SOA Suite and supporting Oracle middleware products.
   
   At the highest organizational and architectural levels, we get executive championship, funding, and governance to envision, plan, and build SOA federation. At this level, we identify and map the constellations of services to well-defined ESB domains. Without this top-down engagement, we would get islands of services that constrain scale rather than services that leverage cross-domain functionality from enterprise-level service inventories.
3. Scale Middleware from the Lower Tier
   At the bottom tier, Oracle infrastructure can provide physical scalability. Infrastructure could consist of the Oracle Exalogic Elastic Cloud and cloud foundation and data integration products. We manage this tier using Oracle database administration best practices [REF-2].
4. Federate Enterprise Service Buses A scaled SOA starts with federated ESBs. But I propose not just a string, but a network of EBSs separated by firewalls and mediated by services in a business-driven management, governance, and security framework.
   
   Why not have a single ESB? The answer is because of security concerns that place each ESB behind its own firewall. Also, multiple ESBs align with the guiding principles of the SOA Manifesto that asks us to "keep efforts manageable and within meaningful boundaries."

Figure 9: A federated on-demand SOA

Figure 10: An on-demand SOA federated network

5. Virtualize Enterprise Service Buses
   ESB separation is achieved through virtualization on top of an Exadata Database Machine, a more cost-effective alternative to having multiple machines that have multiple ESBs. Virtualization abstracts the physical realization of resources from the machine to provide elastically by running the hypervisor to define multiple virtual instances. An Exadata Database Machine minimizes horizontal scale while maximizing vertical and in depth scale.
   
   All elastic resources are virtualized on the basis of each ESB, including server, storage, network, and power. If there are four EBS, there would be four virtual machines that are virtually defined from a single Exadata Database Machine.

Conclusion

A SOA is built by designing for security, simplicity, functionality, and also scalability. Much of the value that a SOA delivers comes from scaling, both in terms of cost efficiencies and in meeting unknown service needs. We can drive scaling horizontally, vertically, in depth, and over time. We can address scaling limitations using Oracle's rich portfolio of middleware and infrastructure solutions. Integrating SOA with Oracle virtualization techniques can help scale an Oracle-driven SOA.

References

• [REF-1] Philip Wik, Thunder Clouds: Managing SOA-Cloud Risk, Service Technology Magazine, October, 2011.
• [REF-2] For information on how to administer scaling, refer to Bob Bryla and Kevin Loney's Oracle Database 11G DBA Handbook: Administer a Scalable, Secure Oracle Enterprise Database, Oracle Press, 2008, 670 pages.

Acknowledgements

I wish to thank the following individuals who reviewed and critiqued this article: Oracle ACE Director Hajo Normann, Accenture; Clemens Utschig-Utschig , Boehringer Ingelheim Pharma GmbH & CoKG; Oracle ACE Director Torsten Winterberg, OPITZ CONSULTING, and Steve Wisner, Director, IT, Genworth Financial

About the Author