[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] Generating faults when operations are used after theconversation has ended
FYI: Please note that a new issue [1] has been filed in the assembly TC. If this is resolved per the proposal it will make this discussion moot. -Anish -- [1] http://lists.oasis-open.org/archives/sca-assembly/200811/msg00033.html Danny van der Rijn wrote: > I'm uncomfortable with this change. I would be more comfortable with it > if I were more comfortable with the original text, but I don't like > that, either. > > SCA-BPEL doesn't get into the details of how conversations are handled > the way that Java does, for instance, with things like @ConversationID, > @Scope, etc. > > If I have a SCA-BPEL conversation that is surrounded by a loop, is that > legal? Should the conversation be re-initialized on each loop > instance? Currently, we say that we initialize the conversation when an > EPR is initialized for a partnerLink. That seems a bit arbitrary to me, > and wouldn't work for many use cases. Would that mean, for instance, > that I start a conversation when I start the runtime, and I'm only > allowed to end it once; after that I can't use it?? > > Even wthout loops, there seems to be some implication that we have one > conversation instance per process instance, but given the way that the > WS-BPEL spec assiduously avoids much mention of runtime, this is a very > nebulous implication, indeed. > > In any case, I think that this whole section on conversations is VERY > light. I was OK with that until we started talking about changing it, > and especially when we start talking about changing SHOULDs to MUSTs, as > I can always ignore a SHOULD when I deem necessary :-) > > Danny > > Mike Edwards wrote: >> >> Folks, >> >> I'll deal with the wording towards the end of my note. >> >> First, I'd like to tackle a question about the error here that was >> bothering me on the call. >> >> Strictly speaking, for a CLIENT of a conversational service, it is >> incorrect for that client to make any call to the conversational service >> after it invokes an endConversation operation on the service. The >> "isCompleted" requirement does not help, in my opinion. I agree >> that without ordered delivery of the client request messages, then it >> may so happen that no error occurs simply because the second >> operation gets to the service ahead of the first operation, but it is >> weird (in my opinion) to rely on such behaviour to avoid an error. >> >> In principle the client reference proxy will know that an error has >> occurred, since it sees the endConversation operation called >> followed by some other call - the proxy is in a position to report the >> error immediately. The sequence of operation calls is clearly >> incorrect. >> >> Now to the words: >> >> >> "Processes MUST NOT invoke an operation on a partnerLink with a >> conversational interface after an /endsConversation/operation is invoked. >> If this occurs, the SCA runtime SHOULD generate an >> sca:ConversationViolation fault. >> If it can be determined through static analysis that a process invokes >> an operation on a conversational reference after an endsConversation >> operation has been invoked, that process SHOULD be rejected by the SCA >> runtime." >> >> >> Yours, Mike. >> >> Strategist - Emerging Technologies, SCA & SDO. >> Co Chair OASIS SCA Assembly TC. >> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. >> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 >> Email: mike_edwards@uk.ibm.com >> >> >> From: Michael Rowley <michael.rowley@activevos.com> >> To: OASIS BPEL <sca-bpel@lists.oasis-open.org> >> Date: 06/11/2008 17:16 >> Subject: [sca-bpel] Generating faults when operations are used after >> the conversation has ended >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> The current spec wording says the following: >> >> "Any process which, through static analysis, can be proved to use an >> operation on a conversational interface after an /endsConversation/ >> operation has completed SHOULD be rejected. In cases where the static >> analysis cannot determine that such a situation could occur, then at >> runtime a sca:ConversationViolation fault SHOULD be generated by the >> SCA runtime when using a conversational partner link after the >> conversation has ended." >> >> If we didn't want to strongly encourage static checking for this, and >> we don't really care if we have a rule that can't always be tested or >> enforced, then we could replace both of these sentences with the >> following: >> >> "Processes MUST NOT invoke an operation on a partnerLink with a >> conversational interface after an /endsConversation/ is completed." >> >> Michael >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> >> ------------------------------------------------------------------------ >> >> / >> / >> >> /Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU/ >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]