[no subject]

(WSDL 1.1, by the way, does not mention "interface" at all, so we are =
just extrapolating here).

What you should say instead is "the other abstract components are bound =
to the abstract operations through the complex area of binding", and I =
agree with that. That's why I said that associating these components =
with a particular operation within BPEL presents some risk, and it's up =
to the BPEL designer to decide whether he/she wants to take that risk.

(By the way, in principle some risk exists even in the case of abstract =
messages associated with abstract operations. There is nothing in WSDL =
1.1 that prevents actual bindings from leaving some message parts out =
when it comes to concrete message - so BPEL would have uninitialized =
parts in that case too).

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Tuesday, November 04, 2003 9:27 AM
> To: Ugo Corda; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> values not defined in portType
>=20
>=20
>=20
>=20
> =20
>=20
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]=20
> Sent: Tuesday, November 04, 2003 8:56 AM
> To: Satish Thatte; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> values not defined in portType
>=20
> Satish,
>=20
> I have no desire of changing BPEL's fundamental design choice=20
> of basing
> all external interactions on WSDL operations.
>=20
> What I want to do is recognize that WSDL allows designers to define
> components of an abstract interface that are not tied up to a=20
> particular
> operation. These abstract components can appear in actual WS
> interactions (not a surprise - otherwise there would be no reason to
> define them in the first place). The specific way these abstract
> components can appear in actual WS interactions is not defined by the
> abstract interface (sorry, I was not one of the creators of WSDL 1.1,
> don't blame me ;-).
>=20
> [Satish] So far I am in complete agreement with you.
>=20
> WS developers have taken advantage of this WSDL feature and=20
> have defined
> in their applications payload elements that leverage abstract=20
> components
> which are not part of an operation. (I am not arguing here about the
> wisdom of their decision - I am just mentioning the current state of
> affairs).
>=20
> Currently BPEL excludes part of the abstract interface from=20
> its reach. I
> am proposing that this portion of the abstract interface that is
> currently excluded be included instead, in order to support=20
> existing WS
> applications.
>=20
> At the same time, it should be clear that BPEL designer that take
> advantage of this "extended" abstract interface do it at=20
> their own risk,
> because of the ambiguities inherent in WSDL 1.1's approach in=20
> this area.
> So they can expect that BPEL processes designed that way will incur
> run-time faults in the case deployments do not properly map messages
> from the "extended" abstract interface to concrete binding elements.
>=20
> [Satish] My primary argument is that doing anything in this direction
> creates a legacy that will need to be controlled and excluded through
> another "profile" -- we have had enough trouble getting to a common
> understanding of acceptable usage of just the abstract interfaces, and
> as you know WSDL 2.0 is still struggling with MEPs.  The=20
> other abstract
> components you speak of are bound to the abstract interfaces=20
> through the
> even more complex area of binding.  We have to start from=20
> asking whether
> bindings are a normative part of an abstract interface or a deployment
> artifact.  I just don't want (us) to get into that rathole.
>=20
> Ugo
>=20
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: Monday, November 03, 2003 9:56 PM
> > To: Ugo Corda; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> > values not defined in portType
> >=20
> >=20
> > Ugo,
> > =20
> > Let us state clearly the current relationship between BPEL=20
> > and WSDL interfaces.
> > =20
> > BPEL allows Web service *operations* defined by such=20
> > interfaces to be invoked or provided by BPEL processes. =20
> > Messages occur in these interactions only in so far as they=20
> > participate in the definition of the operations in the=20
> > concerned portType.
> > =20
> > Your proposal suggests that we change this fundamental design=20
> > point, and start dealing with messages independent of their=20
> > association with operations in a portType.  Do you agree?  Is=20
> > there any constraint you have in mind for which message types=20
> > would be associated with the input and output variables for=20
> > web service interactions?
> > =20
> > Satish
> >=20
> > ________________________________
> >=20
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Mon 11/3/2003 8:26 AM
> > To: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require=20
> > access to values not defined in portType
> >=20
> >=20
> >=20
> > Here is my proposal for a resolution of this issue:
> >=20
> > Allow multiple abstract messages to be associated with each=20
> > input and output variable in those activities (invoke,=20
> > receive, reply) where only a single abstract message is=20
> > currently allowed.
> >=20
> > Ugo
> >=20
> > > -----Original Message-----
> > > From: Ugo Corda
> > > Sent: Sunday, November 02, 2003 11:14 AM
> > > To: wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> > > values not defined in portType
> > >
> > >
> > > Reformulation of the issue:
> > >
> > > Given the fact that a few people are bothered by mentioning
> > > SOAP and SOAP headers, let me try to reformulate the issue
> > > exclusively in terms of abstract interface. Here it goes.
> > >
> > > WSDL 1.1 can define various abstract messages as part of its
> > > abstract interface. Some of these messages show up in
> > > abstract WSDL operations, some others don't. BPEL can only
> > > process abstract messages that are part of WSDL operations,
> > > and it cannot process any other abstract message. What is the
> > > rationale for that?
> > >
> > > 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.
> >=20
> >=20
> > To unsubscribe from this mailing list (and be removed from=20
> > the roster of the OASIS TC), go to=20
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>=20
>=20
>=20
>=20
>=20
>=20