Extreme Transaction Processing: Technologies to Watch

XTP is an emerging application style addressing the modern breed of global-class, multichannel-enabled, highly distributed and highly interconnected, ultra-high-end transactional applications. Established transaction processing (TP) technologies such as TPMs or enterprise application servers (EASs) will be complemented and replaced in the long term by emerging technologies specifically designed to support the demanding requirements of modern XTP systems.

Organizations should prepare for this new generation of application by selecting the appropriate mix of incremental and disruptive technologies on the basis of their anticipated requirements and willingness to take risks to gain competitive advantage.

Gartner defines XTP as an application style aimed at supporting the design, development, deployment, management and maintenance of distributed TP applications characterized by exceptionally demanding performance, scalability, availability, security, manageability and dependability requirements.

Very much like traditional TP systems, XTP applications are aimed at enabling efficient, reliable concurrent and real-time access (read/update) to a shared database by executing application programs commonly referred to as "transactions." XTP applications are usually business-critical in nature. Therefore, they must provide transaction support as well as all the properties of traditional TP systems: availability, reliability, manageability, security, performance, scalability, accountability and extensibility.

In contrast to traditional TP systems — typically based on stove-piped, monolithic, and tightly controlled and "closed" architectures — XTP applications operate in a more complex and highly dynamic environment. They must support multichannel access, are based on componentized and microflow-enabled architectures, are designed to integrate with pre-existing applications in advanced service-oriented architecture (SOA) scenarios and are in many cases accessible by large, globally dispersed populations of often occasional users. Often, XTP applications also have stringent “time to deployment” requirements because they are meant to support fast-growing and fast-changing business strategies and emerging business opportunities. Moreover, XTP applications, unlike traditional online transaction processing systems, frequently deal with heterogeneous data sources (for example, relational data, Extensible Markup Language [XML] documents and event messages). Examples of XTP applications are e-commerce, Internet banking, online insurance, e-auctioning, online betting, electronic trading, online travel booking, microcommerce, micropayments, radio frequency identification (RFID)-based tracking and several other scenarios (see "The Challenges of Extreme Transaction Processing in a World of Services and Events").

In contrast to traditional TP, where applications scale vertically on expensive and proprietary hardware and software, XTP applications are often architected to scale horizontally on commodity hardware and standards-based software to minimize initial deployment costs and optimize the cost of scaling up. One of the key challenges for XTP is designing, implementing, deploying, managing and maintaining business-critical application infrastructures based on commodity hardware (such as Linux or Windows boxes) and standards-based software platforms based on technologies such as Java, .NET, XML, Web services (WS) and open source.

For decades, the foundational software platform of choice for classic high-end TP has been traditional TPMs and database management systems (DBMSs). These technologies emerged more than 30 years ago to support large-scale TP applications by providing high scalability and performance, optimized resource allocation, fast recovery and transaction integrity on top of the bare operating system and file system. DBMS technology evolved dramatically during the past two decades to support the relational model and to provide subsecond response time, even on multiterabyte-sized databases. TPM technology instead evolved much more incrementally, and the same products that were running 1980s TP systems (IBM's CICS, IMS and TPF; BEA Systems' Tuxedo; Fujitsu-Siemens Computers' openUTM; Groupe Bull's TP7 and TP8; and so on) still run the business on most of Global 2000 class organizations.

New technologies are challenging the 30-plus years of classic TPMs’ domination of enterprise computing. Although traditional TPMs are often a good fit for a wide array of requirements, they provide only basic and still unproven service-oriented and event-management capabilities. Mainframe-based TPMs cannot be deployed on commodity Linux or Windows hardware platforms, so their TCO is usually higher than that of modern EASs such as BEA Systems' WebLogic Server, IBM's WebSphere Application Server, Oracle's Oracle Application Server 10g, Red Hat's JBoss Server and Microsoft's .NET. Mainstream EASs initial design goal wasn't focused on supporting XTP-class applications; it was intended to enable implementation of dynamic Web applications. However, EAS technology has evolved dramatically since the late 1990s to cover demanding TP requirements.

Given the distributed, service-oriented and event-driven nature of most new transactional applications, enterprise service bus (ESB) technology has also emerged as a foundation technology for XTP by complementing EAS with a communication platform — providing support for high-performance interaction among distributed resources — that XTP applications can leverage to exchange event messages and service requests in a secure, scalable and reliable environment. However, the combination of EAS and ESB technology cannot provide the scalability and performance required by the most extreme scenarios. Therefore, new technologies and deployment architectures are emerging to complement EASs (and to a certain extend also ESBs) by improving their scalability, performance, availability and TCO without forcing substantial application redesign. Examples of these "incremental" XTP technologies are computing appliances, distributed caching platforms and dynamic resource brokers (see Figure 1).

At the same time, new and potentially disruptive platforms (as they introduce new programming models), such as event-driven and grid-based application platforms, are emerging as alternatives to mainstream, Java EE or .NET-based EASs, specifically designed to support the most extreme requirements in terms of scalability, performance and availability.

As often happened in the past, these technologies will combine into more-comprehensive XTP platforms that will replace the current generation of EAS products. These application platforms will also provide new, more-event-oriented programming models specifically targeted at the XTP applications that will displace the current Java EE and .NET programming styles and long term will be adopted more frequently than the now-current platforms for new XTP applications. By 2011, a new generation of application platforms stemming from the convergence of diverse XTP-enabling technologies will supersede Java EE and .NET as the platforms of choice for large-scale, business-critical applications (0.8 probability). (See "Predicts 2007: Application Platforms on the Verge of Change.")

To minimize risks, organizations looking for an XTP-enabling platform should consider EASs complemented by emerging technologies, but be ready for a potential technological discontinuity as XTP platforms and new programming models enter mainstream adoption by 2011. For mission-critical software projects, users should give preference to vendors that are already investing in leading-edge XTP practices today.

Computing appliances are specialized hardware platforms aimed at increasing performance and scalability of large-scale applications or at reducing their TCO. The fundamental principle of computing appliances is to enable the offloading of certain types of workloads (typically Java-based) from a general-purpose processor onto a dedicated processor that is less expensive or that provides better performance. In a compute appliance-based scenario, the application (and the associated runtime environment — typically an EAS), instead of being executed on the main" processor, is loaded and executed in the appliance, either network-connected or plugged into the same backplane of the general-purpose processors (see Figure 2). Conceptually, the appliance is not another computer, but is an additional processor of the main system. Therefore, the application, although physically executed on the appliance, deals with the same resources (such as databases, network connections, communication middleware, security, operating system functionalities) as if it were running off the main computer. Examples of computing appliances are IBM's zSeries Application Assist Processor (zAAP) and Azul Systems' Compute Appliance.

A zAAP is a specialized processor ("specialty engine" in IBM parlance) that plugs into System Z mainframes and can only execute Java code. zAAP's primary goal is to reduce the TCO of running mainframe-based Java applications. These have approximately the same performance on zAAPs as on System Z general processors (technically a zAAP is a general processor specialized to only run Java via specific "microcode"), but the cost of a zAAP is approximately 70% lower than that of a System Z general processor. IBM provides many other types of "specialty engines," such as the Integrated Facility for Linux, a specialty engine set up to run Linux for System Z operating system, and the Z9 Integrated Information Processor system designed to offload certain classes of Database 2 (DB2)-related operations (for example, star schema parallel queries or some utility functions). IBM will continue to extend its family of specialty engines to offload other MIPS-hungry workloads like WS, XML parsing or TCP/IP support. IBM will also further optimize the products, including zAAPs, by extending functionality and possibly also providing performance improvements.

Azul Systems provides a network-connected compute appliance packaged in various system configurations (96, 192, 384 and 768 processors) based on a newly designed 64-bit, multicore processor (Vega 2). The Java workload is managed through a custom optimized J2SE 1.4-1.5-compatible Java Virtual Machine (JVM) derived from Sun's HotSpot JVM. The Vega 2 processor and Azul's custom JVM are designed to provide large memory heaps (up to 300GB) to implement sophisticated "garbage collection" strategies (aimed at minimizing pauses to clean up the memory heap) and to support optimistic thread concurrency. Each Azul system can concurrently run multiple JVMs.

Depending on the nature of the specific product, computing appliances can help organizations improve the TCO of running Java applications, boost performance, provide consistent response time, or consolidate multiple servers and workloads on a smaller number of boxes. The interesting point is that this can be achieved with minimal impact on the involved applications. These don't usually need to be modified or changed to take advantage of the compute appliance processing power. Having an application running on a computing appliance is usually just a matter of reconfiguring some deployment parameters, and in only a few cases, there is a need to introduce changes, usually minor, to the application itself.

Computing appliances is still a nascent, albeit growing, market. This technology can only be applied to Java-based applications and provides benefits to "Java-processing-intensive" applications. Because they only execute Java code, any part of the application that is not Java-based (for example, access to databases or printers or networks) cannot be offloaded onto the appliance and must still run on the "main" processor. For applications that, for example, frequently access databases but perform little processing of this data or for applications that are partially developed on other languages than Java, the benefits of computing appliances are less compelling than for Java applications that execute intensive data manipulation or complex computing.

Other factors limiting computing appliances' widespread adoptions include still limited independent software vendor support and user skepticism about the real benefits of the products considering the industry trend toward "horizontal" scaling. In specific zAAPs, adoption is primarily hindered by the cautious user's attitude toward Java on System Z mainframes and also by the complex hardware and software "release puzzle” required to put these products in operation. As far as Azul, specific obstacles are availability of the product only in a few geographic locations; users' reluctance to adopt an innovative, but nonstandard hardware architecture; and concerns about long-term vendor viability given its still relatively modest size.

Organizations looking for ways to boost performance and scalability, or to reduce the TCO of Java-based applications, should evaluate whether computing appliances can effectively support their requirements. However, before committing, organizations should also ensure that tools (for example, application servers and development framework) and packaged applications that they use are actually certified to run on the specific computing appliance. Users should also ensure through proof of concepts and intensive testing that the anticipated benefits of these products are obtainable in their specific situation and with their actual workload.

More availability of inexpensive memory and 64-bit hardware architectures, together with emerging standards for distributed in-memory data access, such as JavaSpaces, are paving the way for extensive use of "all in memory" software architectures to support the most extreme performance requirements (see Figure 3). At times based on object/relational mapping technology, distributed caching platforms (vendors qualify their products also as "data grids," "data fabrics" or "information fabrics") provide an "in memory store" where multiple applications can store, share, exchange and manipulate data (or objects) asynchronously fetched from a variety of data sources (RDBMS, but also real-time data feeds, XML documents and asynchronous messages). The goal is to dramatically improve the performance and scalability of data-intensive applications and to enable high-performance, publish-and-subscribe-style interapplication interoperability by keeping critical data as close as possible to the applications themselves (that is, "in memory").

Multiple programs can concurrently manipulate and exchange shared data in the cache via a variety of application programming interfaces (APIs) (for example, SQLJ, JDO, JMS, XML:DB and JCache), and the underlying software infrastructure is responsible for initially loading the cache, for synchronizing the cache state with a persistent data store (files or databases) either in a real-time or near real-time fashion, for saving cached data on files or in an RDBMS (persistence), for managing cache overflow, as well as for locking, transaction management and cache events notification.

Data caches can be distributed across multiple servers for performance or reliability reasons. Clearly, in-memory data is more subject to losses and integrity issues than data maintained in an RDBMS, so a way to reduce the risk of data loss is to replicate data across multiple instances of the cache running on different servers. Therefore, typically distributed caching systems provide for clustering and failover management, cache mirroring, replication and partitioning, as well as the necessary security and management features. To support these capabilities, some products have implemented sophisticated and high-performance messaging mechanism to provide efficient data transports across different cache instances. Some advanced products (for example, GemStone, GigaSpaces and Tangosol) also feature mechanisms similar to DBMS stored-procedure enabling to attach relatively simple application code (typically for performance purposes) to be executed on a given piece of data, irrespective of where in the distributed cache the piece of data might be (that is, the code moves where the piece of data is). These products plug into Java EE application servers, .NET or other platforms, and some enable object sharing across applications running on different technology platforms (for example, Java and .NET) through the distributed cache.

Vendors proposing providing distributed caching platforms include Alachisoft, IBM, Red Hat/JBoss, GemStone, GigaSpaces, Progress Software, Tangosol and Terracotta.

Distributed caching platforms enable organizations to retrofit — with minimal impact — established applications to increase their performance and scalability. Therefore, organizations can enhance the productivity of their business processes, improve customer/supplier/employee satisfaction and extend application reach to larger user constituencies while protecting investments in application assets.

In combination with Java EE or .NET platforms, distributed caching platforms enable organizations to develop distributed, ultra-high-end transactional applications (for example, global-class e-commerce, real-time access to large databases and online trading) that cannot be otherwise supported by traditional platforms alone, thus enabling organizations to explore new business opportunities while protecting users' platform middleware purchases and skills.

Although the market for this technology is growing rapidly, it is from a relatively small user base. Some vendors are more than doubling revenue year on year. Many organizations (about 250 to 300, many more if considering packaged applications that embed this technology) are using distributed caching platforms for supporting business-critical applications in industries such as telecommunications, financial services, automotive, e-commerce and defense. Distributed caching platform adoption will get a boost through bundling into larger software stacks, such as platform middleware (for example, event-driven or grid-based application platforms) or packaged applications. Technology is rapidly maturing, but only products from specialized providers such as GigaSpaces and Tangosol have accumulated a significant installed base. The main limiting factors for more-widespread adoption of these products include the small size and limited sales and marketing resources of most vendors, availability of some products only in selected locations, limited independent software vendor and systems integrator support, and complexity in deployment, configuration and management.

Mainstream organizations looking for solutions to boost performance and scalability of data-intensive .NET or Java EE-based XTP applications requiring minimal changes to established applications, as well as for products to implement loosely coupled, high-performance application interoperability, should consider distributed caching platforms. Despite their technical complexity, some of these platforms are proven products with significant production deployments. However, users should remember that these products don't address important data management issues, such as data quality improvement or data integration. Moreover, the most-mature and proven products are available from small, albeit fast-growing, specialized companies, whereas technology available from large, established software vendors is immature and only partially proven.

Dynamic Resource Broker (DRB) technology — an integral component of Gartner's Real-Time Infrastructure vision (as a localized service governor operating at one specific software layer, such as a DBMS, OS or application server) — is meant to help users optimize resource allocation and to further enhance scalability and availability for applications. One emerging form of DRB is specifically targeting support to mainstream EASs. Basically, a sophisticated form of loosely coupled clustering, this technology enables dynamic deployment or initiation of multiple instances of the same and other applications over a shared pool of networked computing resources, on the basis of defined policies. For example, to keep response time below a certain threshold for a certain mix of applications, at peak hours, more instances of a given application can be temporarily deployed on several servers (perhaps stopping or lowering priority and resource allocation of some other applications already running on those servers). When the spike of use is gone, the additional instances are undeployed so that the associated resources can be allocated to other applications that are, perhaps, dangerously close to reaching their critical performance or availability thresholds.

DRB technology can also be used to increase application availability, although its primary goal is to help users improve TCO by reducing "overprovisioning," that is, the need to allocate — in an exclusive fashion — all the computing resources required to sustain the "worse case scenario" (as an example in terms of workload) for each application. Therefore, DRB technology provides a shared application infrastructure and resources, its allocation determined by policies.

By defining a shared pool of server resources to run in a loosely coupled cluster of shared computing resources, a DRB:

Dynamically distributes requests to the appropriate server node (based on where the application instances are as well as their performance)
Evaluates the performance of applications (typically through Java Management Extensions or proprietary instrumentation, along with defined rules and policies), spawning new instances when additional capacity is needed, or removing instances to make way for capacity required elsewhere
Enables schedule-based capacity increases/decreases
Handles resource failures by restarting application instances on alternative nodes, without manual intervention via policy-based mechanisms

This happens in a way that is virtually transparent to the applications, which therefore don't need to be specifically designed to be deployed in a DRB-managed context. However, a modular and service-oriented application will better exploit a DRB environment than a monolithic application because it has a greater ability to be distributed and replicated.

DRBs are offered by specialized independent software vendors such as Cassatt and DataSynapse, although the larger EAS vendors (BEA Systems, IBM, Oracle and Fujitsu) are busy working to provide similar capabilities as part of their product portfolio (see Figure 4).

DRB technology enables users to improve availability and scalability of established EAS-based applications by optimizing the use of computing resources across multiple applications, thus alleviating the overprovisioning issue and ultimately reducing capital investments in hardware and software licenses. Depending on the effectiveness of management instrumentation and rules/policies, it could also decrease labor costs associated with manually rebalancing application resources and in dealing with resource failures (for example, installation/configuration/deployment of new servers). Because its use is virtually transparent from an application perspective, the introduction of DRB technology can happen once the application has been designed and deployed in production, with minimal or no disruption from the operational and software maintenance points of view. The DRB also has the potential to provide sensible data about the performance of business processes, which can be used by developers to refine and optimize applications.

The current generation of DRB technology has some limitations:

It can only manage the pool of resources it is given to manage because more resources cannot be dynamically added to the pool unless coordinated by a higher-level service governor.
An application server-centric DRB manages computing resources (servers) only and cannot manage virtual networks or storage resources.
It does not manage the end-to-end transaction environment (that is, the end-to-end response time) and just has knowledge, policies and optimization of the resources and section it knows about.

Initial implementations of DRBs will be largely based of homogeneous stacks from the same vendor (for example, BEA Systems, IBM and Oracle). Lack of technical maturity and a more-evident and clear demonstration of TCO benefits are key obstacles for DRB's widespread adoption. Availability of specific powerful capacity planning aids; support for fine-grained security; detailed monitoring, management, logging and metering tools; and the emergence of commonly agreed-to standards for policy definition are requisites for market acceptance of this technology.

Organizations seeking to reduce TCO and to improve scalability and availability of EAS-based applications should experiment with DRB technology, but also remember its still-immature state and the volatility of some vendors of these products.

Event-driven application platforms (EDAPs) aim to support advanced, event-centric programming models. In these programming models, business logic components (called "event handlers") are triggered to process business events represented by proper messages. These event-handler components can also emit events that will trigger other event handlers. Therefore, event processing is a form of distributed computing where components don't explicitly call each other by name (such as in client/server or classic SOA), but communicate indirectly through a communication infrastructure (often called the event bus) that can be implemented via an ESB. Event handlers don't even know of each other; they only process an incoming event, fire another event and move on to deal with the next event. Many transaction processing platforms (for example, BEA Systems' Tuxedo and IBM's IMS) are internally based on a messaging infrastructure, but they are not considered to be EDAPs because they do not expose event-centric programming models (see Figure 5).

Event processing applications are meant to react as fast as possible to business or technical events. Therefore, in the design of EDAPs, volume transaction speed and low latency are the main concerns. They are based on an asynchronous message-passing paradigm commonly referred to as event-driven architecture (EDA). In an EDAP, applications process messages dispatched via message-oriented protocols that represent notable business events (such as a trade or a telecom service request). This implies manipulating messages, reading or updating databases, and eventually sending out messages (representing other real-life events) as a result of the computation.

EDAPs provide a software infrastructure for EDA-style applications. This is in contrast with the client/server remote procedure call (RPC)-style programming model that dominates the prevailing application platforms: Java EE Remote Method Invocation, .NET Remoting and WS JAX RPC. A client/server programming model can be easily implemented atop an event-based programming model, but not the other way around.

An event-driven programming model offers greater flexibility in application management, extension and integration. This is because it implements a minimally coupled relationship between software modules, and all intersystem communication traffic is intermediated. There are many opportunities for control, monitoring and analytics; change that's gradual and isn't intrusive; and extension and integration. Applications benefit from event-driven programming also from a performance perspective because it enables splitting applications into multiple logically chained components. In this way, an instance of an application can work in parallel on multiple events: as one component has done its part of processing of a given message, it hands off subsequent work to the next component in the chain (by posting a message in the event bus) and can process another message.

A crucial factor for EDAPs' success is the emergence of a commonly accepted standard event-driven programming model. One potential candidate is JAIN SLEE, a set of specifications (JSR 22 and JSR 240) coming out of the Java Community Process. JAIN SLEE (at times also abbreviated as “JSLEE”) was born as a platform for telecom traffic-management applications. Conceptually, it is not limited in its design to any one industry. The future of JAIN SLEE is still uncertain. Large software vendors will likely propose alternatives based on extensions to Java EE to preserve their investments and installed base on this technology. In particular, major software vendors are working to introduce event support in the service component architecture set of specifications aimed at providing a standardized programming model for SOA applications. EDAP-like products are also emerging in the context of sensor-based computing, RFID and financial trading applications.

Vendors offering event-driven application platforms include JNetX, Kabira, Mobicent, OpenCloud, Sybase (iAnyWare) and WareLite.

Many business scenarios in the real world are more naturally described as sequences of events, rather than as chains of client/server calls; these scenarios typically require high-performance processing of many events. In addition to the continuing support of the client/server SOA model, the adoption of EDAPs will enable closer affinity between software modeling and certain business process modeling techniques, narrowing the gap between an enterprise's business and IT domains. This will enable an enterprise to develop greater insight into its information resources, achieve greater control of its processes and increase its agility regarding competitive initiatives. In some industries (telecommunications, security trading, logistics and industrial process monitoring), event processing is the nature of the business.

The EDA-style software model can be beneficial in many other business situations as well, but it has typically been ignored in favor of the prevailing and conventional client/server model, which is complemented, as needed, by batch processing. Most programmers and systems designers are not sufficiently familiar with the event-driven programming model. Most EDAPs are pretty immature, often focused on one specific industry or application and only have a handful of production deployments. Most vendors are small, of questionable viability and are potential acquisition targets. But adoption of the event-driven programming style (via specialized EDAPs or as XTP extensions of mainstream EASs) will grow dramatically during the next five years as a result of mounting interest in event-driven architectures to tackle the most extreme performance requirements. By 2010, support for advanced, event-centric programming models will be a standard feature in application platforms aimed at XTP applications (0.8 probability). (See "Predicts 2007: Application Platforms on the Verge of Change.")

Leading-edge enterprises looking for advanced platforms to support XTP requirements should consider EDAP products, especially if their major concern is transaction processing performance and latency. However, they should also be aware that immaturity of most of the products in the market, lack of commonly agreed standards, vendor volatility and limited availability of skills make adoption of EDAPs a risky endeavor that must be justified by high-risk/high-reward business initiatives that cannot be implemented with more-mainstream platforms.

Grid computing refers to a collection of (typically commodity) servers from one or more companies that are coordinated to handle a common task. Grid computing has been used extensively during the past five years to create a large pool of computing resources leveraged to support batch-oriented, high-performance computing (HPC) applications, such as risk analysis in financial services, circuit simulation in the electronic industry or weather forecasting. However, the compelling price/performance of commodity Intel-based blades, high-speed network equipment and network storage devices is attracting the attention of companies interested in leveraging grid-like architectures to also support transaction processing workloads.

Grid-based application platforms provide an application runtime environment for service-oriented and event-based transactional applications, in addition to the same HPC, batch or analytical applications that typically take advantage of traditional grid computing. Grid-based application platforms’ aim is to support "scale-out" scalability and maximum availability on server-based "tera-architectures" (typically large clusters of Linux or Windows-based commodity servers). Typically, transactional applications in a grid-based scenario are designed as a collection of discrete, semiautonomous components glued together through a microflow language.

Grid-based application platforms leverage advanced workload management, peer-to-peer communication (such as Jini technology), distributed caching (such as JavaSpaces technology) and software deployment platforms (such as the Open Services Gateway Initiative Framework and Project Rio) to enable dynamic and transparent allocation across the grid (that is, on one or multiple servers) of as many instances of certain critical components of a transactional (but also HPC) application as needed to meet application-specific service-level agreements (such as response time, availability and so on) (see Figure 6). Also, grid-based application platforms typically enable hot plug-in and disposal of servers without stopping application operations, or manual reconfigurations by dynamically reallocating application components in an optimal way in the new configuration.