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: Issue - 77 - Optional Headers


Issue - How do deal with optional message content?

	Imagine one uses an optional callback SOAP message header. How does
one deal with sending or receiving an optional message header?

There exists no mechanism to express 'optional' message parts in WSDL. All
message parts are mandatory. To make matters worse the web architecture
requires that one be able to deal with optional headers since intermediaries
are always allowed to shove things in.

We can't pretend that BPEL processes won't have to deal with optional
headers since customers are looking at intermediaries for application level
purposes and telling intermediaries to shove their content into the SOAP
body rather than a header is a non-starter as it both directly contradicts
the SOAP 1.1 and 1.2 intermediary model and is functionally impossible in
the face of message security.

Comments have been made that this problem will be dealt with in WSDL 2.0 and
we shouldn't create legacy. The reality is that WSDL 2.0 is far off and
every company out there is going to have to come up with its own solution to
this problem if the BPEL TC doesn't come up with a solution.

In other words, legacy is inevitable, the only issue is - shall we have one
legacy or many?

I believe one legacy is preferable over many and therefore believe the TC
should tackle this problem.

I propose that the least disruptive way to solve the problem is to follow
the recommendation made in
http://lists.oasis-open.org/archives/wsbpel/200310/msg00339.html. Which can
be summarized as - enable an annotation for use by WSDLs consumed by BPEL
that allows messages parts to be marked as optional.

		Yaron

> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Tuesday, November 04, 2003 11:09 AM
> To: Harvey Reed; Satish Thatte; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> values not defined in portType
> 
> 
> > Does WSDL have to be repaired to be able to be used? 
> 
> Sure it does. You would have to move parts from the original 
> "extended" message to the message specified in the operation. 
> In cases like the one addressed by BP 1.0 R2712 (see Ron's 
> previous message) you would also have to modify the schema 
> definition for the (unique) part defined in the operation message.
> 
> > How big of a deal is this really?
> 
> I don't think there is any way to determine this in abstract, 
> without considering specific existing applications.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Harvey Reed [mailto:hreed@sonicsoftware.com]
> > Sent: Tuesday, November 04, 2003 10:58 AM
> > To: 'Satish Thatte'; Ugo Corda; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
> > values not defined in portType
> > 
> > 
> > Question to all:
> > 
> > If we "stay the course" as Satish suggests (the ideal path 
> > let's say), what
> > is the impact on the typical developer who deals with legacy 
> > code all day?
> > 
> > Does WSDL have to be repaired to be able to be used? How big 
> > of a deal is
> > this really? Huge, small, does it block technology adoption? 
> > That's the
> > bottom line. 
> > 
> > I'm for moderate pain in exchange for a better future if it 
> > doesn't block
> > technology adoption.
> > 
> > ++harvey
> > 
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com] 
> > Sent: Tuesday, November 04, 2003 1:50 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,
> > 
> > At the end of the day this is all about where the 
> complexity of actual
> > practice is dealt with.  You are saying we should extend 
> BPEL to allow
> > it to be dealt with within BPEL.  I am saying redefine your 
> interface
> > (and eventually have the ability to do it with annotation) to 
> > match what
> > it really needs to be and use external glue to "make it so" in the
> > deployment of the BPEL process.  In other words I am trying to
> > externalize the variability to keep the process model 
> clean, portable,
> > binding independent, etc.
> > 
> > Satish
> > 
> > -----Original Message-----
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> > Sent: Tuesday, November 04, 2003 10:37 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,
> > 
> > WS-I BP can only establish behavior requirements for 
> bindings that are
> > in its scope. But BPEL wants to address bindings that are 
> out of scope
> > for BP (as we have discussed at length in another thread ;-).
> > 
> > The reality is that WSDL 1.1 operations rely on bindings as much as
> > messages in the "extended" interface do. BPEL's assumption is that a
> > BPEL deployment will do the right thing regarding the 
> mapping of parts
> > in abstract operations. How is that different than assuming 
> > that a BPEL
> > deployment will do the right thing when mapping the 
> messages from the
> > "extended" interface?
> > 
> > Ugo
> > 
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:satisht@microsoft.com]
> > > Sent: Tuesday, November 04, 2003 10:25 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
> > > 
> > > 
> > > Ugo Wrote:
> > > 
> > > (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).
> > > 
> > > Satish:
> > > 
> > > Well in that case I suggest BP 1.1 should forbid this behavior ;-)
> > > 
> > > -----Original Message-----
> > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> > > Sent: Tuesday, November 04, 2003 9:59 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, you say:
> > > 
> > > > the other abstract components you speak of are bound to 
> > the abstract
> > > interfaces 
> > > > through the even more complex area of binding.  
> > > 
> > > Sorry, I disagree on the way you put this. These abstract 
> > > components ARE
> > > part of the WSDL abstract interface. 
> > > 
> > > From WSDL 1.1, Sec. 1:
> > > "abstract definitions: 
> > > messages, which are abstract descriptions of the data being 
> > exchanged,
> > > and 
> > > port types which are abstract collections of operations".
> > > 
> > > (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
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > -----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.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 
> 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/leave_workgroup.
php.

<<attachment: winmail.dat>>



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