How to combine Workflow and Business Rules – in 5 easy steps

Tom has a good post on the jBPM (JBoss workflow) community day held at the Guinness brewery in Dublin. Warning – slides may contain pictures of people drinking beer.

Drools jPBM Business rules presentation

How to combine (jBPM) Workflow and (Drools) Business Rules – here’s the summary. Slideset is available on this blogpost.

  • Workflow (e.g. JBoss jBPM) is great – it allows you to take spaghetti code and draw it as a workflow diagram (flowchart) so that it can be reviewed by the business (the nice people who pay our wages). You then attach standard (Java) actions to these steps.
  • Only problem is when you come to a decision node (the one circled in red below): How do you decide to go left or right (in the workflow)? Normally this is coded in Java – good for us, but hidden from those nice business people (which means that this is more room for errors-in-translation).
  • Business Rules allow you to keep those decision making rules in Plain English: When something is true , then do this. That’s it. The rule engine does most of the hard work.
  • Integrating Workflow and Rules is easy. Use JBoss Seam (link) or do it by hand (link). And it works on non-JBoss web / app servers such as Websphere, Oracle Application Server, Tomcat and Weblogic.
  • Repeat x6 : Use workflow and rules. Use workflow and rules …

Simple Workflow

In a maybe related development, Tom Baeyens is now using strangely Rules-y like examples over on his workflow blog ….

Advertisements

Slides for Life and Death Workflow, using JBoss jBPM

The slides for ‘Life and Death Workflow using JBoss jBPM (Java Business Process Management) are here. PDF , about 800k for 41 slides. I’ve included full notes (even though I won’t get a chance to use them during the presentation), so that they should make sense when reading them online instead of seeing them live at the IJTC.

I’ve been promising people that I’m going to sell my car during the presentation. So here’s a picture of it. Isn’t she a beauty?

Picture of Toyota Corolla

All offers of workflow consultancy work to consultancy@firstpartners.net.

Note: If you’re linking to the slides, please link (here at this page) rather than the PDF (the location of which may change in the future).

Idiots guide to Service Orientated Architecture (SOA)

Lost in the hype around Service Orientated Architecture (SOA) is the fact that the idea is really really simple. It’s all based on the idea that most applications (and that includes websites) are built either to be used by people , or used by computers. The pictures below (a free preview from the Enterprise Java Briefing) show what I mean.

In a ‘normal’ application, such as a online banking website, we need to remember what the user did last (are they logged in, what account are they looking at, are they in the middle of making a payment). If we didn’t , the user would get annoyed about having to repeat themselves every step of the way. It would also make for pretty complicated screens, to allow the user to enter all the information in one go. Instead , we allow the user to enter information in several steps, and remember where there are each time.

Soa Client

In an application designed to be used by computers, we don’t have to worry about this. We can force the computer to give us all the information required all in one go – username , password, bank account to take money from , bank account to give money to, date to execute transaction. For a computer , this is actually easier ; we make one call to our banking service and we are told it has succeeded or failed. It’s also easier for us to build our service:

  • Each service (transfer money, book flight , execute share trade) only does one thing.
  • Because each service ‘forgets’ after each call, we don’t need to worry about trying to remember what we were doing before.
  • Because we have no memory, services are very scalable; we can make several copies of the same service and put them in a pool. Any client can talk to any service – no waiting for a particular server to become available.

Soa Service

So that’s Service Orientated Architecture (SOA) : programs that do one thing (a bit like a function call to a method) exposed that other computers can call. So what’s the big deal? Like all good ideas , a simple concept goes a long way.

Take a look at the picture below. It’s like a Visio diagram, but in fact it’s drawn by the Eclipse Based JBoss IDE. It shows a workflow for an online commerce store – pretty easy to understand. This example uses JBoss Java Business Process Managment (jBPM), but companies such  Tibco, Cape clear and Oracle BPEL have similar products.

soa workflow

Here’s the clever bit; each of these steps is executed by one of the services that we talked about earlier. This means that if the business process changes (and it will), then all you have to do is re-arrange the diagram ; little or no coding changes should be required.

This abilility to mix , match, combine and remix services leads us to a lot of other good things (and we’re only scratching the surface here).

  • Because our services don’t have to run on the same machine, we can use SOA to create a distributed application. This is the concept behind the BPEL (Business PRocess Engineering Language)
  • Services tie well to Ajax and Web 2: Our Ajax web page or portlet can call as many services as it requires to get the job done (it’s one of the reasons Tibcom is sponsoring the open source DWR project)
  • We can call many services at once. If these this service calls are xml based ,or we send these calls as a message then we can filter, duplicate, pass and other distribute these calls as we set. These are the ideas behind Apache Synapse, Apache Servicemix and the  Enterprise Service bus (ESB) in general.

What do you think? Is SOA useful , or over hyped?

related posts

Everything you wanted to know about Business rules

If you’ve reading this blog for a while , you’ll know that I’m into Business Rules. You know, the logic (formal and informal) that are unique to each company / organisation and govern how an insurance claim gets settled , the price you pay for an airline seat, or how your order from Amazon get’s shipped. Rule Engines are a way of getting this knowledge out of people’s heads and into a computer.

Artimis Alliance

Rules are a very simple idea (you just state what you know to be true), but rule engines are not. Ironically, the problem most people have is ‘this is to simple to work’. If you want to get find out more more, the ‘Down to Earth Business Rules blog’ from Artemis Alliance is a good place to start.
They also have a Squidoo Lens (a set of links to other resources) that is worth looking at.

Enterprise Java Presentation at DCU

On Wednesday, I’m presenting on the topic of Enterprise Java at DCU (Dublin City University) , in conjunction with Trigraph.

Trigraph Logo


I’ll blog later about bits and pieces of the slides (for commercial reasons I can’t publish the full set here), but the overview is below.

Description: Success or failure in your business depends on dealing with information faster and better than your competitors. This briefing shows you how Enterprise Java tools can do this and how to apply them to your organisation. Crucially, the briefing shows you when not to use Enterprise Java and details the alternative approaches.The briefing will give delegates an overview of the Java Web development environment, how to architect and distribute multi-tier applications and how to link these components with existing sources of information using Enterprise Application Integration (EAI). Most business have substantial investments in existing and legacy IT systems and the briefing will show how to integrate these with techniques such as JMS Messaging/ MQ Series, SOAP / XML or using the Java Connector Architecture (JCA).

As well as examining the main Java Application Server vendors (including Sun , IBM , Oracle , BEA and JBoss) the briefing will detail the technology stack that they offer. This stack includes Web presentation frameworks and SOA – Service Orientated Architecture at the Front end. In the middle (Business) layer this covers the capture of Business knowledge using Business Rule Engines and workflow (BPEL). At the back (Service) layer, this includes database integration using JDBC, and the Enterprise Service Bus (ESB).

What Problem are we trying to solve?Where Java Fits in Enterprise Computing.
Enterprise Application Integration (EAI).
A Componentised & Connected Enterprise.
Enterprise Java Architecture Overview.
Enterprise Java Platform Roles.
Benefits to the Enterprise.
Alternatives (.Net , PHP , Oracle , Lightweight Java Frameworks , scripting)
Scripting Languages and Enterprise Java (Ruby, Python, Groovy)
Vendors (IBM, Oracle, Sun , Bea , JBoss and SAP)
Vendor Specific Solutions (e.g. Oracle Fusion / ADF , IBM MQ )
Market Trends – Resource availability (can we get the people to do this?)

Foundation Technologies & Techniques.

Enterprise Web 2.0 and Service Orientated Aritecture (SOA).
Integrating with other Systems ( Legacy Systems, Oracle etc)
Enterprise Java Beans 3
Middleware (MOM, Rule Engines, Workflow)
Java on the (Enterprise) Desktop
Web Services / Enterprise Service Bus
Best practices (Code standards, Build standards, Version Control / Iterative Development / Junit)
UI Layer: HTML, Servlets, JSP, XML/XSLT.
XML’s Role in the Enterprise.
Application Tier: EJB, JNDI, JDBC, JDO.
Integration Technologies.
Java Connector Architecture- JCA
RMI, CORBA/IIOP, SOAP.
Security – Application and Server Level
Java Access & Authorization Service (JAAS).
Object-Orientation & UML.
Design Patterns.
Frameworks (Struts , JSF, ADF, DWR, Spring, Hibernate)
.Net interoperability

Enterprise Java Application Architectures.

Overview of Enterprise Application Servers.
Commercial Application Servers.
Distributed Application Models with Enterprise Java.
Enterprise Java Application Server Basics.
How to Choose a Enterprise Java Application Server.
Enterprise Java Application Architecture.
Building a Enterprise Java Application.
Deploying the Application.

Enterprise Java & Your Business.

Planning for Migration.
First Steps.
The Implementation Plan.
Organisational Challenges.
What’s next for Enterprise Java?

Close.