Actional Core Architecture: Enable end-to-end transaction monitoring and alerting

W H I T E P A P E R
ACTIONAL ARCHITECTURE
Core Operational ManagementTABLE OF CONTENTS
> 1.0 INTRODUCTION 1
> 2.0 ACTIONAL ARCHITECTURE: KEY CHARACTERISTICS 2
> 3.0 DESIGN CHALLENGES 4
> 4.0 ARCHITECTURE PATTERNS 6
Distributed Processing 6
Centralized Processing 7
Actional: A Combined Approach 9
> 5.0 ACTIONAL ENTERPRISE: THE OPERATIONAL MANAGEMENT ARCHITECTURE 10
Actional Server-Agent Communication 11
Instrumented Platform Components 12
Tracking Message Flows 14
Injecting "Tracers" into the Flow 15
Storing Information in Memory-in the Flight Data Recorder 16
Evaluating Policy to Detect Abnormal Conditions 17
Enabling Root-cause Analysis 19
> 6.0 A CLOSER LOOK AT ACTIONAL AGENTS 21
Interceptor 22
Analyzer 24
> 7.0 CONCLUSION 251.0 INTRODUCTION
As companies turn to modern distributed, interconnected applications-including service-oriented architecture (SOA), Web 2.0, cloud computing, ESBs, messaging, and business process management (BPM) initiatives-the need for a new kind of management grows. This need is driven by ensuring reliable operations across a distributed, heterogeneous environment. Three simple capabilities are required to do so, and any solution should provide these basic capabilities:
1. Automatically 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 these modern applications, is visibility into the environment with its myriad services, consumers, and the dependencies between them, without requiring changes to the applications themselves. A management solution for such applications 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 these applications, 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.
® ®Progress Actional Enterprise offers the capabilities necessary for organizations adopting distributed, interconnected applications and requiring management and/or security. This white paper explains how the Actional architecture addresses the basic operational monitoring and management challenges and how Actional is implemented in a customer environment.
Specifically, the paper starts with an overview of the Actional architecture's critical characteristics. It then addresses key design challenges of managing distributed, interconnected applications and architectural alternatives. It follows with a detailed description of how the Actional architecture works and provides an introduction to the significant IT, productivity, and cost benefits. Finally, the paper closes with the two approaches to implementation typically taken by Actional customers.
© 2009 Progress Software Corporation and/or its subsidiaries or affiliates. 12.0 ACTIONAL ARCHITECTURE: KEY CHARACTERISTICS
Actional is 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 a distributed application environment.
High ScalabilityActional's architecture uniquely blends distributed policy evaluation with centralized command and control, enabling very high scalability. The Actional 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. Policies, such as service-level agreements (SLAs), 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; this dependency may be variable with the growth of the solution... [download for more]