trying to solve IT problems

I have to admit it, I did not get it. Until I went to the Intalio Business Process Management training that is. I already knew what BPM is, I have seen enough talks from Tom Baeyens about the subject. I had heard of BPEL, a language for web services orchestration, but I still did not get it.

For my job at synergetics, I need to have good knowledge of the Intalio system, so I went to their training. What was demonstrated was a very nice editor for BPMN diagrams (the Intalio Designer), and a tool to map this to an execution (using the Intalio Mapper), which creates a BPEL description for the process. What this does is actually allow you to graphically design the interactions between the tasks which build the process. Each of these tasks is actually a service, as defined using a WSDL document. Usually this is a web service, but there will be a means to have non-http invoked services. Basically however, a task something which sends and/or receives an xml document. The tasks themselves can then integrate using “process data”, which is represented by yet another xml document (defined using a scheme).

As the mapper allows you to map the messages graphically, there is no need for (complex) XSL stylesheets to let the data flow between the tasks. This is a big plus, as (in my opinion) stylesheets are hard to write and maintain.

There is a special tool to handle the user interactions, which are also handled as web services which are automatically generated by drawing a form which is then to be filled by the user. This is a powerful method which can include defining some data constraints etc.

However, because of this reliance on wsdl services, you also need to be able to create them easily. They have actually catered for that as well (and are in the process of adding more), for example by creating an easy way to convert database access paths to web services.
This actually makes me finally understand where the SOA buzz comes from and how things could be written to be fit together. However, the example is still relatively simple and you will need some plumbing to get it all to cooperate as a maintainable enterprise ready application.

The way I see this can be used to combine an application.

• Use a good tool to model your database and data constraints. In the past I have used Uni-d for this, but this is going to be superseded by a new sourceforge project called “equanda” for generating the data access layer, with constraints, with gui to manage the base tables, with support for base web services and defining some actions on this data (accessible from the data access layer, gui and web services). All coming from one single description.
• For complex user interactions, like entering an order, you will need to create some custom forms. That way you can build them to be sufficiently user friendly and efficiently usable. Your power users will appreciate it. These forms will probably include some buttons to start some business processes.
• All complex flows should be processed using business processes. As this is based on a graphical representation, this allows interaction with the people from the organisation to discuss about validity of the processes. Once the processes are determined and implemented, the graphical representation serves as documentation (make it easy to comprehend the business processes, a lot more practical than writing text documents).
• All decisions which are part of the business processes should be represented using a rules engine. I believe that a rules engine should be tightly integrates with the BPM engine. It might seem like overkill for some decisions, but embedding them in a rules engine makes it more practical to discuss about the process, and clearly and cleanly separates certain types of changes. For example the decision of what is a “big order” can easily change over time without changing the business process. As such, you do not want to deploy a new version of the process just because this definition changed.

Some of the biggest problems concerning SOA and web services in general have not been touched though. As usual the demonstration showed simple examples where the mapping between services could easily be dragged and dropped, combined with some simple functions. I assume this can become very tedious when the services have very different xml formats.

Evolution of processes and versioning is a major problem. The task nodes in BPMN look like black boxes, but the mapper allows mapping either process data or the reply from the previous task as data to populate the input for a task. This means there is a dependency between tasks which are linked in the process flow, and thus causes re-doing links when either changing the process.

On the other hand, not only the business processes themselves can change, but also each of the services which is used. If the services change their interface, your business process will fail. You will need good standards/contracts/conventions to prevent that as much as possible.