Re: [wsbpel] implicite links of the runtime engine

[Assaf Arkin <arkin@intalio.com>]

Ron Ten-Hove wrote:

> 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.

+1

> 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?

The question of all questions? ;-)

We need to draw a line in the sand and decide how the language is going 
to be used. If there's any intent for XML authoring than the language 
should accomodate changes that assist in XML authoring (some of which 
were discussed before). If there's any intent for using BPEL for 
high-level representation than it needs to accommodate visual notation. 
If it's purely an execution language then it should only include the 
minimal set of constructs required to represent activities and their 
dependent order of execution.

The modeling tool should not have a problem taking a sequence of 
activities and generating a flow out of that. Modeling tools are 
generally designed to link activities together - the links are already 
part of the visual model. The engine wouldn't have a problem either, a 
sequence of activities is just a chain of activities where the 
completion of one triggers the start of another.

arkin

>
> Cheers,
> -Ron
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org