No, that's not what I'm saying. I'm hoping my other notes will make my
position more clear.
Mike Edwards wrote:
OF067DD9F0.78DA6FF5-ON802573A6.0040C360-802573A6.0041343C@uk.ibm.com"
type="cite">
Danny,
If I read you correctly, you seem to
be taking a view that the SCA conversation mechanism can never be in
conflict
with the
BPEL correlation mechanism.
Logically, the SCA conversation
identifies
a process instance ( a particular instance of the component
implementing
the
service).
So too, logically, the BPEL process
data identifies a process instance.
Surely it is possible for these two
mechanisms to be in conflict? ie SCA identifies process A and BPEL
correlation identifies
process B.
Are you arguing that this
cannot/will
not happen? Or are you saying that if there is ever conflict, the
BPEL mechanism always
wins out?
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
Apologies for wading into this conversation late, and
with such a long note, but...
I am somewhat troubled by the classification of the correlation data as
some kind of ID that identifies the process instance. The
point of BPEL correlations is to get away from that style of usage,
and,
instead, use business data in the message payload. The client should
have no knowledge of how the services are constructed, whether the
services
are bound to one process, multiple processes, one engine, multiple
engines,
etc. WSDL messages carry business data *only* and don't concern
themselves
with implementation details like process-ids, etc. whether in the
header,
or not. See http://www.oasis-open.org/committees/download.php/3249/Original%20Design%20Goals%20for%20the%20BPEL4WS%20Specification.doc,
especially
Properties and Correlation
A running business process is an instance of a
particular
process model. Thus, each running business process requires at least
one unique identifier to be able to pass an incoming message to the
correct
instance of a process model. Since running business processes are
first class business artifacts, they are in practice identified in
business
terms. Different participants of a particular process may want to
identify the process in their own terms and they may even want to
change
the identifier used in the course of their interaction with the
process.
We therefore came to the conclusion that defining artificial instance
identifiers for processes is not the best solution. Instead, we added
a flexible mechanism to BPEL4WS that supports multiple user-defined
identifiers
for a process instance: Correlation via message properties. In
particular,
these message properties are embedded in the application messages
(i.e.,
WSDL abstract messages) exchanged by the process and are not defined as
header fields of the communication protocol. This results in a binding
independent correlation scheme.
Overall Goal 6: BPEL4WS should support an
identification
mechanism for process instances that allows the definition of instance
identifiers at the application message level. Instance identifiers
should be partner defined and may change over time.
Of course, I understand that many implementations will violate this
intent,
and for good reasons, all. However, I don't think that the combination
of SCA and WS-BPEL is enough to warrant standardizing such violation.
OK, so what does all of this theoretical blather mean with respect to
the
current proposal (which I'm not sure I can actually piece together, by
the way)?
There are only 2 dead-letter cases that I think we can standardize:
1) The protocol times out
2) Possibly in cases where a bpel:CorrelationViolation is thrown
internally
My analyses:
1) If the protocol times out, well, then it's too late to send an sca
exception,
isn't it :-) A wise implementation may choose to preempt the timeout
and issue an exception on its own. A case that I think that the
proposed
use of an sca exception is reasonable.
2) If a message is determined to be destined for a particular process
(i.e.
transport-level correlation via SCA, WS-Conversation, etc) but when the
message is delivered to the process, the process rejects it for that
process
(and a bpel:CorrelationViolation is thrown). Some engines may hang
on to that message and try to deliver it to another IMA in that or
other
process instances, current or future. Some engines may not. In
an engine that doesn't hang on to it, it's irrelevant whether a
matching
IMA will ever exist - even if it does, the engine will never try to
deliver
it. In this case, the throwing of an sca exception as proposed, makes
sense to me.
If we choose these 2 axes to consider, then they should probably be
separate
exceptions.
Evaluating this thought process against the ABC's of the thread:
(a) Process instance does not
exist.
e.g. the UUID-like "conversation-id" does not match any active
process instance.
I posit that this is not a valid, spanning case to be talking about.
Correlation
is not meant (solely) for instances, but for business data that is
independent
of process.
(b) Process instance exists
(e.g.
the "conversation-id" matches with an active process instance).
However, there will NEVER be any potential matching IMA (e.g. the
message
is targetting operation "cancelPO" and the process has no IMA
that match the operation at all. Or there is only potentially IMA and
it
is already enabled with a wrong CS value).
Again, this is process-identity based, and is therefore not suitably
wide-enough
scope to consider.
(c) A potential matching
receive
may be enabled in future, but not enabled in a "timely fashion".
This is my (1) above.
Thanks and condolences for reading this far,
Danny
Alex Yiu wrote:
Hi, Michael,
[1]
I think I am sold on why you want to view them differently. :-)
The reason that I agree with you may be slightly different than your
own
wordings. According to you, the main reason is who is causing this
problem
- the message sender? or process itself? The distinction may not be
that
clear cut in that aspect. [e.g. case (b) can be caused a mistake in
process
definition as well]
IMHO, the key differences what factors are involved in determining
whether
we hit one of these problematic cases.
For the cases of (a) and (b), the SCA+BPEL infrastructure can
detect
deterministically by introspecting the state of the process instance
and
the process definition (alone).
On the other hand, case (c) are problems situation that the
infrastructure
cannot detect deterministically by introspecting the state of the
process
instance and the process definition alone. The infrastructure can
safely
classify the situation as problems based on other pre-arranged
heuristic
or protocol (e.g. timeout values).
(Side Note: for case (c): the BPEL process definition itself may be
correct.
It may fail to enable an IMA due to another external error the process
cannot control.)
I believe the consensus so far is: case (c) is not something we try to
cover in SCA-BPEL spec. We will talk about case (a) and (b) here.
I think I will re-visit the wordings of the proposal by using the
Michael's
"never" wording plus variants of the underlined wording above.
[2]
May a SCA standard fault be reused and thrown in other situation not
covered
by the spec?
E.g. May "sca:DeadLetterMessageError" fault be thrown in other
situations, other than case (a) and (b)?
Should the spec be silent on this topic? Or, we should explicitly allow
or disallow such a usage?
Thanks!
Regards,
Alex
Michael Rowley wrote:
In my opinion, the
important
difference between (a), (b) and (c) is that, for (a) and (b) it is
likely
that the client did something wrong. However, I expect that for
timeout
(case c), the error either exists in the infrastructure (something is
down)
or, quite likely, the BPEL process was designed incorrectly such that
it
has a potential deadlock.
This is why I think there
should
be two different faults. I think they would be treated differently,
at to the extent that _any_ faults are treated differently from
any other.
Michael
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Friday, November 16, 2007 3:26 PM
To: Dieter Koenig1
Cc: Michael Rowley; Mike Edwards; Najeeb Andrabi; sca-bpel@lists.oasis-open.org;
ALEX.YIU@oracle.com
Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation
Disagreement between SCA and BPEL proposal
Hi, Mike and Dieter,
Thanks for the follow up discussion emails.
It looks like there are 3 cases listed on the table in the previous
emails
sent by Mike and Dieter.
(a) Process instance does not exist. e.g. the UUID-like
"conversation-id"
does not match any active process instance.
(b) Process instance exists (e.g. the "conversation-id" matches
with an active process instance). However, there will NEVER be any
potential
matching IMA (e.g. the message is targetting operation "cancelPO"
and the process has no IMA that match the operation at all. Or there is
only potentially IMA and it is already enabled with a wrong CS value).
(c) A potential matching receive may be enabled in future, but not
enabled
in a "timely fashion".
If I read Michael's email correctly, his two cases are (a)+(b) together
as one case and (c) as the other case. On the other hand, Dieter's two
cases are (a) and (b).
IMHO, (a) and (b) are definitely close enough to be treated together,
as
both of them do not involve "timely fashion" concept.
Few additional points to consider:
·
When
a UUID-like conversation is used (Oracle's product has similar feature
in the form of WS-Addressing for a while - pre-dated SCA), most users
would
not use BPEL-CS as an additional correlation mechanism anymore. That
implies
frequency of case (b) is actually very small compared with (a) and (c).
·
Even
though the underlying causes for cases (a), (b) and (c) are different,
the behavior observable by the message sender is exactly the same in
these
3 cases. Do we want to define another fault for user to catch
differently?
That is a usability concern.
o
My
thought is: case (c) is not applied, if there is no "timeout"
value specified. For example, if someone use plain simple SOAP without
any special protocol related headers, case (c) would not be applied.
·
If
we decide to have a different fault for case (c),
o
Do
we want to define this separate fault in SCA spec?
o
In
that case, the "sca:DeadLetterMessageFault" will be mainly for
case (a) in real life usage.
·
In
BPEL spec, there was a formal discussion on whether user-code can throw
a standard fault defined by BPEL spec (e.g. "bpel:selectionFailure").
I guess similar questions are applied here: whether
"sca:DeadLetterMessageFault"
can be re-used outside the scenario described by the SCA spec.
On the topic: "who specifies timeout and what timeout value"
I am not proposing we should define a detailed timeout mechanism in
SCA-*
spec, because it may depend on the actual underlying protocol. If a
protocol
with a business-conversation timeout mechanism exists, my gut feeling
is
that the sender should specify the value. The actual time out will vary
depending on the nature of business conversation.
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Mike, my preference goes into a
similar
direction.
(1) Indicating that no existing
process
instance can be correlated with a
request - note that this may not
always
be because of a faulty correlation
set; it may also happen if a branch
of the process navigates to an <exit>
activity such that a
<receive>
on another branch is effectively cancelled -
this would not be a problem caused
by the client.
(2) Indicating that an existing
process
instance that has been correlated
with a request can never consume
the
request - of course only if this
situation can really be detected -
I agree that any good timeout value can
be wrong in another scenario.
Kind Regards
DK
From: "Michael
Rowley" <mrowley@bea.com>
To:
"Alex Yiu" <alex.yiu@oracle.com>
Cc:
Dieter Koenig1/Germany/IBM@IBMDE, "Mike Edwards" <mike_edwards@uk.ibm.com>,
"Najeeb Andrabi" <nandrabi@tibco.com>,
<sca-bpel@lists.oasis-open.org>
Date: 16.11.2007
16:22
Subject: RE: [sca-bpel]
Issue 3 - An amended proposal - Correlation Disagreement between SCA
and
BPEL proposal
My first inclination would be to
have
two different faults. One fault that
says we know, logically, that you
have
sent a faulty correlation set. A
different fault would be used to
report
that your seemingly valid
correlation set hasn’t been matched
by some designated timeout period
(although I’m not sure which side
should define that timeout).
If others feel strongly that these
two error conditions should be combined
into one fault, I would be OK with
that, but my preference would be to keep
them separate. I’m also not
sure that I would bother standardizing on the
timeout fault, since it may be
appropriate
for it to be different for
different bindings. Essentially,
this is an argument to keep it as
“never”.
Michael
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, November 14, 2007
4:21 PM
To: Michael Rowley
Cc: Dieter Koenig1; Mike Edwards;
Najeeb
Andrabi;
sca-bpel@lists.oasis-open.org;
ALEX.YIU@oracle.com
Subject: Re: [sca-bpel] Issue 3 -
An
amended proposal - Correlation
Disagreement between SCA and BPEL
proposal
Hi Michael,
I understand your concern.
Wording versions:
Version 1: "will never be matched"
Version 2: "will not be matched"
Version 3: "can not be matched"
I think the current version 3 has
the
least interpretation space for the
engine to queue up messages,
because
it loses the time dimension semantic.
Differences on whether to use the
term
"never":
Consider the case that: (one of the
bullet in the proposed non-normative
text)
· matching
IMAs blocked by other activities within a sequence
Say, a matching IMA is blocked by
another
preceding receive. Or, a matching
IMA is blocked by an ill-defined
preceding
loop.
If we pick the term "never"
in version 1, then using this standard fault to
notify the message sender won't be
covered by the if-condition. Because,
the engine cannot logically
conclude
the external message for the blocking
receive will never arrive or the
engine
cannot logically conclude the
ill-defined loop will never finish.
My intention here is: the engine
may
notify the sender of this error
condition, if a matching IMA cannot
be found in a timely manner.
E.g. if a section of a process
typically
takes only few minutes or hours,
after days or weeks of waiting for
the blocking receive / loop, and, if the
engine decides to notify the sender
of this error condition by this new
fault, it should be covered by the
spec.
So, I prefer wordings of version 2
or a new version wording (modified based
on version 3):
Version 4: "can not be matched
... in a timely manner"
Of course, the exact details of
"timely
manner" will depend on the
underlying protocol (transport and
coordination) and etc.
For example, if:
· the
operation is request-response
· HTTP
is the transport protocol (say the HTTP timeout is: 360
seconds)
· an IMA
cannot be matched within the transport timeout period
· but
a potential matching IMA is pending but not activated yet.
If we use the term "never",
then this new standard fault does seem to be
applied and the existing transport
level time out fault will be applied
instead. If we use wordings of
version
2 or version 4, then this standard
fault can be applied and covered by
the spec.
Further thoughts and comments?
Thanks!
Regards,
Alex Yiu
Michael Rowley wrote:
The reason I had included the word
"never" was precisely for this
reason. I didn't want it to read
that there is no IMA active right now.
I wanted to say that the system
determined
that there never would be
one. There certainly are times
when that can occur, such as when you
are using a combination of
engine-managed
correlation and explicit
correlation sets.
If we don't say "never",
then I'm not sure how we would word this to
allow for queuing up messages until
an IMA becomes active.
Michael
-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Tuesday, November 06, 2007
4:31
AM
To: Mike Edwards
Cc: alex.yiu@oracle.com;
Najeeb Andrabi; sca-bpel@lists.oasis-open.org
Subject: Re: [sca-bpel] Issue 3 -
An
amended proposal - Correlation
Disagreement between SCA and BPEL
proposal
Alex, Mike E, Mike R, Najeeb,
I assume we agree that we want to
allow
a BPEL implementation to store a
message if it can be consumed by a
process instance at a later point in
time. Do we want to make this
explicit
in the normative language? (Of
course, it cannot be decided in
many
cases, and additional
considerations
apply - e.g., it makes a lot of
sense
for one-way messages and it makes
less sense for request-response
operations
called via synchronous
bindings
[<- btw, this is another
scenario
for issue BPEL-12]).
For those cases where we finally
decide
to return an
"sca:DeadLetterMessageError"
fault to the sender, I have additional
questions:
- in case of request-response
operations, would this fault manifest
itself
as an SCA ServiceRuntimeException?
- in case of one-way operations,
will SCA (the assembly spec?) define
the
coordination protocol messages?
Kind Regards
DK
From: Mike
Edwards <mike_edwards@uk.ibm.com>
To:
sca-bpel@lists.oasis-open.org
Cc:
Najeeb Andrabi <nandrabi@tibco.com>,
alex.yiu@oracle.com
Date: 06.11.2007
09:46
Subject: Re: [sca-bpel]
Issue 3 - An amended proposal - Correlation
Disagreement between SCA and BPEL
proposal
Alex,
I agree with your point about
"never",
but I don't like your additional
words in parentheses at all. The
extra qualifiication just complicates
things needlessly
- let us leave it to the SCA &
BPEL infrastructure to work out whether
matching can be done. I changed
"will" to "can" as well, to get rid of
this flavour of
"future-ness" in the wording
which is not appropriate, since this
statement
is about a state and what to do
when
this state is detected.
How about:
"If the SCA or BPEL infrastructure
is able to determine that a message,
that has been sent to an endpoint
address
of a business process, can not
be
matched with a corresponding
inbound
message activity (i.e. receive,
onMessage or onEvent), then:"
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
Alex Yiu
<alex.yiu@oracle.
com>
To
Michael Rowley
<mrowley@bea.com>
05/11/2007 19:23
cc
Najeeb Andrabi
<nandrabi@tibco.com>,
sca-bpel@lists.oasis-open.org,
ALEX.YIU@oracle.com
Subject
Re: [sca-bpel]
Issue 3 - An amended proposal -
Correlation Disagreement
between SCA and BPEL
proposal
Hi, Michael,
Thanks for the quick feedback.
I agree with you that the "if"
condition in the normative text can be
tightened up. I like your changes
in
general.
I am wondering whether the word
"never"
may be a bit too strong. I am
thinking to use the word with a
weaker
tone with extra qualification
description.
How about:
"If the SCA or BPEL infrastructure
is able to determine that a message,
that has been sent to an endpoint
address
of a business process, will
not
be matched with a corresponding
inbound
message activity (i.e. receive,
onMessage or onEvent) (possibly
based
on a message protocol or some
infrastructure heuristic), then:"
If the extra qualification
description
"(possibly based on a message
protocol or some infrastructure
heuristic)"
opens new cans of worms, I
am
comfortable to drop it.
Thanks!
Regards,
Alex Yiu
Michael Rowley wrote:
Alex,
Thanks for the background material.
I also the proposed normative text,
except for the reference to "a
dead letter message", without having a
definition for that in our spec. I
also thought that "message receiver"
might be too vague. Perhaps the
first sentence, which you had as:
"If the SCA and BPEL infrastructure
of the message receiver is able to
detect a dead letter message:"
could instead read:
"If the SCA or BPEL infrastructure
is able to determine that a message
that
has been sent to an endpoint
address
of a business process will never
match
a corresponding inbound message
activity
(i.e. receive, onMessage or
onEvent), then:
Michael
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, November 01, 2007
12:34
PM
To: Najeeb Andrabi
Cc: sca-bpel@lists.oasis-open.org;
ALEX.YIU@oracle.com
Subject: Re: [sca-bpel] Issue 3 -
An
amended proposal - Correlation
Disagreement between SCA and BPEL
proposal
Hi all,
Here is an amended proposal for
this
Issue 3.
I believe the spirit of the
proposal
is the same. But, wordings and
details
are different. This amended
proposal
avoids/addresses a few issues that
the
original proposal has:
*
"bpel:correlationViolation"
is for BPEL's CorrelationSet
lifecycle violation - not CS
mismatch.
I am not sure we want to overload
it. All existing "bpel:*"
fault thrown are for internally consumption
only.
Not directly visible through BPEL
partnerLink.
* There
is no formal notion of "wrapping" in WS fault.
* We need
to address the difference in one-way or
request-response
MEP.
* The flow
chart has "wait until all the IMA in all existing
processes have been activated".
That seems to be not so feasible /
well-fit.
The proposal has two parts:
background
(non-normative) text and
normative
text.
If the background text is too long
for some audience, I am happy to trim
and para-phrase it. I send this
longer
version for the benefit for the
TC
discussion.
About the normative text, I hope it
is short yet concise.
One thing to highlight is: it may
be
infeasible to specify a universal
dead
letter detection algorithm, which
has
real values to users. Hence, I am
using SHOULD and MAY here, instead
of MUST.
------------------------------------
[background text begins here ...]
When an inbound message comes into
the SCA and BPEL infrastructure, such
a
message is normally consumed by a
matching
inbound message activity
(IMA)(e.g. a <receive>
activity).
However, due to process model error or
runtime message data error, there
is
no matching IMA at all or a
matching
IMA is not enabled within the
expected
time limit of the
(system/business
level) protocol between the message
sender and receiver. This kind of
messages, which do not have a
matching
IMA, are termed as "dead message
messages"
Examples of process model error are:
* matching
IMAs are skipped by faults
* matching
IMAs blocked by other activities within a sequence or
an
impossible-to-fulfill control link
transition condition.
* IMAs
cannot receive message due to incorrect usage of message
correlation mechanism, including
BPEL
correlation set and SCA
conversational interface
Examples of runtime message data
error
are similar to above, as the
above
error are not inside the process
definition
itself but caused by
incorrect
data values.
There might not be a universal way
to determine a message is truly a
"dead
letter message" without any
additional
protocol between message senders
and
receivers. Consider the following
example,
an message is dispatched to a
BPEL process instance by SCA
conversational
mechanism. At the moment
when
the message is matched with the
BPEL
process instance, there might be no
<receive> activity enabled
for
the matching partnerLink and operation at
all, or there is a <receive>
activity enabled for the matching
partnerLink
and operation but with a mismatched
correlation set. Some users might
think
this is certainly a dead letter
message
situation. However, a matching
IMA
may be enabled minutes, hours, or
days
later, as the matching IMA might
be
blocked in the process model.
On the other hand, there might be
some
cases that the BPEL
infrastructure
can determine there will never be a
matching IMA enable in future. And,
some advanced features in BPEL
infrastructure
(e.g. process instance
repair
or process definition repair) might
make the detection of "dead letter
message" cases more difficult.
However, with some additional
system-level
protocol coordination between the
message
sender and receiver, it might
make detection easier.
------------------------------------
------------------------------------
[normative text begins here ...]
If the SCA and BPEL infrastructure
of the message receiver is able to
detect a dead letter message:
* If the
message is sent through a request-response operation,
"sca:DeadLetterMessageError"
fault SHOULD be thrown to the message
sender
* If the
message is sent through a one-way operation and
additional
system-level protocol is used
between the message sender and receiver,
the
dead letter message error situation
MAY be notified to the message
sender,
according to the protocol used.
------------------------------------
Looking forward to further comments
and fine-tuning.
Thanks!
Regards,
Alex Yiu
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
---------------------------------------------------------------------
To unsubscribe from this mail list,
you must leave the OASIS TC that
generates this mail. You may
a link to this group and 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
|