Hugo Troche's blog

Why aren't Workflow engines parts of almost every JEE application? The Missed Opportunity

Workflow Engines like jBPM from JBoss are the perfect tool to model any process that has many paths, and requires human involvement between process tasks. Let's just start thinking about some common applications:

- Shopping cart: It is a perfect fit for a workflow engine. Each step in the process of buying an item is well defined, each step requires human interaction and finally there are many paths in the process (a shopper can pick from a myriad of shipping options for example, each with its own distinct actions to follow).
- Recruiting website: A candidate needs to enter his/hers skills. The system then matches the candidate to a job and notifies a recruiter and the candidate. The candidate and the recruiter review the match. If there is common interest, both parties communicate and so on.

I can keep going on and on with application examples that are simple business process representations. If that is the case, why don't we use JBPM or similar frameworks more often? Why are we not fluent in BPEL? After all, a workflow engine provides us with so many advantages:

a) It saves the state of the process. If a shopper exits a website before finishing with the shopping cart, the engine will easily bring the back session exactly to the point where it was before the user exiting. Implementing that logic without a workflow engine is usually time consuming and error prone.

b) It provides with a clear separation between the business process definition and the process task itself. jBPM is so effective in abstracting the task from the process that a non developer can reorganize the tasks later on. Most of these tools also have GUIs to manage the business processes. Try implementing that from scratch.

c) It reduces the complexity of applications by leveraging the engine to do the "plumbing" work of the business process. The developer just needs to focus on the process tasks and the business analyst in the process.

There are many other reasons about why a workflow engine is such a great and fundamental component to almost any application. Yet, why aren't workflow engines more popular? These questions nagged me for a while. I think there are 3 main reasons why workflow engines are not more popular:

1) The learning curve to be proficient in any of these frameworks is high. Thanks to frameworks such as Spring, developers want tools that they can start using right away after reading a few tutorials. jBPM is no such tool. This by itself should not be a reason for the unpopularity of workflow engines, but combined with,

2) There is no dominant player in the market. The market is fragmented. Don't get me wrong, there are many standards that most players are using, yet the standards are too low level for the skills to translate between frameworks.

3) Workflow engines live in the murky grayness between developers and business analysts. Some of the commercial workflow engines are geared and sold to business analysts. While other engines like JBPM are more geared towards developers. The successful engine has to be able to address both concerns.

The workflow engine will start becoming the Rosetta  Stone of modern enterprise systems. With the current SOAs Web Service access orchestration is already difficult. To take advantage of the long tail of possibilities in an SOA, a developer needs a solid way to model the business processes that access all those web services. Then, as the market moves towards ESBs, workflow engines and rule engines will be the glue of modern enterprise systems.

So, who will come up with the Spring of BPEL? How will come up with a powerful simple, open source framework that scales?

Single Sign On (SSO) in SOA

A common problem that I see in the field is how to enforce the security policy in the execution context of a service (are those enough SOA concepts in one sentence for you?). The market is full of Federated Identity Management tools. Once you decide on what identity management package you will use, you have the task to actually integrate that solution with the rest of your infrastructure.

Let's supposed that you decide to go with a SAML token solution from a vendor that is big and blue for example. The way this will work, is the identity management server will either intercept or redirect the initial communication going to your services, and challenge the service consumer to provide credentials. If the identity server accepts the credentials it will consider the service consumer authenticated and place a SAML token in the header of the request to the service.

Now, suppose the service the consumer is trying to access is a web service. What the identity server will do is place a SAML token in the SOAP header of the request going to the web service. All the web service container needs to do now is verify that the request has a valid SAML token. This would take care of authentication. By accepting the token the web services acknowledges that the consumer is who it pretending to be. The SAML authentication process is actually more involved than that, but for the example this will do.

If you are using JBoss, this is what you need to do to make your web services accept the token:

a) Create a generic handler (according to the JSR 109 specifications) that gets called before it ever hits the endpoint. You insert this handler in the chain. You make the handler deny the request if the
SAML token in the SOAP header is not valid.

b) You set the principal in the SOAP envelope to the principal that you read from the token. This will allow your JAAS login module to have a Subject loaded.

c) You create a custom JAAS login module that takes the Subject and performs authorization. Just because the consumer is who it say it is, it does not mean that it has access to this particular service. A common solution is to save the user/roles information for JAAS login module in an LDAP server. Then, the login module loads what roles are assigned to the user and the application server decides whether the role can access the resource or not. You define what roles can access a resource in the application configuration files.

This architecture will work with other type of tokens, or non token based federated identity management. In this particular case the authentication was separated from the authorization because of limitations with federated system. The SAML token can easily contain the role information for the user, so the application server does not have to hit the LDAP server as well.

Let me know if you need more details or have any questions, comments, etc.