Chapter 3. Runtime Governance

In SwitchYard, the applications are exposed as shared business processes or services. In a shared environment, the most common challenges revolve around access control, access rights, security issues, and service authorizations. SwitchYard uses Runtime Governance to facilitate complete control over the shared services by following a policy based approach. SwitchYard classifies Runtime Governance into two aspects:
  • Policy definition and enforcement
  • Collection and exposure of runtime metrics for services and service references
To provide you with a deeper understanding of Runtime Governance and how it works, this chapter covers the following information:
  • The Runtime Governance architecture, its components, and details on how these components integrate and process business information from the activity events.
  • The activity events, and details on the types of activity events and their significance.
  • The role of Activity Collector and Activity Server in collecting, validating, processing, and recording activity event information.
  • The role of Event Processor Network and Event Processors in processing activity events.
  • The Active Collection mechanism, its implementation, and details on how you can use Active Collection to store processed events and notify the end-users or applications.
For information on setting up the Runtime Governance server, see the Red Hat JBoss Fuse Administration and Configuration Guide.
For information on using the user interface and gadgets, see the Red Hat JBoss Fuse User Guide.
You can enable or disable Runtime Governance through the collectionEnabled property in the $JBOSS_HOME/standalone/configuration/overlord-rtgov.properties file. By default, the value of the collectionEnabled is set to false.
This property will determine whether activity information is collected when the server is initially started.

3.1. Architecture Overview

The Runtime Governance architecture provides a modular and loose-coupled solution for processing business activity information in real-time. The architecture is classified into four distinct areas:
  • Activity Collector: Used to collect activity events.
  • Activity Server and Store: Used for central activity event storage and querying.
  • Event Processor Network: Used for generic event analysis to process the activity events.
  • Active Collections: Used for active information management to post-process and cache information for end-user applications.
You can configure these components to work together to build a Runtime Governance solution for real-time monitoring of business transactions. Out of these, the Activity Server is the only mandatory component, as it provides the central hub for storing and querying activity events. This means that you can replace the way in which events are processed, or presented to end users and applications, with any other more appropriate technology for a particular target environment. You can use the Event Processor Network and Active Collection mechanisms to process and manage the presentation of any type of information.
Also, a collection of REST services is provided to support remote access to the information. You can use REST API to develop new custom code to access Runtime Governance information.

3.1.1. Activity Collection and Reporting

Runtime Governance supports the following public APIs:
  • The Activity Server API: This is used by Runtime Governance itself to communicate with a remote Runtime Governance server.
  • The Active Collection API: This is used to query active collections.
The Embedded Activity Collector collects events and sends them to the Activity Server in batches. Activity Server also receives events from external activity sources. The Activity Server saves these events in its data store and also notifies other components about the activity information. The diagram below illustrates the functions performed by the first stage of the Runtime Governance architecture:

Figure 3.1. Activity Collection, Reporting, and Storage

Activity Collection and Reporting in Runtime Governance
  • Collection: The Activity Collector component of the architecture is optional and is responsible for collecting information from the execution infrastructure as efficiently as possible. It collects the activity events associated with a particular thread as a group, contained within an Activity Unit. This provides an implicit correlation of the activities that are associated with the same business transaction. You may also pre-process the activity events to extract relevant context and property information before it is reported to the Activity Server. Activity Units are then batched into further groups, and reported to the Activity Server at regular time intervals or when the batch gets too large. If the Activity Collector and Activity Server are co-located within the same execution environment, the Activity Units are reported directly. If the Activity Server is running remotely, then you can use suitable connectors to report the information via REST API.
  • Activity Server: The Activity Server provides a public API for reporting a list of Activity Units. Remote components can access this API either directly (for example, as a CDI component), or remotely via REST. The Activity Server has the following main responsibilities:
    • To ensure Ids are set and consistent.
    • To store the events in a repository.
    • To notify other interested modules.
  • Storage:The Storage component records the activity events in a persistent data store.
  • Notification: The Notification component is an API and keeps the other modules notified as and when the activity events are reported.

3.1.2. Event Processor Network

The Activity Server notifies the Event Processor Node about the activity events through the Event Processor Network. The Runtime Governance infrastructure notifies one or more Event Processor Networks (specifically Event Processor Networks that have a subscription for the subject ActivityUnits) about activity events reported to the Activity Server. The following diagram illustrates how a node within an Event Processor Network functions to process the inbound event information.

Figure 3.2. Runtime Governance Event Processor Network and Nodes

Runtime Governance Event Processor Network architecture
The Event Processor Network is a graph based mechanism for processing a series of events. You can register one or more networks to receive the activity information as notifications from the Activity Server and process it. Processing involves filtering, transforming and analysing the activity events. Each network defines a graph of Event Processor Nodes connected by links that transfer the results from the source node to the target node. The graphs can subscribe to event subjects in order to identify the information they are interested in. The graphs then identifies and nominates the node(s) within the network that processes the information on that subject. The nodes can also publish their results to event subjects, for other networks to further process it. This provides a de-coupled way for networks to exchange information.
Each Event Processor Node defines the following:
  • An optional predicate to determine whether the event is of interest, and
  • An event processor to perform the actual task of event processing.
You can have multiple versions of the Event Processor Network. When you deploy a new version of a network, the events that are being processed by the old version continue to be processed using that network, while new events being dispatched to the network are handled by the newer version.
Additionally, you can configure the nodes to generate different levels of notification. other applications or components may use these notifications to check the information being processed through the network. These notifications are distributed to named notification subjects. This enables observing components to remain de-coupled from the details of which networks or nodes are producing results for that subject.

3.1.3. Active Collections

The Active Collection mechanism provides a capability for storing processed events and derived analysis information in a manner that the end users can access. It also actively notifies the end users or applications when any changes occur. The following diagram illustrates the Active Collection mechanism:

Figure 3.3. Active Collections

Runtime Governance Active Collections
The Active Collection mechanism differs with the standard collection concept, where interested components or applications can register interest in changes that occur to the contents of a collection such as a list or a map. The Active Collection mechanism is used to maintain information that is presented to the users, for example via the Gadget Server.
An Active Collection Source manages the information within a particular Active Collection. The Active Collection Source acts as an adapter between the actual source of the information and the Active Collection. For example, an out of the box implementation of an Active Collection Source checks for different types of information produced by an Event Processor Network.
The generic Active Collection Source implementation includes:
  • The ability to aggregate information which is then stored as a summary within the Active Collection.
  • The ability to perform routine maintenance tasks.
  • The ability to clear the collection entries based on configured criteria, such as maximum size of the collection, or maximum duration an item should exist in the collection.
Additionally, you can also create derived (child) collections from these top-level collections. The derived collections have a predicate that determines whether an entry in the parent collection is relevant to the child collection. This can be used to manage specific sub-sets, and provide an active query mechanism, enabling interested clients to observe changes to the child collection.

3.1.4. Runtime Governance Topologies

You can install and run Runtime Governance either on the same application server as Design Time Governance, S-RAMP, and SwitchYard, or on a separate server.
Using Runtime Governance client in the SwitchYard environment to talk to a remote Runtime Governance server, enables the Runtime Governance server to run in its own isolated cluster.

Figure 3.4. Runtime Governance on a Different Server

Runtime Governance on a Different Server
If co-located, then although you are saving on the REST communication and serialization, it means that all event processing will be done on the same servers as the business logic. And if the business application uses JMS, then the EPN event distribution also uses the same JMS infrastructure.

Figure 3.5. Runtime Governance on the Same Server as JBoss Fuse

Runtime Governance on the Same Server as JBoss Fuse
If you are working on testing and development environments without high loads, it is possible to run one JVM with the server, Runtime Governance, and JMS enabled as the performance hit is not dramatic. However, if you need Runtime Governance in high performance environment, Red Hat recommends running Runtime Governance in a separate JVM. The JVM instance running Runtime Governance must have JMS enabled, whereas other application server instances can run without JMS.
The Runtime Governance server configuration is same in both situations. The only difference is that, in the Runtime Governance client configuration, there are configuration details in overlord-rtgov.properties file to provide the server URL for reporting activity events via a REST API. Also, you need to install the appropriate war file depending upon the Runtime Governance client and server topology you choose during installation.

3.1.4.1. Runtime Governance and S-RAMP in a Clustered Environment

When you start the server using the HA profile, runtime governance is automatically clustered based on the clustered Infinispan, HornetQ, and a shared database. S-RAMP only requires a shared database. There is no dependency between runtime governance and S-RAMP as they are installed and configured independently.
In a clustered environment, it is recommended to have a dedicated runtime governance server, separate from the execution servers. In this case, all servers connect to this server via the runtime governance client. Depending upon the load of the runtime governance server, it may also be necessary to set up a cluster of governance servers as well. If you have a cluster of runtime governance servers, then they only need to connect to the same database instance. However, it is possible to also configure each runtime governance server to have its own S-RAMP database. The JBoss Fuse installer configures all components to use the same database by default so that runtime governance and S-RAMP share the same database instance. However this is not mandatory.