Next in thread → Next in month →

RE: [wsbpel] Issue - 110 - Issues with the Pattern Attribute

From
Ugo Corda <>
Date
2004-03-25T00:04:34+00:00
ID
Thread
RE: [wsbpel] Issue - 110 - Issues with the Pattern Attribute
Title: Message

My understanding of 
the spec is that whenever it talks about a synchronous invoke it is referring to 
an invoke done on a request/response WSDL interface, regardless of the fact that 
the interface could be bound to an asynchronous protocol.

 

An asynchronous 
invoke, according to the spec, would be an invoke done on a one-way WSDL 
interface, possibly paired with a corresponding receive done on a separate WSDL 
one-way interface defined on the BPEL side of the wire.

 

I agree that 
terminology and semantics should be better clarified.

 

Ugo

  

  
-----Original Message-----
From: ws-bpel issues 
  list editor [mailto:] 
Sent: Wednesday, 
  March 24, 2004 12:08 PM
To: 
  
Subject: [wsbpel] Issue - 110 - Issues 
  with the Pattern Attribute

  
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 - 110 - Issues with the Pattern AttributeStatus: 
  open
Area: Syntax and validation
Date added: 24 Mar 
  2004
Submitter: Yaron Y. 
  Goland
Date submitted: 24 March 2004
Description: 
  Section 10.2 of the specification currently says: 
  Finally, in the case of invoke, when the operation invoked is 
    synchronous request/response, a pattern attribute is used to indicate 
    whether the correlation applies to the outbound (request) message, the 
    inbound (response) message, or both. These ideas are explained in more 
    detail in the context of the use of correlation in the rest of this example. 
  
  
There are several issues this text raises about the pattern attribute: 
  
    
The pattern attribute is intended to deal with request/response patterns 
    but such patterns are not required to be synchronous. It is legal in WSDL 
    1.1 to define a request/response operation that bind to an asynchronous 
    binding. I realize that the intent was probably to say that the behavior 
    within BPEL (as opposed to on the wire) is synchronous but in that case the 
    distinction needs to be made clear. 
    

    
I consistently get confused about what in versus out means. Why not use 
    names that more closely match the WSDL names? E.g. something like "request | 
    response | both"? I would extend this change to the inputvariable and 
    outputvariable attributes renaming them responseVariable and 
    requestVariable. 
    

    
The text in the referenced paragraph has caused confusion because it 
    implies that the pattern attribute is only needed on correlation sets on 
    request/response invokes. But we also require its use on one-ways. Ideally 
    we would make the pattern attribute illegal on correlation sets defined on 
    one-way Invokes and mandatory on correlation sets used on request/response 
    Invokes. I realize that we probably can't express that restriction in XML 
    Schema but, if so, we shouldn't allow XML Schema's limitations stop us from 
    doing the right thing for our users. 

Changes: 24 Mar 2004 
  - new issue

  

  
To comment on this issue, please follow-up to this announcement on the 
   list (replying to this message should 
  automatically send your message to that list), or ensure the subject line as 
  you send it starts "Issue - 110 - [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/leave_workgroup.php. 
  

Next in thread → Next in month →