Step 10: Consider Performance

Performance is too often ignored until it's too late. A word of advice: Don't ignore performance! Application integration systems that don't perform well are destined to fail. For example, if processing a credit report for a telephone customer takes 20 minutes during peak hours, the application integration solution does not have business value.

While most application integration solutions won't provide zero latency with today's technology, the movement of information from system to system, or the invocation of common business processes, should provide response times under a second. What's more, the application integration solution should provide that same response time under an ever-increasing user and processing load. In short, the application integration solution must scale.

So, how do you build performance into a system? Design for performance, and test performance before going live. Remember, performance is something that can't be fixed once the application integration solution has been deployed. Performance must be designed from the ground up. This means the architecture of the application integration solution needs to provide the infrastructure for performance, as well as the selected enabling technology. It is possible to make some adjustments before the solution is deployed using traditional performance models, such as those developed over the years within the world of distributed computing. Finally, it is necessary to run some performance tests to ensure that the system performs well under a variety of conditions. For example, how well does it perform at 100 users, 500 users, 1,000 users, and even 10,000 users? What about processing load? What happens to performance as you extend the application integration solution over time?

Making Application Integration Scale

Let's face it: Many application integration solutions are not scaling to meet enterprise needs. End-user organizations are finding that their application integration solution that worked so well at the department level is falling down when stepping up to the enterprise. So, what did they do wrong? There are many reasons why performance/scaling, in the world of application integration, has just become an issue.

First, most existing application integration problem domains are small less than six source and target systems. The message or transaction rate is also small typically less than ten messages per second. Now, with application integration taking more of a B2B and enterprise-wide focus, problem domains are growing larger, and the number of source and target systems are growing well past six with message rate requirements moving past the 100-message-per-second range. The hard fact is that both the architectures and technologies leveraged for smaller problem domains may not work in larger ones. We saw this in the world of client/server development, and we are seeing it again within application integration.

Second, most application integration projects are tossed together without much architectural thought, including scalability planning. As I work with many application integration architects and projects, I'm hard-pressed to find project leaders who have any idea of how their solution will scale in both performance and capacity to meet future requirements. They seem content with just getting the technology up and running.

Third, and expanding upon the previous point, most application integration projects fail to perform adequate performance testing and almost never create performance simulation models. Solutions should be put through their paces, including simulated and increasing transaction loads being placed on the middleware, as well as simulating additional source and target systems. The cost of testing application integration solutions, of course, is high because the solution sets are so complex. However, clearly it's much better to find out that your solution won't scale before rather than after it's placed into production.

Finally, application integration technology vendors, with just a few exceptions, have done a poor job in creating technology that scales. The focus has been on adding features and functions in order to make the final cuts with end-user organizations, rather than focusing on operational efficiency. Scalability is not yet a sexy concept in the world of application integration. While everyone says they can scale, the fact is that few can. Claims are only verifiable through expensive testing.

Performance Anxiety

Issues such as message rates, transactions per second, and interface/adapter performance must be taken into account when considering performance engineering and application integration. Determining performance within an application integration problem domain is very complex, because there are so many variables to consider; for example:

  • Message consumption rate from source system.

  • Number of transformations required and duration.

  • Message splitting or combining required.

  • Rules-processing cycles for each message.

  • Message production rate to target system.

This, of course, is just an instance of what occurs as application integration solutions operate. You need to consider the fact that many message consumption, transformation, splitting, combining, and production operations occur simultaneously. As such, you must consider how each operation consumes resources (processor cycles, memory, storage, etc.), and how the application integration solution behaves as the message rate and number of integrated systems increases. The dynamics may surprise you.

The most reliable approach to performance in the design of an integration solution is to select the technology, test, and then do a simulation model to make an educated assessment of how well it will perform. Using simulation tools, it is possible to determine the time it will take for a message or a transaction to move between applications. This simulation must test the various entities of the system at the component (e.g., server) and system (e.g., integrated systems) level to ensure the overall performance of the application integration solution. Just as a chain is no stronger than its weakest link, an integration solution is no more efficient than its slowest-performing component. Testing identifies problem components before the solution is actually implemented.

Making an application integration solution scale comes down to selecting the correct approaches and enabling technology for the problem domain. For example, if message rate is going to be a limiting factor, it is important to select a technology that can distribute message processing among any number of connected message brokers. If transaction load and database access integrity is the limiting factor, then transactional middleware may be a better fit.

There is no hard-and-fast rule about designing a system to scale. The first step is to determine your requirements and then back the appropriate architecture and technology into those requirements. Putting the technology first is a very costly example of putting the cart ahead of the horse. And, once again, simulation tools and performance models are your first stop in determining scalability of your application integration solution. If we consider application integration for what it is, a strategic solution, than ignoring performance and scalability is simply not logical.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net