Testable architectures

Steve has posted an interesting article on his recent use of the testable architectures approach he's been discussing for several years. It's obviously closely related to what we're trying to achieve together on Process Governance, so take a look.

Developing BPM console plugins

I committed a first draft of a plugin mechanism that allows composition of BPM console features more easily. Initially we'd been looking for a convenient way to deal with the differences in jbpm3 and jbpm4, but now it has proven to be good solution for console mash-ups in general. For instance future integration or composition with Guvnor.

The idea is simple: While providing common elements like authentication, configuration and look and feel, the console needs to be assembled out of common and proprietary features. Not everything we build into it, works across BPM runtimes even though it's our foremost goal.

Fortunately GWT already ships with an extension mechanism called "Deferred Binding". It allows you to replace or generate components at build time. Build time in our case means maven, and the easiest way to customize a maven build is by providing different sets of dependencies. Unlike the regular GWT compilation which is restricted to a subset of the JDK, the deferred binding has access to the full API, including classloading. It actually happens before the GWT compiler kicks in.

Great. That means our plugin loader can build upon the availability of plugins in the classloading scope.
Maven already provides the dependency management, then we are set.

Let's look at an example. Trunk contains a plugin-example that should get you going. Take a look at the pom.xml dependencies first. Any plugin has a dependency on the console plugin API:

<dependency>
     <groupId>org.jbpm.jbpm3</groupId>
     <artifactId>gwt-console-plugin</artifactId>
     <version>1.0.0-SNAPSHOT</version>
</dependency>

It ships with a few concepts that we need to clarify before we can move on. The console acts as a Workspace. A Workspace contains Editors, which are composed of different Views. Developing a plugin actually means implementing an Editor and providing a workspace configuration (workspace.cfg).

When building the console, the deferred binding generates and links the code that is required to associate all Editors in a workspace configuration with the console framework. Sounds terrible, but a plugin developer only needs to know a few interfaces and create a workspace configuration.

public abstract class Editor extends Panel
{
 protected ApplicationContext appContext;

 public abstract String getEditorId();
 public abstract String getTitle();
 public abstract String getIconCSS();
 public abstract MenuSection provideMenuSection();
 
 [...]
}

An Editor is your plugin root implementation. It needs to be uniquely identified (editorId) and contribute to the main menu (MenuSection). It can contain one or more views:

public abstract class View extends Panel
{
  protected ApplicationContext appContext;

  public abstract String getViewId();
  public abstract String getIconCSS();
}

The editor and it's views share an ApplicationContext that gives you access to common things like authentication, configuration, logging, etc.

public interface ApplicationContext
{
  [...]
  void displayMessage(String message, boolean isError);
  Authentication getAuthentication();
}

Besides that, you can leverage anything GWT provides for implementing your plugin.
I think you get the idea. Take a look at the plugin example (Google Maps integration), especially the editor implementation.
In order to enable this workspace configuration you need to build with "mvn -Pplugin-example" switch.

Discussion
Please join us in the overlord forum for further discussions.

Typing a BPM system

While working on the GWT console I came across two requirements that I couldn’t realize easily within the console: process variables inspection and task management forms. Both solutions should allow modification of data associated with a process through web based forms.

In order to build such a form and to process the data submitted through it you’d need some kind of data type description associated with the process definition. Even if you don’t intend to build those forms at runtime, but instead chose a design time approach you would still be left with the question of validation.

But not only that. The tooling that helps you build the task forms at design time would need some data type description as well. How would know what types to chose for UI elements and the keys to access it?

This leads to an additional requirement: Once you got the data type description and you successfully modeled your form, how do access the data at runtime? Somehow the process data needs to extracted and displayed through the forms.

One thing you may realize at this point is that a simple example like the task management forms already require type information across BPM components. It start’s with the tooling, is used to extract data at runtime and finally describes how the forms should be rendered.

One thing that jumps to my mind XML and XSD. Ok, I admit that I have been working on the JBoss web service stack, but other problem domains chose such a solution as well. Just think of heterogenous (i.e. ESB) or event based systems (i.e. CEP). And they do so for good reasons:

• You get a data type model that supports structured and simple types
  
• It can be validated through XSD
  
• Access to the data can either be done programatically or through XPath
  
• Data can be represented in Java or XML
  

If you add XForms to the picture we are one step closer to solving my initial task management problem: Describe your data types through XSD, extract it by using XPath and display it through XForms.

But there’s more to it: Decoupled producer and consumers in SOA, in which BPM plays in important role, would greatly benefit from such a type system as well. Any invocation between a process and a service could then be constrained to the type information at hand.

GWT console Beta2

Some things changed in Beta2 others did improve and I’d like to give you a quick update on what happened the last two month.

TokenEditor

Something you may already know from the JSF console and what is commonly used during development is the possibility to signal tokens directly from the console. We’ve added that feature to the GWT console under the section “Development tools”. You’ll notice those by the little wrench icon in the upper corner. These tools will be available to a particular role only, once we add authorization to the editors.



Report server integration

Beta2 drops the gchart, the client side Javascript charting library and instead switched to BIRT. There have been several reasons leading to this decision.
On the one hand we’ve realized that biggest challenge with reporting is not rendering itself (which gchart could have provided) but the tooling that needs to go along with it.



We’ve realized that it’s close to impossible to come up with the one and only BPM report that pleases everyone. Most reporting and dashboard applications are actually quiet the opposite: Highly customized towards particular users and their problem domain. This is the approach we are taking with BIRT as well. The jBPM console ships with stock reports, that can be extended or even be replaced.

If you are interested in jBPM reporting a good starting point would be the report server project introduction.



Task management

We’ve also added the first task management functionality which currently does focus on task assignments.



The current release allows you to claim tasks, complete them by signaling or reassign tasks to a particular user or group. Future console version will embed task forms for human interaction, but this area in particular requires further discussion.

Stay tuned...

Guerilla Governance?

An old friend of mine started talking about Guerilla SOA a few years back and got into some interesting debates around it. Ignoring the fact that some of G-SOA is flack about the need (or not) for vendor specific SOIs (always a good thing to push if you're working for a consultancy firm), one of the important aspects that I take from this is the incremental approach to SOA. Whatever you call it, the concept of taking things one step at a time when you approach SOA rather than trying to do a big bang approach is fairly obvious and intuitive. We're used to working in that way for many different things: you don't have to know all of Java in order to write HelloWorld; you don't have to understand how your car engine works in order to drive it etc. etc.

This incremental approach to SOA is something we've been pushing since the very early days of JBossESB and it's embodied in the latest release of our SOA Platform. The feedback we've been getting is overwhelmingly positive, so we've also been doing this within Overlord. I'm not sure if we'll call this Guerilla Governance (G-Governance?) but the principles are the same: start small and build up as you gain experience and as your needs evolve. A flexible SOA Governance infrastructure should adapt to you while at the same time encouraging good governance practices so that you can adapt to it. This is why we've started with things like DNA/Guvnor and Process Governance, as they satisfy well defined needs on an independent basis but also within the whole Overlord infrastructure as and when we get there. SAMM is a little more invasive as far as governance is concerned, as is the forthcoming work on Policy Enforcement Points and SLAs. But more on them in the future.

So if you're looking to deploy your favourite SOI and are concerned about governance, don't think you necessarily have to buy in a complete solution immediately. (I'm not even sure there is such a thing as a complete solution!) Look for something that can grow with you and even better, something that you can influence with your own policies and approaches to governance.

And if you're using JBossESB or our SOA Platform, take a look at the Process Governance work. As soon as you start to tie together more than a couple of services, something like this (helping you to write and enforce provable correct choreographies between arbitrary services and across arbitrary complexities) is essential.

Process Governance 1.0MR1 released

The first milestone release of our Process Governance work has just been released. Please take the time to download it and try it out. This is a major contribution to the whole governance area and we hope to get your feedback. Congratulations to everyone involved.

Process Governance

I've mentioned a few times before how important I think the WS-CDL effort has been and how overlooked it's been. But we started to put that right about a year ago when we looked to integrate the great tooling that the Hattrick guys have been working on with JBossESB. Well we're almost ready for the first milestone release and I've been going through what the team have been working on. It's very cool and I'm impressed. We'll be making an announcement soon, but this will really add an important differentiator to Overlord that we're calling Process Governance. I'll blog more on that later, but watch this space!