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?

Binding JBoss to a Different set of Ports

A common problem that I encounter is the need to configure JBoss to work on a different set of ports. If for some reason the environment is already using port 1099 and 1100, 8080 is not available, etc, then I have to change the ports JBoss is running on. The hard way of solving this problem is by changing all the ports manually. That means editing all the JBoss service configurations and changing the ports there. This process is almost impossible considering how many configuration files and ports are involved. Not only that, your configurations need to match between files. It can really be a nightmare.

Thankfully there is another solution. JBoss has a Binding Manager service. You can configure this service to bind ports defined in a configuration file. JBoss also provides a sample configuration file with 4 sets of ports. In order to use this service you need to do the following (JBOSS_HOME represents the directory where JBoss is installed and SERVER_NAME represents the server instance you are working with):

1) Find sample-bindings.xml . It is usually located at /JBOSS_HOME/docs/examples/binding-manager/ . If you can't find it there, download JBoss and it will be in that zip file.

2) Copy that file to /JBOSS_HOME/server/SERVER_NAME/conf/ . I like to rename the file to bindings.xml, but that is up to you. The rest of the tutorial assumes you did not rename the file.

2) Enable the binding manager service. Open /JBOSS_HOME/server/SERVER_NAME/conf/jboss-service.xml. In that file uncomment the following section and make the change indicated in red:

<mbean code="org.jboss.services.binding.ServiceBindingManager"
     name="jboss.system:service=ServiceBindingManager">
     <attribute name="ServerName">ports-01</attribute>
     <attribute name="StoreURL">${jboss.server.home.dir}/conf/sample-bindings.xml</attribute>
     <attribute name="StoreFactoryClassName">
       org.jboss.services.binding.XMLServicesStoreFactory
     </attribute>
   </mbean>

Note that we changed StoreURL to point to the file you copied over. The other important attribute here is ServerName. ServerName specifies the set of ports to use from sample-bindings.xml. You can find the different servers names in sample-bindings.xml by searching for:

<server name

Bellow each of the server name tags you will find the port definitions. The options for the ServerName attribute with the default content of sample-bindings.xml are:

- ports-default
- ports-01
- ports-02
- ports-03

Look into sample-bindings to see to what ports each of those configurations binds to.

3) Save jboss-service.xml and restart JBoss. Now JBoss should be binding to the set of ports defined by ports-01.

An extra feature of this mechanism is in the fact that you can easily create your own set of custom ports to run JBoss on. Just copy everything from <server name="ports-01"> to </server> and attach it to sample-bindings, change the name attribute and you are ready to change that configuration to your heart's content. Then simply specify the name of that configuration in the ServerName attribute of the binding manager service (in jboss-service.xml).

Clustering JBoss in the Amazon EC2 Cloud

I have been working on a number projects that involved deploying infrastructure to the Amazon EC2 Cloud. For those you of you that do have a life (shame on you, remember in school, the Turincratic oath, you shall not have a life outside of your work? Dating is a NP-incomplete problem?  Anyone? I am starting to believe that was a practical joke somebody played on me) and do something else except Software, here is a link that explains EC2 http://www.amazon.com/gp/browse.html?node=201590011 .

The problem with deploying clusters in EC2 is that multicasting is not enabled in the EC2 network. This means that JGroups will not work by default in the Cloud, which in turns means that JBoss Clustering will not work either. There is plenty of debate of why Amazon does not allow multicasting and what they can do to fix it. Until Amazon enables multicasting this is what you need to set up a JBoss cluster:

Start a Gossip Server:

java org.jgroups.stack.GossipRouter -port 5555 -bindaddress localhost

 

Then in the JGroups configuration of the file %JBOSS_HOME/server/all/deploy/cluster-service make the following modifications in all nodes of the cluster:

<UDP ip_mcast="false" mcast_addr="224.0.0.35" mcast_port="45566" ip_ttl="32"

 mcast_send_buf_size="150000" mcast_recv_buf_size="80000"/>

<PING gossip_host="gossip_server_name" gossip_port="5555"     
gossip_refresh="15000" timeout="2000" num_initial_members="3"/>

 

Now, instead of nodes multicasting to find other nodes, they will register and get information about the cluster from the gossip server. This brings one interest point. The gossip server is a single point of failure. Therefore UDP gossip multicasting will not work for a solution that does not permit single points of failure. The solution is then to use TCP Gossiping.

To enable TCP Gossiping you start Gossip Servers in various nodes. Then in the same file as before you make this change in all the nodes of the cluster:

<TCPGOSSIP initial_hosts="gossip_server1[5555],gossip_server2[5556]" 
gossip_refresh_rate="10000" num_initial_members="3" />

You also need to disable other types of multicasting in that configuration 
file. gossip_server1 and gossip_server2 are the servers where you started the
 gossip server and 5555 and 5556 are the respective ports.

There is one more strategy you could try and it involves configuring J
Groups to use TCP ping. With TCP ping you don’t need to start Gossip Servers. The tradeoff here
is that you assign the JVM of a few nodes to handle the extra Gossip Server load, but it is easier 
to maintain since you don’t have start another process. Here is how to you configure the nodes 
in cluster-service.xml:

<TCP start_port="7800" />

<TCPPING initial_hosts="HostA[7800],HostB[7800]" port_range="5" timeout="3000" 
num_initial_members="3" />

HostA and HostB are your designed Gossip Servers. 

For more information take a look at the relevant JGroups documentation at 
http://www.jgroups.org/javagroupsnew/docs/manual/html/user-advanced.html .