[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro)
> I'm putting out a particular opinion in the understanding that the > specification is geared towards the definition of executable processes. > Is that a wrong assumption? We obviously support and will continue to support both abstract and executable processes. Abstract processes are clearly not relevant only to execution engines. As Yaron has pointed out, even execution oriented BPEL models will be looked at and modified by humans whatever our intention or recommendation. > For the record we looked at this long and hard within the context of > BPML. Does BPML have a notion of links and graphs? I must have missed that. Satish -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Friday, June 20, 2003 1:13 PM To: Satish Thatte Cc: Ron Ten-Hove; Maciej Szefler; Eckenfels. Bernd; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro) Satish Thatte wrote: >Not sure what you are proposing here - Pi calc linked to WSDL with a >couple of your rules? > > On the contrary. I've justified my criteria by looking at the possibilty of going all the way down to pi-calculus linked to WSDL, and rejected it on the grounds that while it actually does not reduce the number of constructs and if anything further complicates the specification. >Please keep in mind that no matter what criteria you have for >minimality, it is extremely unlikely that the resulting "minimal feature >set" will be unique. > Agreed. I think what we lack here is coherence. If we are not striving for a minimal feature set than there are others features we should entertain that would simplify some definitions especially from the perspective of modeling and/or XML authoring. If we are looking for a minimal feature set what are our criteria? Is that strictly to address execution or do we need to look at a larger scope? >I have heard people argue rather vociferously that links should be >dropped (rather than sequence). This is clearly possible if you do all >intra and inter process synchronization uniformly through messaging, >letting the implementation optimize the intra-process case, rather the >way you are proposing that the implementation should optimize the >sequential case. > So did I, but I could not imagine how that would simplify the specification. For the record we looked at this long and hard within the context of BPML. For the engine it makes absolutely no difference and the engine can definitely optimize intra-process messaging. But does it make the specification simpler? On the contrary. Not only do you have to define the same semantics of links, but you have to define a set of constraints to ensure proper usage of messaging, and the resulting language ends being more complex to define and test. So speaking purely from my experience having done this before I would suggest we don't do down this path a second time. >So where would that leave us? My minimal set is better than yours >because "From an execution perspective I have a strict preferrence for >linking activities approach and always did"? > > With the open question of what criteria we use to judge which constructs are part of the specification. I am not going to say that my opinion is valid in all possible contexts. In other contexts I would have a different set of requirements and may actually favor having more language constructs. I am sure other members also have a list of requirements that are context sensitive. I'm putting out a particular opinion in the understanding that the specification is geared towards the definition of executable processes. Is that a wrong assumption? arkin >Satish > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]