The aim of this release is primarily to focus on the infrastructure for both components, rather than higher level features, but there is a small demo to illustrate some of the capabilities, which will be discussed later in the post.
Overview of the architecture
Activity Collector
One of the goals of the BAM infrastructure is to support real-time activity collection and analysis. However when monitoring the execution of a distributed system, this can involve the collection of a large amount of information.Therefore, although this component is optional, it provides the ability to integrate a collection mechanism into an application or container, which is designed to minimise the impact on the application, and deliver the activity details to the Activity Server in the most efficient manner. A batching approach is used based on maximum time interval and size - both of these values can be adjusted via a MBean.
Collecting activity information in this manner can also provide an implicit correlation between tasks that are carried out on behalf of a business transaction, minimising any post-processing that maybe required to recover this correlation if the events had been independently reported.
If the executing services are running in a remote location from the Activity Server, then one of the appropriate bindings will be used to deliver the information to the server - currently only REST is supported. However, if the services (and thus collector) are co-located with the Activity Server, then the information is reported directly.
Activity Server
The Activity Server has two responsibilities, firstly enabling clients to record activity information and secondly to provide query methods to retrieve a subset of the information. The server will be accessible via a range of bindings, although currently only REST and the direct Java API are supported.When activity information is being stored, the Activity Server performs the following tasks:
- Pre-Process the activity information to assign unique ids
- Store the data in a persistent store
- Notify interested listeners about the activity information
Event Processor Network
The Event Processor Network (EPN) is a graph based mechanism for processing a series of events. In the context of the BAM infrastructure, one or more networks can be registered to receive the activity information (as notifications) from the Activity Server and process it (filter, transform, analyse, etc) using whatever means is appropriate.Each network defines a graph of nodes connected by links that transfer the results from the source node to the target node. The graphs can subscribe to event subjects, to identify the information they are interested in, as well as the node(s) within the network that will process the information received on that subject. The nodes can also publish their results to event subjects, for other networks to further process.
Each node defines an optional predicate, that can be used to determine whether the event is of interest, and an event processor to perform the actual task. An example of an "out of the box" event processor is one used to trigger CEP rules (using Drools Fusion) to process the events.
The nodes can also be configured to generate different levels of notification, which can be used by other applications/components to observe the information being processed through the network (e.g. events that passed the predicate evaluation, results from the event processor, etc.).
When an EPN is registered, it will become manageable via a JMX MBean:
The Event Processor Networks are also versioned, so that networks can easily be upgraded without impacting events being processed by a previous version. Only new events submitted to the network will be processed by the newer version.
Active Collections
The Active Collection mechanism is a variation on the standard collection concept, where interested parties can register interest in changes that occur to the contents of a collection (e.g. list, map, etc). This is one of the mechanisms that will be used to maintain information that is to be presented to users (e.g. via the Gadget Server).The information within a particular Active Collection is managed by an Active Collection Source, which effectively 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 is provided to observe different types of information produced by an EPN node. This implementation also includes the ability to aggregate information to store a summary within the Active Collection - this mechanism has been used with the service response time information in the demo to be described later in the post.
As well as the information within an Active Collection being maintained by an Active Collection Source, the configuration of the source can define certain constraints on the Active Collection - e.g. maximum number of items, item expiration duration, etc. These provide a means to keep the Active Collections a managable size.
When an Active Collection Source is registered, the associated Active Collection becomes manageable via a JMX MBean:
Gadget Server
The Gadget Server provides a GWT implementation of the OpenSocial specification. This provides a visual container for gadgets, allowing users to select the gadgets they are interested in, and define the layout in which they wish to organise them.A range of gadgets will be implemented to enable users to access information provided by the BAM system. However it will also be possible for users to upload their own gadgets into the server and used along side the Overlord provided gadgets.
A simple demo
The first milestone includes a simple demo application, with an additional 'test business transaction' generator. This demo works with Switchyard 0.5.Final.Setup the environment
First step is to download Switchyard (0.5.Final or above) and the Overlord BAM distribution for JBossAS. Although Switchyard is being used for this demonstration, JBossAS7 can equally be used - the only dependency on Switchyard is the example application that is deployed.Unpack both in suitable locations.
Open a command window in the root folder of the Overlord BAM distribution and set the JBOSS_HOME environment variable to point to the root folder of the Switchyard installation. Then run the following command:
mvn install
(To uninstall, run the "mvn clean" command from the same folder).
Change directory to the samples/slamonitor folder, and then run:
mvn install
This will automatically install the four war files associated with the sample into the Switchyard deployments folder.
Startup the server
First start the Switchyard environment using the following command from the bin folder:./standalone.sh --server-config=standalone-full.xml
(Full config required as JMS is used).
Start the browser
Once the server has started, then opena browser at the URL: http://localhost:8080/gadget-webYou will be presented by a login screen:
Currently users are not persisted, so each time the server is started (or on first access) you will need to press the "Signup" button:
Fill in some temporary details and press the "Submit" button. This will display an initially blank tab - however when a user's profile is persisted, this will show the profile previously configured by the user.
At the top right hand corner of the screen will be an "Widget Store" link which takes you to the list of available gadgets:
Press the "Add To Page" button for the Response Time and SLA Gadget entries, before pressing the "Back to Tabs" link in the top right hand corner.
Run the activity client
Using the same command window, change directory to the samples/activityclient folder, and then run the following command to generate a set of business transactions:mvn clean install -Dcount=1000
This will perform 1000 business transactions, a majority of which will be valid with the occasional transaction that will result in a SLA violation.
This will result in the response time information and service violation details being presented in the browser:
The gadgets are set to refresh every 30 seconds, although this polling interval can be changed as part of the gadget configuration. Future versions will experiment with using active pushing of the changes to the browser.
The Response Time gadget currently shows all response time information for any service and operation. In a future release it will be possible to filter the service and/or operation being viewed. The specific details regarding a particular point on the chart can be viewed by hovering over the point:
The SLA Violations can also be processed as JMX notifications (using JConsole):
The source configuration for the two Active Collections has some configured constraints:
Response Time
This Active Collection represents a set of aggregated results. Every second an aggregated result is produced based on all of the response time information for a particular service type and operation. This aggregated result represents the average, minimum and maximum values.The collection is also constrained to define a maximum number of 100 items. As the collection cleanup cycle runs periodically, this maximum threshold is not strictly enforced, but provides the level at which cleanup will be triggered. So you will notice that during the test, the number of items will exceed 100, but when the test stops, eventually the final cleanup will truncate the list size to 100.
SLA Violations
The SLA Violations active collection has the constraint that each item will expire after 40 seconds. Therefore, once the activity client has finished generating test data, you will notice that the entries will eventually all be removed.Monitoring a Switchyard Application
The activity client provides the means to generate a large number of transactions quickly, to make it easier to demonstrate the UI. However it does not demonstrate collecting information from a real application.When deploying the SLA Monitor samples above, one of the war files (slamonitor-orders.war) is actually a Switchyard application that includes an 'exchange handler' that intercepts messages passed between services and reports them via the Activity Collector.
To demonstrate activities being reported from the Switchyard application you will need to startup your favourite SOAP client and send the following message:
to: http://localhost:8080/demo-orders/OrderService
<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:body>
<orders:submitorder xmlns:orders="urn:switchyard-quickstart-demo:orders:1.0">
<order>
<orderid>PO-19838-XYZ</orderid>
<itemid>BUTTER</itemid>
<quantity>400</quantity>
</order>
</orders:submitorder>
</soap:body>
To generate an SLA violation, simply change the itemId from BUTTER to JAM and then resend the message.
References
Further information can be obtained from:User Guide
Developers Guide
Discussions can be held on the Overlord User Forum.
Problems or feature requests can be reported here.
