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: [wsbpel] Issue - 299 - Proposal for Vote



Resending the proposal as adopted by the TC on June 19, 2006.

Submitter's proposal (Word document with markup showing the changed text):
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18839/Issue%20299%20-%20Proposal%20for%20Vote.doc

Submitter's proposal:

Section 9.2, paragraph 3, change from:

"The <correlationSet> specifications are used in <invoke>, <receive>, and
<reply> activities (see 10.3. Invoking Web Service Operations and 10.4.
Providing Web Service Operations); in the <onMessage> branches of <pick>
activities, and in the <onEvent> variant of <eventHandlers> (see 11.5. Pick
and 12.5.1. Message Events). These <correlationSet> specifications identify
the correlation sets by name and are used to indicate which
correlationSet's (i.e., the corresponding property sets) occur in the
messages being sent and received. The initiate attribute on a <correlation
Set> specification is used to indicate whether the correlation set is being
initiated."

to:

"The <correlationSet> specifications are used in <invoke>, <receive>, and
<reply> activities (see 10.3. Invoking Web Service Operations and 10.4.
Providing Web Service Operations); in the <onMessage> branches of <pick>
activities, and in the <onEvent> variant of <eventHandlers> (see 11.5. Pick
and 12.5.1. Message Events). The <correlation> specifications identify the
correlation sets by name and are used to indicate which correlation sets
(i.e., the corresponding property sets) occur in the messages being sent
and received. The initiate attribute on a <correlation> specification is
used to indicate whether the correlation set is being initiated."

After the following paragraph (#9 I think):

"In the case of <invoke>, when the operation invoked is a request/response
operation, a pattern attribute on the <correlationSet> specification is
used to indicate whether the correlation applies to the outbound message
(“request”), the inbound message (“response”), or both
(“request-response”). The pattern attribute used in <invoke> is required
for request-response operations, and disallowed when a one-way operation is
invoked. Any violation of this rule MUST be detected during static
analysis."

Add the following new paragraph for clarification:

"In the case of <invoke>, when the operation invoked is an one-way
operation, or in the case of <reply>, the usage of correlation sets with
initiate="no" is for message validation purposes only. With this, a
business process can ensure that the message to be sent carries the
expected correlation tokens."

Change the following paragraph for clarification, from:

"A message can carry the tokens of one or more correlationSet’s. The first
example shows an interaction in which a purchase order is received in a
one-way inbound request and a confirmation including an invoice is sent in
the one-way response. The PurchaseOrder correlationSet is used in both
activities so that the one-way response can be correlated to the request at
the buyer. The <receive> activity initiates the PurchaseOrder
correlationSet. The buyer is therefore the leader and the receiving
business process is a follower for this correlationSet. The <invoke>
activity sending the one-way response also initiates a new correlationSet
called Invoice. The business process is the leader of this correlated
exchange and the buyer is a follower. The response message is thus a part
of two separate conversations, and forms the bridge between them."

to:

"A message can carry the tokens of one or more correlationSet’s. The first
example shows an interaction in which a purchase order is received in a
one-way inbound request and a confirmation including an invoice is sent in
the one-way response. The PurchaseOrder correlationSet is used in both
activities so that the one-way response is validated against the
correlation set to correlate with the request of the buyer. The <receive>
activity initiates the PurchaseOrder correlationSet. The buyer is therefore
the leader and the receiving business process is a follower for this
correlationSet. The <invoke> activity sending the one-way response also
initiates a new correlationSet called Invoice. The business process is the
leader of this correlated exchange and the buyer is a follower. The
response message is thus a part of two separate conversations, and forms
the bridge between them."

Change the last paragraph in 9.2 for clarification, from:

"An <invoke> can consist of two messages: an outgoing request message and
an incoming reply message. The correlationSet’s applicable to each message
must be separately considered, because they can be different. In this case
the PurchaseOrder correlation applies to the outgoing request that
initiates it, while the Invoice correlation applies to the incoming reply
and is initiated by the reply. Because the PurchaseOrder correlation is
initiated by an outgoing message, the buyer is the leader of that
correlation. However, the buyer is a follower of the Invoice correlation
because the values of the correlation properties for Invoice are initiated
by the seller in the reply received by the buyer. "

to:

"An <invoke> can consist of two messages: an outgoing request message and
an incoming reply message. The correlationSet’s applicable to each message
must be separately considered, because they can be different. In this case
the PurchaseOrder correlation applies to the outgoing request that
initiates it, while the Invoice correlation applies to the incoming reply
and is initiated by the reply. Because the PurchaseOrder correlation is
initiated by an outgoing message, the buyer is the leader of that
correlation. However, the buyer is a follower of the Invoice correlation
because the values of the correlation properties for Invoice are initiated
by the reply message of the seller received by the buyer."

Kind Regards
DK
                                                                                                                         
 Dieter König                                Mail: dieterkoenig@de.ibm.com         IBM Deutschland Entwicklung GmbH      
                                                                                                                         
 Senior Technical Staff Member               Tel (office): (+49) 7031-16-3426      Schönaicher Strasse 220               
                                                                                                                         
 Architect, Business Process Choreographer   Fax (office): (+49) 7031-16-4890      71032 Böblingen                       
                                                                                                                         
 Member, Technical Expert Council            Tel (home office): (+49) 7032-201464  Germany                               
                                                                                                                         



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