[no subject]

>=20
> It is absolutely not the case that WSDL is only about the=20
> wire representation.  If that were so we would not be able to=20
> use it in BPEL. WSDL binding is about wire formats.  WSDL=20
> abstract interfaces are about data and interaction models=20
> independent of wire representation. Otherwise the use of=20
> infosets would be meaningless.

The scope of WSDL is exclusively limited to describing what happens when
messages are exchanged between endpoints, and abstract interfaces are
also defined to support that domain. What happens behind a WS endpoint
is none of WSDL's business. A BPEL process variable is *behind* the WS
endpoint described by WSDL, and a mapping between WSDL and the variable
has to be explicitly established (and this mapping is *not* described by
WSDL).


>=20
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]=20
> Sent: Friday, September 24, 2004 10:32 AM
> To: Satish Thatte; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] An amendment to the proposal for issue 103
>=20
> Please see below.
> Ugo
>=20
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: Friday, September 24, 2004 10:10 AM
> > To: Ugo Corda; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] An amendment to the proposal for issue 103
> >=20
> >=20
> > Yes, except the content of a message data model in BPEL would
> > be essentially the same as MTOM.=20
>=20
> Not really. The MTOM messaging model has to deal with things=20
> like the SOAP processing model, SOAP intermediaries, HTTP=20
> binding, etc. that simply do not exist in the context of BPEL=20
> variables.
>=20
> > I would find it bizarre for
> > us to do something along those lines in BPEL, especially=20
> > considering the amount of trouble and headache that MTOM=20
> > caused in the WSDL world. =20
>=20
> Not clear what you are referring to as "trouble and=20
> headache", so I cannot say whether those issues would apply=20
> to our context.
>=20
> > When we attach BPEL to WSDL 2.0 in
> > the next generation, the MTOM infoset model for message data=20
> > would be available to us automatically, and at that point=20
> > having a legacy of "our own version" would be an even=20
> bigger headache.
>=20
> You make it sound like BPEL automatically inherits any WSDL=20
> model. That in fact is not the case because, again, WSDL's=20
> scope is limited to what happens on the wire.=20
> BPEL currently does not say anything precise about the=20
> mapping from WSDL to the BPEL language and vice-versa=20
> (compare that to JAX-RPC, which devotes a big portion of the=20
> spec just to define the WSDL/Java mapping). I think Alex and=20
> Yaron's proposal addresses exactly that missing mapping.
>=20
> >=20
> > If it isn't clear already, I for one would be strongly
> > opposed to adding this type of message content model to BPEL.
> >=20
> > Satish
> >=20
> > -----Original Message-----
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Friday, September 24, 2004 10:04 AM
> > To: Satish Thatte; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] An amendment to the proposal for issue 103
> >=20
> > No need to refer to MTOM (which, again, deals with messaging
> > on the wire, which is not what we are talking about here). We=20
> > only need to use the basic concepts of XML Infoset and=20
> > infoset serialization.
> >=20
> > Ugo
> >=20
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:satisht@microsoft.com]
> > > Sent: Friday, September 24, 2004 9:56 AM
> > > To: Ugo Corda; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] An amendment to the proposal for issue 103
> > >=20
> > >=20
> > > Do you really want to recapitulate MTOM as a part of the WS-BPEL=20
> > > standard?
> > >=20
> > > -----Original Message-----
> > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > > Sent: Friday, September 24, 2004 9:29 AM
> > > To: Satish Thatte; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] An amendment to the proposal for issue 103
> > >=20
> > >=20
> > > > The second point to note is that WSDL allows parts to=20
> be based on
> > > > type systems other than XML, for instance arbitrary=20
> MIME content=20
> > > > types.  It is possible to have a part that carries a JPEG=20
> > image, and
> > > > it is perfectly reasonable for a BPEL process to assign
> > the content
> > > > of such a part from one message variable to a
> > corresponding part in
> > > > another message variable without ever concerning itself with the
> > > > content type.  We assume that the process knows its=20
> message types=20
> > > > and will bind only XML parts into XPath expressions.  Any
> > > > proposal that attempts to create an XML-based content model=20
> > > > for arbitrary WSDL 1.1 messages will run into trouble with=20
> > > > these issues.
> > > >=20
> > > > =20
> > > >=20
> > > > It may be argued that WSDL 2.0 has moved to a pure XML
> > infoset model
> > > > for messages, as indeed it has.  However, the WSDL 2.0=20
> WG has not
> > > > provided a "migration story" for rendering WSDL 1.1=20
> > messages in WSDL
> > > > 2.0 infoset form, apart from the fact that the BPEL TC has
> > > > explicitly declined to take a dependency on any WSDL 2.0=20
> > feature.
> > > > It hardly seems our place to provide an XML-based content
> > model for
> > > > WSDL 1.1 messages when the WSDL 2.0 WG has not done so.
> > > >=20
> > >=20
> > > I think we should distinguish the data model used by WSDL=20
> from the=20
> > > data model used by BPEL for its variables. The data model defined
> > > by WSDL is
> > > limited exclusively to representation of messages *on*=20
> the wire. The
> > > data model for BPEL variables deals with messages taken=20
> > > *from* the wire
> > > and manipulated internally by the BPEL process.
> > >=20
> > > So, in my view, WSDL itself has nothing to say about the
> > data model of
> > > BPEL variables, and we have to make our own rules there. In
> > > particular, I think it is completely legitimate for BPEL to=20
> > adopt an
> > > infoset-based data model for its variables. From that
> > perspective, a
> > > JPEG part is just
> > > an infoset EII corresponding to the Schema description
> > provided in the
> > > WSDL abstract interface. The fact that the concrete
> > representation of
> > > that EII is a JPEG binary image is just a matter of infoset=20
> > > serialization (a la MTOM).
> > >=20
> > > Ugo
> > >=20
> > > To unsubscribe from this mailing list (and be removed from the=20
> > > roster of the OASIS TC), go to
> > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > ave_workgr
> > oup.php.
> >=20
> >=20
> > To unsubscribe from this mailing list (and be removed from
> > the roster of the OASIS TC), go to=20
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgr
> oup.php.
>=20
>=20