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>


The only reason I keep pushing on this issue is that I'm really scared 
we are putting up such a high barrier of entry to people writing BPEL 
using anything but a 4G tool, that all of the quick hacks and notepad 
users will be effectively thrown out.

To send a request/reply one now has to:

Define a WSDL
Define a partnerLinkType
Define a partnerLink
Define two variables
Do some 'stuff'
Create receive
Create reply
Figure out the right scope that encloses the receive/reply
Define a message exchange item
Assign ID

Every time a receive or reply is changed, instead of this being a 
lightweight operation, one now has to dig around to find the associated 
messageExchange declaration and make sure it's still in the right scope.

Getting rid of the messageExchange item will remove only two steps from 
the first list but it does really simplify the second task. Of course 
the cost is that one might create colliding names. But that's true in 
both cases.

Is this one feature going to be 'the' feature that destroyed easy 
editing of BPEL? Of course not. But it's a question of accretion. One 
feature here. One feature there. Soon one has a mess. So the only way to 
stop accretion is to not add all the tiny, individually harmless 
features. But that's what makes fighting accretion so hard. Each feature 
by itself seems harmless.

This isn't an obvious call to me. It really is a matter of taste. Which 
probably argues that we should just vote on it.

		Yaron

Satish Thatte wrote:

> 
> 
> Yaron wrote:
> 
>  >  The contract is defined in the WSDL.
>  >  That's where the extra piece of information is.
> 
> OK, I buy that.
> 
> At this point there is a difference of taste I guess.
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Monday, July 12, 2004 11:20 AM
> To: Satish Thatte
> Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
> 
> See below
> 
> Satish Thatte wrote:
>  >
>  >
>  > The pattern is a contract -- we are enforcing not only an implicit
>  > correlation but also a contract.  We wouldn't allow a reply to occur
>  > before the request, in our case.
>  >
>  > Thus if there is more than one pattern we need to know which contract to
>  > enforce.  Which is an "extra piece of information".
>  >
> 
> The contract is defined in the WSDL. That's where the extra piece of
> information is.
> 
>  > And Yuzo summarized well other benefits including lifetime control and
>  > name scoping.  Your concerns regarding having to look for duplicate
>  > names can be turned on their head - without scoping you have no control
>  > over name collisions and will potentially have inadvertent matches.
>  >
> 
> Which we can again turn on its head because scoping can cause accidental
> matches that were never intended. Neither solution is ideal since both
> allow for matches that weren't intended. I suspect the real issue
> becomes - is the overhead of the extra declaration worth the protection
> it provides? If one assumes that BPEL processes are going to be enormous
> complex programs then the answer may be yes. But if one assumes, as I
> do, that the vast majority of BPEL processes will be relatively small,
> then any benefit is, I believe, outweighed by the extra machinery.
> 
>  > -----Original Message-----
>  > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>  > Sent: Monday, July 12, 2004 10:13 AM
>  > To: Satish Thatte
>  > Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
>  > Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
>  >
>  > See below
>  >
>  > Satish Thatte wrote:
>  >
>  >  >
>  >  >
>  >  > As far as your points about scoping, you could make the case that we
>  >  > should remove variable decls with exactly the same arguments ;-)
>  >  >
>  > The key difference between variable declaration and link ID declaration
>  > is that in variable declaration one defines an extra piece of
>  > information that is independent of the use of the variable, the
>  > variable's type. In the case of reply IDs I do not believe that an extra
>  > piece of information is necessary. See below.
>  >
>  >  > I am not especially strongly advocating the pattern attribute -- just
>  >  > pointing out that if there are many patterns rather than the 
> single one
>  >  > we need to support now, then in that world we would need a hook to
>  >  > specify the pattern.
>  >  >
>  >
>  > Why would the introduction of new MEP patterns in the WSDL place an
>  > obligation on us to directly declare them? They are already, by
>  > definition, declared in the WSDL. It is also interesting that in the
>  > 
> <http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-patterns.html?content-type=text/html%3B0charset=utf-8> 
> 
> 
>  >
>  > all the patterns are some variant of either one-way or request/response.
>  >
>  >
>  >
>  >  > -----Original Message-----
>  >  > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>  >  > Sent: Wednesday, July 07, 2004 2:41 PM
>  >  > To: Satish Thatte
>  >  > Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
>  >  > Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
>  >  >
>  >  > With the original proposal correlating a receive and reply 
> consists of:
>  >  >
>  >  > Step 1 - Put a messageID attribute on the receive with a unique 
> value.
>  >  > Step 2 - Put a messageID attribute on the reply with a unique value.
>  >  >
>  >  > With the modified proposal correlation a receive and reply 
> consists of:
>  >  >
>  >  > Step 1 - Declare a messageExchanges element
>  >  > Step 2 - Put in a messageExchange entry with a unique name and an
>  >  > optional pattern.
>  >  > Step 3 - Put a messageExchange attribute on the receive with a unique
>  >  > value.
>  >  > Step 4 - Put a messageExchange attribute on the reply with the unique
>  >  > value.
>  >  > Step 5 - Check to make sure that the receive and reply are both 
> children
>  >  > of the scope that contains their messageExchange declaration from 
> step 2
>  >  > otherwise move the declaration to another location.
>  >  > Step 6 - If the messageExchange declaration is declared in a
>  >  > messageExchange declared in a sub-scope then look through all the 
> parent
>  >  > scopes to make sure there isn't a messageExchange name collision 
> since I
>  >  > suspect the usual name scoping rules will apply.
>  >  >
>  >  > If later on the programmer wants to move an existing receive or 
> reply,
>  >  > ones that already have messageExchange attributes, they have to go 
> back
>  >  > and check to see if the messageExchange declaration is still in scope
>  >  > and if not, then move the declaration. Even if it is in scope, 
> they have
>  >  > to make sure there is no name collision. Very quickly programmers 
> will
>  >  > learn to start their processes with a single scope that contains 
> nothing
>  >  > but a messageExchanges element so they can declare all of their
>  >  > messageExchanges in one place and not have to worry about scoping.
>  >  >
>  >  > I am also worried about the pattern attribute. It is redundant
>  >  > information. The MEP is already declared in the WSDL so I don't 
> see much
>  >  > value to declaring it twice. Also, I don't see how the pattern 
> attribute
>  >  > really helps us with WSDL 2.0. Could you please expand on that point?
>  >  >
>  >  >                 Yaron
>  >  >
>  >  >
>  >  > Satish Thatte wrote:
>  >  >
>  >  >  >
>  >  >  >
>  >  >  > 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]