For those of you who aren’t familiar with the jBPM human task module, here’s a very brief introduction:
To start with, a “human task” describes two things:
- In an otherwise automated business process, a “human task” is the concept that one of the steps in the process consists of and is strongly dependent on human input.
- In a larger sense, a “human task” is a label that helps people who model business processes differentiate between system interactions and human interaction in a process.
Somewhat obviously, the “human task” aspect of BPM is problematic but important to model and formalize. Modelling human behaviour in a (computer) systems’ environment is not a simple task. There are even two specifications that describe how this should be done:
- To start with, we have the WS-HumanTask specification, which is the generally accepted specification for describing how a human task can be formally described.
- There’s also BPEL4People, which is essentially a BPEL extension for human tasks.
In any case, the jBPM human task module implements the WS-HumanTask specification. This module basically takes care of all the bookkeeping and administration specified for human tasks: who gets a task, who may get a task, who is working on a task, which tasks are closed, which content is associated with which tasks, etc.
If these were “computer tasks” instead of “human tasks”, then the BPM engine would call the computer or system responsible for the “computer task”. Then, a second or two later the computers respsonsible for the task would have completed the task and done all the bookkeeping or otherwise informed the BPM engine that an error occurred.
However, humans don’t work that fast. And they also need a human friendly method of letting the BPM engine know the status of the task. And lastly, given that computers are better at that bookkeeping thing (which is basically computation), humans also want the computers to do that. Thus, we get the WS-HumanTask specification and the jBPM implementation of that specification.
Phew, okay, now that we’ve gotten that out of the way, I can write about what I really want to.
Persistence in the jBPM human task code is a cross-cutting concern. Click on the link for wikipedia’s definition of the term, but in short, persistence has nothing to do with the human task code.
The easiest way to identify cross-cutting concerns is to think about how you would fix a bug in the code. For example, if you have a bug in the jbpm-human-task code because tasks aren’t being assigned to the correct users, then you look at the logic in the jbpm-human-task module dealing with task ownership. A persistence bug, however, will have nothing to do with the task ownership logic — or any of the other logic in jbpm-human-task that describes the human task bookkeeping and administration. A persistence bug will only have to do with the code in the jbpm-human-task module that well, deals with persistence. Well, at least, a persistence bug should only have to do with the persistence bug..
And that’s exactly my point: code deals with cross-cutting concerns should always be encapsulated and isolated from the rest of the code when possible. This isolation is a form of loose-coupling. Encapsulation is important so that other developers don’t mistakenly start using instances or methods that they shouldn’t — and of course, it makes finding bugs a lot easier. Loose-coupling is important because it allows developers to extend and further develop projects with relatively little problems. (Loose-coupling is one of several fundamental ideas that a developer should have hardwired into his or her brain, in fact).
Lastly, if you do not encapsulate or apply loose-coupling to your code, you are in for a world of hurt, as they say. This regardless of which cross-cutting concerns you’re actually dealing with. Lack of encapsulation or loose-coupling means project death, if left alone. I am really serious about this — and if you don’t believe me, or don’t understand how important this is, well.. then, I’m actually speechless (or I’m otherwise convinced that you haven’t studied computer science). If you then also happen to be one of my colleagues or work on my project, don’t worry, I already know who you are. <evil laugh>
Why am I writing all of this? So that I can refer to this post in the discussions that I unfortunately expect to have about this issue. And of course, as always, I’m writing this because that is what this blog is about.
Hi there! Do you know what TDD is? It’s Test Driven Development.
To tell the truth, no, I don’t do proper TDD: technically, you’re supposed to write the tests before you write the code, and while that’s a nice thought, not being able to write the ideas in my head down immediately gets in the way of the creative process. Tests are the equivalent of “editing”: writers of all types and kinds write first, and then edit, sometimes almost endlessly. That’s why it’s called “polished” writing.
There are a couple important benefits to TDD: better architecture of your code and less tightly coupled code, code technical quality (less bugs, in short), and documentation through code. However, there’s one more benefit that I hadn’t run into until recently: tests help maintain backwards compatibility.
True, sometimes you will have to rewrite your tests when you modify code — but please, it should at least make you stop and think twice.
There are two things going on when you modify your tests:
- Every project has externally facing methods and classes (your API/SPI) and internally facing methods and classes (code used only internally by the project itself).
- You should be aware of what your test actually tests. In short, you should separate and write your tests according to whether they deal with externally or internally facing code.
When you modify your test, and it tests externally facing code, then that should trigger a realization about what you might be doing to users of your project.
FOSDEM is the “Free and Open Source Software Developers Meeting” and it’s happening this weekend in Brussels. It’s a fairly large conference (5000-10000 attendees) covering all sorts of free software.
And I’ve been working on a presentation for it about jBPM Designer this week. Putting a presentation together can sometimes be more work than you expect — hmm, maybe more work than I expected then, at the least.
Here, good readers, is a link to a description of the presentation. Geoffrey De Smet, another core Drools/jBPM developer, is doing the first half the presentation on Guvnor, which Designer integrates into. You can find his blog post about it here. He’s also the lead developer on the Drools Planner project which I like. “You should check it out” are the words that you just read and that you already knew were coming.
A good friend of mine who’s somewhat of an expert in learning told me that all presentations and trainings should attempt to pose one question to the viewers and answer it. In this presentation, my question is
How do we let business analysts to do their work well (so that they leave the business software developers alone)?
It’s a question which I have at times found very pertinent, even though I have worked with some very good business analysts.
Designer is a great web project that already is a polished, easily usable web application and integral part of Guvnor (from the jBPM standpoint) — and it’s getting better every day. In short, Tihomir (Surdilovic), who’s probably done most of the work on the project, has added lots of features that make it easy to develop a (BPMN 2.0) process. The Guvnor integration means that, as Tiho put it, Guvnor becomes a “one-stop shop” for developing, storing and deploying processes.
You can just open up Guvnor (in a browser), create a new process, edit it, save it, build the package and then go directly to jbpm-console and BAM!, start your process. That’s kinda nice.. !
In my presentation, I’ll go over the background of BPM, BPMN and JBPM (if you’re attending, please practice saying that 10 times quickly), some of the main features of Designer, and then give a quick (max 10 minute?) demo. We might finish a few minutes early — depending on questions.