ZapThink » Quovadx

High Performance SOA

Jason Bloomberg — Wed, 20 Sep 2006 00:09:00 +0000

In the world of information technology, the concept of abstractions are particularly handy. Take, for example, the Services abstraction at the heart of SOA, which masks the complexity of the underlying technology implementation while presenting composable business Services to internal and external users. But every abstraction comes at a price, and the Services abstraction is no exception. Loose coupling, composability, agility, and the other benefits of SOA all introduce performance overhead. For limited sets of Services with small numbers of users, this performance hit may be minimal. For SOA implementations with large numbers of users, Services, or traffic, however, maintaining the necessary performance levels presents a substantial challenge, both to the architects who design the infrastructure as well as IT operations personnel who are responsible for keeping the lights on.

In fact, in SOA environments with the highest performance requirements, maintaining the Services abstraction in the face of high traffic is a paramount concern. Fail to maintain the abstraction, and the Services no longer meet the agile needs of the business, and the quality of the SOA implementation comes crashing down like a house of cards.

Performance Beneath the Services Abstraction
The SOA performance problem falls into two broad areas: ensuring sufficient performance of atomic Services as well as of composite Services. Atomic Services provide Service interfaces that abstract existing systems, so ensuring their performance necessitates managing the performance of the components, applications, and systems that lie beneath the Services abstraction. As you might expect, dealing with the performance of atomic Services leverages well-established capacity planning and performance quality assurance (PQA) techniques, including clustering, virtualization, and load testing. Today’s architects are adept at making infrastructural decisions that ensure, for example, sufficient database performance, distribution of traffic onto a cluster of application servers, and the like.

Furthermore, traditional PQA also serves atomic Services well. Simulating loads on Service interfaces is quite similar to simulating traditional Web page performance, after all — and many Web Service PQA tool vendors have predictably based their products on Web page PQA tools that performance test traditional Web applications via their Web interfaces. But while Web Services share some similarities with Web pages, there are some fundamental differences. In particular, Web page interactions are usually request/reply, but Web Services support a wide variety of interaction styles, including asynchronous, synchronous, event-driven, publish/subscribe, and one-way. Load testing a Service that has such a wide range of interaction styles requires more sophisticated tooling than traditional Web page-centric PQA tools.

Performance Above the Services Abstraction
While SOA manifestly relies upon Services, there is far more to properly architecting SOA than simply building a bunch of Services. Architects must consider the consumption of those Services as well, including the dynamic, business-driven composition of Services into Service-Oriented Business Applications (SOBAs). Unfortunately, the very nature of SOBAs as flexible, continually changing, potentially ad hoc compositions presents complex performance challenges to architects and operations personnel alike.

In fact, there are several dimensions of SOBA performance that architects must consider as they plan their SOA:

Balance between use and reuse — Some services expect high use, meaning large volumes of traffic from specific consuming applications, while others expect high reuse, implying a range of different consumers that may use Services in different ways, for example, in different SOBAs. High usage is often (but not always) more predictable than high levels of reuse, but the architect must plan for both, as well as the combination of the two.
Very Large Messages and Granularity — Some Service interactions involve the exchange of very large messages (VLMs). Addressing the performance issue of VLMs requires different infrastructure and different planning from Service interactions that exchange large volumes of messages. Sometimes the VLM problem directly relates to the granularity of the Services, while other times it might concern SOAP attachments, encryption, or other features that increase the size of messages. But in any case, the architect must take the sizes of messages into account as part of the SOA performance plan.
Dynamic Performance policies — In some cases, the service level requirements of individual Services is part of the contract for each Service, but in other cases, the organization requires performance policies that they can apply to Services as part of their governance framework. In fact, being able to reconfigure performance policies may be a business requirement the architect must take into account when planning the SOA.
Service dependencies — Service compositions come in many flavors: orchestrated flows, flexible choreographies, data virtualizations, and various combinations thereof. String several Services together where the output of one contributes to the input of the next, for example, and if one Service in the chain is too slow, the entire composition suffers. Multiply this bottleneck issue by the numerous ways that people can create SOBAs, and the architect has a complex task ahead.

Tackling the SOA Performance Problem
Dealing with performance bottlenecks is like playing whack-a-mole: defeat one and another immediately pops up. Even worse, implementing SOA just increases the number of moles you have to whack. It’s essential, therefore, for the architect to plan for performance bottlenecks at different levels, both above and beneath the Services abstraction. In other words, the architect must craft a performance plan that might take advantage of some combination of the following approaches:

Service and infrastructure virtualization — Various virtualization techniques can provide cost-effective approaches to dealing with variable performance issues, essentially by abstracting a specific part of the infrastructure. Virtualization is especially useful for dealing with unexpected spikes in demand, but the complexity of virtualizing heterogeneous resources can often limit such approaches’ effectiveness.
Combining judicious loose coupling with strategic tight coupling — While a simplistic view of SOA might suggest that loose coupling is always better than tight coupling, the fact of the matter is that loose coupling introduces overhead, while tight coupling can smooth out bottlenecks. The architect’s challenge, therefore, is in identifying those situations where the business requires some level of loose coupling, and then providing only as much as it needs, for example, by implementing transactionality in compiled code and distributing that code for high concurrency parallel processing underneath the Services abstraction.
Registry-based dynamic routing — A Service-oriented approach to load balancing leverages registry-based location independence to route Service requests to the appropriate Service instances in order to satisfy performance requirements. This dynamic routing approach to scalability and fault tolerance is unlikely to be as performant as tightly coupled clustering, but works well in heterogeneous environments, and can leverage the declarative policy management capabilities of the registry.
Performance as part of the SOA governance framework — Leveraging the registry’s policy management features should be more than an afterthought, however. In fact, the broadest, most agile approach to SOA performance is to plan for it as part of the governance framework for the SOA implementation. Based on the performance constraints of the technology, craft policies that will maintain the required performance levels while empowering users as much as is practical. For example, if the architecture team can distinguish particular types of SOBAs that the infrastructure can support from others that it cannot, then the team should be able to craft policies that will appropriately limit SOBA creation, and thus create predictable limits for overall performance.
PQA throughout the Service lifecycle — Traditional PQA typically applies simulated loads before deployment to a QA environment that closely mimics the production environment. After all, such traffic loads can bring systems to their knees, so nobody would want to run them in a live environment. Maintaining parallel QA environments for SOA implementations, however, is difficult to impossible, because of the wide range of possible configurations of SOBAs and the Services that feed them. PQA for SOA must therefore take a more subtle approach than the “pound on it until it fails” technique. Instead, SOA PQA relies upon the use of configurable policies that indicate whether a Service is in live or test mode, combined with active SOA management that proactively monitors live performance and takes preventative steps should Services cross pre-set warning thresholds.

The ZapThink Take
Analyzing SOA performance highlights the fact that SOA is more evolutionary than revolutionary. Architects must still know how to use every capacity planning and performance enhancement tool in their toolbelt, only now they’re able to add a few new tools to the mix. In fact, there’s no way we’d be able to figure out how to scale Web Services if we hadn’t already worked out how to scale traditional Web applications.

It’s also important to note that SOA performance is about more than ensuring that Services perform as required, just as SOA is about more than building Services. SOA best practices also cover the consumption of Services — within SOBAs as well as at the user interface. As a result, the comparatively mundane world of SOA performance has direct relevance to the sexy world of Enterprise Web 2.0. After all, no enterprise would depend upon rich, collaborative applications if there were no way to ensure their performance.

Finally, dealing with SOA performance requires an Enterprise Architecture approach to SOA. Those bottleneck moles in the whack-a-mole game can appear anywhere in the enterprise, at any level of abstraction. The fact that SOA hides the complexity of the infrastructure from the user only exacerbates the need for an enterprise perspective, because high quality, high performance SOA requires high performance from every part of the enterprise.

Rogue Wave Software Announces General Availability of Rogue Wave Hydra Suite Version 3.0

admin — Tue, 18 Apr 2006 00:04:00 +0000

click here
Rogue Wave Hydra empowers IT architects and professional developers to achieve order-of-magnitude performance and throughput improvements for critical software applications. Rogue Wave Hydra is based on Rogue Wave Software’s pioneering “Pipelines” technology and associated methodology, which focuses on achieving efficiency and scalability through parallel processing. Pipelines allow for efficient execution and distribution of software components or services for simultaneous processing on available resources. This peer-to-peer architecture minimizes bottlenecks and allows businesses to achieve new levels of throughput and performance. According to research firm ZapThink, 50 percent of the total services-oriented software market will have high-performance requirements by 2010.

ZapForum Webcast — Practical Approaches for Optimizing SOA Performance

Ronald Schmelzer — Wed, 05 Oct 2005 00:10:00 +0000

“Practical Approaches To Optimizing SOA Performance”

Guest Experts: Michael Leventhal, Sr. Director, XML Products, Tarari and Tim Triemstra, VP, Product Strategy, Rogue Wave Software

Topics:

Understand where the performance bottlenecks are
What are the tricks and techniques for surmounting efficiency problems?
Learn about software, hardware, and other means for optimizing performance

Setting the Stage: ZapThink Analysts
Companies are very familiar with the primary benefit of SOA being business agility, but what about performance? How can we implement SOA without having to bear the brunt of its inefficiency and complexity? Is Web Services the real barrier to efficiency, or is there something about SOA, no matter how we implement it, that causes inefficiencies?

Guest Expert: Michael Leventhal, Sr. Director, XML Products, Tarari

Michael will explain how SOA-aware network appliances can offload common functionality from the application server in order to reduce XML processing complexity and make the network more manageable, as well as utilize specialized network devices to do XML processing tasks much better and faster than multiple application servers duplicating that functionality.

Key Takeaways:

Learn how to mitigate application-server based SOA performance problems by leveraging XML hardware-accelerated network appliances
Learn how to reduce SOA complexity and Web Services programming by leveraging XML hardware-accelerated network appliances
Learn how to reduce costs and time to market using intelligent, SOA-aware network devices

Guest Expert: Tim Triemstra, VP, Product Strategy, Rogue Wave Software
Tim will discuss how many companies today, particularly those in transaction-intensive industries such as financial services, are now demanding increased levels performance in their applications, in some cases by orders of magnitude. Tim will explore practical techniques to accomplish this goal, including parallel processing, access to XML and non-XML data and how to encapsulate any software component as a service.

Key Takeaways:

Learn practical approaches for increasing performance from your SOA applications by restructuring your software architecture to address processing bottlenecks.
Better understand the business requirement challenges to successfully implement parallel application logic.

This 34-page presentation is formatted as a pdf document with two slides per page. It contains the slide content only; to view the full Webcast, please see the ZapThink Web site.Download File

Solving the Very Large Messaging Problem in the Enterprise

Ronald Schmelzer — Wed, 09 Feb 2005 00:02:00 +0000

Companies are increasingly seeking to tie together their disparate enterprise using the promising, but emerging technologies of XML, Web Services, and Service-Oriented Architectures. These approaches promise significant business agility in the face of IT heterogeneity. However, these benefits come at a price: performance and efficiency. As the network traffic increases due to the increasing size and volume of messages, both XML and non-XML based, existing corporate IT infrastructure will be taxed to its limit. General-purpose application servers, network equipment, and messaging infrastructure will be increasingly devoted to simple message parsing, handling, and routing functions, while precious few resources will be left to execute the core business logic so important to companies.

Research shows that the quantity and size of these metadata-laden messages won’t be decreasing soon. Developers and specifications bodies continue to tax messaging systems with additional layers of headers and metadata meant to abstract underlying infrastructure. Increasingly large message size, along with a general increase in message volume, combine to create the challenge of Very Large Messaging (VLM).

Previous approaches to solving distributed messaging problems, including messaging middleware, ESB, and application servers, were not designed to handle the challenges of VLM. Emerging approaches such as hardware appliances and binary XML, may solve part of the overall VLM problem, but fail to provide a comprehensive approach that targets all systems, networks, and processing infrastructure that runs within the corporate IT environment. Further, while these approaches may remove some of the overhead of message parsing, they offer no direct benefit to assimilating and utilitizing these messages within applications.

As a result, new approaches are needed to deal with messages being exchanged on the network that are exceeding the capabilities of the general purpose hardware and software that is now being applied to the problem. How can efficient content-level message processing be distributed to all the nodes in a corporate network? How can dumb networks be made more intelligent through the ability to process data and metadata it formerly ignored? In this paper, approaches to the “Very Large Messaging” (VLM) problem, and potential optimal solutions that hope to break the stalemate in network processing of data are presented.Download File

The Might of XML

admin — Fri, 03 Dec 2004 00:12:00 +0000

Current XML parsers are not very effective. The APIs (define) have just as much trouble reading large file types in an efficient manner as they do reading multiple small file types.

This stresses out current processors, which power the application server to deliver content. Research firm ZapThink said this poses a problem because it believes corporations will continue to ramp up the amount of XML they employ in their networks, expanding from 15 percent today to almost 50 percent by 2008.

With the glamour of Web services steeped in the possibility of processing thousands or even millions of transactions on a network, the threat that insufficient XML consumption could tie up computer systems is very real. ZapThink analyst Ronald Schmelzer said customers and vendors have expressed concern about XML’s ability to underpin Web services.

He admitted the problems with XML processing put a damper on the research company’s prognostication for the multi-billion-dollar growth for service-oriented architectures and distributed computing.

ZapThink’s Schmelzer said the glut of XML is thick enough to bear a large market in which the likes of DataPower and Rogue Wave can sell their wares. He predicted the XML performance optimization market will reach $1.2 billion by 2010.

The SOA Implementation Framework

Jason Bloomberg — Tue, 13 Apr 2004 00:04:00 +0000

The world of distributed computing is currently in the midst of a major transition, as tightly coupled, integration-centric approaches gradually lose favor and give way to loosely coupled, Service-oriented computing techniques. At the core of this trend are Service-oriented architectures (SOAs), which promise greater flexibility in the way that companies produce and consume IT assets, in particular when IT environments are heterogeneous and business requirements are dynamic.

However, building SOAs is challening for most organizations, for several reasons: they involve a different way of thinking about software resources, they require a level of architectural discipline, and companies need a range of software solutions to build, run, and manage an SOA. In particular, companies need a framework of capabilities that include access to data sources and the composition of Services into business processes in a secure, managed environment.

Today, most enterprises must purchase a range of products to assemble the software they need to build an SOA. However, there is a new class of product called the SOA Implementation Framework that offers all the elements a company would need to build and run an SOA. Such frameworks are only now coming to market, but one such framework, Rogue Wave Platform X, from Rogue Wave Software, a division of Quovadx, is well-positioned to be a leader in this nascent market for comprehensive SOA software frameworks.Download File

AmberPoint Extends Market Leadership with Marquee New Customers and Strategic Relationships

admin — Wed, 14 Jan 2004 00:01:00 +0000

“The addition of these significant names to AmberPoint’s customer roster speaks to the strength of their solutions,” said Jason Bloomberg, senior analyst at ZapThink. “This indicates that the Web services management market is continuing the growth we’ve predicted.”

AmberPoint Greenlighted By Numerous New Customers

admin — Wed, 14 Jan 2004 00:01:00 +0000

Service Orientation Market Trends

Jason Bloomberg — Mon, 05 Jan 2004 00:01:00 +0000

Key Points:

ZapThink sees a consolidation of most SO functionality into a single market category that can be delivered as individual products, product suites, or service offerings that contain broad functionality, including features that are currently associated with the security, management, process, integration, and tools segments. We call that market the SOA Implementation Framework market.
The total SOA Implementation Framework market opportunity will go from $4.4 billion in 2005 to $43 billion by 2010.
The big winners from the shift to Service Orientation will be large vendors who are able to leverage the innovation of the smaller players to build fully functional SOA Implementation Frameworks. New entrants will find opportunity in adding value to these large vendors’ products, or by finding opportunity in the gaps between their solutions.

Table of Contents:

I. Report Scope
II. Context: The Shift to Service Orientation
- 2.1. The shift to Service Orientation affects all distributed computing
- 2.2. Shifts in market segments
- 2.3. The SOA Implementation Framework
- 2.4. The march toward the SOAIF
- 2.5. Integration: the key transitional market
III. Vendor Landscape
- 3.1. Core Service Orientation segments
- 3.2. The role of the incumbents
- 3.3. The role of On Demand
IV. Market Trends
- 4.1. Methodology
- 4.2. Core market numbers
- 4.3. SOAIF market numbers
- 4.4. Who will win the SOAIF battle?
V. Conclusions
- 5.1. Key notes
- 5.2. Decision points
- 5.3. Figures
- 5.4. Tables
Download File

The Web services interoperability group unfurls a practical business use scenario for running

admin — Thu, 11 Dec 2003 00:12:00 +0000

ZapThink Senior Analyst Jason Bloomberg said the delivery of the sample applications will free WS-I up to conduct other interoperability tests.

Now that these deliverables are off the WS-I’s plate, they can focus more specifically on building the interoperability profile for Web Services security — a tougher problem than basic interoperability, but every bit as important, Bloomberg told internetnews.com .