Tuesday, March 4, 2014

Simplified Run Time Governance and Fuse Service Works

Simplified Workshop Series
Run Time Governance
in Fuse Service Works

Welcome to the Simplified demo series. I refer to this as a workshop in a box, meaning everything is included to get you started such as the source, instructions, videos, presentations, etc. This demo will walk you through a quick demo of Run Time Governance in Fuse Service Works. It is split into 3 main sections. First is the quick demo which walks you through the quick steps to run a quick, easy demo (The What). The second section gives an overview of the technology and how the demo was created (The Why and How). The third section gives you additional collateral. So let’s get started and as they say so easy a non techie can do it...

Section 1 : Run a quick demo

Step 1: Clone the repository from https://github.com/kpeeples/simplified-rtgov

Step 2: Download Fuse Service Works from http://www.jboss.org/products/fsw.html

Step 3: Place the software in the distros folder

Step 4: Modify the support/InstallationScript.xml file to contain the full path to the installed/fsw directory. Make sure to leave the installed/fsw directory. The script performs the automated install of Fuse Service Works. NOTE: This is installing the Switchyard, DTGov, S-RAMP and RTGov components which wouldn’t be the recommended setup as Design Time would be a separate server from the Switchyard/Run Time Server.


Step 5: Modify the post-run.sh file to have the appropriate directory for the quickstarts.

Step 6: Run the install-run.sh script to install FSW and start the server

Step 7: Open another terminal and run the post-run.sh script. This will kick off the individual examples.

A. First we deploy the application and information processor. The accepted status from the response should be true.

B. Next we will show the Synchronous Policy Enforcement to see that orders from Fred cannot be performed more the 1 request every 2 seconds.

C. Next we will show the Asynchronous Policy Enforcement to see that a customer will be suspended after 3 attempts that goes over a threshold. A make payment is done in order to continue orders.

D. Next we will show SLA Monitoring. The “Situations” active collection will report SLA violations to the end user through REST or JMX. We will use REST.

E. Next we will show SLA Reporting. We will generate a report which will return the violations that occured in year 2014.

This is a quick demo of Run Time Governance. More detail of configuration and step by step are below.

Section 2 : Technology Overview and creating the demo step by step

Technology Overview

This was compiled from http://docs.jboss.org/overlord/rtgov/quickstart/1.0.0.Final/html_single/index.html and https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Fuse_Service_Works/6/html-single/Development_Guide_Volume_3_Governance/index.html.

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 Run-Time Governance to facilitate complete control over the shared services by following a policy based approach. SwitchYard classifies Run-Time Governance into two aspects:
  • Policy definition and enforcement
  • Collection and exposure of run-time metrics for services and service references
The architecture is separated into four distinct areas, with components that bridge between these areas:
  • Activity Collector - this component is optional, and can be embedded within an executing environment to manage the collection of information
  • Activity Server - this component provides a store and query API for activity information. If not using the Activity Collector, then activity information can be reported directly to the server via a suitable binding (e.g. REST).
  • Event Processor Network - this component can be used to analyse the activity information. Each network can be configured with a set of event processing nodes, to filter, transform and analyse the events, to produce relevant rules.
  • Active Collection - this component is responsible for maintaining an active representation of information being collected. UI components can then access this information via REST services to present the information to users (e.g. via gadgets)

Step by Step

The step by step will be added in the next version.

Section 3 : Additional Collateral and demo structure

The root folder of the demo contains:
  • install-run.sh to install and run FSW
  • pre-run.sh to do any pre-installation setup or compiling
  • post-run.sh to do any post-install setup or compiling
  • README.MD to briefly descibe the demo
  • readme.html to meet the objectives 1) quick and easy demo 2) step by step instructions with collateral
  • reset.sh to reset the demo
The collateral folder contains:
  • Video for videos or link to video
  • Presentation for presentations or link to presentation
  • Blog for a blog document or link to blog
  • Simulation for a simulation of the demo or link to simulation
The distros folder contain the downloads for the demo
The installed folder contains subfolders for the software to be installed when the script is run
The source folder contains any source projects to be compiled and deployed
The support folder contains any supporting files/directories