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.
<installpath>/home/kpeeples/demos/fsw-simple-demo/installed/fsw</installpath>
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:
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
- 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
Closing
