Loraine Lawson spoke with CERN's Derek Mathieson about what moving the world's largest particle physics lab to an SOA taught the organization about BPEL engines and BPM.
Lawson: The Active Endpoints PR person called this the mother of all SOA and BPM success stories, which cracked me up. Can you talk about how SOA and BPM work together for you?
Mathieson: The BPEL engine, which is the core of all of this technology, basically allows us to define what the processes are here. The BPEL engine will automate the business process definitions, which come from the process owners through the different services within the organization.
For example, if there is an engineer who wants to come and work in a particular area and the work that the engineer does is welding or something like this, it may cause smoke, and then the engineer will have to disable the fire detection systems. So there is a business process to make sure the fire detection system is switched off, the work is done, and then the fire alarm is switched back on again. This is what we would call a business process. We have to make sure that the appropriate people are informed, that there is follow-up to make sure that when the process reaches the expected end date that someone actually will check and make sure the fire alarms are switched back on again, and this kind of thing.
The other kind of processes that we would automate would be basic purchase orders, where I will make a purchase order for a product, it gets approved by the people who can control it financially, it will also maybe be approved by people who are checking on the kind of material being purchased for safety requirements or this kind of thing, and then finally the document is transferred into the purchasing system, which ultimately becomes a purchase order and gets sent out from the organization.
You can get the idea that there is quite a wide range of different process styles we have to automate - not only your typical administrative roles but also safety and logistics and this kind of thing. We want to automate all of these processes and, consequently, we have to talk to lots and lots of different systems. So the idea of having a more service-oriented architecture, which allows us to have a standardized interface to each of the different systems and automate everything using the BPEL-based process engine, was a fairly nice match for us.
Lawson: Active Endpoints is your BPEL engine. What role does it play with your new architecture?
Mathieson: Yes, that's the BPEL engine. We, in fact, did an evaluation of several BPEL engines at the beginning. There was one by Oracle, one by IBM, there was one supported by Sun. There are several BPEL engines out there at the moment, but they all have pros and cons.
The standard is pretty good. One of the things we quite liked about the BPEL standard was you can be fairly sure of interoperability between the different BPEL engine vendors. In fact, we proved that, because when we started working, we initially started developing the process definitions using the Oracle BPEL engine, and when we ran into technical problems with the Oracle engine, that's when we started looking around and found Active Endpoint's engine. We basically just took the process definitions that we had made with Oracle and put them into the Active Endpoint's engine and it understood them. Basically, the migration was pretty straightforward, thanks to fairly tight specifications from the Oasis people.
So yeah, Active Endpoints is the BPEL engine. It's a state machine kind of thing, so you do your process definition as a big XML file and that tells you which of the different states within the process and how to get from one state to the next and what conditions caused the state transitions. One of the odd things with BPEL is the fact that everything is a Web service. So the processes themselves are a Web service and every step in the process when you want to talk to something else, you always talk to in terms of another Web service. So it's very, very service-oriented. It's very much Web service-based.
Lawson: Now, why Active Endpoints?
Mathieson: When we started working with BPEL, one of the difficulties we had was that it has a very tight definition of what to do when something goes wrong. So they have a thing called an exception handler, which basically allows you to treat when an exception occurs. It goes into a fault handler and that fault handler, or what they call a compensation handler, allows that to process the exemption, after which the process terminates and it's done.
So basically it had a very strict definition of what to do when something goes wrong. For completely automated processes, what they typically describe as straight-through processing, where there are no human interactions, it just does the job and when it's completed all of the operations, it's finished and it's okay. The typical examples are things like a money transfer between bank accounts and this kind of thing. So you either do this process and it completes it correctly or, if it fails in some way, then there is a compensation handler to undo the damage and then it completes.
The problem is that with the processes we automate, there are people involved. So for example, people will sign a document and then call you back a half hour later and say, "Well, I just signed that document but I didn't actually mean to approve it, I meant to reject it." So things can go wrong and you need to undo actions. The BPEL process definitions don't have a very good concept of this idea of people who can make mistakes. So that's the first difficulty with BPEL.
The second thing is that all of our reference data is always in a state of transition. So, for example, people get hired, people leave, people change units. All the different reference data that our processes are based on can change during the day. It can mean that occasionally you have a process which goes and looks for some reference date and the reference date is not there or is incomplete or there is something wrong. Now, with a standard BPEL process, what would be expected to happen is the process faults, it fails, and that's the end of it.
But if we have this as a workflow process, for example, for a purchase order and we make a purchase order for $100,000 and several people have signed it - my boss has signed it, his boss has signed it - and it's looking for the CIO or something, at that point in time the CIO is either not defined or is absent with no replacement. What you don't want to happen is the process faults and you have to start the whole thing again. You want it to wait so when someone looks and then intervenes manually, fixes the problem, then you can restart the process from where they left off.
The Oracle engine, which we were using originally and many other engines, don't have this concept of what Active Endpoint's has, which is this idea of a thing called a suspend on fault. So rather than actually just give up completely, it will recognize that something has gone wrong, freeze the process and then an alert goes to say that something is not right, what should I do? And then obviously we can intervene, make whatever corrections are necessary, and then allow the process to continue.
It's just a very practical thing. With a large organization there is always - the reference data is always in a state of flux. There are always things changing. So you can never be 100 percent sure that everything will always go according to plan. Consequently, you need the flexibility to be able to pause things, change things and adjust things as the processes are running. Active Endpoints is one of the few products that will let us do that kind of thing.