(j)BPM: where does it fit architecturally?

How does jBPM fit into my architecture?

This question pops up regularly in my mailbox or on the jBPM user forum. Even when I was still a jBPM consultant, this question was the first line new customers asked me.

But there is no ‘all-in-one’ answer to this question. Like many answers in IT, the real answer is ‘it depends’. It depends on which frameworks you selected already. It depends on the expected load of the business processes. It depends on the existing systems which need to be accessed in the process. It depends if you want to centralize BPM knowledge in one application or not. And so on and so on …

jBPM is extremely flexible since our key feature is being embeddable in any Java technology out there. Pick your favorite framework, and I’m sure there is a way to fit in jBPM. But it’s the very same embeddability that often causes people architectural headaches. Mis- or underinformed people often want to take the easy path, and big BPM vendors know this.

A well-dressed sales guy will give a smooth presentation with colorful charts and he will promise you heaven and more. Of course, before acquiring the BPM system, you must first put (a lot of) cash on the table. That’s the way the world turns, right? And what are you getting: a big black-box server. You can send requests to it and it magically gives you the answer (hopefully it is the right one), hence the developer in the picture below that is painting on his screen. Paintings tend to look good from a distance, but you know that once you get close it tends to get blurry.

Big black-box servers don’t give you architectural headaches. No, on the contrary: they define how your architecture should look…

It could be me, but I like to keep things under control. I like to see what’s happening in my architecture, how it all fits together and which systems are communicating with each othe.. You know, that warm, fuzzy feeling you get once your own designed architecture keeps up with every load you throw at it. jBPM just gives you that openness en flexibility you need to build an architecture suited for your business, without having to suit your business to an architecture implied by a big black-box system.

Since jBPM is at its core just a simple Java library, there is no limitation on how you want to include it into your architecture. I’ll list a few of them here, but remember that jBPM will never be the limiting factor when designing your architecture. However, I do have my own ideas and experience. So, there is a definition I tend to use when people ask me about jBPM and architectures:

A business process *is* a part of the domain model, so ideally BPM should be non-intrusive and integratable with *every* architecture and technology. So let me reverse the question now: how does your domain model fit into your architecture?

Many people don’t see a business process as part of the domain model (remember my black-box story …), but it makes a lot of sense if you think about it. What is a domain model? Well, it is a representation of your business domain, of the raison d’ĂȘtre of your business of company. What is a business process? Well … it is a representation of how your business does something to create value. It is a representation of domain objects communication in some fixed way (a ‘flow’) to create some business-specific value.

So what does this mean in practice? It means that concepts like a Task (eg ‘send inquiry’), a Process Instance (a ticket sale) or an actor are at the same conceptual level as the domain model. Do note it doesn’t mean to scatter around your logic (like custom activitities, service invocations, etc.). Best practices in architecture design do still apply, and even more with jBPM (since they are applicable without restriction).

So by now I hope you can understand why we at jBPM don’t like the black-box-magical-server approach. A domain model is often scattered around many architectural layers or applications. Nobody asks questions when a domain object tends to be used accross different layers, and it is the same for the business process. If it makes sense in your architecture to not centralize a business process, then do it. It will make your architecture more understandable and easier.

Like I said, this means you can use jBPM in a lot of architectural styles:

  • In some designs, a BPM layer is placed either above a service layer – I like to call this a scenario layer
  • jBPM code is often wrapped the same way as a DAO (where I most of the times use the term PAO (Process Access Object). Services make calls to the PAO’s, just like they are accessing domain objects through the DAO’s. In a Spring environment, this is a true and tested approach.
  • Or you could build a big centralized server that does only BPM operations. This looks very much like the black-box servers I mentioned before. In some architectures this makes sense (eg tax processing split over several clusters), but you now don’t get a black-box server, but an open system that shows you all its internals. No magic involved. If you want to wrap it in WS-*, REST or whatever gets you going, fine. You don’t get that kind of choice with typical BPM products.

I’m sure that if you searched our user forum, you could triple this list in a few minutes.

Conclusion

This article is a bit of a side track in my current ‘jBPM4 real-life example: The Train Ticket Demo’ saga, but you’ll see that my ideas of this article are applied in the eventual Train Ticket Application (ie ‘jBPM on Rails’). Architecture designs tend to get a lot simpler if you look at BPM as part of the business domain. And jBPM just gives you that kind of control: flexibility and embeddability in any Java technlogy.

So, let BPM enrich your architecture, not cripple it.Use jBPM and free your architecture today!

6 Comments

  1. Yuri September 13, 2009

    That’s an interesting post.
    Currently we are thinking whether we should put our BPM (jBPM) Layer over the our service layer which is probably the classical way.
    Or should we rather allow services to use the workflow too for managing states.
    And then in turn these services are orchestrated in some kind of master business worklow.
    The second option might no be the ideal SOA design, but it gives you a hell of opportunities.
    What do you think?

  2. Joram Barrez September 14, 2009

    @Yuri:

    Both are certainly valid approaches. The ‘BPM layer’ approach is indeed a more classical way of looking at the problem. I wouldn’t necessarily see this layer ‘on top’ of the existing service layer, but as a integral part of it. Eg as you’ll see in one of the next articles, my ‘TicketService’ is conceptually on the same layer as the rest of the services. This ticketServices then gives you CRUD like operations, but then for workflows (ie start, stop, etc.).

    The second approach you mention can mean a boost in productivity, if you choose the granularity of the subactivitities of the workflow fine enough. Imo, it is completely valid to eg start a new workflow when you do a save operation of some entity in some service.

    This way, workflow is not used as a separate component in your design, but as a integral part of your logic, what is a more natural design imo.

    Regards

    Joram

  3. Yuri September 15, 2009

    @Joram, thanks for sharing your thoughts. Interestingly we came to conclusion that it’s not a crime to call the workflow engine from a service.

    The “PAO” pattern is not a bad idea of a term to call this approach. Aervices should be stateless by thier nature and when they interact with workflows, they communicate with the outside world.
    Example: the save() method of a service starts a new process instance which in turn has a verificaton task. As soon as this proc.instance reaches that task, a new task item appears in the work list of an employee who completes that task (i.e. client app calls service method verify(), which again signals the process to go on) and the workflow runs on to the next node.

    Thus the complete state management is independant from the service.

    Another interesting point to hear your opinion on would be, is it a good practice to save the state of the object (for example pending-submitted-accepted-removed) not only in the workflow but in an attribute of the business objet itself. If your business object is completely unaware of the workflow it is used in, it is very hard if not impossible to make queries against such objects in order to, say, find all objects in the archived state. If the object itself has no idea of its state, you have to query the associated process instance each time you want to get its state, which means pretty bad performance. Have you had similar requirements in your projects?

  4. Joram Barrez September 15, 2009

    @Yuri: The PAO approach is something that I’ve used in the past on several jBPM projects. The services should indeed always be stateless. As described in your example, a start could leas to a the creation of a task (=stateless). The completion of that task is again stateless. You’ll notice that in fact BPM operations are a lot like CRUD operation, which means you can treat them like that.

    Imo, also the logic gets more natural. Saving an entity (eg an order), will practically always mean starting a new order-process. By putting the save-entity and start-process instance operation together, you get something that is very natural to develop and maintain. I’m speaking out of real-life experience here.

    Regarding the business object state problem. This is something I have encountered many, many times. In fact, it is my opinion that every BPM project get to this questions at a certain point in time. So, I have a very clear answer for you:

    The state of a business object should always be maintained in the business object itself. There is no need to duplicate this in the workflow (duplicate data is never good). Every process revolves around a certain object. And every object always has a unique ID:

    * An order process revolves around an order (orderId)
    * A jira-like workflow revolves around a project (projectId)
    * …

    In jBPM there is the concept of a ‘business key’. This key is a process-global unique value and every process instance can (and should!) have a business key. This means that process instances can uniquely be found once you know the business key.

    * Give me the process instance for order 15987
    * Give me all the tasks open for project 54
    * Give me all the tasks from orders that are in the state ‘submitted’ -> select first the ids of the orders, than the processes.

    Altough, there is not much literature around this concept, all the jBPM team members agree that using a business key:

    1) simplifies your development a lot
    2) It gives you great performance (put an index on the business key column and that’s it)
    3) Is a simply a BEST PRACTICE when using jBPM

    Trust me, I’ve used jBPM before the business key concept was introduced and once you get a lot of processes writing queries was just hell.

    Mmmm, while writing this answer I realized that I better should blog about this in the close future. Many people could benefit from this knowlegde. Thanks for triggering me, Yuri !

  5. Kunal March 19, 2013

    Hi Joram,

    Any views on this from latest BRMS standpoint?

    Embedding JBPM into Application seems to limit extensibility of the process (say I want to add a new node/ human task in the process). I wonder whether you have explored latest JBPM offering and it’s embeddability into web applications.

    Regards,
    Kunal

  6. Joram Barrez March 19, 2013

    @Kunal: yes, I still stand for what I wrote almost 4 years ago. That is still very valid today.

    I haven;t looked at jBPM for a while now, mostly because I’m now working on Activiti (http://activiti.org/).

Leave a Reply

Your email address will not be published. Required fields are marked *