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 - Editing 9.3.1

+1.  but i respectfully request that you open another issue number for this.
i think this is the third bona fide important issue that is known as issue

> P.S. Did you really read this far? =)

of course i did.  it was spellbinding.

----- Original Message ----- 
From: "Yaron Goland" <ygoland@bea.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, August 08, 2003 3:33 PM
Subject: [wsbpel] 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
> This was never intended and the language needs to be amended so as to
> 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>
> 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
> 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
> 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
> in the previous three points.
> Long Winded Version:
> Let's imagine a programmer has a variable that contains a WSDL message
> 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
> 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
> 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
> 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
> fault for 'your input variable doesn't match the message schema for the
> identified operation'. Such a fault can never occur because static
> 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
> 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 als
> illegal in BPEL. Section 9.3.1, point 1 explicitly states that one cannot
> an assignment between two variables with different WSDL message types,
> 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
> 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
> 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
> 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
> is not.
> In fact, given the language as it now exists in section 9.3.1 it looks
> 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
> What was intended however is that one could only copy data from a source
> 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
> 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
> 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
> 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
> to pull off is to use expression and getVariableData to pull content out
> DUMMY and put it into REAL but that will only work if the BPEL engine
> 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
> 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
> 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
> will then be thrown.
> Yaron
> P.S. Did you really read this far? =)


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