Re: [wsbpel] implicite links of the runtime engine (was: Implicit<sequence> macro)

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Fred Carter wrote:

> Thus quoth Ron Ten-Hove (~ 17-Jun-03 2:08 PM ~)...
>
>>     If BPEL were to be strictly a modelling language, then the 
>> inclusion of both <sequence> and <flow> would be justifiable from the 
>> modelling perspective. Perhaps we can make this claim for abstract BPEL?
>>
>>     On the other hand, "concrete" BPEL has a different purpose: it is 
>> an /executable /description of a process. It may be appropriate for 
>> the TC to create a formal semantics for the execution of each BPEL 
>> element, in order that we may analyse and better understand what we 
>> are creating. Even if we don't go as far as formalising the 
>> semantics, it is true that the simpler the language, the easier it is 
>> to reason about. 
>
>
> That may be true, but I think it's also the case that a specific, 
> well-understood, definition is likely to engender greater acceptance. 
> Having to "figure out" how to say "please do these things one after 
> the other" seems odd.
>
> "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. 

Agreed -- and  this brings us back to the "how do we author BPEL 
documents?" question again. I would submit that if the process author 
has no more sophisticated an authoring tool than vi or emacs, wizardry 
will be required regardless. Managing information from assorted WSDL 
documents, complying to one or more abstract BPEL processes, and sorting 
through a relatively complex syntax (XML serialization being what it 
is), we have already restricted the pool of authors to a relatively 
small one (with all the right skill sets). Even hello world, aided by 
syntactic sweeteners, becomes a headache.

On the other hand, if the process author is aided by auitably helpful 
tools, then the amount of detail he/she need manage can be reduced. If 
they are faced with authoring process graphs, suitably annotated, and 
BPEL exists safely behind the scence, then the BPEL language can be 
optimized to improve important aspects of a process language, rather 
than raw-text authoring.

>
>
>
>>                                                             From this 
>> perspective, it is entirely appropriate for Arkin to ask that the 
>> <sequence> activity justify its existence, when equivalent structures 
>> exist elsewhere
>>
>>     So what is our rational moving forward? Is this (primarily) a 
>> modelling language, or an executable artifact? Or are there better 
>> criteria for resolving these issues?
>
> I would further argue that the closer the modelling is to the 
> implementation, the more likely they are to accomplish similar things.
>
> 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). 

[For those who may not know, which is likely a majority: Fred and I used 
to work together on some BPM and EAI products.]

Your example is a good one. A high-level process graph is typically not 
directly executed, but rather converted / compiled to be executed atop a 
purpose-built infrastructure. Human-friendly structures are converted 
into ones amenable to execution by machine.

The question is -- where does BPEL fit in this? Is it a high-level 
representation, suitable for modelling processes in a fashion that a 
business analyst (or other such domain expert) want? Or is it an 
intermediate form, with well understood execution semantics? Or is it a 
little of both? If the last choice is correct, then what principles will 
be used to choose between the dual poles of representing high-level 
domain concepts, and simple executable semantics?

Cheers,
-Ron