492357C5.3030300@oracle.com" type="cite">
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/
>>
>>
>>
>>
>>
>>