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


Ron,
 
Could you please clarify your point below about BP 1.0 conformance? As far as I know, BP 1.0 is neutral in this area.
 
Ugo
-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Friday, October 31, 2003 10:36 AM
To: Frank Leymann
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] RE: Issue - 77 - Motion to require access to values not defined in portType

Frank,

    Your points about the user of SOAP headers are well taken. Just a few comments in response:
  • The use of composability via SOAP header blocks is applicable at several levels in the "stack." It is conceivable that business process-level protocols may be supported by such mechanisms (some forms of transactions are sneaking up on this). Could this eventually require BPEL "awareness" of header blocks in support of  higher-level protocols?
  • Also, a message doesn't necessarily have a single payload. This is commonly "worked around" in SOAP/WSDL by placing the extra payloads into header blocks, especially if conformance to BP 1.0 is desired.
  • While we, as a technically sophisticated group would not abuse SOAP/WSDL in unnatural ways, there are plenty of people devising web services today that have no such sensibilities. Are we, the BPEL TC, to stick to the "high road" and refuse to treat with such abominations, or take the "low road" and get a bit dirty in process (no pun intended). Will this substantially affect adoption of BPEL?
Regards,
-Ron

Frank Leymann wrote:
Yaron (or do you prefer "Yoland" in the meantime?   ;-)),

the scope of the problem you describe is generic, not coupled to BPEL at
all. Thus, the BPEL TC shouldn't attempt at all to solve that problem. This
includes defining new mechanisms to declare optional headers, teach people
how to specify appropriate WSDL etc..

The fundamental importance of SOAP headers is to provide for composability
of Web service mechanisms at the message level.  So, headers are about
folding in "QoS" aspects like security, reliability, addressability,
transactionality etc etc.  It is the SOAP body that is intended to carry
the "real" application payload. I  personally don't think that application
programmers should take care about headers (i.e. QoS-like stuff), but take
care only of the body. The "environment" should take care about headers,
i.e. QoS-like stuff.

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
--------------------





Please respond to <ygoland@bea.com>

To:    Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
cc:
Subject:    RE: [wsbpel] RE:  Issue - 77 - Motion to require access to
       values not defined in portType


I'm unsure how one differentiates between middleware payload and endpoint
payload. For example, there are many good reasons why an endpoint would
want
to be able to access a SOAP header containing digital signature or
correlation information. So I don't think we can ever say that it's o.k.
not
to be able to get to the SOAP headers.

It has been suggested that perhaps we could tell people to write enhanced
WSDL definitions that contain headers that are present at the SOAP level
but
weren't defined in the original WSDL.

Unfortunately this isn't a workable solution in a case where the SOAP
header
is itself optional. For example, one could have an operation that MAY be
digital signed which means that in some cases you will have a digital
signature header and in other cases you wouldn't. WSDL 1.1 is incapable of
expressing the concept of 'optional' headers.

I think the easiest way to get around this problem would be for the group
to
introduce a new attribute for use with WSDL that would specify when a
message part is optional both for incoming and outgoing messages. The
normative behavior would then become that you would have to take the
original WSDL, which doesn't mention the optional headers, mark it up to
include those headers (i.e. the previously suggested 'enhanced' WSDL) and
then mark those headers as optional.

If a message is received without the optional part then that part would be
left as uninitialized in the message variable and accessing that part of
the
message variable would throw a fault. We would have to introduce a function
to allow one to test if a part is uninitialized.

If a message is sent whose definition contains an optional part then if the
part is never assigned to, that's fine, it just means that the part won't
appear in the outgoing message.

The main downside I see to this proposal is that if someone sends you a
message with content you just weren't expecting (For example, an
intermediary throws in a SOAP header that is made up) then you can't get to
it. But the only use case I can see for wanting access to that information
is for logging purposes and I'm not sure that is a compelling enough use
case to worry about this in V1.

But I believe it is important that one be able to both send and receive
optional message parts (e.g. optional SOAP headers) so some change to the
BPEL standard seems called for.

             Just an opening thought,

                         Yaron


  
-----Original Message-----
From: Frank Leymann [mailto:LEY1@de.ibm.com]
Sent: Friday, October 24, 2003 6:47 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to
values not defined in portType



The WSDL 1.2/2.0 group is currently considering to remove headers from
messages at all, and replacing this by appropriate applications of
"policies".  I read this as another indicator that application data is
assumed to be part of the message body, and that headers should carry
"middleware payload" (indicated by appropriate "policies").

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
--------------------





To:    Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
cc:
Subject:    RE: [wsbpel] RE:  Issue - 77 - Motion to require access to
       values not defined in portType


I'm still not clear whether it's expected that bpel users
will sometimes
have to construct
bpel-convenient wsdl for web-services that already have wsdl
defintions
but which don't give
the required accessiblity/granularity in the existing wsdl. The wsdl,
with some accompanying
free text description of what the parameters are, might have been good
enough for implementation
of client and service by hand, but now bpel wants a standard
expression
of some of that free text.
Or would such wsdl reworking be regarded as a Bad Thing ? it's
conceptually a refinement,
though whether it would be visibly such in the two wsdl
descriptions I'm
not sure).

If the bpel user is expected to have such a trick in his mind (and
perhaps his tools), would an
alternative solution to the underlying problem here be say if the
abstract wsdl doesn't give you
the access you want, then write one that does. The bindings are then
more explicit, but still below
the woodwork from the bpel position.

Peter



    
-----Original Message-----
From: Frank Leymann [mailto:LEY1@de.ibm.com]
Sent: 23 October 2003 11:57
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] RE: Issue - 77 - Motion to require
access to values not defined in portType



I wholeheartedly support Satish's position!

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
--------------------





To:    <ygoland@bea.com>, "Furniss, Peter"
<Peter.Furniss@choreology.com>,
       <wsbpel@lists.oasis-open.org>
cc:
Subject:    [wsbpel] RE:  Issue - 77 - Motion to require
access to values
       not defined in portType


I was simply making the point that BPEL is deliberately
agnostic about bindings, thus allowing deployment
flexibility.  Process models that are meant to capture the
essence of business process logic in a portable way should
not become dependent on deployment descriptors, which is at
least the intent of the binding element of WSDL 1.1 service
descriptions.  The fact that the intent may be imperfectly
realized is not a reason to throw the principle out.


From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Wednesday, October 22, 2003 3:27 PM
To: 'Furniss, Peter'; wsbpel@lists.oasis-open.org; Satish Thatte
Subject: Issue - 77 - Motion to require access to values not
defined in portType

In a previous mail in this thread Satish Thatte said:


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.


Section 3.7 of the WSDL 1.1 states " It is not necessary to
exhaustively list all headers that appear in the SOAP
Envelope using soap:header. " This means that even a portType
which has been done 'properly' may not necessarily have
messages for every header that may appear in the SOAP
envelope received over the wire. Given that even WSDL 1.1
recognizes that one can reasonably receive SOAP headers that
weren't defined in the portType it would seem reasonable for
BPEL to provide a mechanism to access such values.


I would therefore propose that we put forward a motion that
requires the group to define a mechanism that will enable
access to the full contents of a WSDL described message as
transmitted over the wire including contents not specifically
defined in the portType definition.


    Yaron
-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Tuesday, October 21, 2003 5:14 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Reannouncement - Issue - 77 - BPEL cannot
handle some SOAP header bindings Due to a mistake on my part,
this issue was erroneously announced as number 78. It is
really number 77 and is in the issues list with that number.
Here it is again with a hand-edit of the number.

This issue has already had considerable discussion as
"Possible new issue ...", which I've grandfathered into the
links list - please use an Issue - 77 - subject line on
further discussion messages.

Peter
 -----Original Message-----
 From: Furniss, Peter
 Sent: 21 October 2003 21:36
 To: wsbpel@lists.oasis-open.org
 Subject: [wsbpel] Issue - 78 - BPEL cannot handle some SOAP
header  bindings


 This issue has been added to the wsbpel issue list. The
issues list is  posted as a Technical Committee document to
the OASIS WSBPEL TC pages on a  regular basis. The current
edition, as a TC document, is the most recent  document with
the title in the "Issues" folder of the WSBPEL TC document
list - the next posting will include this issue. The list
editor's working  copy, which will normally include an issue
when it is announced, is  available at this constant URL.


 Issue - 77   - BPEL cannot handle some SOAP header bindings
 Status: open
 Date added: 21 Oct 2003
 Submitter: Ugo Corda
 Date submitted: 21 October 2003
 Description: 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.
 Links: Ugo Corda, 20 Oct 2003     Frank Leymann, 21 Oct
      
2003     Ugo
    
 Corda, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Peter
Furniss, 21
 Oct 2003     Ugo Corda, 21 Oct 2003     Satish Thatte, 21
Oct 2003     Ugo
 Corda, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Ugo
Corda, 21 Oct
 2003
 Changes: 21 Oct 2003 - new issue



 To comment on this issue, please follow-up to this
announcement on the  wsbpel@lists.oasis-open.org list
(replying to this message should  automatically send your
message to that list), or ensure the subject line  as you
send it starts "Issue - 78 - [anything]" or is a reply to
such a  message.


 To add a new issue, see the issues procedures document (but
the address  for new issue submission is the sender of this
announcement).


 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_workgr
oup.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_workgr
oup.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
.







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.



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
.







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.

  


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