[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
I agree that the XML ID/IDREF mechanism should NOT be used. I do not think Yuzo was proposing to use it.
I am in favor of a single attribute for all participating interactions in the exchange.
Satish
-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Wednesday, July 07, 2004 7:40 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
I like the R1 as well, seems like the cleanest approach; but I am a bit
confused (after reading the different positing on this issue) as to whether
the proposal is to introduce a "message exchange id" attribute or to use
the standard XML ID/IDREF mechanism. The latter would not be consistent
with the way BPEL does naming and referencing (BPEL introduces its own
dedicated attributes for that, as in the case of link sources/targets).
So I am for R1 if a "operation instance" (name TBD) attribute(s) is
introduced. It seems that we can either use two attributes (one for the
receive, one for the related replies matching in values) or a single one
(to label all associated activities in the exchange), which seems simpler
and cleaner.
Paco
"Satish Thatte"
<satisht@microsof To: "Ugo Corda" <UCorda@SeeBeyond.com>, "Eckenfels. Bernd"
t.com> <B.Eckenfels@seeburger.de>, <wsbpel@lists.oasis-open.org>
cc:
07/07/2004 01:55 Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
AM
I agree that we should not restrict combinations of WSDL interface
characteristics with usage in BPEL - e.g., that one cannot have two
outstanding requests on the same partnerLink and operation if the operation
response signature happens to omit the properties needed for the
correlation set used to disambiguate the request.
I also think that the requirement to have distinct correlations for
multiple outstanding requests is actually and, especially in case we allow
the proposed "engine managed" correlation (issue 96), clearly unworkable.
I therefore like the R1 variant proposed by Yuzo. It has the following
additional virtues
1. It gives a clear scope to the reply, thus allowing an internal fault if
a reply does not occur "in time". Better control and error detection.
Thus, for instance, the MEP declaration for a request received in an event
handler would be implicitly associated with the implicit scope for the
corresponding instance of that handler, and therefore must be replied to
inside the handler.
2. It allows for future new MEPs that may be supported in WSDL 2.0.
Better future proofing. This is what I took Yuzo's "pattern" attribute to
be for.
I do not understand the arguments about "overhead". As Yuzo has said, this
MEP-ID is an optional attribute. The simple cases of request/response do
not need it. In any case the overhead would not be in runtime performance.
Satish
-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Tuesday, July 06, 2004 11:03 AM
To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
+1.
We should not expect modifications of the WSDL interface of the process for
the exclusive benefit of the underlying implementation of the process
itself (BPEL, in our case, but it could be, for instance, a Java module
instead - the Java module might also want its own modifications, which
could just happen to be different than the ones expected by BPEL, so that
the whole thing would be a big mess).
Ugo
> -----Original Message-----
> From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
> Sent: Tuesday, July 06, 2004 2:23 AM
> To: wsbpel@lists.oasis-open.org
> 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
>
> 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
.
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]