- Service boundaries are absolute they "how" techniques can
- Alter internal state
- Invoke external services
- They cannot
- Contain activities that are internal to another service
In this way there is no Process to Service mapping, but Service acts as a container for process, and process is the mechanism via which the capabilities of that service are realised.
The next challenge is how to model these processes within a service context. First challenge is the current tools aren't set up to do this, they like to model process as the ultimate goal and they haven't yet got to modelling business as services. This means we have to do a few work arounds. The first option is to use service models, as per the methodology, to indicate the orchestration of services to deliver capability.
If using BPMN rather than modelling the whole end to end process model the overall execution process (the numbers on the diagram) and model EACH of the invocations as individual process. Do NOT try and model this has a massive process with lots of swim lanes. This will make the transition to services harder as these process models will cross service boundaries within one process model. The challenge is to be able to create these end-to-end processes as views rather than as models, again the tools don't really help here at the moment as they are process oriented rather than service oriented.
All this is at the level at which process is a series of activities. This isn't the only level at which process and service need to interact, the other level is where process describes a broad area like "buy" which means all of those processes releated to buying. At this level the terms service and process can be reasonably interchangable because they both are used to describe broad areas. The key therefore is to identify the points at which process stops being about broad areas and about stringing activities together.
In an enterprise model this often occurs between level 2 and 3, but this isn't a fixed point so you need to be careful.So in summary : Broad area process is pretty much interchangable with service, activity and orchestration processes are contained by services and implement capabilities of those services.
Technorati Tags: SOA, Business Process, BPMN, Service Architecture
9 comments:
Coming from the BPM side, I'm often asked about SOA and BPM (which is the same service and process discussion, but on a different level). My response is that SOA provides the design philosophy and enterprise context for building services, and BPM orchestrates those services. In other words, I see process primarily as the orchestration of services, not the means for delivering the capability within a service, although either could occur.
The reason why I disagree with that as an approach is that it makes process and service two divergent things. No one would suggest that Java should be used to only orchestrate services, though functionally its equally able to do that as a process language, and I don't see why process languages should be treated so differently. This is paticularly the case if you consider service as a business driven concept rather than a technical aggregation.
Of course the challenge is at the moment that BPM vendors haven't managed to get the trick yet of combining multiple processes behind a single interface. Its this technical failing that IMO is more responsible for the separation of Process layers and Service layers than any sensible architectural decisions.
Nice post though, I just disagree that service "stop" at a given level, for me they go right to the top.
If you consider service and process as concepts, not as particular technologies, then I agree that they're more intertwined than my description. My comment was about my standard response when people ask me about SOA (which is a philosophy) and BPM (which is a technology, regardless of what Gartner says about it), which is sort of like asking the difference between purple and cats.
What do you mean by "combining multiple processes behind a single interface" wrt BPM vendors?
What I mean is that if you a service (.g. for HR) that has 4 capabilities (onboard, fire, promote, resign) and you want to implement these as processes then you have a problem.
Most of the tools (in fact I think everyone of them) allows you to design the four processes, and (for the BPEL tools) create ONE WSDL for EACH of the processes. What you can't do is select the FOUR processes and create a single interface with FOUR invocation points. This is (IMO) rubbish as it means that lower level languages like Java are better able to create good business service interfaces than higher level languages!
Well, you could create the four as subprocesses in a single process using a pure-play BPM tool. Most of the tools would allow all of the activities to be defined in a single large process with multiple invocation points, or a single invocation point that branches to any of the multiple subprocesses based on passed parameters.
Nice! Where you get this guestbook? I want the same script.. Awesome content. thankyou.
»
But the problem with having a single process with multiple sub-processes is that this is a work-around for the basic challenge. You really want multiple processes behind a single interface. Lets take an example
Add Customer
Delete Customer
Update Customer
Get Customer
These are four distinct processes, which should clearly be behind a single "CustomerService" interface. Having a "CustomerService" process makes very little sense, especially as step one is either "TypeOfRequest" or worst still it branches and waits for one of four invocations to determine what it should do.
These four process are related in that they share context, they are quite clearly not the same processes. Having work arounds in the tools is crazy when all they need is a simple "Select four processes, right click, select generate interface" or "Attach process to interface" or "Generate process for interface method(s)". Its not rocket science but the BPM folks haven't got as far as Visual Basic developers.
Hi! Just want to say what a nice site. Bye, see you soon.
»
Just for the record, in BPEL the receive_choice mechanism allows one to implement multiple operations on a single interface.
Essentially, you have one logical BPEL process that contains multiple paths, at runtime, each path executes as an atomic process in a separate thread from the other paths...
Post a Comment