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


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]