ACTIONAL ARCHITECTURE SERIES: ACTIONAL FOR SOA OPERATIONS

W h i t e P a P e r

ACTIONAL ARCHITECTURE SERIES: ACTIONAL FOR SOA OPERATIONS

The core Actional platform

Copyright ©2007. Progress Software Corporation. All rights reserved.

TAbLE OF CONTENTS

> 1.0 INTRODUCTION 3

> 2.0 ACTIONAL SOA OPERATIONS ARCHITECTURE: KEY CHARACTERISTICS 4

> 3.0 SOA MANAGEMENT DESIGN CHALLENGES 6

> 4.0 SOA MANAGEMENT ARCHITECTURE PATTERNS 8

Distributed Processing 8

Centralized Processing 9

Actional for SOA Operations’ Combined Approach 11

> 5.0 ACTIONAL FOR SOA OPERATIONS ARCHITECTURE 12

Actional Server-Agent Communication 13

Instrumented Platform Components 14

Tracking Message Flows 16

Injecting “Tracers” into the Flow 17

Storing Information in Memory—in the Flight Data Recorder 18

Evaluating Policy to Detect Abnormal Conditions 19

Gathering Relevant Information 20

Enabling Root Cause Analysis 21

> 6.0 ACTIONAL FOR SOA OPERATIONS: A CLOSER LOOK AT AGENTS 24

Interceptor 24

Analyzer 26

> 7.0 CONCLUSION 28

3Copyright ©2007. Progress Software Corporation. All rights reserved.

1.0 INTRODUCTION

As companies turn to service-oriented architecture (SOA) as a solution for enterprise integration, the need for SOA management grows. The basic purpose of a SOA management solution is to ensure reliable SOA operations. Three simple capabilities are required to ensure reliability. The solution should enable SOA operators to:

1. Understand what’s happening in the environment

2. Quickly troubleshoot problems through root cause analysis

3. Analyze historical metrics for planning purposes

The key to accomplishing these three goals, and managing SOA applications, is visibility into the SOA environment with its myriad services and consumers and the dependencies between them. A management solution needs the ability to monitor inbound requests and track them as they move through the related services across the “dependency chain,” regardless of the system or protocol used, all the way through the response to the consumer. However, given the distributed, heterogeneous nature of an SOA, this requirement poses a number of challenges. These include scalability, application modification and coding, and maintenance or keeping track of all related services and policies, to name a few.

Actional offers three products for organizations adopting SOA and requiring management and/or security. Progress® Actional® for SOA Operations is the base offering, on which the others are built. This white paper explains the Actional for SOA Operations architecture, how it addresses these challenges head-on, and how the Actional architecture is implemented.

Specifically, the paper starts with an overview of the Actional architecture’s critical characteristics. It then addresses key SOA management design challenges and architectural alternatives to provide a context for a detailed description of how the Actional architecture works and provides significant IT, productivity, and cost benefits.

For information about Progress® Actional® for Active Policy Enforcement or Progress® Actional® for Continuous Service Optimization please visit www.actional.com/products.

http://www.actional.com/products

Copyright ©2007. Progress Software Corporation. All rights reserved.4

2.0 ACTIONAL SOA OPERATIONS ARCHITECTURE: KEY CHARACTERISTICS

Actional’s offerings are built from the ground up for enterprise-level deployments. The following are the key characteristics of the Actional architecture and their advantages in handling the complexities of an SOA environment.

High Scalability

Actional’s SOA Operations architecture uniquely blends distributed policy evaluation with centralized command and control, enabling very high scalability. The Actional SOA Operations management server is guaranteed to be able to manage at least 1,000 managed nodes and 50,000 service interdependencies. Also, the server is never a single point of failure. SOA Operations policies are evaluated at the managed nodes; therefore, a server failure does not affect policy evaluation.

Comparable solutions may scale to as few as 20 managed nodes to the server or, even worse, their ability to scale may depend on which type of agent is deployed. Being dependent upon the type of agent means that the solution architecture is dependent upon the features required. With Actional for SOA Operations, each agent has all the features required, and scalability characteristics are independent of the features used.

High Performance

With less than 50 microseconds of latency added to each message, Actional has the greatest performance of any SOA management solution on the market. This excellent performance enables the solution to be run “all the time” in production, allowing operators to track each and every message across the SOA. In addition, because the server is not ever “in the flow of messages,” the server or network will never detract from management performance. Furthermore, on-site tests have shown less than 2% of CPU utilization and message throughput of more than 3.5 million messages per hour on Actional managed nodes— even though this is where policy processing occurs.

Automatic Discovery

Automatic discovery is a very powerful feature. Actional for SOA Operations can automatically discover service producers, service consumers, and the dependencies between them. This auto-discovered interconnection can be viewed graphically. Message flows between nodes are identified down to the operations level. In addition, there is absolutely no need to know anything about the services ahead of time for them to be discovered or managed. In other words, there is no explicit configuration necessary to manage services once Actional is installed. Simply installing the Actional Agent enables operators to deploy policy that takes effect on the first service call to the node.


The automatic nature of service discovery is critical to providing assurance to operators that what they expect is what is actually happening. Often, when companies first install Actional for SOA Operations, they discover services and service consumers that they were unaware were running in the production environment. For example, they find QA/test services accessing production systems (because the configuration wasn’t completely changed after the migration) or users continuing to use an old service long after it was believed that everyone had upgraded to a new version.

Automatic discovery is just as critical in enterprise-scale SOA deployments. In this case, there are often tens of thousands of relationships between nodes as well as the possibility that these relationships change each time an application change or upgrade occurs. It simply is unrealistic to expect an enterprise to manually map those relationships and keep the resulting relationship map up-to-date.

Multi-protocol Support

In the real world, SOA does not depend only on HTTP(s) and SOAP traffic but includes a multitude of protocols such as JMS, ADO.NET, RMI, JDBC, EJB, ESB, and others. Consequently, a complete management solution needs to provide an end-to-end view of the services network, regardless of the protocols (or vendors) included in the SOA.

No Application Changes

Using Actional for SOA Operations to manage an SOA does not require any application changes. Actional for SOA Operations can be installed into an existing application environment (or even be removed) without modifications to the application. Additionally, there is no need to deploy Actional Agents everywhere to take advantage of the product; even a single instrumented (managed) node can bring value because of the automatic discovery of consumers and services one hop away from each instrumented node.

Service-level Agreement (SLA) Policy Inheritance

Policies are automatically applied to a service based on service metadata. While this characteristic is not unique to Actional for SOA Operations, the Actional implementation is very interesting, especially in combination with automatic discovery. When a service is first discovered, a pre-written policy can be automatically applied based on service characteristics. In other words, Actional makes sure that no services can slip into production unnoticed even if there is no explicit service-to-policy mapping.

Another key advantage here is that policy lifecycle management can be independent of service lifecycle management. A policy can have a different owner from the services to


which it applies. Changing the policy does not require services changes and vice versa. This significantly decreases the cost of ownership of SOA policies over the long term.

Policy Enforcement Optimization

Actional for SOA Operations can optimize the distribution and execution of policy. Because it “knows” the flow of a message, it does not need to evaluate policy at each step in the flow, but can evaluate policy as close to the consumer as possible. If something happens downstream, Actional for SOA Operations will know about it and collect the related results across the entire message flow. The information is presented graphically to help identify the root cause of the problem, even when the problem service or system is not where the policy triggered.

The Actional user interface also supports very complex policy expressions, for example, those that combine exceptions and averages into a single policy.

To shed more light on the power and benefits of the Actional architecture, here’s a closer look at the design challenges inherent in an SOA management solution and at how different architectural alternatives address them—as a prelude for understanding the Actional SOA Operations architecture and how it implements the characteristics just discussed.

3.0 SOA MANAGEMENT DESIGN CHALLENGES

In general, designing a solution for managing an SOA, or any technology, offers a set of challenges on how to optimize for performance, cost, visibility, and scalability at the same time. The problem is that these goals seem to be incompatible because optimizing for one of them often entails making compromises on the others.

Performance and Cost

On the one hand, an SOA management solution needs to have minimal performance impact on the applications managed. On the other hand, it should be powerful and agile enough to manage all kinds of applications no matter what the size of the SOA environment. Often, in implementing an SOA management solution, companies start small and grow. However, as the SOA (and, consequently, the need for visibility) grows, the management solution—both the server and the managed applications—grind to a halt.

There’s also the matter of cost versus benefit. If the management solution adds overhead (hardware or software) in order to maintain acceptable performance, who pays for the extra capacity and who benefits from it? The IT operations group benefits; however,


usually business pays. Should the business be required to pay for the increased costs associated with management overhead that doesn’t add any value to the business?

The goal is to minimize the CPU impact of the management platform as well as to minimize the added latency for management activities. Both of these are necessary to keep the tangential costs related to management at a minimum.

Visibility

Most application vendors offer a limited management solution. Examples include vendors that can only or best handle their own environment or solutions that address only one technology, such as either Web services or portals. The real need for SOA management is, however, to provide visibility across the entire SOA environment in one single place—so that it can build an overview of the SOA that combines all the various protocols and platforms used.

As stated before, SOA encompasses more than just HTTP and SOAP. A large number of protocols should be supported (e.g., JMS, ADO.NET, RMI, JDBC, etc.) to offer an end-to-end view of the overall SOA in operation. This is usually beyond the capability of the single-platform vendor solution.

Scalability

While many kinds of management solutions exist, none can get access to in-flow information while in production. Other solutions add too much performance overhead to run all the time. Usually, when a problem occurs, the management solution has to be switched to “debug mode” to be able to gather detailed problem-analysis information. Switching to debug mode obviously changes the parameters of the operating environment so that the original problem cannot be isolated, does not occur any more, or requires waiting to happen a second time. Because Actional is “always on,” operators can capture the details of SOA operations during a policy violation the first time it happens.

The ideal SOA management solution should minimize impact on performance and cost, on the one hand, and, on the other, offer broad visibility into the SOA environment all the time. If the management solution cannot accomplish its tasks in production, on actual SOA traffic, then it cannot be considered to have met the first two design goals listed here.

Two architectural designs can be identified that try to accommodate these requirements and, as a result, face related challenges. Here’s a closer look at these different architectures and their pro’s and con’s.


4.0 SOA MANAGEMENT ARCHITECTURE PATTERNS

A number of architectural design patterns can be applied to SOA management.

Distributed Processing

In this design, policy evaluation processing is distributed throughout the network. (See Figure 1 below.) This provides a very high performance solution and greatly improves scalability. The only information or messages sent back to the server are alerts based upon policy violations (for example, for SLA violations). All visibility is provided by the node, with the management server simply consolidating the display of information from the various nodes.

A major drawback of this design is the added computing requirements at the application platform level. This management overhead adds costs to the application being managed by increasing CPU requirements, which, in turn, increases application server licensing costs as CPUs are added to maintain performance.

Another drawback is the inability of this architectural solution to create a holistic view of overall SOA health, independent of any particular silo or platform. Simply processing local information and sending back alerts centrally are not enough.

Aler

ts

SOAPerformance

Scalability

Visibility

Cost

Figure 1. Distributed Processing Architecture


Advantages:

> Performance. Policy evaluation happens on the managed node, so that the server and network are not a bottleneck to message throughput.

> Scalability. Distributing policy processing scales linearly with the number of managed nodes in the network.

Disadvantages:

> There is a heavy CPU load on the managed nodes.

> Localized node management results in no overall view of the SOA.

> There is increased cost for the application due to management overhead as CPUs are added to maintain performance.

In short, the drawbacks and challenges of a distributed processing architecture would suggest a more centralized approach.

Centralized Processing

In this architectural design pattern, the policy evaluation processing is centralized, removing any additional CPU requirements for management activities from the application and providing a holistic view of the SOA. (See Figure 2.) The centralized server off-loads processing from the application, reducing the overall CPU requirements.

The challenge with a centralized architecture, however, stems from requirements that are unique to SOA management. SOA management requires sitting in the flow of messages and works at the application layers, often gathering information from message metadata or context. The reason is that SOA management needs more information about the message flow than traditional application management.

Thought of another way, SOA management is about managing the messages between services as much as it is about managing the services themselves. In traditional application management, the only need is to manage the application and what comes in and out.

As a result of being “in flow” and managing message by message, centralized management has certain drawbacks:

1. The management server may become a bottleneck and delay the message flow, or worse, become a single point of failure.


2. Network traffic increases significantly as calls are made from the managed node to the central server for each message processed. Network traffic triples instantly!

3. Network latencies are much greater than inter-process latencies, so that end-to-end application performance suffers.

Advantages:

> A holistic view of the SOA.

> Application costs separated from management costs because the only CPU added is a central management server. Should management needs increase, the management server can be upgraded without changing the application configuration.

Disadvantages:

> Centralized server potentially a processing bottleneck or single point of failure.

> Significant increase in network traffic.

> Degradation of end-to-end application performance.

> Explosion in the number of management servers required as the number of nodes in the SOA grows.

Resu

lts

Raw

Dat

a

SOAPerformance

Scalability

Visibility

Cost

Figure 2. Centralized Processing Architecture


In short, the drawbacks and challenges of a centralized processing architecture would suggest a more distributed processing architecture. But this, as shown, has its own significant disadvantages.

What is required, therefore, is a fundamentally different architecture that can meet the opposing sets of requirements. In addition, the management solution should also be transparent to the application. The solution is architecture that combines both approaches, which, in fact, is the architecture used by Actional for SOA Operations.

Actional for SOA Operations’ Combined Approach

In this design, the policy evaluation processing is distributed into the network and the server is “in the know,” providing a holistic view of the SOA based on the information shared by agent(s). (See Figure 3 below.) The advantages of both the distributed processing model and the centralized processing model are combined, eliminating the disadvantages of both.1

Not surprisingly, there is one drawback to this approach: integration with each different platform in the distributed network requires a unique implementation. It is not one-size-fits-all. This requires a deep understanding of the supported platforms. However, Actional supplies this expertise.2 It provides SOA operators with a single installer from which each platform and protocol is selected during the installation.

Polic

ies

Aler

ts

& Sta

ts

SOAPerformance

Scalability

Visibility

Cost

Figure 3. Actional’s Combined Processing Architecture

1 Actional has patented this combined architectural approach.2 Actional provides a software developer’s kit (SDK) with samples and documentation for end users who want to instrument their

custom applications and partners who want to instrument their products.


Advantages:

> Scalability. Analysis is distributed in the network, which results in virtually unlimited scalability (i.e., the management solution scales linearly with the SOA).

> A holistic SOA view. Existing message flows are leveraged, resulting in global visibility without a central bottleneck.

> Performance. Existing message processing is leveraged on each managed platform, resulting in low CPU utilization and no impact on application performance.

Disadvantages:

> None that affects the enterprise or SOA developers and operators. There is need to have a deep understanding of each supported SOA platform because there is no “one-size-fits-all” solution. Actional solves the problem with a simple, consistent installation package for customers.

In short, by using a combined approach to SOA management, Actional delivers all advantages of both distributed and centralized processing architectures. Here’s a closer look at how, in fact, this combined architecture works in an implementation.

5.0 ACTIONAL FOR SOA OPERATIONS ARCHITECTURE

Actional for SOA Operations consists of two components: the Actional for SOA Operations Server (“server” from now on) and the Actional for SOA Operations Agent (“agent” from now on).

The agent is installed on a platform, turning it into an instrumented platform. The term “instrumented” means that the platform can be managed by the server. Neither installation nor operation of the agent requires making changes to the application.

The server is installed on a (standalone) system and is highly scalable: each server can support over 1,000 managed nodes. Servers can be clustered for redundancy and availability (fallback), but they do not offer load balancing. This, however, is not an issue because of the server’s capacity to scale. The server runs standalone, on a dedicated system, and on any number of application platforms. It requires a database and supports many popular databases. For a complete and up-to-date list of supported platforms and databases, please visit http://www.actional.com/products/technical-specifications.

http://www.actional.com/products/technical-specifications


Actional Server-Agent Communication

Figure 4 shows how the server-agent works step by step.

1. An administrator creates and configures policies centrally.

2. The centrally configured policies are pushed out to the instrumented nodes in the network.

3. The managed nodes report back to the server [using SOAP over HTTP(s) or JMS] at regular, configurable intervals, providing statistics and any newly discovered services, consumers, and relationships. The server creates a holistic SOA view based on this information. The holistic view encompasses all consumers, services, relationships, and protocols.

4. As messages flow through the network, policies are evaluated at the instrumented platform. When a policy violation occurs, the agent notifies the server, and, when required, the server “asks” the agents in the network for additional information related to the specific policy violation.

SOA OperationsServer

SOAP over HTTP(s) or JMS

On Alert, When Needed, Server AsksAgent for Additional Information

Policies Created Centrally

Statistics Reported Back on Timing Interval. Alerts Reported Asynchronously

Policies Provisioned forDistributed Execution

Instrument Platform

2

3

1

3 4

Figure 4. Actional Server-Agent Communication


As discussed, Actional combines distributed evaluation of policies with centralized control and centralized collating of information into the holistic overview. The server knows which message flow triggered the violation and collects information from other agents in the network about that message that pertain to the policy violation.

The instrumented platform is often an application server, but can also be a supported hardware device. Platforms are instrumented with agent technology—and work as discussed in the following section.

Instrumented Platform Components

An agent is made up of two components: the interceptor and the analyzer. Any managed node will have one analyzer running and one or more interceptors installed. The number of interceptors depends upon the platforms and protocols to be managed—with one interceptor per protocol/platform per node.

The analyzer and interceptor(s) work together to provide management and visibility as shown in Figure 5 below.

Flight Data Recorder

Statistics Aggregation

Policy Evaluation

Alerts and Statsto Server; Policyfrom Server

HTTP(s)

SOAP

EJB

JMS

Servlets

Message Traffic

Uplink.cfg

MessageActivity

ConfigurationInfo

Analyzer

RMIJDBCADO.NETESBDataPowerReactivity

HTTP(s)SOAPEJBJMSServletsRMI

SOA Protocols Supported

JDBCADO.NET 2.0/3.0ESBDataPower Reactivity

Interceptor

Figure 5. Instrumented Platform Components


The Interceptor

An interceptor is a lightweight component that plugs into a particular protocol stack or application platform to gather information about calls being passed by the system. A number of protocol stacks and platforms are currently supported. For a current list of supported platforms, please visit http://www.actional.com/products/technical-specifications.

The interceptor is typically quite small and leverages the processing and message tracking done natively on the platform. In this way, it delivers a key advantage of the Actional architecture: minimizing duplicate message processing.

The interceptor reads configuration information from the uplink.cfg file (created by the analyzer) to know how to configure itself. The uplink.cfg file contains information about where (i.e., to what port) the interceptor should send events and what information to report (whether the message body is needed, etc.). The uplink.cfg file also contains a key used to securely communicate with the analyzer. If uplink.cfg cannot be located, the interceptor will disable itself and check back for uplink.cfg on a regular interval.

The uplink.cfg file is also accessed by the analyzer at regular intervals. This action is used by the interceptor to determine if the analyzer is up and running.

With rare exception, the port used to communicate between interceptor and analyzer is restricted to their local machine. The protocol is binary and uni-directional—from interceptor to analyzer—to prevent an analyzer problem from blocking the message flow by hanging the interceptor.

The Analyzer

The analyzer processes events by reading them from the in-memory buffer, called the “Flight Data Recorder.” This buffer is used to level off event peaks in runtime traffic and maximize analyzer performance. Buffer space is reused when available, and the buffer size is configurable.

Statistics (such as number of calls made from a consumer to a provider) are updated based on the events processed and are kept in Statistics Aggregation buckets.

Policies are evaluated against incoming messages and on a time schedule for aggregate statistics. Alerts are sent to the server asynchronously, as policy violations occur. On a regular interval all statistics are sent back to the server for persistent storage and for the creation and/or update of the network flow map.




In particular, the agents (and their constituent parts) and the management server perform as follows.

Tracking Message Flows

The interceptor tracks messages and message flows. It is developed to hook in wherever messages go into and out of an application platform. Figure 6 below shows where interceptors would typically be inserted to track message flows.

The interceptor is inserted without modifying the application and, as such, is invisible to the application developers. The result—a key benefit—is that the application does not need to be tailored to be managed.

The interceptor runs in the platform protocol stack, not on the application server and, as a result, becomes part of the application server. This means that Actional can be deployed independently and without knowledge of the services to be managed. Services can be added after Actional is deployed and will automatically be discovered without an impact on the management functionality available. The interceptor also provides visibility into the platform one hop away from the instrumented platform, resulting in Actional’s unique ability to discover consumers and manage services even without installing software on the provider.

Figure 6. Tracking Message Flows


Injecting “Tracers” into the Flow

To be able to follow a message moving through a flow, the interceptors insert a manifest into the transport header. The actual application message is not touched (i.e., the message data is not changed), and the extra information is not visible to the application. For nodes that do not have an agent installed, the additional transport information is simply ignored. For encrypted or otherwise secured messages, the manifest has no security impact.

The manifest enables the capture of exact message sequences both within a machine and across machines. Figure 7 below shows how an interceptor injects a “tracer” and how this is followed through the message flow.

If transport headers cannot be used (e.g., when using JDBC), the interceptor keeps track of traffic from the application server, and no transport header is necessary.

As a result of this feature, no manual correlation mapping needs to be defined, and relationships can be discovered automatically. All this is achieved without any application modifications and across multiple protocols. If an inbound call is made using HTTP, which (in turn) makes a request using SOAP to a Web service that is really a wrapper for an RMI call somewhere else, end-to-end tracking is still available across all the protocols without configuring anything upfront.

Figure 7. Injecting “Tracer” into the Flow


Storing Information in Memory—in the Flight Data Recorder

The message information gathered by the interceptor is sent to the analyzer for processing. The analyzer makes use of a buffer called the “Flight Data Recorder.” The buffer mechanism is used to level out peak message events and make processing more efficient.

Because the Flight Data Recorder tracks every single message flowing through the network (on the local node), Actional for SOA Operations has a true, complete picture of what’s happening. There is no need for using synthetic transactions to infer information about production message flow performance or characteristics. (However, Actional supports synthetic transactions, called “watchdogs,” as well.) When no policy violations occur, the agent sends statistical information over the collection interval back to the server for persistent storage.

The Actional for SOA Operations architecture allows for monitoring every single message flowing through the network without impacting performance. By tracking each individual message and being able to correlate it with flows through the network, Actional for SOA Operations is able to identify problem messages the first time a problem occurs and is



Policy Evaluation



Policy Evaluation



Policy Evaluation



Policy Evaluation

Figure 8. Storing Information in Memory


able then to provide insight into the root cause of the problem (enabling the SOA operator to drill down) without “turning on debug mode” and waiting for the problem to recur.

Evaluating Policy to Detect Abnormal Conditions

The analyzer compares the messages with policies, alerting the server when a policy violation occurs, as shown in Figure 9 below.

Because Actional tracks all dependencies, policy evaluation can be optimized to happen only at one point in the flow of the message (usually the one closest to the consumer). This capability helps to greatly reduce overall policy processing requirements without sacrificing policy enforcement.

Actional also enables policies to “make more sense.” For example, in traditional management systems, a policy comparable to “alert on slow response time” might be required on each of the four machines in Figure 9. The reason is that if one of the



Policy Evaluation



Policy Evaluation



Policy Evaluation



Policy Evaluation

Figure 9. Evaluating Policy and Alerting the Server


machines has a delayed response, measured from request in to response out, somebody needs to investigate.

The real issue, however, is not how the machines are doing (i.e., their performance), but how machine performance impacts service consumers, that is, end-to-end requests made by consumers. The important fact is not whether any of the four machines is slow but whether the consumer making the request is getting a response within the timeframe specified in an SLA.

Gathering Relevant Information

Upon receiving a policy violation alert/warning from an agent, the Actional server gathers, correlates, persists, and visualizes relevant records from each related Flight Data Recorder, as shown in Figure 10.

When an alert occurs as the result of a specific message, the server goes out to the network and collects information about it. Using the related information, it can create a flow map for that message alert along with all the metrics from each step along the way to help with root cause analysis. The information gathered is persisted to the database by the server.



Policy Evaluation



Policy Evaluation



Policy Evaluation



Policy Evaluation

Figure 10. Gathering Related Information


Enabling Root Cause Analysis

The server creates the flow map to aid with root cause analysis. SOA operators view the map using the Actional Console. The screenshot in Figure 11 shows the Actional Console, which provides capabilities for managing the entire network of services regardless of protocol, policy type, or node.

The display shows a number of nodes with agents installed (the orange nodes) together with some nodes that were auto-discovered (the gray nodes) because they communicate with an agented node. Gray nodes do not have Actional software installed, but can still be “seen.”

In this example, a policy has been created to alert SOA operators when a consumer using the partner gateway (the highlighted node) has a response time greater than five seconds. The policy is placed and evaluated only on the partner gateway, not on every node that might participate in the transaction. The network overview display in the Alert Analyzer shows only those nodes that were involved in the message transaction and is able to show every node involved from end-to-end even though the policy was only put on the partner gateway. The display also shows a red arrow indicating where the policy

Figure 11. Actional Console Showing Policy Violation


has been violated and thicker arrows where response times were below those specified in the policy. In short, even though the policy is only evaluated at the partner gateway node, the server is able to help find the root cause by applying some intelligence to the gathered information.

By drilling down into a node from the flow map using the Actional Console, SOA operators can view more detailed statistics about the selected node, as shown in Figure 12 below.

The drill-down view of the partner gateway node (see Figure 13) provides more detailed statistics, showing that local processing time on this node is within limits. Local processing time is small enough; downstream, however, processing time is a lot longer.

Figure 12. Actional Console Showing Detailed Node Statistics


Following the transaction through a number of hops shows the order management node making a request to the inventory management node. The response from inventory management to order management is quite slow. In fact, it is responsible for most of the latency of the consumer request.

In short, with Actional even though the policy was evaluated on the partner gateway, SOA operators can quickly track the root cause of the problem back to the inventory management system, allowing them to take timely measures to fix the delays.

Figure 13. Actional Console Showing Root Cause of the Problem


6.0 ACTIONAL FOR SOA OPERATIONS: A CLOSER LOOK AT AGENTS

The key role played by agents in the Actional SOA Operations architecture merits a closer look at their internal components and how they work. Figure 14 shows the agent, which consists of the analyzer and interceptor components together with their supporting components and structures.

Interceptor

Figure 14 shows the interceptor installed for a particular application platform. It is looking at and intercepting messages coming into and going out of the system. Multiple interceptors can report into a single analyzer. The analyzer (with very rare exception) is located on the same machine as the interceptor.

Correlator

Within the interceptor the messages pass through the correlator, which is implemented “in container.” The correlator performs several functions. It:

> Captures details of messages flowing into and out of applications. It resides in the application level “protocol stack” seeing every message.

> Correlates messages across machines and within applications by reading and embedding context in transport headers.

Anal

yzer

Inte

rcep

tor



Policy Evaluation

Corr

elat

or

Corr

elat

or

ApplicationPlatform

Reporter

Figure 14. Inside the Actional Agent


> Stores and retrieves context in container state. Because of this, the interceptor is application-server-specific, but protocol-independent. [Actional supports HTTP(s), EJB, JMS, JDBC, ADO.NET, RMI, ESB, and other protocols.]

Figure 15 shows the activity sequence of the correlator when a message passes through the application platform.

Specifically, the correlator:

1. Reads the correlation state from the incoming transport-level message header

2. Stores the correlation state in the container’s processing context (e.g., transaction, session, or process context)

3. Allows the container to transfer and persist the correlation state as necessary

4. Reads the correlation state from the container’s processing context

5. Embeds the correlation state in the outgoing transport-level message header

This capability results in several benefits. There is no need for manual correlation mapping. Relationships can be discovered automatically. No application changes are required to implement this functionality.

Reporter

The reporter buffer captures details of messages flowing into and out of the application, which it can report back to the analyzer. The size of the reporter buffer is 64K, but can be changed. The buffered data is sent to the analyzer through a local socket connection.

Corr

elat

or

Corr

elat

or

ApplicationPlatform

Reporter

1 2 3

4 5

Figure 15. Correlation Management


The interception of messages takes place without modifying the application hosted by the platform. Instead, the intercepter uses what are called “plug points.” Several plug-in options are available to the interceptor and are used depending on availability. These include:

1. Using platform-specific plug points

2. Using bytecode instrumentation to hook into the protocol stack

Platform-specific Plug Points

When the application platform supports plug points (such as Tomcat valves or .NET machine.config), the interceptor uses these predefined plug points to capture the necessary messages.

Not every platform supports plug points or provides the necessary information through the available plug points. When predefined plug points do not exist, Actional uses bytecode instrumentation.

bytecode Instrumentation (bCI) into the Protocol Stacks

This technique is used to plug into the platform just as if the platform provider provided ready-to-use plug points. The platform vendor does not have to have defined the correct plug points (or, in fact, doesn’t need to provide any plug points) in its platform architecture for the interceptor to capture the required information. Bytecode instrumentation allows Actional to control precisely which parts of a platform or application are profiled. As a result, only relevant information is reported, and the impact on application performance is reduced so that even large applications can be profiled easily.

BCI used by the interceptor is not arbitrary (i.e., Actional does not allow users to choose what functions to capture). Actional very explicitly controls exactly where BCI is used.

Analyzer

The analyzer is installed once on a node. Each of the installed interceptors on the node contacts the analyzer and sends message information to it for further processing.


The Flight Data Recorder buffer captures message details used for processing by the analyzer. This information exists only in memory, is used only by the local analyzer (i.e., is never sent over the network), and is never persisted. The default buffer size is 64 MB, but


can be configured via the console. The message details contain only the minimum data needed to properly execute policy.

For security, only authorized interceptors can access the analyzer or the Flight Data Recorder buffer directly. The uplink.cfg contains a random key that interceptors must provide if they want to contact the analyzer. The uplink.cfg file needs to be secured properly, so that only authorized applications can access it, to control the ability of unauthorized users impersonating interceptors.

Because the interceptor and analyzer run on the same machine, there is no way for an “outsider” to capture the data stream flowing between them (without having kernel-level privileges).


The statistics aggregation buffer accumulates statistics about messages, segmented appropriately by:

> Node

> Group

> Service

> Operation

> Minimum, maximum, average, sum, count, sum of squares

The stored information is gathered by the server when the gather interval expires, at which time the statistics are reset, and the existing totals are dropped.

Policy Evaluation

Policies governing an individual instance of service are evaluated as each message arrives. Policies governing aggregated services are evaluated on a periodic time interval. Policy evaluation can trigger actions such as sending an alert to the server for further action or storing an audit event in the audit database for later retrieval.


7.0 CONCLUSION

The Actional for SOA Operations’ architecture combines distributed policy evaluation and centralized management and control. This design approach, together with some unique agent and server capabilities, results in a number of characteristics that, in turn, provide significant benefits.

As shown, Actional provides

> High scalability. It supports more than 1000 nodes per server and 50,000 dependencies per server—for extremely cost-effective SOA evolution.

> High performance. Actional optimizes CPU utilization. Testing of its management overhead indicates it take up less than 2% of CPU capacity in real-world scenarios. In addition, the central server is not in the message flow, so there are no central bottlenecks for policy evaluation. This capability enables business to run at competitive speeds without adding IT resource (nodes or management servers) simply to boost performance.

> Automatic service discovery and correlation. With Actional, services, service consumers, and service relationships are automatically discovered and tracked without prior knowledge of their existence. Actional also enables visibility one hop away from any managed node. Correlation of discovered services is automatic as well, significantly increasing the likelihood that what is “documented” is what is really happening. These capabilities result in time and cost savings—because there’s no need for coding or configuration to achieve visibility—while contributing significantly to ensuring the reliability of SOA operations.

> Policy inheritance. Policies can be created independent of services. As a service is discovered, a policy can be applied via metadata correlation. This separation results in significant time and cost savings, eliminating the burden of coding policies into services and re-coding when policies or service change.

> Multi-protocol support. The Actional interceptor architecture is technology agnostic. Protocols supported include SOAP, HTTP, JMS, EJB, RMI, JDBC, ADO.NET, and others. As a result, Actional can function in the most diverse and heterogeneous environments, enabling companies to leverage their IT investments.

> No application changes required. With Actional, an application does not need to be modified in any way to be managed, and companies to not need to install Actional on every node in order to have a managed SOA. Because it was built from the ground up for integration, there is no vendor lock-in to Actional. Actional can be removed as easily as it is installed.


> Policy enforcement optimization. SOA operators can apply policy closest to the consumer. Actional understands the interrelationships across the SOA and uses this information to minimize the amount of policy processing required without sacrificing effective policy enforcement. Companies reduce risk as well as system overhead. They also can deploy fewer agents, for lower cost of ownership.

As a result, the Actional SOA Operations architecture provides an SOA management solution that is powerful and cost-effective.

Worldwide HeadquartersProgress Software Corporation, 14 Oak Park, Bedford, MA 01730 USA Tel: +1 781 280-4000 Fax: +1 781 280-4095 www.progress.com

For regional international office locations and contact information, please refer to www.progress.com/worldwide

© Copyright 2007 Progress Software Corporation. Progress and Actional are registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. or other countries. All rights reserved. Any other trademarks contained herein are the property of their respective owners.

Documents

ACTIONAL ARCHITECTURE SERIES: ACTIONAL FOR SOA OPERATIONS