Comments on: BPEL Bashing Redux: Seeking a Middle Ground http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/ Bruce Silver's blog on business process management Sat, 27 Feb 2010 10:22:38 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Change is nothing, everything is. » BPM vs SOA and where BPEL fits in http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-299 Change is nothing, everything is. » BPM vs SOA and where BPEL fits in Thu, 23 Nov 2006 13:00:55 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-299 [...] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “BPEL is really good for orchestrating business services out of fine-grained APIs — how SOA uses orchestration. It’s less good — although it can do it — for orchestrating end-to-end business processes.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). [...] [...] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “BPEL is really good for orchestrating business services out of fine-grained APIs — how SOA uses orchestration. It’s less good — although it can do it — for orchestrating end-to-end business processes.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). [...]

]]> By: jonas http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-244 jonas Wed, 04 Oct 2006 12:22:12 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-244 <blockquote cite="">"Human tasks are different from services in 2 ways."</blockquote> Take for example a tele-marketing scenario where a sales person calls up a potential customer and makes him buy stuff. Her work can be defined in a workflow with a lot of decision making through out the phone call. She can make the decisions but the workflow decides what the continuation will be. She will interact with the process using calls into the process, and receive tasks from the process. This is actually not different from how a system process works. The assignment is called routing in relation to SOA, a role is called interface, and the human is called the endpoint. I don't even see why we cannot use the same repository for both roles, interfaces, humans, and endpoints. Why should a service be stateless? A call to a long-running process will be similar to a long-running task. The human will call back into the process the same way as a sub-process would do for updating the state of the job. <blockquote cite="">"For example, if the calling service has to terminate while the ’subprocess’ is running, how does the subprocess get terminated?"</blockquote> Wouldn't just the terminated caller process compensate the sub-process from within a compensation handler?

“Human tasks are different from services in 2 ways.”

Take for example a tele-marketing scenario where a sales person calls up a potential customer and makes him buy stuff. Her work can be defined in a workflow with a lot of decision making through out the phone call. She can make the decisions but the workflow decides what the continuation will be. She will interact with the process using calls into the process, and receive tasks from the process. This is actually not different from how a system process works.

The assignment is called routing in relation to SOA, a role is called interface, and the human is called the endpoint. I don’t even see why we cannot use the same repository for both roles, interfaces, humans, and endpoints.

Why should a service be stateless? A call to a long-running process will be similar to a long-running task. The human will call back into the process the same way as a sub-process would do for updating the state of the job.

“For example, if the calling service has to terminate while the ’subprocess’ is running, how does the subprocess get terminated?”

Wouldn’t just the terminated caller process compensate the sub-process from within a compensation handler?

]]> By: bruce http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-242 bruce Tue, 03 Oct 2006 15:34:51 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-242 Jonas, Good questions. Human tasks are different from services in 2 ways. First, they are assigned to roles (mapped at runtime to users or groups) not service endpoints (URLs). Second, they are inherently stateful: ready, claimed, done, failed (e.g., see the BPEL4People white paper), whereas services are (from the consumer's perspective) inherently stateless. The way these are handled in BPEL-based BPMSs is typically via a vendor-proprietary Task Manager service or a vendor-proprietary BPEL extension. In the first of these, BPEL creates tasks by invoking the Task Manager service, and those tasks are performed by users interacting with that service. When the task is done, the service calls back the process. Effectively I suppose you could call that a human-performed service, except that the details of the task are unknown to BPEL and it's all vendor-proprietary. Similarly for subprocesses. You can certainly define a second BPEL process and invoke it as a service from the first process, but there is no lifecycle coordination between them. For example, if the calling service has to terminate while the 'subprocess' is running, how does the subprocess get terminated? If there is a business transaction involved, how does compensation get triggered? You can do it with custom programming but it's not built into the language. These are the reasons IBM and SAP last year offeredthe BPEL4People and BPEL-SPE proposals -- which supposedly will become draft specs once BPEL 2.0 is put to bed. The fact that they are pitched as "optional extensions" says there is still a sizable (majority?) segment of the BPEL community that couldn't care less about these "BPM" concerns. Jonas,
Good questions. Human tasks are different from services in 2 ways. First, they are assigned to roles (mapped at runtime to users or groups) not service endpoints (URLs). Second, they are inherently stateful: ready, claimed, done, failed (e.g., see the BPEL4People white paper), whereas services are (from the consumer’s perspective) inherently stateless. The way these are handled in BPEL-based BPMSs is typically via a vendor-proprietary Task Manager service or a vendor-proprietary BPEL extension. In the first of these, BPEL creates tasks by invoking the Task Manager service, and those tasks are performed by users interacting with that service. When the task is done, the service calls back the process. Effectively I suppose you could call that a human-performed service, except that the details of the task are unknown to BPEL and it’s all vendor-proprietary.

Similarly for subprocesses. You can certainly define a second BPEL process and invoke it as a service from the first process, but there is no lifecycle coordination between them. For example, if the calling service has to terminate while the ’subprocess’ is running, how does the subprocess get terminated? If there is a business transaction involved, how does compensation get triggered? You can do it with custom programming but it’s not built into the language.

These are the reasons IBM and SAP last year offeredthe BPEL4People and BPEL-SPE proposals — which supposedly will become draft specs once BPEL 2.0 is put to bed. The fact that they are pitched as “optional extensions” says there is still a sizable (majority?) segment of the BPEL community that couldn’t care less about these “BPM” concerns.

]]> By: jonas http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-241 jonas Tue, 03 Oct 2006 13:32:13 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-241 Hello, <blockquote cite="">So how can you use an orchestration language without support for human tasks and subprocesses?</blockquote> What's the difference between orchestrating human tasks and system tasks? Behind a service there can be a human, cant it? A human can call a process as a service, cant she? A sub-process is just another service, isn't it? Are there any scenarios where abstracting services as sub-processer is ineffective? - <a href="http://moveflow.blogspot.com/" rel="nofollow">Jonas</a> Hello,

So how can you use an orchestration language without support for human tasks and subprocesses?

What’s the difference between orchestrating human tasks and system tasks? Behind a service there can be a human, cant it? A human can call a process as a service, cant she?

A sub-process is just another service, isn’t it? Are there any scenarios where abstracting services as sub-processer is ineffective?

- Jonas

]]> By: BPMS Watch » Watch Out for Oracle http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-240 BPMS Watch » Watch Out for Oracle Mon, 02 Oct 2006 20:59:56 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-240 [...] OK, so far that sounds like a complete, but not especially cool, BPMS offering.  Here’s the cool part, and it goes back to the recent BPEL discussion.  Remember, a problem with BPEL in BPM has always been keeping the executable design in sync with the business analyst’s model once the developer has taken a whack at it — the notorious roundtripping problem.  Oracle has solved that here with the Business Process Outline - a model that sits in between BPA (ARIS) and BPEL, with unambiguous mappings to both, and intelligible to business as well as IT.  They described their conception of it last spring in Business Integration Journal, and I blogged about it then.  But it’s place in the offering was not at all clear back then.  Now it is. [...] [...] OK, so far that sounds like a complete, but not especially cool, BPMS offering.  Here’s the cool part, and it goes back to the recent BPEL discussion.  Remember, a problem with BPEL in BPM has always been keeping the executable design in sync with the business analyst’s model once the developer has taken a whack at it — the notorious roundtripping problem.  Oracle has solved that here with the Business Process Outline – a model that sits in between BPA (ARIS) and BPEL, with unambiguous mappings to both, and intelligible to business as well as IT.  They described their conception of it last spring in Business Integration Journal, and I blogged about it then.  But it’s place in the offering was not at all clear back then.  Now it is. [...]

]]> By: Age of programmable business networks « Utterances of a Zimboe http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-235 Age of programmable business networks « Utterances of a Zimboe Wed, 27 Sep 2006 17:20:36 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-235 [...] But yay, now we’re going to have a very nice orchestration and integration topping over all this web services offering. Long live REST and SOAP! And remember kids, REST is for noobs and SOAP is for the leet. And what’s with all the BPEL bashing? (Nice redux, btw.) I think all this antagonism is a bit off-course. Going little off-topic here (like I was having any… harrr!) but I preserve the right to include this reminder: “BPEL is the XML glue that binds Web Services into cohesive units [and so on].” Isn’t that just great or what? Just all you enterprisey folks keep your durrty BPM hands off of this nice web services programming language. The 2.0 is already working well. All the transportability etc. might be nice extra features, but not that critical – for me, at least, which admittedly may not be much. Well, on the other hand, I’m the developer programmer… [...] [...] But yay, now we’re going to have a very nice orchestration and integration topping over all this web services offering. Long live REST and SOAP! And remember kids, REST is for noobs and SOAP is for the leet. And what’s with all the BPEL bashing? (Nice redux, btw.) I think all this antagonism is a bit off-course. Going little off-topic here (like I was having any… harrr!) but I preserve the right to include this reminder: “BPEL is the XML glue that binds Web Services into cohesive units [and so on].” Isn’t that just great or what? Just all you enterprisey folks keep your durrty BPM hands off of this nice web services programming language. The 2.0 is already working well. All the transportability etc. might be nice extra features, but not that critical – for me, at least, which admittedly may not be much. Well, on the other hand, I’m the developer programmer… [...]

]]> By: Change is nothing, everything is. » More on BPM vs SOA and where BPEL fits in http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/comment-page-1/#comment-234 Change is nothing, everything is. » More on BPM vs SOA and where BPEL fits in Wed, 27 Sep 2006 10:46:02 +0000 http://www.brsilver.com/wordpress/2006/09/26/bpel-bashing-redux-seeking-a-middle-ground/#comment-234 [...] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “BPEL is really good for orchestrating business services out of fine-grained APIs — how SOA uses orchestration. It’s less good — although it can do it — for orchestrating end-to-end business processes.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). [...] [...] In another, more recently, post from Bruce, he talks about BPEL: “Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well?”. Further he goes on saying “BPEL is really good for orchestrating business services out of fine-grained APIs — how SOA uses orchestration. It’s less good — although it can do it — for orchestrating end-to-end business processes.”. And I think I agree with him on that on, because BPEL has already proved its lack of portability and everyone that has taken a look at the specification knows that the simplicity is no longer a design goal here (the BPEL 2.0 standard are even not backwards compatible, more on BPEL here). So, further I agree with Bruce that BPMN-model should be the best way to model and make portable business processes. Different platforms and vendors then have differents techniques for implementing/converting these models into a executable process language (like BPEL or something else). [...]

]]>