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] RE: Issue - 77 - Motion to require access to values not defined in portType




 

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
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

Satish,

I have no desire of changing BPEL's fundamental design choice of basing
all external interactions on WSDL operations.

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 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 ;-).

[Satish] So far I am in complete agreement with you.

WS developers have taken advantage of this WSDL feature and have defined
in their applications payload elements that leverage abstract 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).

Currently BPEL excludes part of the abstract interface from its reach. I
am proposing that this portion of the abstract interface that is
currently excluded be included instead, in order to support existing WS
applications.

At the same time, it should be clear that BPEL designer that take
advantage of this "extended" abstract interface do it at their own risk,
because of the ambiguities inherent in WSDL 1.1's approach in 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.

[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 other abstract
components you speak of are bound to the abstract interfaces through the
even more complex area of binding.  We have to start from 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.

Ugo

> -----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
> 
> 
> Ugo,
>  
> Let us state clearly the current relationship between BPEL 
> and WSDL interfaces.
>  
> BPEL allows Web service *operations* defined by such 
> interfaces to be invoked or provided by BPEL processes.  
> Messages occur in these interactions only in so far as they 
> participate in the definition of the operations in the 
> concerned portType.
>  
> Your proposal suggests that we change this fundamental design 
> point, and start dealing with messages independent of their 
> association with operations in a portType.  Do you agree?  Is 
> there any constraint you have in mind for which message types 
> would be associated with the input and output variables for 
> web service interactions?
>  
> Satish
> 
> ________________________________
> 
> 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 
> access to values not defined in portType
> 
> 
> 
> Here is my proposal for a resolution of this issue:
> 
> Allow multiple abstract messages to be associated with each 
> input and output variable in those activities (invoke, 
> receive, reply) where only a single abstract message is 
> currently allowed.
> 
> Ugo
> 
> > -----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.
> 
> 
> 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.







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]