[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 11 - Editing 9.3.1
Executive Summary: This e-mail identifies two separate problems with the BPEL specification. The first problem is that the language in section 9.3.1 makes it effectively impossible to ever copy any data into a message type variable from any source other than another message type variable of identical type. This was never intended and the language needs to be amended so as to match the original intent. The second problem is that even if section 9.3.1 is fixed so that it says what the authors originally intended this would still prohibit a situation in which one could copy XML from a source whose schema is <ANY> to a destination whose schema is anything other than <ANY>. This is because 9.3.1 requires that the schema of a source either be identical to or a subtype of the destination's schema. This e-mail therefore proposes that: * The rules in 9.3.1 be altered so that the validation requirement read that the XML instance from the source must be valid against the schema of the destination regardless of the source's schema. * It be legal to copy entire messages of different types so long as the message structure and parts names of the source match the message structure and part names of the destination and the XML instance associated with each part in the source matches the schema in the matching part in the destination. * A new fault be introduced that would be thrown if a copy is attempted where the source's XML instance is not valid against the destination's schema. * The validation rules described in the three previous points be allowed for use with input/output variables for receive/invoke/reply. That is, one can submit an input/output variable whose message type is not identical to the message type of the associated operation so long as the type of the variable submitted is valid as defined in the previous three points. Long Winded Version: Let's imagine a programmer has a variable that contains a WSDL message that contains three parts, each part with some schema definition. We will call the variable REAL. The programmer wants to build up the value in REAL but needs to do so incrementally. The most natural thing for the programmer to do would be to create a variable called DUMMY which also has 3 parts but whose schema definition is 'ANY' for each part. Once the programmer is ready to send off a message the programmer could submit DUMMY as the input variable to an invoke. So long as DUMMY has the same number of parts with the same part names as expected by the invoke and so long as the contents of each part match against the schema for the outgoing message then everything should be fine. If there is a mismatch then a fault would be thrown. However this behavior is illegal in BPEL. I have to admit that I can't find the exact language in the BPEL spec which requires that input (and output) variables MUST be of the same message type as the message being sent or received but this is the intended BPEL requirement. That is why there is no fault for 'your input variable doesn't match the message schema for the identified operation'. Such a fault can never occur because static analysis would detect that the mismatch and reject the BPEL before it ever got a chance to run. But our intrepid programmer is not so easily bowed. He decides that instead of submitting DUMMY directly to the invoke he will instead issue a COPY of DUMMY to REAL and then submit REAL to the invoke. However this plan is also illegal in BPEL. Section 9.3.1, point 1 explicitly states that one cannot do an assignment between two variables with different WSDL message types, even if the syntaxes are compatible. But wait, our programmer isn't defeated quit yet, what he will do is issue three copies, one for each part in DUMMY and copy each part individually to REAL. There are a number of reasons to believe that even this is illegal. Reason #1 - The language in point 1 of section 9.3.1 provides a blanket ban on copying from one message type to another. No exceptions are made for cases where one is just copying a particular part of a message. Reason #2 - The language in point 3 of section 9.3.1 does allow for values from different schemas to be copied to each other but only if the source's schema is a subtype of the destination's schema. In this case the source's schema is <ANY> which is clearly not a sub-type of the destination's schema. Ahh, but our industrious programmer is still not quite beaten. He figures that what he can do is use a copy where the from spec is "expression" and then use the getVariableData function in an XPATH to copy the values from DUMMY and then point at REAL. Do this three times and he is done. Unfortunately, this is also illegal. Point #2 of section 9.3.1 explicitly forbids a situation in which a from/to is a WSDL message type and the other is not. In fact, given the language as it now exists in section 9.3.1 it looks like it is impossible to ever legally copy any value into a WSDL message type variable unless the source is another variable of exactly the same WSDL message type. Obviously this wasn't the intent and the language clearly needs to be fixed. What was intended however is that one could only copy data from a source to a destination if the source and destination's schemas are identical or if the source's schema is a sub-type of the destination's schema. There was never any intention that it would prevent legitimate behavior like copying a subsection of one value into another where the schemas exactly matched. Unfortunately the language in 9.3.1 does not actually say any of this and so needs to be modified. Even if 9.3.1 is fixed to match its intent and it is legal to copy any XML from any source to any destination so long as the schemas either match or the source is a sub-type of the destination our poor programmer is still in trouble. He cannot submit DUMMY directly to the invoke because its message type doesn't match. He cannot copy content from one part of DUMMY to its matching part in REAL because the schema for the DUMMY part is <ANY> which clearly isn't a sub-type of anything. About the only trick he might be able to pull off is to use expression and getVariableData to pull content out of DUMMY and put it into REAL but that will only work if the BPEL engine isn't sophisticated enough to associate schema with data retrieved through an XPATH function. In theory the BPEL engine could still detect the schema mismatch and reject the copy. In other words, you really can't get there from here. I would propose that the way forward is to introduce implicit casting into BPEL. Section 9.3.1 should be re-written to have a two level matching restriction. If the destination is an entire WSDL message (e.g. there is no part specified) then the source MUST have the same message structure and part names (but not necessarily message type) as the destination. In all cases when moving XML from source to destination the XML from the source MUST be validated against the schema of the destination. If the source's XML does validate against the destination's schema, regardless of the schema of the source, then the copy is allowed. I would also propose that we apply these same rules for receive/invoke/reply so that both input and output variables that have a matching message structure but different schemas can be used so long as schema validation works as described above. In this way the programmer could submit DUMMY directly to the invoke and so long as the parts and schemas validate against the operation's message definition then all is fine. If not, we will introduce a new exception that will then be thrown. Yaron P.S. Did you really read this far? =)
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]