[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] implicite links of the runtime engine
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]