by Philip Wik
A look at how Oracle solutions fit into a scalable Service Oriented Architecture
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.
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.
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.
Let's use a tesseract to represent scaling.
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.
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.
Horizontal scaling refers to adding or removing resources of the same type, such as 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.
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.
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:
Memory Usage Tuning
Data Manipulation Tuning
Network Traffic Tuning
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.
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.
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.
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.
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.
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.
Superimposed on these tiers are layers of services that Oracle SOA Suite can orchestrate and choreograph within and across business domains and architectural 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.
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.
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.
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.
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.