DTGov release workflow using 'Domain Deployment'

Introduction

DTGov ships with workflows which can help you with deploying releases to runtime environments. At the moment the deployment service supports 4 ways to deploy an application:

• copy, file copy to a directory
• rhq, using the RHQ REST API to deploy an application to a resource managed by RHQ.
• as_cli, using the JBoss AS Client to deploy to a JBoss Domain.
• mvn, deploy the application to a maven repository.

In this blog post we demonstrate how to deploy an application using the JBoss AS Client.

DTGov configuration

To use the JBoss AS Client we need to configure a target in the dtgov.properties file referencing the as_cli protocol. For example to deploy to a domain on server 192.168.1.31 we'd use

governance.targets=   qa|http://www.jboss.org/overlord/deployment-status.owl#InQa|as_cli|admin::admin123!::192.168.1.31::9999

Where admin/admin123! are the credentials to log into the remote domain.

JBoss Domain Setup

The DTGov deployment service can deploy to a JBoss Domain. Look here if you need more information on how set one up.

1. Open the domain/configuration/domain.xml file for editing, and make sure you have a 'qa' group, which is name of the target mentioned above. You should end up with something like
    <server-groups>
        <server-group name="qa" profile="full"> 
2. Open the domain/configuration/host.xml file for editing, and assign servers to this group. In this example we add 'server-one' to the 'qa' domain group. You want to add more then one server.
    <servers>
        <server name="server-one" group="qa">
 
3. Now you can start your domain using something like
   bin/domain.sh -b 192.168.1.31 -bmanagement=192.168.1.31

You can test your credentials (admin/admin123!) by logging into the management console, which in this case would run on http://192.168.1.31:9990, and/or using the client: bin/jboss-cli.sh. You may have to add an admin user using the bin/add-user.sh script. Also verify that you see the 'qa' domain group in the management console.

Deployment of your application

At this point the release workflow is ready to deploy an application to the 'qa' domain group. Once you've approved the 'dev' task, you should see the dtgov deployment REST API logging on the dtgov server:

Calling POST TO: http://localhost:8080/dtgov/rest/deploy/qa/0e7a209c-f298-433c-b9a6-3d40d4ac2f5c



This means that the dtgov is invoked the jboss client on the 'qa' domain to deploy the application, where '0e7a209c-f298-433c-b9a6-3d40d4ac2f5c' is the UUID of the application artifact that will get deployed. If something is wrong at this point you can use your favorite REST client tool and perform POST's to this url until things work. 

 Figure 1. Screenshot of the management console after the requirements jar was deployed (probably a bad choice to deploy the requirements!!)

 I hope this worked for you too, and that you picked a better artifact then I did as deploying the requirements from the dtgov-demos-project doesn't really make a whole lot of sense! Well other then demonstrating that it works :).

Cheers,

---Kurt


 

S-RAMP v1.0 Specification submitted into the OASIS Review Process

[announcement]
Today the S-RAMP v1.0 specification was submitted for review by OASIS. You can download your own copy of the two spec documents from a public link on from OASIS. Randall Hauch, Eric Wittmann and yours truly worked on both the specification as well as on an implementation of the spec at the same time.

[plug for our project]
The open source S-RAMP implementation is under developement under the umbrella of the Overlord project and ships under the Apache v2 License. We hope that it will become the S-RAMP Reference Implementation (S-RAMP-RI). You can download the S-RAMP implementation from our downloads page. The source code is hosted on Github. Our implementation uses RESTEasy for the Atom based REST APIs and on the back-end it uses ModeShape (JCR) and Infinispan (persistence) for massive performance and scalability. Well that's what the ModeShape guys tell us anyway, someone should test it out! We are currently about 75% complete and -to speak in building a bridge terminology- we are 'out of the water  now': The foundations are finished and everything we are doing now is in full view. If you are interested in contributing please let us know, there is still lots to be done.

[your chance to get famous]
One area we are really looking for help is for someone who can help us develop some best practice governance scenarios: for example project workflows, with supporting document templates for approval etc.

Cheers,

--Kurt

Release S-RAMP-0.1.1 adds Governance Workflow

I'm proud to announce release 0.1.1 of the S-RAMP project. The S-RAMP project implements the OASIS SOA Repository Artifact Model and Protocol. Two of the developers (Eric Wittmann and yours truly) are members of the Technical Committee.  The spec is nearly complete and it will be submitted to OASIS for review in a matter of one to two weeks.

On the S-RAMP project we have implemented about 75% of the spec and we've layered governance features on top of that. The objective is to have a functional set of features before implementing features we do not need right away. Things are working now, but may not always be 100% compliant (think about things like error handling etc).

Some major features we have working now

• Working S-RAMP repo - sitting on top of JCR (ModeShape by default) and using RESTEasy for the S-RAMP Atom binding.
  
• Maven integration, so developers can release artifacts into the S-RAMP repository or they can reference artifacts in their builds as dependencies.
• S-RAMP ATOM Binding, anything that can consume a atom feed can interact with the repo.
• S-RAMP GWT based browser
• S-RAMP cmdline shell, so you interact by typing, or you can script interactions
• Governance Workflow - Integration with a BPMN2 engine (jBPM by default)
• custom REST-Based BPMN2 services to deploy artifacts from S-RAMP to runtime
• customer notification service (email + templates)
• custom S-RAMP interaction service to classify artifacts as they move through their life cycle.
•  Advanced XPATH-2 query capability into the S-RAMP repository.

Some things we are working on at the moment

• Security - we need SSO across the board. We are trying to use Picketlink IDM & OAuth, sticking point is that RESTEasy 3 supports it but SOA-P 6 wants to stick with 2.3.*. Maybe we can get Bill to back port.
  
• Governance console to manage workflow configuration and to embed Task Forms (right now we direct you to the jbpm-console)
• Add Documentation - We developed a kick ass process to push Asciidoc github wiki to docbook into the regular doc stream (https://github.com/Governance/s-ramp/wiki/GuideReadme). Now all we need is more content and demos.
  
• Implement all features an end2end for some interesting Switchyard use cases.
  
• Add more out of the box best practices governance workflow.
• RHQ and JBossAS7 domain model deployment integrations.
• Support for SLA and policies in general.
• Auditing of what goes in and out of the repo.

If you are interested check out the workflow demo, download the distro and come contribute so you can be crowned and become one of Overlords.

Cheers,

--Kurt

S-RAMP-0.1.1 Governance Workflow Demo

With the recent S-RAMP-0.1.1 release we added Governance Workflow capability to the S-RAMP repository. This release can be download from http://www.jboss.org/overlord/downloads/sramp. In the demo below we show how a mvn deploy of a Switchyard application to the S-RAMP repository kicks of a Simple Release Process as shown in Figure 1.

Fig 1. Simple Release Process, click to enlarge

This BPMN2 process runs on jBPM (default BPMN Engine) and calls deployment and notification services that ship with the S-RAMP Governance application. For more details on the SOA Governance configuration see the SOA Governance Wiki.

Fig 2. Click to start the demo.