white paper: sOA and Web Services—The Performance Paradox

SOA and Web Services—

The Performance Paradox
august 2007

CA Wily Technology
Table of Contents

section 1 3 Section 6 13
Introduction Managing Additional SOA Technologies

section 2 4 Section 7 15
Web Services and the Problem of SOA Complexity Conclusion

section 3 6 About CA Back Cover

Requirements for Effective Management
of Web Services
Transaction Visibility
Always-On Monitoring
Production Orientation

Section 4 9
Gaining Control Over Web Services
Environments: CA Wily Web Services Manager

Section 5 10
SOA Management in Action: Case Studies
Problem Isolation in Full Context
Transaction Mapping

Copyright © 2007 CA.All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.
section 1

Introduction
By simplifying communication among disparate information systems, loosely-coupled web
services in Service Oriented Architectures (SOAs) provide the flexibility that enterprises need
to adapt quickly to changing business demands. But they introduce new challenges when it
comes to ensuring superior performance and availability.

Many of today’s heterogeneous environments are made up of both legacy applications and
newer, service-based technologies. IT teams lack visibility into web services transactions
as they traverse these environments, where services are often shared among several
applications and failure can occur anywhere along the transaction path.

This compounds the task of managing next-generation SOA-based web applications.

Considering both the number of services in place and the many points at which they
intersect—any one of which could bring down an application—how is it possible to ensure
the health and availability of these services in a real-time production environment?

It’s no longer enough to address the performance of web services without considering their
impact on the web application environment into which they are deployed. In fact, any product
for managing web service-enabled applications will only be effective if it can see into the entire
transaction path and into each critical intersection along the way. Enterprises must therefore
adopt an end-to-end performance management approach that looks at all integration points
as well as services, web applications and connected back-end systems.

This paper discusses the challenges of managing complex web services-enabled application
environments and is intended for IT teams faced with the challenge of maintaining a SOA
production environment. It begins with a discussion of the growing complexity of today’s
SOAs and the requirements for effective web services management. The paper provides
a detailed discussion of CA Wily Web Services Manager and then offers concrete examples
of how IT teams are using it in the real world to gain control over the performance and
availability of web services.

White paper: Soa and web services—the performance paradox  

 Section 2

Web Services and the Problem of SOA Complexity

Today’s leading organizations are implementing web services because of the many advantages
the technology offers. Web services allow IT to better align with business by providing greater
flexibility for optimization of the web infrastructure. Because they are scalable and can
be rapidly deployed they are more resilient and better suited to dynamic, constantly changing
IT environments. This allows your organization to react more quickly to changing business
needs. Web services are also an excellent way to reduce the cost of enterprise integration.
By creating reusable, standards-based services, web services create greater efficiencies and
provide a consistent framework for assembling services.

But when it comes to ensuring superior performance and availability, SOA management
is challenging. IT complexity remains a huge burden for most enterprises. And while web
services-enabled information systems provide many business advantages, complexity can
hamper business agility. A number of factors have led to this complexity:
• Enterprise architectures are constantly growing in scope and function. Instead of ripping
and replacing existing systems, most enterprises have grafted new capabilities onto what
they already have. The resulting, heterogeneous environment—made up of both legacy
applications and newer, service-based technologies—becomes more complex and more
difficult to maintain.
• Shifting architectural paradigms add new layers of complexity. When outages occurred
in classical client-server architectures, it was easy to pinpoint a failure, and possible
sources were limited to a handful of systems. In services-enabled composite application
environments, the web application server or the web server is a central point of coordination
across multiple client-server systems, and a failure can occur anywhere along the
transaction path.
• The ability to rapidly deploy new services, or versions thereof, makes it difficult to accurately
map out the application architecture. Almost as soon as it’s drawn, the chart is out of date.
In this type of rapidly-evolving environment, how can someone troubleshooting a single
transaction know which version of a service was deployed at the time of the error?
• Business factors, such as a change in organizational structure, a merger, or an acquisition
can also increase the complexity of an enterprise architecture. Personnel that previously
were experts in specific areas of enterprise functionality can find themselves working
in new departments, leaving behind an institutional knowledge gap. As a result, additional
application functionality tends to be “glued on,” making the service more complex.

  Soa and web services—the performance paradox

 Web services were designed, in part, to allow the systems of one company to interoperate
seamlessly with those of another. Traditionally, information systems have operated independently,
managing their own data while remaining blissfully unaware of other systems within
the environment. The advent of web-based technology and the resultant need to share data
from disparate sources led to the creation of point-to-point communication links between
applications. SOA replaces hard-coded links with a loosely coupled approach but this means
that from a performance management perspective, more attention must be paid to the
integration points themselves.

Managing response time also becomes more difficult when a particular component or service
Web services performance is shared among several applications. Various applications have different load requirements,
management solutions must new applications can be deployed at any time, and the service administrator may not
be alerted regarding an increase in usage. The varying application usage makes it hard to plan
be able to provide visibility for and predict service load characteristics.
across the entire transaction,
In addition, developers of one service typically don’t know much about another service, other
from initiation to completion, than the information which is expressed in WSDL. Therefore, they usually have no means
from the browser to back-end of diagnosing problems caused by a particular web service, and they may not even be able
systems, ensuring that to identify which web service caused the problem. This lack of visibility is the biggest challenge
with most SOA implementations and one that an effective services management product
no problems occur along must solve.
the way.
As SOA-based web application environments become more widespread, the difficulty
of managing them and the need for end-to-end transaction visibility grow exponentially.
The very fact that SOA makes it easier to integrate standards-based and legacy systems,
whether internal or external, means that management tools must be able to reach across
and within all of those systems to unearth internal relationships and dependencies.

White paper: Soa and web services—the performance paradox  

 Section 3

Requirements for Effective Management of Web Services

The first important concept to keep in mind when considering management of complex,
SOA environments is that SOA itself is not another “silo” to be managed. SOA is a design
approach to building a composite web application infrastructure and SOA technologies such
as web services are deployed in a web application context. SOAs are simply the next
generation of composite web applications, a more efficient way of taking data from
disparate sources and linking it together to provide web-based business services
to customers, partner and employees.

figure a The Evolution of Composite Applications

SOA represents the next generation
of composite web applications. Before SOA After SOA
Application Dependent Business Functions Composite Applications

Service Ordering Account Composite Ordering Account Service

Scheduling Processing Management Application Processing Management Scheduling
Check Customer Check Customer Calculate
Status Status Shipping Composed
Charge Busn, Process
Determine Determine
Product Product Order Status
Availability Availability
Check Credit
Verify Customer
Credit Check Check
Reusable Check Reusable Reusable
Customer Order
Service Invoice Service Service
Order Status Status Status

Reusable Reusable Check Check Reusable

Service Service Credit Inventory Service

Data Repository

Marketing Sales CRM Finance Data External Marketing Sales CRM Finance Data External
Warehouse Partner Warehouse Partner

SOA therefore, is an evolution rather than a revolution. With composite, distributed web
application environments, specific web applications are responsible for delivering critical
business services, be they Services Scheduling, Order Processing or Account Management
(CRM). This architecture is faster and more efficient than it was 20 years ago, but it still
requires the orchestration of many disparate functions into application “silos.”

On the other hand, with a web services-based architecture, composite application environments
are cleaner and more modular, further reducing inefficiencies and creating business agility.
Now you have the critical business functions exposed as web services that are part
of a services repository. These services can each be invoked as needed in a shared
environment. Again, with web services, you now have a more flexible environment that lets
you quickly and efficiently take advantage of changing business conditions.

  Soa and web services—the performance paradox

Because SOA transactions traverse heterogeneous web application environments, knowing
how to manage web services and other technologies within web application environments
is a key capability. IT teams need the ability to open up the black box and gain visibility
where there was none before, whether in web application code, connections to back end
systems, web services, portlets, databases, and more. Therefore, these same teams will want
to make sure that any products they consider for managing SOA technologies have
proven capabilities in web application management as well as SOA management. Given
the challenges discussed above, controlling the complexity of SOA and web services-based
web applications requires specific management capabilities described below.

Transaction Visibility
Comprehensive transaction visibility is an essential requirement for managing the performance
of web services. IT teams need the ability to monitor 100% of all transactions, 24x7 at the
component level. Many web services transactions span multiple processes or multiple web
applications instances. Therefore, it is essential that IT teams have the ability to understand
each services transaction in the context of the individual transaction path.

The other side of the visibility coin is root-cause analysis. Having the ability to detect incidents
when they happen doesn’t do your IT team a lot of good unless they can transform transaction
performance data into actionable intelligence for remediating problems. Therefore, your team
must be able to use information about web services transactions to isolate the root issue
no matter where it arises within the application infrastructure—individual problem transactions,
service faults, problem components, unstable connections to back-end systems, and more.

Always-On Monitoring
The next step in managing web services is always-on performance and availability monitoring.
IT teams must have visibility into web services performance and SLA compliance in the
production environment so that issues are detected early, in real time. And with the complex
nature of the service-enabled applications that enterprises deploy, discovery of the services
to be monitored must be automatic, so that application support teams spend less time
configuring what to monitor and more time managing the performance of services as well
as the applications and back-end systems to which they connect. The ability to monitor web
services 24x7 enables IT teams to then proactively take steps to detect issues, before they
severely impact the business.

White paper: Soa and web services—the performance paradox  

 Production Orientation
SOA management products are often targeted towards developers and architects. These
are of course key stakeholders in any web service implementation, but they are often not
the ones charged with monitoring the performance of web services-enabled applications
24x7. It’s important that your team adopt a product that provides value to all stakeholders,
whether they are the operations teams who must monitor performance around the clock
and take quick action when issues arise, the architects who need to understand the impact
of poor performance at a more structural level, or the developers who may get called
in to resolve code-related problems and need immediate data from operations on the nature
and likely cause of the issue. SOA management products must be able to provide live views
into the services infrastructure with no additional overhead on the monitored systems.
Additionally, this view must be customizable so that each stakeholder can view data in a way
that is unique to their role and fosters collaboration when it comes to detecting, triaging and
diagnosing incidents.

Simply put, your teams must make a distinction between development tools and production
performance and availability management tools. This prevents developers from inheriting
Simply put, your teams must the role of production monitoring specialist and from getting called every time an incident
make a distinction between occurs, regardless of whether the issue is code related or not. Likewise, operations teams need
development tools and a tool they can use to monitor production applications and web services, quickly determine
the nature of the problem and get the right people involved in remediation efforts. And lastly,
production performance a production tool that can monitor the performance of web services-enabled applications
and availability in production, around the clock and provide key data about infrastructure performance trends
management tools. is an invaluable asset for the architects who must ensure web services are meeting Operational
Level Agreements (OLAs) and business objectives.

Related to production-orientation, the SOA management product should be a completely

passive observer. The tool should be able to tell a real-time story regarding transaction
processing without adding additional overhead to the monitored system, which can add
latency to response times—one of the very issues that you are likely trying to correct.
Nor should operations personnel manage runtime policies that affect message processing
and business logic in a production environment. All such policies need to be built, tested and
deployed in a development or QA environment. Managing the performance and availability
of your critical web services implementation is not tantamount to runtime governance.
The processes and best practices you implement for detecting, triaging and diagnosing web
services-related issues are separate from governance, which can best be described
as a discipline that architects and developers use to create policies for services—how potential
services in the web application environment are identified, as well as the standards and
processes used when implementing them. While important to the overall success of any SOA
initiative, governance is not related to application performance management and consequently
governance tools are not suitable for production monitoring and root-cause analysis of web
services and SOA environments.

  Soa and web services—the performance paradox

 section 4

Gaining Control Over Web Services Environments—

CA Wily Web Services Manager
Effective SOA performance management must support more than basic functions such
as monitoring, alerting, and reporting. The management product you deploy must comprise
proven technologies for monitoring web services 24x7, diagnosing issues efficiently and
managing SLA compliance. CA Wily Web Services Manager (WSM) enables consumers
and producers of web services to monitor critical services around the clock, detect problems
proactively, and perform root-cause analysis when issues arise. This product provides
comprehensive, live views into web services, web applications and the back-end systems
to which they connect.

CA Wily’s SOA Management capabilities help IT teams manage the complexity of SOA
environments and ensure transaction integrity by delivering a deep understanding of service
performance and availability—why a service is slow, underlying dependencies, and how service
performance affects the web applications as a whole.

For example, CA Wily Web Services Manager gives operations and application support teams
advance notification of incidents, before end-users are affected, allowing them to effectively
measure and manage SLAs. Moreover, CA Wily WSM delivers the detailed information
architects and developers need to quickly isolate and resolve problems: views of individual
transactions in which web services are involved, the number and nature of web service faults,
and component interactions.

figure b CA Wily Web Services Manager Overview

Effective management of web services
requires real-time views of services
performance and availability as well
as proactive alerts that warn of issues
before SLAs are violated.

White paper: Soa and web services—the performance paradox  

 When an incident occurs—response time for a particular web service slows due to thread
pool starvation, for example—an alert notifies appropriate stakeholders of the problem before
an SLA is violated or an end-user is affected. To gather information about the nature of the
problem and narrow his focus, the application support manager can view detailed errors data
in the context of individual transactions. Additionally, views of the slowest web services allow
her to isolate the worst offenders, and socket bandwidth metrics provide crucial information
about message throughput.

Once the likely source of the problem has been identified, web services architects or developers
can use CA Wily Web Services Manager to diagnose the root cause. They can drill into web
service errors to obtain critical data about the nature of the issue, including information about
the SOAP message. CA Wily WSM also provides views of individual service and operation
metrics related to response times, faults, stalled threads and concurrent invocations.

Historical reporting facilitates SLA management and ongoing improvements to the web services
architecture. IT teams can run SLA compliance reports on individual services and operations
to ensure that service level objectives are being met and if not, to understand what failed
and when. Performance, availability and usage reports for service capacity planning allow
architects, developers and IT management to plan for future requirements.

section 5

SOA Management in Action: Case Studies

A brief examination of real-world scenarios will illustrate how IT teams are using CA Wily
SOA Manager to solve management challenges.

Problem Isolation in Full Context

A leading North American bank was encountering serious performance problems with their
web services. Customers were experiencing extensive delays when accessing their credit card
accounts and paying bills online.

Newly deployed web services-based applications were assumed to be the problem since
performance had degraded immediately after deployment. However, the problem was difficult
to isolate in a complex, composite SOA environment where failure can occur at any number
of points.

When problems start occurring in a production environment, IT administrators and managers

need to avoid a bias that assumes that web services are the cause of the problems. Accurate
problem isolation should take into account the full context of the transaction path, including
not only the web service but also supporting applications, database calls and many other
environmental factors. Unfortunately, the bank’s traditional monitoring tools lacked the ability
to monitor services transactions end-to-end, so they were unable to locate and solve the problem.

10  Soa and web services—the performance paradox

 To properly ensure transaction integrity and gain comprehensive visibility into the SOA
environment, the bank acquired the CA Wily product, which allowed them to:
• Monitor transactions end to end in the full context of the full application
• Detect potential issues proactively before customers and service levels were impacted
• Utilize a single tool for both application monitoring and web service monitoring

figure c The Managed Application Envionment

When troubleshooting performance
issues in web services-enabled Identity SAP
environments, IT teams must have Manager

visibility into the entire PSFT

transaction path. Siebel

Mainframe Database
Network Router Firewall Switch Load Portal
Balancer Web
Servers Applications

End User Web

Services

Databases

3 rd Party
Applications

As it happened, the performance problem was indeed caused by other factors (in this case,
MQ and database calls) instead of the web services applications. The application support
team was able to quickly isolate the cause and notify the right system administrator to get
the problem fixed quickly.

White paper: Soa and web services—the performance paradox  11

 Transaction Mapping
A major financial services provider had become an early-stage adopter of web services, using
a SOA-based solution to deliver online services to millions of customers worldwide. A SOA
design had been created to facilitate a three-tier architecture allowing transactions to flow
from presentation layer to normalization services to back-end systems. However, the IT
organization needed to gradually roll out this infrastructure; a wholesale deployment would
have compromised the integrity of their customer-facing applications. As the deployment
unfolded, they needed an accurate, real-time picture into transactions to get a perspective
on active components deployed to the web services supply chain.

Web-service development practices were also a problem. Getting the right level of granularity
around service operations requires architectural expertise and a deep understanding
of the interface use cases. Being new to web service development, with the first couple
of development attempts web service interfaces tended to be too granular, requiring several
requests and responses just to complete a single transaction. The increased number
of requests and responses resulted in greater overhead and network latency. IT required
an understanding of the complete path for a single transaction: the long leg of the call stack
and the number of times backend resources were invoked.

The developers also often used service connections that their colleagues had already
implemented, or just used connections that they knew would work. Sometimes, the developers
bypassed the interface altogether and simply executed a direct API call for the service. These
practices created a “spaghetti” of unplanned, ad hoc connections among nodes, further limiting
the ability to properly manage transactions.

figure d The Unplanned “Spaghetti” Effect

By executing direct API calls rather
than the web services interface, Presentation
the development team created Layer
a “spaghetti” of unplanned WS
connections that complicated
management efforts.

WS WS WS
Normalization Normalization Normalization
Service Service Service
WS WS WS

WS WS WS WS WS WS
Backend Backend Backend Backend Backend Backend
System System System System System System

12  Soa and web services—the performance paradox

To address these problems, IT made the decision to use CA Wily’s end-to-end performance
management product for web services that allowed them to:
• Better understand how messages flow through the entire system, end to end
• Assess the impact to web services when performance issues occurred
• Gauge network latency
• Support strategic, web-services development based on granular performance data

With this product in place, they were able to see live transactions down to the component
level in the context of the transaction path. The application support team was then able
to work with the development team to ensure all transactions were meeting service level
objectives and to develop processes for ensuring superior application performance throughout
each stage of the web application lifecycle.

section 6

Managing Additional SOA Technologies

CA Wily Technology also offers performance management products for other key
SOA technologies.
• Message Broker  A message broker is a communication layer responsible for guaranteed
message delivery. It is used to decouple applications from each other. Examples include
WebSphere MQ Series, JMS, Sonic MQ® and TIBCO Rendezvous. In SOAs, the message
broker acts as the channel over which services can publish messages to a list of subscribers,
thereby enabling loose orchestration of the services. CA Wily Introscope® PowerPack for IBM
WebSphere MQ Connectors and Messaging System allows application support personnel
to monitor WebSphere MQ Java connectors as well critical activity inside the MQ messaging
system itself including queue depth, channel metrics and message rate. It measures web
applications’ use of the messaging system and correlates application performance with that
of the messaging infrastructure. With this product, IT personnel responsible for ensuring
web application performance can identify the cause of problems within the messaging
infrastructure and provide MQ administrators with specific information about the nature
of performance problems. Introscope can also monitor JMS, as well as solutions from Tibco
and Sonic.
• Integration Broker  Historically, integration brokers have provided a wide range
of functionality that encompasses message brokering, back-end connectivity (via adapters),
and process orchestration. Integration brokers continue to offer the vital service of process
orchestration. By coordinating and managing transactions across services, developers
have the ability to rapidly construct services-enabled applications that mirror established
business processes. Integration brokers provide business process orchestration, engaging
message brokers where asynchronous interactions are required. CA Wily Introscope®

White paper: Soa and web services—the performance paradox  13

 and Introscope PowerPacks provide performance management for leading integration broker
solutions such as IBM WebSphere® Business Integration, BEA WebLogic® Integration as well
as integration solutions from TIBCO and Vitria. Introscope offers deep, component-level
visibility into these environments, allowing IT personnel to detect problems end-to-end,
and to isolate the root cause of performance issues whether in the integration broker,
connected business application adapters (for example, adapters for mySAP, Siebel, etc.),
or in the web application itself.
• Enterprise Service Bus (ESB) ESBs inject dynamism into an SOA. Acting as an intermediary
among various service consumers and providers, ESBs provide authentication, transformation,
and routing services that can be configured and deployed at runtime. They coordinate
communication between IT resources, including applications, services, information, and
platforms. CA Wily Introscope can be customized to monitor ESBs by incorporating metric-
based management technologies such as Java™ Management eXtensions (JMX).
• Portal Server Enterprise IT teams are increasingly recognizing portal servers as an integral
component of an SOA environment. Portal servers provide a presentation framework that
traditionally has acted as a web service consumer. However, with the introduction and
adoption of WSRP, portals have begun to act as services providers as well. CA Wily Portal
Manager is the only product built specifically for ensuring the superior performance
of enterprise portal solutions such as IBM WebSphere Portal, BEA WebLogic Portal and
SAP Enterprise Portal. CA Wily Portal Manager delivers 24x7 monitoring of the entire
portal framework including individual portlets (as well as WSRPs) and workflow processes
to give a comprehensive, real-time view of portal performance. It also provides visibility into
connected back-end systems so that performance issues can be identified and eliminated
throughout the portal environment.

14  Soa and web services—the performance paradox

section 7

Conclusion
Loosely-coupled service environments provide unique benefits to the organizations that
utilize them but they introduce new challenges. IT teams responsible for ensuring service
performance and availability currently do not have the comprehensive visibility they need
to detect performance issues before SLAs are violated, to determine the exact nature
of errors as they occur, and to resolve problems quickly, regardless of whether they are
caused by a service, application code or connections to supporting systems.

As the real-world examples in this paper illustrate, ensuring the superior performance
of services enabled environments requires:
• End-to-end response-time monitoring of web-based transactions;
• A deep understanding of service performance (why a service isn’t performing and how
poor service affects an application);
• The ability to view down to the individual transaction level of a web application and its
associated services;
• Capabilities for ensuring SLA compliance via real-time 24x7 visibility into performance
and proactive notification that can provide advance warning of a slowdown or outage.

Only when these requirements are met can IT teams—operations, application support,
architects and developers—fully gain control over complex, composite applications upon
which so much of their business depends.

White paper: Soa and web services—the performance paradox  15

CA, one of the world’s largest information technology (IT)
management software companies, unifies and simplifies
the management of enterprise-wide IT for greater business
results. Our vision, tools and expertise help customers
manage risk, improve service, manage costs and align their
IT investments with their business needs.
CA Wily Technology is the market-leading provider
of Enterprise Application Management solutions.
By delivering end-to-end visibility into customer
transactions in real time, products from CA Wily
Technology enable companies to successfully manage
the health and availability of their critical Web applications
and infrastructure. CA’s collaborative management
approach allows enterprises to rapidly detect and diagnose
application slowdowns and failures, and better assess
the impact of application performance on business success.
This means better customer service, more stable revenue
streams, and higher IT productivity.

0807