[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Call for Discussion
Yaron Y. Goland wrote: > DOM is a completely untyped API. BPEL is a heavily typed language. The > two don't go well together. As soon as someone needs to perform a > manipulation that requires two or more steps, the intermediate steps > placing the target variable in an inconsistent state, BPEL's typing > rules will be violated. This then leads us to introducing some kind of > magic scope where the validation rules aren't enforced. But that leads > to the problem of what happens if a fault occurs inside of the magic > scope? This then leads us to introduce transactions into BPEL. Yuck. This is why <assign> is atomic. The intermediate states are never exposed. > > As for XUPDATE, its mandate is to deal with how to perform XML > manipulations in heavily typed environments. Therefore it is a much > better match for BPEL's needs than the DOM and therefore when it is > released it will probably quickly replace DOM usage in BPEL. > > As for companion languages, for a companion language to BPEL to be > useful it must be able to see and manipulate BPEL variables. So it > seems reasonable to expect to be able to drop down into the companion > language, manipulate the BPEL variables using the companion language's > XML manipulation facilities and then pop back up into BPEL. Is it your assertion that we should create a standard that MUST be supplemented by an unspecified companion language, in order to create executable processes? -Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]