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] Issue - 123 - Matching <reply> with <receive>


Hello Yuzo,

I dont think it is ok to require a response to have correlation values, if the businenss case (i.e. sync service) does not. Because this will not allow a BPEL Engine to provide services according to existing WSDL interface descriptions. I think we agree here, that this is not really a good thing.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com]
Sent: Monday, July 05, 2004 4:13 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>


Assaf,

Assaf Arkin wrote:
> Yuzo Fujishima wrote:
> 
>> (To: Asaaf
         ===== Sorry for the misspell here.

>> Please reply to this message because the previous one have not
>> reached the wsbpel mailing list.)
>>
>> Do you think the message to be sent by <reply> must contain
>> the message properties that match the specified correlation set(s)?
> 
> 
>>
>> If the answer is yes, we don't need any new mechanisms.
>>
>> My guess is that we want to say no, for example, to
>> accommodate simple yes/no reply message. Then we need
>> a new mechanism.
> 
> 
> Are you talking about generic request/response, or the case where you 
> have two (or more) outstanding requests on the same 
> partnerLink/operation? The correlation set only affects the latter. So 

I am talking about the latter. My assumption is that we need to
specify only as many correlation sets as necessary to disambiguate
the receive-reply correspondence.

> the simple case remains simple, and I would hate for it to become more 
> complicated, but I don't see a clear need for a referencing mechanism. 
> As for two outstanding on same partnerLink/operation, in all the use 
> cases I could imagine for doing this, I would use message properties in 
> the response.

OK. I think I understand your position. Let me confirm it.
Suppose two receives with the same partner link, port type,
operation but different correlation sets are outstanding.
Following your rule, then the messages to be sent by two reply's must
contain the message properties that are referenced by the correlation
sets used for disambiguation. Do I understand you correctly?

Further suppose that the above two request-response are performed
synchronously using two connections, for example, via plain SOAP
invocation. I think this is a very common case.
Then the client sides don't need any message properties for correlation,
because the responses are sent back in the same connections as for requests.
Do you think it is OK to request the reply messages contain message properties
in this case?

Yuzo Fujishima
NEC Corporation


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