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