Comments inline...
Danny van der Rijn wrote:
4918C2CF.50104@tibco.com" type="cite">
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?
Yes. And by "SCA-BPEL conversation", I assume that you mean a partner
link that uses an interface that has been marked as conversational.
4918C2CF.50104@tibco.com" type="cite"> Should
the conversation be re-initialized on each loop
instance?
If the partner link is declared in a scope that is inside the loop,
then yes. If the partner link is declared outside of the loop, then
the loop would be part of the same conversation. I think these two
things are implied by our statement that the conversation is
initialized when the partner link is initialized (the spec text that
you note below).
4918C2CF.50104@tibco.com" type="cite">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??
I don't know of any way to declare a partner link in such a way that it
is initialized when the runtime is started. The partner link is
initialized when its scope is initialized.
4918C2CF.50104@tibco.com" type="cite">
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.
Perhaps we need to clarify what it means to initialize a partnerlink,
since you seem to be reading it very different from the way I read it
(i.e. its initialized when the scope starts).
4918C2CF.50104@tibco.com" type="cite">
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
Michael
4918C2CF.50104@tibco.com" type="cite">
Mike Edwards wrote:
OF81C9A961.23D76323-ON802574FB.002995B3-802574FB.002A9D18@uk.ibm.com"
type="cite">
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 endsConversationoperation 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
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
|