Paco, you say:
> the WSDL service was badly designed (because business and quality of
> service data were not appropriately factored)
Please find me a quote from WSDL 1.1 or SOAP 1.1 that says that business information only goes in the body and QoS information only goes in the headers. I cannot find any.
SOAP 1.1, sec. 4.3.1, goes as far as saying: "A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of '1'."
Ugo
> -----Original Message-----
> From: Francisco Curbera [mailto:]
> Sent: Tuesday, October 21, 2003 2:18 PM
> To: Ugo Corda
> Cc:
> Subject: RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP
> header bindings
>
>
>
>
>
>
> Hi Ugo,
>
> I think the assumption in your example can then be stated as
> saying that
> the WSDL service was badly designed (because business and quality of
> service data were not appropriately factored) but that it
> would be *really*
> nice if BPEL could deal with it anyhow.
>
> I think that the requirement to support legacy does not
> require being able
> to seamlessly "patch over" any possible design however bad it is. The
> wrapper service that Rajesh suggests seems like a reasonable approach.
>
> Paco
>
>
>
>
>
> "Ugo Corda"
>
> <UCorda@SeeBeyond To:
> "Satish Thatte" <>, "Frank Leymann"
>
> .com>
> <>, <>
>
> cc:
>
> 10/21/2003 03:57 Subject: RE:
> [wsbpel] Possible new issue: BPEL cannot handle some SOAP header
> PM bindings
>
>
>
>
>
>
>
> Satish, you say:
>
> > presumably
> > with the assumption that the parts from other message types
> > used in headers affect only QoS not app-visible data.
>
> That's an assumption that might sound good to you and me, but
> here we are
> dealing with third parties that might have made all kind of different
> assumptions in the way they use headers (assumptions that,
> from the WSDL
> 1.1 point of view - and probably from the SOAP 1.1 point of
> view too - are
> perfectly legitimate). There lies the legacy problem with this issue.
>
> Ugo
>
> > -----Original Message-----
> > From: Satish Thatte [mailto:]
> > Sent: Tuesday, October 21, 2003 12:40 PM
> > To: Ugo Corda; Frank Leymann;
> > Subject: RE: [wsbpel] Possible new issue: BPEL cannot
> handle some SOAP
> > header bindings
> >
> >
> > Ugo,
> >
> > I think the WSDL 1.2/2.0 model for dealing with headers is
> > what we should look at for future guidance. For WSDL 1.1 we
> > don't apply any restrictions, just the principal that BPEL
> > processes are binding agnostic. Unfortunately, WSDL 1.1
> > allows changes to the data model in binding, but presumably
> > with the assumption that the parts from other message types
> > used in headers affect only QoS not app-visible data.
> >
> > Satish
> >
> > ________________________________
> >
> > From: Ugo Corda [mailto:]
> > Sent: Tue 10/21/2003 12:22 PM
> > To: Satish Thatte; Frank Leymann;
> > Subject: RE: [wsbpel] Possible new issue: BPEL cannot handle
> > some SOAP header bindings
> >
> >
> >
> > So what you are saying is that BPEL imposes additional
> > restrictions to the way information can be legally defined in
> > a WSDL 1.1 file. This is a pretty serious statement because
> > it affects BPEL compatibility with "legacy" Web services. Is
> > this the only place in the BPEL spec where we specify such
> > restrictions?
> >
> > It's also interesting to look at this issue from the point of
> > view of WSDL 1.2, i.e. the elimination of the message
> > construct. In the example I gave before, it just happens that
> > the header is defined in terms of a part that is in an
> > abstract message different than the one that defines the
> > body. If the concept of message is removed, then we just have
> > a bunch of abstract parts, one of which happens to end up in
> > a SOAP header.
> >
> > Ugo
> >
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:]
> > > Sent: Tuesday, October 21, 2003 11:54 AM
> > > To: Frank Leymann;
> > > Subject: RE: [wsbpel] Possible new issue: BPEL cannot
> > handle some SOAP
> > > header bindings
> > >
> > >
> > > We must assume that the design of a portType is done
> > > properly, i.e., the "application level" data required to
> > > process a message in a business process is part of the
> > > definition of each message. If this assumption is violated
> > > there is not much we can do.
> > >
> > > ________________________________
> > >
> > > From: Frank Leymann [mailto:]
> > > Sent: Tue 10/21/2003 1:04 AM
> > > To:
> > > Subject: Re: [wsbpel] Possible new issue: BPEL cannot handle
> > > some SOAP header bindings
> > >
> > >
> > >
> > >
> > > Ugo, this is a deployment/binding issue that is not
> > > addressed by BPEL at
> > > all. You easily write down bindings that won't work with a
> > > certain BPEL
> > > process model...
> > >
> > > Regards,
> > > Frank
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > To: <>
> > > cc:
> > > Subject: [wsbpel] Possible new issue: BPEL cannot handle
> > some SOAP
> > > header bindings
> > >
> > >
> > > Let's suppose we have the following WSDL file:
> > >
> > >
> > > <message name="In">
> > > <part name="InPart" element="InElement"/>
> > > </message>
> > >
> > >
> > > <message name="Header">
> > > <part name="HeaderPart" element="HeaderElement"/>
> > > </message>
> > >
> > >
> > > <portType name="myPortType">
> > > <operation name="op1">
> > > <input message="In"/>
> > > </operation>
> > > </portType>
> > >
> > >
> > > <binding type="myPortType" ... >
> > > <soap:binding ..../>
> > > <operation name="op1">
> > > <input>
> > > <soap:body parts="InPart" ...>
> > > <soap:header message="Header" part="HeaderPart" .../>
> > > </input>
> > > </operation>
> > > </binding>
> > >
> > >
> > > In this example, the abstract operation "op1" refers to
> > > message "In", but
> > > the binding brings in an additional second message,
> > "Header", for the
> > > concrete operation.
> > >
> > >
> > > It seems that BPEL would not be able to process the "Header"
> > > information in
> > > any way. For instance, a "receive" operation would only be
> > > able to specify
> > > one inputVariable, which would be associated with the "In"
> > > message and not
> > > the "Header" message. In other words, the "Header" message
> > would carry
> > > information to the "receive" operation that BPEL would have
> > > no access to.
> > >
> > >
> > > If this is the case, new Web services defined with BPEL in
> > mind could
> > > easily modify this scenario by defining both body and header
> > > as being part
> > > of a single message, but legacy Web services might be out
> > of reach for
> > > BPEL.
> > >
> > >
> > > Please confirm that the current status is as I described. If
> > > it is, I will
> > > formally raise a new issue.
> > >
> > >
> > > Thank you,
> > > Ugo
> > >
> > >
> > >
> > >
> > >
> > > 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
.
