Process Engines, usually BPEL engines or Workflow engines, execute proces-steps based on a predefined process. This is a sound practice, however not for long-running processes.
Long-running processes have the nasty habit to change over time. This will affect all active and running processes. Why? Because the process engines usually store the process state and corresponding data in a persistence store. The effect of a change in the process requires you to migrate all those saved instances, unless you are able to leave them running the old version of the process.
A different approach is a State engine, where the next step in the process is not determined by the predefined steps in the process, but on the current state of the subject and the event that has been received. This leads to more decoupling between process and services. However, so far I haven't seen any Process engine that works like this.
In theory there's not much difference between the two approaches. You could state that a process engine uses implicit states as defined in the process, whereas a state engine uses explicit states. The end result could/should be exactly the same. A state engine would give some more flexibility, but also needs more functionality to be able to have an overview and control of the process.
Anyone knows of any tool that works like a state engine? I'd really like to know.
Tuesday, 30 June 2009
Monday, 22 June 2009
ODTUG Update: SOA Symposium
Yesterday at 8 pm we started the SOA Symposium at ODTUG (yes, Sunday and Father's Day to boot). ODTUG is well known for its technological content, but as SOA becomes more and more mainstream, SOA will become a integral part of ODTUG.
The symposium was organized by three Dutch Oracle Ace Directors: Lonneke Dikmans, Lucas Jellema and myself. The setup we choose was a little different then one would expect from a symposium. From the start, we aimed to get a very interactive symposium where the goal is to meet other SOA adepts and to exchange experiences. We managed to achieve this by doing just 3 presentations (to create a mindset) followed by two workshops and a panel discussion.
The day was divided in two parts. In the morning we approached SOA from a business point of view, in the afternoon we discussed technology. The average knowledge level and experience of the participants was rather high, which made discussions very very interesting. It was good to see that there were a lot of Oracle Ace Directors present.
We've made several very interesting conclusions which will be put on the Oracle Wiki.
The symposium was organized by three Dutch Oracle Ace Directors: Lonneke Dikmans, Lucas Jellema and myself. The setup we choose was a little different then one would expect from a symposium. From the start, we aimed to get a very interactive symposium where the goal is to meet other SOA adepts and to exchange experiences. We managed to achieve this by doing just 3 presentations (to create a mindset) followed by two workshops and a panel discussion.
The day was divided in two parts. In the morning we approached SOA from a business point of view, in the afternoon we discussed technology. The average knowledge level and experience of the participants was rather high, which made discussions very very interesting. It was good to see that there were a lot of Oracle Ace Directors present.
We've made several very interesting conclusions which will be put on the Oracle Wiki.
Saturday, 20 June 2009
ACE Briefing @ Oracle HQ
Today we have a briefing of all ACE and ACEDs (Ace Directors). Unfortunately we are not yet allowed to disclose anything that's been said.
Interesting? ABSOLUTELY. It will not surprise anyone that we've seen and heard an awful lot about the soon to be released 11g versions. All I can see for now is to stay tuned!
If you are a serious Oracle professional, the upcoming launch of 11g is something you should be part of. Don't miss out and register here. I think you will be as impressed as all the Ace's and Ace Directors present today.
For those who are attending ODTUG as well, be sure to visit the keynote by Steve Miranda. It's rumoured that we'll see some interesting demo's there around Oracle Fusion Apps.
Monday, 15 June 2009
Accessing Oracle SOA documentation
Ever tried to find that one document about the ESB on OTN? Did you quite remember where you found that BPEL Developers Guide? Well, life's been made easy for you. Marc Kelderman (Oracle Consulting) has made a list of just about all you need to start out with SOA from an Oracle perspective. Go and have a look at Marc Kelderman's shortlist. Way to go, Marc!
Wednesday, 3 June 2009
SOA: Process driven, message driven or event driven?
For a long time I thought that SOA is process driven, meaning that the functional requirements were discovered by working downwards from a business process perspective to a comprehensive set of services to deliver the business value.
However, the more solutions I see, the less I believe it. Saying so, I realize I need to clarify that a bit more. Whenever you're building an SOA from the Business process downwards, it is smart to discover possible candidate services from your existing legacy environments (building upwards) so you can execute a 'meet in the middle approach'. This usually results in orchestrating business processes (with BPEL) and -simplified - composing composite services (based on atomic services from your legacy).
Is that bad? Not in itself, I think. It depends on the type and the number of processes. Suppose you have - on average - 50.000 running instances of a process. If you have to change that BPEL process you defined, what will you do? The first question to answer is: what do I need to do with my current active processes? Can they continue using the existing process or do the need to switch? Does it depend on the state they are in or not?
This problem gets worse the longer a process runs. It increases the chance that a process change will occur during the time it runs. Besides, not only functional changes impacts the running processes, but an update of the underlying BPEL engine may do so as well. Of course, if the number of instances increases, your problem gets worse too. Ever tried to restart a BPEL engine with 150.000 instances?
If it's a short running process, you could stop all incoming transactions for the specific process and wait for the running processes to finish before you upgrade the process to it's new version. Unfortunately life is usually not that simple.
Let's get back to the initial thought: is an SOA process driven or not? If you follow the scenario I sketched above, you might end up with one that is. What you should keep in mind while designing an SOA application, is that you have to look ahead to see what possible situations you need to able to handle. If you know beforehand that you will have a (very) large number of active processes, that they will be long-running and that they will very likely be subject to change, you might want to consider a different approach. Why? Because migrating running processes in a BPEL environment is a very hard thing to do (and expensive too). You will need to make allowances in your architecture to prevent problems.
In that scenario, a more event-driven or message-driven approach may be the answer. By loosely coupling the stages a process will go through, using either events or messages, you are a lot more flexible when it comes to migrating to new versions of a process(step). This will mean that your 'highest level' process will probably not be visible as a process in your BPEL engine, but the underlying steps may be. Again depending on the duration of the processes.
However, the more solutions I see, the less I believe it. Saying so, I realize I need to clarify that a bit more. Whenever you're building an SOA from the Business process downwards, it is smart to discover possible candidate services from your existing legacy environments (building upwards) so you can execute a 'meet in the middle approach'. This usually results in orchestrating business processes (with BPEL) and -simplified - composing composite services (based on atomic services from your legacy).
Is that bad? Not in itself, I think. It depends on the type and the number of processes. Suppose you have - on average - 50.000 running instances of a process. If you have to change that BPEL process you defined, what will you do? The first question to answer is: what do I need to do with my current active processes? Can they continue using the existing process or do the need to switch? Does it depend on the state they are in or not?
This problem gets worse the longer a process runs. It increases the chance that a process change will occur during the time it runs. Besides, not only functional changes impacts the running processes, but an update of the underlying BPEL engine may do so as well. Of course, if the number of instances increases, your problem gets worse too. Ever tried to restart a BPEL engine with 150.000 instances?
If it's a short running process, you could stop all incoming transactions for the specific process and wait for the running processes to finish before you upgrade the process to it's new version. Unfortunately life is usually not that simple.
Let's get back to the initial thought: is an SOA process driven or not? If you follow the scenario I sketched above, you might end up with one that is. What you should keep in mind while designing an SOA application, is that you have to look ahead to see what possible situations you need to able to handle. If you know beforehand that you will have a (very) large number of active processes, that they will be long-running and that they will very likely be subject to change, you might want to consider a different approach. Why? Because migrating running processes in a BPEL environment is a very hard thing to do (and expensive too). You will need to make allowances in your architecture to prevent problems.
In that scenario, a more event-driven or message-driven approach may be the answer. By loosely coupling the stages a process will go through, using either events or messages, you are a lot more flexible when it comes to migrating to new versions of a process(step). This will mean that your 'highest level' process will probably not be visible as a process in your BPEL engine, but the underlying steps may be. Again depending on the duration of the processes.
Oracle Fusion Middleware 11g Launch
Finally the date is known. July 1st will bring us Oracle Fusion Middleware 11g, immediately followed by a huge training program.
What will be delivered:
Oracle WebCenter Suite 11g: the long awaited Portal solution
Oracle WebLogic Suite 11g: BEA Weblogic Server the new middleware foundation
Oracle Identity Management 11g: Next level of security and compliance
Oracle SOA Suite 11g: a new, very tightly integrated environment to build service oriented applications.
What's missing? Oracle BPA Suite 11g, which will probably appear within 1 month.
The delayed delivery (we expected 11g to be released about a year ago) is mainly due to effort that went into the integration of BEA. Too bad that we had to wait, but in the end it is delivering us a whole lot more value. It was worth it! Enjoy 11g!
What will be delivered:
What's missing? Oracle BPA Suite 11g, which will probably appear within 1 month.
The delayed delivery (we expected 11g to be released about a year ago) is mainly due to effort that went into the integration of BEA. Too bad that we had to wait, but in the end it is delivering us a whole lot more value. It was worth it! Enjoy 11g!
Subscribe to:
Posts (Atom)