[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]