[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 87 - Proposal for Vote - Part 1
I guess we disagree on whether it needs to be at the WSDL level as well. Satish -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Monday, October 11, 2004 1:00 PM To: Satish Thatte Cc: Eckenfels. Bernd; wsbpeltc Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1 The extension would be at the BPEL not WSDL level but yes. Satish Thatte wrote: > > > Do you mean we should design a WSDL 1.1 extension for port type > (input/output) specification that mimics the WSDL 2.0 app data > feature, and mandate its use as a part of the BPEL spec? > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Wednesday, October 06, 2004 2:58 PM > To: Satish Thatte > Cc: Eckenfels. Bernd; wsbpeltc > Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1 > > Given in this case that there is no conflict between the WSDL 2.0 > feature and WSDL 1.1 why not simply adopt the solution to fix the > problem? There is no backwards compatibility issue. WSDL 2.0 simply > came up with a solution that applies as well to WSDL 1.1 as it does to > WSDL 2.0 so why not avail ourselves of their work? > > Satish Thatte wrote: > > > > > > We all recognize the WSDL 1.1 has flaws and limitations. > > > > Regarding the app data feature in WSDL 2.0, as you know that is a > part > of the abstract web service interface specification, not magic > in the > binding > > (http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#app-data). > > And as you have pointed out, WSDL 2.0 is not backwards compatible > with > WSDL 1.1. Although many WSDL 2.0 features may be interesting > and > valuable to us, I don't think we can or should emulate WSDL 2.0 > features > given our WSDL 1.1 dependency. > > > > Satish > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Wednesday, > October 06, 2004 9:53 AM > To: Satish Thatte > Cc: Eckenfels. Bernd; > wsbpeltc > Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - > Part 1 > > Because there is a flaw in WSDL 1.1 that doesn't allow > for optional > parts. This means that WSDL 1.1 is unable to support > scenarios that > involve: > > > > Optional Intermediaries (e.g. sometimes an intermediary is on the > > message path and sometimes not) > > Up-version Clients (Additional > SOAP headers are typically used to > provide for new backwards > compatible features) > > Even if the optional parts support was > added it still wouldn't be > sufficient as it wouldn't support: > > > > Query and Log of Unexpected Data (Dynamic filter systems can often > take > advantage of 'unexpected' data. A classic example are the spam > headers > used by systems like SPAM Assassin which mail clients can > use even > without understanding them thanks to filters. Similar > issues exist if > the client needs to log data.) > > Semantic Web > Scenarios (RDF and OWL allow one to understand data in a > format > that one wasn't expecting by inference with known data. But this > > only works if one can get to the unexpected data. Something WSDL 1.1 > > can't handle) > > This problem was recognized by the WSDL 2.0 > working group and it is they > who added the application data feature > to work around it. I just adapted > their work for BPEL. > > > > Yaron > > > > Satish Thatte wrote: > > > > > > If the extra data is binding dependent how can the process logic > rely on > > it? Processes should not be binding dependent. If the > data is binding > > invariant then why is it not in the abstract > port type? As we said in > > the discussion of issue 77, if the > port (or message) type is incomplete, > > you can add a "shim" port > type that will provide what you need. > It is > > > not BPEL's business to fix your abstract interface for you. > > > > > > *From:* Yaron Y. Goland [mailto:ygoland@bea.com] > > *Sent:* > Tue 10/5/2004 4:45 PM > > *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/leave_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/leave_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/leave_workgroup.php. > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]