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.
Posts
Installing Soa Suite 10.1.3.5.1 on Weblogic
2 days ago
9 reacties:
Hi Mike,
Recognise the challenges you describe. Some additional thoughts and asepcts on bit.ly/GdU7i
"...is an SOA process driven or not?"
SO is service driven. Identification of services probably needs to steer away from existing process definitions--that would be a process-oriented approach, correct?
Processes may end up using services but service identification and definition should be largely independent from the processes (stateless, no assumptions about the nature of the consumer, etc.)
"SOA: Process driven, message driven or event driven?"
SO is service driven and is a style, not an architecture. A business architecture or enterprise architecture can be all of these and more. Focus on BA/EA (or whatever level fits), not on SOA. Make those follow SO principles.
Nice point you make, Rob. SO and SOA are two different issues. I'm not sure that you cannot use a process driven approach to discover and identify services. After all, a (business) service has to be identified by the need for such a service. Such a need can be easily identified by having a close look at existing processes.
Other services to be discovered are external (for example a service from a chainpartner) or capabilities of internal applications.
The point I'm trying to make is that I used to identify services purely by looking at either the process or the existing applications. And yes, you usually end up having some statefull services (high level process services), that use functional stateless services. It's especially those statefull services that generates the troubles.
Mike, are you using SOA in the context of an entire value chain or just "the service" itself?
The services should indeed be loosely coupled.
To me NOT having the high level business process as part of a BPM tool where the "business person/analyst) can make the changes to the process makes SOA otherwise useless and misses the point on all levels.
The bpmn process maps are both event and message based so I think it is just which piece of SOA value chain you or another is specifically under consideration. Good subject though. Thanks.
have no idea wat u r talking about, wat is an SO and wat is an SOA
@Anonymous: SOA exists in my opinion only in the context of the entire organization, as it is an Architecture. Service orientation concepts are used on all levels.
BPM is a prerequisite for any enterprise wide SOA initiative. Tooling to go from BPM to executable processes is sadly lacking. Attempts to go from BPM to BPEL fail due to the different abstraction levels of both techniques.
I do agree that bpmn process maps are both event and message based. It's a very important concept when translating a business process to an executable process. I'm planning on doing a post on that subject soon. So stay in touch.
Great hearing more people recognizing the synergy between EDA and SOA. I've got a blog post up describing how those higher level services collaborate using events here:
http://www.UdiDahan.com/2008/11/01/soa-eda-and-cep-a-winning-combo/
Would be great hearing your thoughts on it.
I like the works, Udi. I agree on most points, save for the need for an ESB.
The combination of SOA and EDA is a very strong concept, in my point of view. It combines the more predefined process approach of SOA with a more dynamic, proactive approach that comes with EDA.
Post a Comment