Friday, February 28, 2014

Run Time Governance Quickstarts in Fuse Service Works



I - Overview
II - Setup
III -  Synchronous Enforcement Quickstart
IV - Asynchronous Enforcement Quickstart
V - SLA Monitor Quickstart
VI - SLA Report Quickstart

Overview 

First a quick overview and then a run through of the Run Time Governance Quickstarts.  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)
Setup

This blog assumes you have Fuse Service Works installed from jboss.org/products/fsw.html with RTGov and the quickstarts installed.

Open jboss-eap-6.1/standalone/configuration/overlord-rtgov.properties and modify collectionEnabled to be true before starting Fuse Service Works.

Start the server

./standalone.sh -c standalone-full.xml

Next we want to test and deploy the ordermgmt and ip quickstarst. First change to the jboss-eap-6.1/quickstarts/overlord/rtgov/ordermgmt folder. Go under the ip (Information Processor) folder. This quickstart provides an example configuration for information processors related to the messages sent and received by the Order Management application. These information processors are responsible for extracting information that may be required in subsequent event processing.   The information processor is defined in src/main/resources/ip.json  Deploy the Information Processing Definitions.

mvn jboss-as:deploy

Next let's change to the app folder.   This quickstart provides an example SwitchYard application, based on the Orders demo from the SwitchYard
project.  The service accepts either an order or a payment.  Orders are checked with the inventory service and if available, the order is accepted and finally sent to the logistics service to be delivered to the customer.  The RTGov hook is in the org.overlord.rtgov.quickstarts.demos.orders.interceptors.ExchangeValidator.  Now let's deploy the Switchyard application.


mvn jboss-as:deploy

To test the service, there are a set of example request SOAP messages defined in the test/main/resources/xml folder. These can be sent to the service using a SOAP client (e.g. SOAP UI), or using the following command:

    mvn exec:java -Dreq=<name> [ -Dcount=<number> ]

The 'req' property specifies the name of the request SOAP XML file. Available values are:
  • order1 - Valid order for BUTTER, from customer Fre
  • order2 - Invalid order for LAPTOP, from customer Fred, due to item not being available
  • order3 - Valid order for JAM, from customer Fred, which results in a delay causing SLA violations
  • order4 - Valid order for BUTTER, from customer Joe
  • fredpay - Fred makes a payment
The 'count' property represents the number of requests that will be sent - the default value is 1.

Let's confirm the application is running.

mvn exec:java -Dreq=order1

You should see the accepted order status.

Reply 1:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/><soap:Body><orders:submitOrderResponse xmlns:orders="urn:switchyard-quickstart-demo:orders:1.0"><orderAck><orderId>1</orderId><accepted>true</accepted><status>Order Accepted</status><customer>Fred</customer><total>125.0</total></orderAck></orders:submitOrderResponse></soap:Body></soap:Envelope>


Policy Enforcement

The examples located in the samples/policy folder, demonstrates two approaches that can be used to provide "policy enforcement". This example makes uses of the example in Switchyard
application, located in the samples/ordermgmt folder.

Synchronous Enforcement

The runtime governance infrastructure analyses the activity events generated by an executing business transaction using one or more Activity Validators. By default, Activity Validators are not invoked from within the SwitchYard environment. The specific SwitchYard applications need to be configured to include an auditor that will invoke the validation. In the Order Management quickstart, this is achieved using the class org.overlord.rtgov.quickstarts.demos.orders.auditors.ExchangeValidator. This class is derived from an abstract base class that provides most of the required functionality for converting an Exchange message into an activity event.

Change the directory to jboss-eap-6.1/quickstarts/overlord/rtgov/policy/sync and deploy the quickstart.

mvn jboss-as:deploy

To demonstrate the synchronous policy, we will send the following message twice in less than 2 seconds.  Run the test client available with the Switchyard application, by running the following command from the ${rtgov}/samples/ordermgmt/app folder:

mvn exec:java -Dreq=order1 -Dcount=2

If the two requests are received within two seconds of each other, this will result in the following response.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>org.switchyard.exception.SwitchYardException: Customer 'Fred' cannot perform more than one request every 2 seconds</faultstring>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

This quickstart example demonstrates how a policy enforcement mechanism can be provided using the Activity Validator mechanism, to immediately evaluate the business policy and (if appropriate) block the business transaction.

Asynchronous policy

This approach shows how a business policy can be implemented in an asynchronous (or out-of-band) manner, where the decision is taken after the fact, and can therefore only be used to influence future business transactions. The benefit of this approach is that the decision making process does not have to occur immediately and therefore avoids potentially impacting the performance of the business transaction. The disadvantage is that it does not permit any decision that is made to be enforced immediately.
This example will show how:
  • activity event analysis, using the Event Processor Network mechanism, can be used to implement business policies
  • results from the business policies can be cached for reference by other applications
  • platform specific interceptors can reference the results to impact the behavior of the business transaction (e.g. prevent suspended customers purchasing further items)
An mvel based policy to assess credit, implemented in an asynchronous (or out-of-band) manner. Action is taken after execution and then alters future transactions.

Change the directory to jboss-eap-6.1/quickstarts/overlord/rtgov/policy/async and deploy the quickstart.

mvn jboss-as:deploy

To demonstrate the asynchronous policy enforcement, we will send the following message to the example Switchyard application.  Run the test client available with the Switchyard application, by running the following command from the ${rtgov}/samples/ordermgmt/app folder.

mvn exec:java -Dreq=order1

This will result in the following response, indicating that the purchase was successful, as well as identifying the total cost of the purchase (i.e. 125).

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <orders:submitOrderResponse xmlns:orders="urn:switchyard-quickstart-demo:orders:1.0">
         <orderAck>
            <orderId>1</orderId>
            <accepted>true</accepted>
            <status>Order Accepted</status>
            <customer>Fred</customer>
            <total>125.0</total>
         </orderAck>
      </orders:submitOrderResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

You may recall from the overview above that if the customer’s debt exceeds the threshold of 150 then the customer would be suspended. Therefore if the same request is issued again, resulting in another total of 125, then the overall exposure regarding this customer is now 250.

If we then attempt to issue the same request a third time, this time we will receive a SOAP fault from the server. This is due to the fact that the PolicyEnforcer auditor has intercepted the request, and detected that the customer is now suspended.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>Customer 'Fred' has been suspended</faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

If we now send a "makePayment" request as follows to the same URL:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:switchyard-quickstart-demo:orders:1.0">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:makePayment>
         <payment>
            <customer>Fred</customer>
            <amount>200</amount>
         </payment>
      </urn:makePayment>
   </soapenv:Body>
</soapenv:Envelope>

This can be sent using a suitable SOAP client (e.g. SOAP-UI) or the test client in the order management app:

mvn exec:java -Dreq=fredpay

This will result in the customer being unsuspended, as it removes 200 from their current exposure (leaving 50). To confirm this, try sending the "submitOrder" request again.

This quickstart example demonstrates how a policy enforcement mechanism can be provided using a combination of the Runtime Governance infrastructure and platform specific interceptors.   This particular example uses an asynchronous approach to evaluate the business policies, only enforcing the policy based on a summary result from the decision making process. The benefit of this approach is that it can be more efficient, and reduce the performance impact on the business transaction being policed. The disadvantage is that decisions are made after the fact, so leaves a tiny window of opportunity for invalid transactions to be performed.

SLA Monitoring

This example, located in the samples/sla/monitor folder, demonstrates an approach to provide "Service Level Agreement" monitoring. This example makes uses of the example Switchyard application located in the samples/ordermgmt folder.

This example will show how:
  • activity event analysis, using the Event Processor Network mechanism, can be used to implement Service Level Agreements
    • uses the Complex Event Processing (CEP) based event processor (using Drools Fusion)
  • impending or actual SLA violations can be reported for the attention of end users, via
    • JMX notifications
    • REST service
  • to build a custom application to access the analysis results
This example shows a simple Service Level Agreement that checks whether a service response time exceeds expected levels. The CEP rule detects whether a situation of interest has occurred, and if so, creates a org.overlord.rtgov.analytics.situation.Situation object and initializes it with the appropriate description/severity information, before forwarding it back into the EPN. This results in the "Situation" object being published as a notification on the "Situations" subject.
 
Run the same command from the ${rtgov}/samples/sla/epn and ${rtgov}/samples/sla/monitor folders.

mvn jboss-as:deploy

To demonstrate a Service Level Agreement violation, we will send the following message to the example Switchyard application.

Run the test client available with the Switchyard application, by running the following command from the ${rtgov}/samples/ordermgmt/app folder:

mvn exec:java -Dreq=order3

The itemId of "JAM" causes a delay to be introduced in the service, resulting in a SLA violation being detected. This violation can be viewed using two approaches: REST Service and JMX Console.

REST Service

Using a suitable REST client such as a RESTClient in Firefox , send the following POST to: http://localhost:8080/overlord-rtgov/acm/query (using content-type of "application/json", username is admin and password).

{
    "collection" : "Situations"
}

The response will be a JSON response.

JMX Console

The Situations active collection source also generates JMX notifications that can be subscribed to using a suitable JMX management application. For example, using JConsole we can view the SLA violation.


This quickstart demonstrates how Service Level Agreements can be policed using rules defined in an Event Processor Network, and reporting to end users using the pre-configured "Situations" active collection.

The rule used in this example is simple, detecting whether the response time associated with an operation on a service exceeds a particular level. However more complex temporal rules could be defined to identify the latency between any two points in a business transaction flow.

SLA Reporting

This example, located in the samples/sla/report folder, demonstrates how to provide pluggable reports that can access information in the activity store. This particular example uses the activity information to compile a Service Level Agreement report, highlighting violations above a specified response time.

This example will show how:
  • to configure a pluggable report
  • to generate the report via a REST API
This example provides a simple Service Level Agreement report, based on identifying service invocations that exceed a specified maximum response time over an optionally specified averaged duration. If the averaged duration is not specified, then each service invocation will be checked to determine if it exceeded the maximum response time - and if so, get added to the report. If the averaged duration is specified, then when an invocation is detected (that exceeds the max response time), then all other suitable invocations within the specified duration are averaged to determine if the response time overall still exceeds the specified maximum. This is to ensure that periodic spikes are not unnecessarily reported.

It is also possible to optionally specify a business calendar, which can be used to determine the business period in which activities are of interest. If SLA violations occur outside the specified business calendar, then they are not relevant.

To demonstrate a Service Level Agreement report, we will need to create some relevant activities that can be reported upon. Send multiple instances of the following messages to the example Switchyard application

Run the test client available with the Switchyard application, by running the following commands from the ${rtgov}/samples/ordermgmt/app folder:


mvn exec:java -Dreq=order1
mvn exec:java -Dreq=order3

To generate a report, we will send a GET request to the following URL using the Basic Authentication username admin and password:

http://localhost:8080/overlord-rtgov/report/generate?report=SLAReport
  &startDay=1&startMonth=1&startYear=2013&endDay=31&endMonth=12
  &endYear=2013&maxResponseTime=400&averagedDuration=450

This will return a report (with name SLAReport) containing violations that occur within the year 2013. If you wish to experiment with the default business calendar, then append "&calendar=Default" to the end of the URL. This will also identify what percentage of the business working period has been impacted by the SLA violations.

This quickstart demonstrates how report definitions can be deployed to the Runtime Governance infrastructure and invoked to generate a report instance via a REST service.

Thursday, February 27, 2014

Kenneth Peeples, Red Hat Evangelist, at SOA Summit


SOA Summit - Online Conference

How Next-Gen SOA Delivers Success for API, Cloud & Mobile

Date:
Thursday, February 27, 2014 (1pm ET / 10am PT) [Replay available]

Speakers:
Oracle, Red Hat, Ping Identity, SOA Software, Axway

Download Slides & White Papers Now! - Register Here:
https://www.idevnews.com/registration/?event_id=290&code=11206

Speakers & Presentations

[Oracle]
Simplifying Cloud and On-Premises Integration
* Bruce Tierney - Director for Oracle SOA Suite

[Ping Identity]
Harness The Power of Federated Business
* Loren Russon - VP of Product Management & Design

[SOA Software]
Are APIs and SOA Converging?
* Sachin Agarwal - VP, Product Marketing and Strategy

[Axway]
API Management: Architecture Best Practices
* Mark O'Neill - VP, Innovation

[Red Hat]
Better Business Results with Open Source Integration
* Kenny Peeples - JBoss Technology Evangelist

White Papers & Data Sheets

[Axway]

White Papers:
* The 3 API Management Platforms
* The 5 Phases of API Management

Datasheet:
* Axway API Gateway

[Oracle]

White Papers:
* Avoiding the Accidental SOA, Cloud Architecture
* Simplifying Cloud Integration
* Next Generation Service Integration Platform

Datasheet:
* Oracle SOA Suite

[Ping Identity]

White Papers:
* Extending Security to the Cloud with Adaptive Federation
* Secure Internet Single Sign-On 101

Datasheet:
* PingAccess: Next-Gen Identity Gateway

[RED HAT]

Datasheets:
* JBoss A-MQ
* JBoss Data Virtualization

Tech Overview:
* JBoss Fuse Service Works


[SOA SOFTWARE]

White Papers:
* Building Successful APIs - Enterprise API Platform
* Accelerating API Adoption through Lifecycle Management

Datasheets:
* API Management - Transform Business Potential
* Lifecycle Manager for APIs

Register Here for SOA Summit - an Online Conference

https://www.idevnews.com/registration/?event_id=290&code=11206

DevNation Agenda now Posted!

I am excited about DevNation being co-located with Red Hat Summit.  The agenda has been posted.  DevNation includes CamelOne, JUDCon and Red Hat Connect/Developer Exchange.  I am speaking with Jack Britton on iPaaS (Integration Platform as a Service) this year.  Come Join us to learn about Fuse on OpenShift.

AN OPEN SOURCE CONFERENCE, BY AND FOR DEVELOPERS ACROSS THE GLOBE
April 13 - 17, 2014 | San Francisco, CA | USA
Announcing DevNation, an open source, polyglot conference for application developers and maintainers.   Co-located with Red Hat Summit, our premiere event will offer sessions, labs, hackfests, and panels geared for those who build with open source.  Registration is now open!

Agenda: http://www.devnation.org/#agendawww
My session at DevNation is Wednesday April 16th
Using Red Hat JBoss Fuse on OpenShift - Jack Britton, Kenny Peeples (Room 208)
OpenShift Online automates the provisioning, management and scaling of applications so that you can focus on development and creativity.  The newly created JBoss Fuse 6.1 Cartridge allows using Fuse and Fuse Fabric in OpenShift Online Public Cloud.  JBoss Fuse provides a full-featured, easy-to-use and intuitive framework for integration with extensive connectivity options to external applications. Join this session to see how to use Fuse and Fuse Fabric in OpenShift online.

Monday, February 24, 2014

Difference between Docker and Vagrant



http://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-io-for-creating-an-isolated-envinronment

I thought this was an excellent description of the difference between Docker and Vagrant from http://stackoverflow.com/users/8325/mitchell

From Mitchell--
Disclaimer: I wrote Vagrant! But because I wrote Vagrant, I spend most of my time living in the DevOps world includes software like Docker. I work with a lot of companies using Vagrant and many use Docker, and I see how the two interplay.
Before I talk too much, a direct answer: in your specific scenario (yourself working alone, working on Linux, using Docker in production), you can stick with Docker alone and simplify things. In many other scenarios (I discuss further), it isn't so easy.
It isn't correct to directly compare Vagrant to Docker. In some scenarios, they do overlap, and in the vast majority, they don't. Actually, the more apt comparison would be Vagrant versus something like Boot2Docker (minimal OS that can run Docker). Vagrant is a level above Docker in terms of abstractions, so it isn't a fair comparison in most cases.
Vagrant launches things to run apps/services for the purpose of development. This can be on VirtualBox, VMware. It can be remote like AWS, OpenStack. Within those, if you use containers, Vagrant doesn't care, and embraces that: it can automatically install, pull down, build, and run Docker containers, for example. Vagrant exposes a single user experience to do this.
Docker specifically runs Docker containers. If you're comparing directly to Vagrant: it is specifically a more specific (can only run Docker containers), less flexible (requires Linux or Linux host somewhere) solution. Of course if you're talking about production or CI, there is no comparison to Vagrant! Vagrant doesn't live in these environments, and so Docker should be used.
If your organization runs only Docker containers for all their projects and only has developers running on Linux, then okay, Docker could definitely work for you!
Otherwise, I don't see a benefit to attempting to use Docker alone, since you lose a lot of what Vagrant has to offer, which have real business/productivity benefits:
  • Vagrant can launch VirtualBox, VMware, AWS, OpenStack, etc. machines. It doesn't matter what you need, Vagrant can launch it. If you are using Docker, Vagrant can install Docker on any of these so you can use them for that purpose.
  • Vagrant is a single workflow for all your projects. Or to put another way, it is just one thing people have to learn to run a project whether it is in a Docker container or not. If, for example, in the future, a competitor arises to compete directly with Docker, Vagrant will be able to run that too.
  • Vagrant works on Windows (back to XP), Mac (back to 10.5), and Linux (back to kernel 2.6). In all three cases, the workflow is the same. If you use Docker, Vagrant can launch a machine (VM or remote) that can run Docker on all three of these systems.
  • Vagrant knows how to configure some advanced or non-trivial things like networking and syncing folders. For example: Vagrant knows how to attach a static IP to a machine or forward ports, and the configuration is the same no matter what system you use (VirtualBox, VMware, etc.) For synced folders, Vagrant provides multiple mechanisms to get your local files over to the remote machine (VirtualBox shared folders, NFS, rsync, Samba [plugin], etc.). If you're using Docker, even Docker with a VM without Vagrant, you would have to manually do this or they would have to reinvent Vagrant in this case.
To address specific counter arguments that I've heard in favor of using Docker instead of Vagrant:
  • "It is less moving parts" - Yes, it can be, if you use Docker exclusively for every project. Even then, it is sacrificing flexibility for Docker lock-in. If you ever decide to not use Docker for any project, past, present, or future, then you'll have more moving parts. If you had used Vagrant, you have that one moving part that supports the rest.
  • "It is faster!" - Once you have the host that can run Linux containers, Docker is definitely faster at running a container than any virtual machine would be to launch. But launching a virtual machine (or remote machine) is a one-time cost. Over the course of the day, most Vagrant users never actually destroy their VM. It is a strange optimization for development environments. In production, where Docker really shines, I understand the need to quickly spin up/down containers.
I hope now its clear to see that it is very difficult, and I believe not correct, to compare Docker to Vagrant. For dev environments, Vagrant is more abstract, more general. Docker (and the various ways you can make it behave like Vagrant) is a specific use case of Vagrant, ignoring everything else Vagrant has to offer.
In conclusion: in highly specific use cases, Docker is certainly a possible replacement for Vagrant. In most use cases, it is not. Vagrant doesn't hinder your usage of Docker; it actually does what it can to make that experience smoother. If you find this isn't true, I'm happy to take suggestions to improve things, since a goal of Vagrant is to work equally well with any system.
Hope this clears things up!

Devnexus in Atlanta

I am at Devnexus today and tomorrow in Atlanta, GA at the Cobb Galleria.  Red Hat is a Silver Sponsor this year.   I am at the booth spreading Check out the site at: http://www.devnexus.com/s/index

We have 2 Red Hat speakers at Devnexus:

Steve Pousty, Developer Evangelist - Deploy and Develop your Application in a PaaS: 0 to Awesome in 3 minutes
In this session, we give an introduction to Platform as a Service (aka awesome-sauce for developers) with OpenShift as an example. You will get a chance to see why PaaS is one of the most important trends to affect the application development process. After a few slides on PaaS, we will spend the rest of the time working with code! First we will bring up Tomcat 7 and MySQL with one command. Then you to get your own JEE6 with JBoss EAP code up and running. We will show you how easy it is to bring in dependencies and deploy your code. We will also demonstrate how to connect your code to a MongoDB back-end data store. We will also have you merge in some of the Github quickstarts we have assembled - including JEE6 with Mongo Spatial. There are two goals of this session:
1) To leave knowing why you should start using a PaaS for your development work
2) Leave with first hand knowledge on how to run your Java code in the cloud for free!
PRESENTATION: http://talks.thesteve0.com/devnexus
Grant Shipley, Lead Evangelist for OpenShift - Full Stack JavaScript
Grant Shipley will demonstrate how to develop iPhone and Android apps with MongoDB backends for the cloud. Let’s skip having to learn three different languages and jumpstart the development process using what you already know. We will start with developing a native mobile application using only javascript. Next, we’ll deploy our app to the cloud using node.js and explore a few tips and tricks for managing the MongoDB backend.

Friday, February 21, 2014

Simplified Design Time Governance and Fuse Service Works


Simplified Workshop Series
Design 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 Design 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

NOTE: Screen shots and more step by step for creating/running the demo from scratch are in section 2.

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

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. You will notice in the installation script the components that are being installed. 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 of the fsw-simple-demo for the link for the production server. This allows for the demo to be installed on the server after moving to the prod task in the DTGov workflow.

ln -sv /tmp/prod/jbossas7/standalone/deployments /home/kpeeples/demos/fsw-simple-demo/installed/fsw/jboss-eap-6.1/standalone/deployments

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 may take a little bit of time to compile and deploy the default DTGov workflow, compile and deploy the switchyard demo to dtgov/s-ramp and create the link for the production server. The build should be created successfully.

Step 8: The demo is now setup. First browse to http://localhost:8080/dtgov-ui and sign on with fswAdmin and redhat1!

Step 9: View Deployments. Click on deployments under deployment life cycle. You should see the switchyard-quickstart-demo-orders-1.1.1-p5-redhat-1.war deployment. Click on the deployment to see the deployment history, deployment contents and browse in S-RAMP options.

Step 10: Move the deployment through the workflow. Click on the DTGov dashboard on the breadcrumbs. Click on task inbox. Select the second TestDev and check the artifact which should be the switchyard war deployment. The first is the source jar. Notice it indicates deployed to target /tmp/dev. The dtgov properties file indicates the deployment targets which default to the file copy. We setup a link in tmp to the deployment folder for the server for testing so that once the task hits prod then the war will be deployed to the server. Click Claim, Start, Pass, Complete. Then click on Task inbox. You will now see Test QA. Click on the task and follow the same process to move the depoyment to stage. Do the same for the Test Stage task. Once in Test Prod the war has been deployed to the server.

Step 11: Test the Orders Demo once deployed to Production. Now that the deployment is in Prod we can test the application. Browse to the Order Service at http://localhost:8080/demo-orders/OrderService?wsdl. Browse to the application screen http://localhost:8080/switchyard-quickstart-demo-orders-1.1.1-p5-redhat-1/home.jsf enter PS-19838-XY for the order ID and BUTTER for the Item Id. Click Create to have the order accepted.

This is a quick demo of an artifact going through the DTGov workflow. More detail of configuration and step by step are below.

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

Technology Overview

Step by Step

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

Simplified Data Virtualization Install and Template

I created a template to easily install and start Data Virtualization through the automated installer.  This is done in 5 easy steps.  I structured the demo in such a way that you can add pre-install, post-install steps so that source can be compiled and deployed.  Additional collateral can also be included such as a simulation, video, etc.  This helps a PoC, PoT or quick demo to be created easily.  Give it a try and please provide feedback to improve it.  Keep your eyes out for more Simplified Demos.

Simplified Workshop Series
Automated Installation Demo Template
in Data Virtualization

Version 1.0

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 the Data Virtualization Installation. 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

NOTE: Screen shots and more step by step for creating/running the demo from scratch are in section 2.

Step 1: Clone the repository from https://github.com/kpeeples/simplified-dv-template.git

Step 2: Download Data Virtualization from http://www.jboss.org/products/datavirt.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/dv directory. Make sure to leave the installed/dv directory. The script performs the automated install of Data Virtualization. 

<installpath>/home/kpeeples/demos/dv-install-script-demo/installed/dv</installpath>

Step 5: Run the install-run.sh script to install DV and start the server

Browse to http://localhost:8080/dashboard for the Data Virtualization Dashboard and use user/user as the credentials that were installed as default.  This is a quick demo of running the automated DV installer. You can use this as a template to build your demos. More detail of configuration and step by step are below.

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

Technology Overview

Step by Step

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

Simplified Fuse Service Works Install and Template

I created a template to easily install and start Fuse Service Works through the automated installer.  This is done in 5 easy steps.  I structured the demo in such a way that you can add pre-install, post-install steps so that source can be compiled and deployed.  Additional collateral can also be included such as a simulation, video, etc.  This helps a PoC, PoT or quick demo to be created easily.  Give it a try and please provide feedback to improve it.  Keep your eyes out for more Simplified Demos.

Simplified Workshop Series
Automated Installation Demo Template
in Fuse Service Works

Version 1.0

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 the Fuse Service works Installation. 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

NOTE: Screen shots and more step by step for creating/running the demo from scratch are in section 2.


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. You will notice in the installation script the components that are being installed. Also you will notice the variables file defines the passwords for Goverrnance, SAML keystore and vault keystore passwords. 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: Run the install-run.sh script to install FSW and start the server

Browse to http://localhost:8080 for the EAP 6 Welcome screen.  This is a quick demo of running the automated FSW installer. You can use this as a template to build your demos. More detail of configuration and step by step are below.

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

Technology Overview

Step by Step

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

Monday, February 17, 2014

JBoss BPM Suite Webinar - Business rules, events, and processes. Oh, my!

Eric Schabell will be hosting a webinar on the topic of rules and process integration based on Red Hat JBoss BPM Suite 6 on February 20th, 2014 at 11:00 EST.


Go to his blog to view the abstract and find the registration link to join. 


http://www.schabell.org/2014/02/redhat-jboss-bpmsuite-webinar-rules-events-processes-ohmy.html





Tuesday, February 11, 2014

Data Virtualization v6 is now GA!

Red Hat JBoss Data Virtualization - VERSION 6.0 GENERAL AVAILABILITY

Turn siloed, fragmented data into actionable information at your business speed.

We are announcing the general availability and public launch of the Red Hat JBoss Data Virtualization v6 (formerly known as Red Hat JBoss Enterprise Data Services Platform).
The volume, velocity and variety of data in the enterprises are on the rise.  The need to transform this data into actionable information is a top business priority.  However, many organizations struggle to gain operational and anlytical insights due to the inability to effectively utilize data trapped in disparate applications and technology silos.
JBoss Data Virtualization is complete data provisioning, federation, integration and management solution that enables organizations to gain actionable and unified information.  Red Hat JBoss Data Virtualization enables agile data utilization in 3 easy steps:
  1. Connect: Access data from multiple, heterogeneous data sources.
  2. Compose: Easily create reusable, business-friendly logical data models and views by combining and transforming data.
  3. Consume: Make unified data easily consumable through open standard interfaces.
DOWNLOAD DATA VIRTUALIZATION v6 AND TRY IT OUT FOR FREE!


Wednesday, February 5, 2014

Fuse Service Works Simple Demo v1

This demonstration will give you a quick example of Fuse Service Works v6.  The Orders v1 example includes a Switchyard Application, using Design Time Governance and using Run Time Governance.


1. Download the Fuse Service Works Installer from http://www.jboss.org/products/fsw.html

2. Run the Fuse Service Works Installer and start the standalone server.

3. Install the DTGov workflow from the dtgov-data.  Use S-RAMP username and password from the install (fswAdmin/redhat1!).

mvn clean deploy

4. sign onto DTGov - http://localhost:8080/dtgov-ui/ in the S-RAMP repository notice the DTGov workflow dtgov-workflows-1.0.1.Final-redhat-6.jar


5. Run 

mvn clean install

for the orders demo in quickstarts/switchyard/demos/orders.  The build should show success and a order SOAP test should have been successful.

6. copy war to deployments from target/switchyard-quickstart-demo-orders.war

7. verify WSDL - http://localhost:8080/demo-orders/OrderService?wsdl and submit order with SOAP or run mvn exec:java to send order

8. verify JSF - http://localhost:8080/switchyard-quickstart-demo-orders-1.1.1-p5-redhat-1/home.jsf and submit order



9. View the switchyard application in JBDS


10. Check the DTGov Workflow in JBDS in the dtgov-workflows under src/main/resources/SRAPMPackage view overlord.demo.SimpleReleaseProcess.bpmn



11. Deploy to DTGov to view the deployment in S-RAMP and follow the workflow (NOTE: this will go through the defined workflow but the /tmp/[environment] directories would have to be setup to deployment folders for jboss servers to deploy to an environment). Replace the pom.xml with

  <?xml version="1.0" encoding="UTF-8"?>
<!--
- Copyright 2013 Red Hat Inc. and/or its affiliates and other contributors.
-
- Licensed under the Apache License, Version 2.0 (the "License")
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.switchyard.quickstarts</groupId>
        <artifactId>switchyard-quickstart-parent</artifactId>
        <version>1.1.1-p5-redhat-1</version>
        <relativePath>../../pom.xml</relativePath>
    </parent>
    <groupId>org.switchyard.quickstarts.demos</groupId>
    <artifactId>switchyard-quickstart-demo-orders</artifactId>
    <packaging>war</packaging>
    <name>Quickstart Demo : Orders</name>
   
  <properties>
    <switchyard.version>1.1.1-p5-redhat-1</switchyard.version>
    <version.org.overlord.sramp-s-ramp-wagon>0.3.1.Final-redhat-7</version.org.overlord.sramp-s-ramp-wagon>
  </properties>
  
    <dependencies>
        <dependency>
            <groupId>org.switchyard</groupId>
            <artifactId>switchyard-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard</groupId>
            <artifactId>switchyard-plugin</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard.components</groupId>
            <artifactId>switchyard-component-bean</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard.components</groupId>
            <artifactId>switchyard-component-soap</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard</groupId>
            <artifactId>switchyard-test</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard.components</groupId>
            <artifactId>switchyard-component-test-mixin-cdi</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.switchyard.components</groupId>
            <artifactId>switchyard-component-test-mixin-http</artifactId>
            <scope>test</scope>
        </dependency>
        <!-- Import the CDI API, we use provided scope as the API is included in JBoss AS 7 -->
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <!-- Import the Common Annotations API (JSR-250), we use provided scope as the API is included in JBoss AS 7 -->
        <dependency>
            <groupId>org.jboss.spec.javax.annotation</groupId>
            <artifactId>jboss-annotations-api_1.1_spec</artifactId>
            <scope>provided</scope>
        </dependency>
        <!-- Import the JSF API, we use provided scope as the API is included in JBoss AS 7 -->
        <dependency>
            <groupId>org.jboss.spec.javax.faces</groupId>
            <artifactId>jboss-jsf-api_2.1_spec</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>commons-httpclient</groupId>
            <artifactId>commons-httpclient</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <finalName>${project.artifactId}</finalName>
       <extensions>
      <extension>
        <groupId>org.overlord.sramp</groupId>
        <artifactId>s-ramp-wagon</artifactId>
        <version>${version.org.overlord.sramp-s-ramp-wagon}</version>
      </extension>
    </extensions>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <debug>true</debug>
                    <showWarnings>true</showWarnings>
                    <showDeprecation>true</showDeprecation>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.switchyard</groupId>
                <artifactId>switchyard-plugin</artifactId>
                <configuration>
                    <scannerClassNames>
                <param>org.switchyard.component.bean.config.model.BeanSwitchYardScanner</param>
                        <param>org.switchyard.transform.config.model.TransformSwitchYardScanner</param>
                    </scannerClassNames>
                    <!-- Output to war directory -->
                    <outputFile>${project.build.directory}/${project.build.finalName}/WEB-INF/switchyard.xml</outputFile>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>configure</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <!-- Java EE 6 doesn't require web.xml, Maven needs to catch up! -->
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <configuration>
                    <mainClass>org.switchyard.quickstarts.demos.orders.OrdersClient</mainClass>
                </configuration>
            </plugin>
        </plugins>
    </build>
   
  <profiles>   
    <profile>
      <id>demo</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <configuration>
              <skip>false</skip>
            </configuration>
          </plugin>
        </plugins>
      </build>
      <distributionManagement>
        <repository>
          <id>local-sramp-repo</id>
          <name>S-RAMP Releases Repository</name>
          <url>sramp://localhost:8080/s-ramp-server/?artifactType=SwitchYardApplication</url>
        </repository>
        <snapshotRepository>
          <id>local-sramp-repo-snapshots</id>
          <name>S-RAMP Snapshots Repository</name>
          <url>sramp://localhost:8080/s-ramp-server/?artifactType=SwitchYardApplication</url>
        </snapshotRepository>
      </distributionManagement>
    </profile>
  </profiles>
  
<!-- Modified by POM Artifact-Version Manipulator version 1.3.6-redhat-4-soa (20c6737) -->
</project>

12. deploy to DTGov NOTE: enter S-RAMP user/pass if prompted fswAdmin/redhat1!

mvn -Pdemo -DskipTests=true -Dsramp.auth.username=fswAdmin -Dsramp.auth.password=redhat1! clean deploy

it should indicate build success and server console should indicate workflow started.

13. On the task inbox, Claim, Start and Pass the Dev task which should move the deployment to QA



14. RTGov: to be added.