Should 'Process Visibility' be a service?
It has been my experience that most people who look at BPEL solutions want a combination of the following:
1. A way to combine multiple web services into a single service (composition).
2. A method to explicitly define the flow of control between activities (or steps) in a business process.
3. The ability for management to know what step or state a process is in.
Number 3 is the Use Case for 'Process Visibility'. So, how do you do this as a service? Well, you still have to identify all of the activities to the degree in which you are interested in visibility. You also have to identify combinations of 'interesting state'. For example, if an order for a part comes in and no inventory is available for that part, well - that is interesting. This becomes a declarative rule applied towards a handful of variable to define a single state of interest. Also, anyone that is participating in providing visibility must be able to identify which instance of a process they are talking about, thus the equivalent of a correlation token must be used.
I'm thinking something like this:
Key=(ProcessID, InstanceID, CorrelationTokens)
updateProcessData( Key, SomeData)
It would be easy enough to turn this into an aspect (AOP) in a BPEL engine - but I'm not so sure that you want to bottleneck these calls. I do think it should be an aspect but invoked at the event source.
Now that you have a service that is collecting data across a distributed environment, it must tell others about the 'interesting states' that it has encountered. That sounds like a pub/sub problem to me.
I don't know... maybe something like this:
subscribeProcess(ProcessId, StateID, StateOfInterest)
(This implies that it is interested in all process instances that achieve a certain state.) Obviously, the BAM system would end up being a subscriber to this.
Hmmm... interesting. Now we have a state machine firing when certain states of interest are achieved.
Next up: 'Flow Control as Metadata', followed by 'Service Oriented Metadata'