Archive

Archive for July, 2011

jBPM 5 database testing mechanisms

22 July 2011 Leave a comment

I recently finished making a mechanism for enabling the use of different databases with a set of unit tests.

A thorough explanation of the mechanism in its entirety can be found here:
http://community.jboss.org/wiki/JBPM5DatabaseTesting

The reason I’m also posting this here is because the mechanism that I describe can actually be built in to most maven projects that contain unit tests that use persistence.

In my case, the specifics are as follows:

  • The mechanisms are built into the jBPM framework (the code can be found here).
  • The unit tests are spefically using JTA (the Java Transaction API).
  • The Transaction layer is handled by the Bitronix transaction manager.

But none of these details mean that the same mechanism can’t be applied to any other project, including those that don’t do anything with JTA. Using JPA is to some degree intrinsic to the mechanism, although other java persistence frameworks that also use XML configuration could also be used, I think.

In short, it comes down to maven filtering + the Properties mechanism in Java + using XML configuration for JPA (persistence.xml, in this case).

Advertisements
Categories: CI/Buiilds, jBPM, Persistence Tags:

(j)BPM in the cloud

11 July 2011 Leave a comment

Right, so I’ve been thinking about this for a little bit:

What exactly do you want from a BPM engine if it’s in the Cloud?

[Yes, here, we capitalize the word Cloud. Good, that’s settled.]

First, a minor diversion from the topic at hand:

VMware:

At one of my previous jobs/assignments/workplaces the developer machines were all virtual machines. It was fantastic for the developers (well, almost) and particularly so for the system administrators and management. Far less inventory (machines) that simply weren’t worth anything after 5 years and no more walking around doing almost physical maintenance on machines.

But the biggest advantage is that my (virtual) workstation could be moved to whichever node that the systems administrators wanted it to be moved to, and that creating a new workstation was as simple as a couple of clicks and ticks. Furthermore I could simply login whereever I wanted to — even from home via a VPN — and presto magico, have my work environment available to me exactly as I had left it!

System administrators were no longer spending as much time on figuring out where a machine was and when it could be turned off to do what — they were becoming more efficient in their job.

The Cloud

Why do you move your (j)BPM process to the cloud? Because you don’t care (and don’t want to care) about where your BPM process is running.

Sure, to be clear, you want your BPM process instance to be secure and safe and dependable: but the hardware underneath — in short, the server, anything and everything except for your process just doesn’t matter to you.

And when we’re talking about BPM processes, that means that the only thing you care about is that somewhere out there, in the wild blue yonder, your process is running.

This has some consequences.

This means that, well, at lot like my virtual workstation, my BPM process should be able to be moved, on the fly.

As a 80’s valley girl would have said it: like, the process is just stopped and then like, it’s over here, like, and then it’s running again and like, if you didn’t know, like, you wouldn’t know! Oh.. my.. god!

BPM processes in the cloud:

Huh? Exactly.

What I’m imagining is being able to move, in this case a business process and the entire related java stack just like that <snaps fingers>.

There are several things that the infrastructure needs to be able to keep consistent in this case:

  1. Encapsulated (persistence) context.
  2. Java stack.

That’s actually it, as far as I can tell. We need the data and where we were — exactly — in the process.

Persistence context:

A BPM process needs a connection to a database in most cases: usually in order to persist (save) process information at critical junctures, like the end of a process. With regards to a transportable process, that means that a process needs to be able to encapsulate and transfer it’s (not yet commited) persistence context with itself.

This doesn’t seem that hard: sure, it’s a bit of hacking but on the other hand, it’s pretty clear how we could do this.

Java Stack

This is an interesting one, because there are some interesting cases:

  • BPMN 2 step.
  • Java code that’s associated with a BPMN 2 node.

The first case is easy enough: in short, it’s a step in a BPMN 2 workflow, no associated java code, we pause the process at the end of the step, move everything and restart the process where we had paused it on the new cloud node.

The second case is more interesting. Maybe we have a long running step — a human task or some such — and we can’t wait for the step to finish. Things to think about are then the following:

  • There are already mechanisms for asynchronous execution in jBPM and other frameworks. We can probably use these to our advantage here.
  • Input from, say, a returning webservice: it might need to be “cached” and then “forwarded” to the node that jBPM is running on.
  • Otherwise, we can mark steps in the BPMN 2 process as “atomic/unmoveable” in the sense that in those steps, the process can not be transported.
  • We need to save the stack: we can already retrieve the stack using Thread.currentThread().getStackTrace(). But how can we “recreate” that stack (with all of it’s data) on the new cloud node? There will be cases where we will want to do that!
  • Related to saving the stack: what type of mechanisms or otherwise constraints do we give the process creator/user in order to ensure that the process is saveable and transportable? Do we “save points” in our XML? Do we force the user to call a “saveProcessStack” method, or otherwise build the automatic/automagic calling of that into processing methods?

Cool, more questions than answers! And lots to build on.

‘Till next time!

Categories: Cloud, jBPM Tags: , ,