[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 87.1 - Proposal for Vote - Part 1
Following discussion in the issues subgroup, I've split issue 87, with Yaron's proposal applied to the subissue 87.1, and the residuum left as 87, which reverts to open (since I've taken it that the earlier proposal is now withdrawn) If further follow-ups on Yaron's 28 Sept proposal change the subject line number to 87.1, or are replies to this message, the issue list scripts will assign them correctly. The issue splitting is still a bit experimental, but if a proposal is consciously for only part of the issue, could they state this in the text, and summarise what part is covered, and I'll split out a sub-issue. Peter > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: 06 October 2004 00:46 > To: Eckenfels. Bernd > Cc: wsbpeltc > Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1 > > > In your case issue 87 wouldn't apply because you model the > binary data > as a WSDL part. > > 87 only applies to data that is in a message, is not > associated with a > part and that the binding chooses to make available. > > A classic example of how to use this feature are optional > headers. For > example, if someone is using SOAP and wants to have an optional SOAP > header they are out of luck because it is impossible to model > optional > headers using WSDL message parts and the standardized > SOAP/WSDL binding. > Parts are always mandatory therefore if a header is optional > it cannot > be modeled as a part. > > A similar problem exists with HTTP and SMTP. Both of those bindings > support optional headers but WSDL isn't currently able to express the > optionality at the part layer. > > Issue 87 gets around this problem by providing another point at which > one can get access to message information. The non-bound parts of the > message would show up inside of the ApplicationData > container. How this > would occur would be binding specific. > > Thanks, > > Yaron > > > > Eckenfels. Bernd wrote: > > > > > > Hello Yaron, > > > > in our engine we have a similiar extension, which allows us to > > transport > > binary (attachment) data. However we do this inside the > WSDL limits, and > > require a part to be defined of a special type. > Essentially this part > > carries the reference id to the binary attachment. When > receiving the > > id, you are free to assign it to any outgoing mesage, which will > > automatically attach the binary (in a somewhat lazy fashion). > > > > I am not sure if using a element outside the usual WSDL > possibilities > > is > > a good ideas since that is somewaht against the idea of > well defined > > services. Perhaps you have a practical example for your extension? > > > > Mit freundlichen Grüßen > > Bernd Eckenfels > > Chief Architect > > -- > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > mailto:b.eckenfels@seeburger.de - http://www.seeburger.de > > > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Tuesday, September 28, 2004 8:36 PM > > To: wsbpeltc > > Subject: [wsbpel] Issue - 87 - Proposal for Vote - Part 1 > > > > > > The original proposal for vote contained two parts, one > that defined > > the generic mechanism and another that specified language > for specific > > bindings. In order to allow us to make forward progress I > am removing > > the section on specific bindings for this vote and instead just > > focusing on the mechanism. This vote will not close issue > 87 as, if it > > is passed, we will still need to decide if we wish to address any > > binding specific issues. > > > > 14.9 Application Data > > > > Application data is data transmitted in a message outside > > of the normal message channel, specifically data in a > message that is > > not bound to a WSDL message part referenced in the > portType/operation > > definition that applies to the sent or received message. > > > > To enable BPEL processes to access application data the > from-spec is > > extended to include: > > > > <from appDataForMessage="ncname"/> > > > > The value of the appDataForMessage attribute MUST be the name of a > > WSDL message type variable. The output of this from-spec > will always > > follow the schema: > > > > <element name="applicationData" type="bpws:tApplicationData"> > > > > <complexType name="tApplicationData"> > > <sequence> > > <any processContents="lax" minOccurs="0" > maxOccurs="unbounded"/> > > </sequence> > > <anyAttribute processContents="lax"/> > > </complexType> > > > > The application data will be recorded inside of the applicationData > > XML element. > > > > To enable BPEL processes to set application data the to-spec is > > extended to include: > > > > <to appDataForMessage="ncname"/> > > > > The schema of the data assigned using this to-spec MUST follow the > > previously defined schema or a > bpws:mismatchedAssignmentFailure MUST > > be thrown. > > > > When a message is received by the BPEL process any application data > > associated with the message MUST be made available via the > application > > data from-spec. The exact means by which application data > is retrieved > > from a message is binding specific and the binding definition has > > final say as to what data will appear as application data but in > > general any parts of the incoming message that do not have > bindings to > > specific WSDL message parts are considered application > data. Similarly > > when a message is sent if any application data has been associated > > with the message then the application data MUST be sent with the > > outgoing message using the rules defined for the particular > binding in > > use. > > > > Any application data associated with a WSDL message type > variable is > > replaced with application data from the incoming message, if any, > > whenever that variable is used to receive a new message. > > > > Schema Changes: > > > > Add to tFrom: > > > > <attribute name="appDataForMessage" type="NCName"/> > > > > Add to to: > > > > <attribute name="appDataForMessage" type="NCName"/> > > > > To unsubscribe from this mailing list (and be removed from > the roster > > of > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgroup.php. > > > > > > > > To unsubscribe from this mailing list (and be removed from > the roster > > of > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgroup.php. > > > > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgroup.php. > > Choreology Anti virus scan completed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]