OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]