DTGov Release: Version 1.2.0.Final

We are very pleased to announce the release of version 1.2.0.Final of Overlord DTGov.  This latest version contains a number of bug fixes along with support for Tomcat 7!

Please download it and give it a try!  We welcome all ideas and feedback.

S-RAMP Release: Version 0.4.0.Final

We are happy to announce the release of version 0.4.0.Final of the Overlord S-RAMP project.  This new version contains a number of a bug fixes, but most importantly we now have support for all of the following runtime platforms:

• JBoss EAP 6.1
• JBoss Fuse 6.1
• Tomcat 7

Additionally, the S-RAMP User Interface now includes an Ontology Manager, which is long overdue.  It's pretty hard to manage ontologies without an editor, due to the format (RDF + OWL Lite) of the file.  To help with that, version 0.4.0.Final includes a user interface that will allow users to create, upload, and edit their ontologies.

It is of course recommended that users finalize (as much as possible) their ontologies prior to using them to classify artifacts.  Once an ontology is heavily used to classify artifacts, it becomes much more difficult to make significant (read non-addition) changes to it!

S-RAMP specification 1.0 is public!

We are proud to announce that OASIS just officially published the S-RAMP 1.0 specification:

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=s-ramp

The Overlord project had two members on the TC (Eric and yours truly), while Randall Hauch joined from the ModeShape project. The Overlord S-RAMP implementation is an Apache 2.0 licensed Open Source implementation of the specification, and it has already found adoption as the Enterprise repository of choice; one repository for all enterprise artifacts. You can download the complete spec bundle from http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/cs01/s-ramp-v1.0-cs01.zip. For our implementation see: https://www.jboss.org/overlord.

Cheers!!

--Kurt

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


 

SOA Governance Projects and Organizational Roles

In large organizations building and maintaining services is not a one man job, instead it is a process that touches many people in the organization. Figure 1 is a copy of figure 5.6 on page 95 of the 'SOA Governance' book by Thomas Erl et al.

Figure 1. Common associations of organizational roles with different SOA project stages.

With this many people and roles involved, how to you manage a project like this? Especially since in a large organization you will have many of these project running simultaneously. We would have loved to implement a full project workflow based on the figure 1 process, but two things are currently standing in our way: time and real world input. Who is going to pick up the challenge?

To get you started we created a 'Simplied Project Lifecycle Workflow' demo that implements just 3 boxes; Requirements gathering, Service Design and Service Implementation, with one role responsible for each stage, which are a Business Analyst, SOA Architect and SOA Developer. Each role can be fulfilled by more then one person. In the demo we assigned all three roles to the 'admin' user so we don't have to log in and out as different users all time. The demo uses the workflow shown in Figure 2. Each column represents one of the phases. The first phase being Business Analysis. The hope is this demo provides you with the building blocks to create the real world implementation we talked about earlier.

Figure 2. Simplified Project Lifecycle Workflow.

Some benefits of using this workflow are:

• Helps your organization with adoption of SOA by following proven processes. It is clear who is responsible for approval.
• Provides insight in where your projects are.
• Helps your organization work together in different teams.
• Audit features allow full history tracking.
• Released artifacts are in the repository, the artifact is automatically in escrow this way, and documentation and sources are stored along side the binaries all in one place.

Some optional benefits:

• It is possible to send a BPMN event at the end of the workflow (or from anywhere else), which can kick off a release workflow to automate deployment. Though one could also write a governance query looking for a service implementation artifact with classification #ImplPass.
• Easy integration with other systems (think bug track systems, or time management systems)

If you want to follow along with the demo you should

1. Have DTGov running; see http://jboss-overlord.blogspot.com/2013/11/bleeding-edge-governance-getting-started.html.

2. Install the Eclipse BPMN2 Modeler into your Eclipse IDE, or you can try the early access JBoss Developer Studio.

Enjoy

Customize Managed Deployments Workflow

DTGov ships with a number of BPMN2 based processes that you may want to update so they fit your business processes. In this demo we will update the 'Manage Deployments' workflow. It is recommended you go over the Managed Deployments usinf DTGov demo if you haven't already done so.

If you want to follow along with the demo you should

1. Have DTGov running; see http://jboss-overlord.blogspot.com/2013/11/bleeding-edge-governance-getting-started.html.

2. Install the Eclipse BPMN2 Modeler into your Eclipse IDE, or you can try the early access JBoss Developer Studio.

Managed Deployments using DTGov

DTGov ships with a workflow to perform deployments of released artifacts to the dev, qa, stage and prod runtime. Some benefits of using this workflow are:

• Releases artifacts are in the repository before they go to a runtime, the artifact is automatically in escrow this way, and the sources are stored along side the binaries.
• Automated deployments (using file copy, RHQ RestAPI, or JBoss Domain RestAPI).
• Email notifications.
• Sign off using Human Tasks in the workflow. Users and roles can be tailored to fit your organization. The sign off enhances the visibility of the where an artifact is in the deployment lifecycle.
• Audit features allow full history tracking of the artifacts.
• One repository for everything; so things can be found easily. This answers the "Where is my stuff" question. The XPath like query language of S-RAMP can used for searching.

If you want to follow along with the demo you should

1. Have DTGov running; see http://jboss-overlord.blogspot.com/2013/11/bleeding-edge-governance-getting-started.html.

2. Install the Eclipse BPMN2 Modeler into your Eclipse IDE, or you can try the early access JBoss Developer Studio.

Enjoy