Re: [wsbpel] implicite links of the runtime engine

[Assaf Arkin <arkin@intalio.com>]

Fred Carter wrote:

> "Simple things should be simple."  If the /Hello, world/ of BPEL 
> requires a 2-star wizard (we'll reserve the 3 & 4 stars to other 
> needs), then one could argue that we've failed.

Hello world does require a 2-star wizard. You need to define your 
message using XML Schema, strap a WSDL operation onto that, add the 
protocol bindings so you can define an endpoint. When you link that to 
the BPEL make sure to use the proper references to the proper 
definitions disperesed throughout these documents, or it will not 
validate. And don't forget the deployment descriptor -- you won't be 
able to send/receive messages without it.

We can make BPEL as easy as HTML, you still won't be able to deploy it 
without tooling support. So if you look at the whole mix of 
specifications you have to deal with just to say "hello world", it 
really makes no difference. For the tools both options are the same, and 
for the vi user both options are impossible.

> Even if it's "executable" only, I'd argue as an implementer for 
> process-type things in a previous life :-), that having an engine 
> "knowing" that the intent is sequential may allow it to do a much 
> better job resource-wise, without being a very sophisticated system 
> (i.e. wider acceptance). 

That's a good argument.

My counter argument is that you need to build support for serializing 
activities that synchronize through links. It's not an easy task, but 
you'll have to do it anyway. If you already spent the time making flows 
work properly, might as well use that piece of code in all cases. If you 
write it once and use it all over the place then there's a good ROI 
argument in favor of using <flow> as much as possible. Less code to 
develop, less test cases, etc. At least from an execution perspective.

arkin