Jacques and all,
Here's some comments
to this thread.
Regards,
Mike
----- Original Message -----
Sent: Friday, February 13, 2004 9:43
PM
Subject: [ebxml-iic] minutes, next
call Monday 23, and more
All:
Next call:
Time: Monday February 23, 2004, 2pm
PT
Host: Fujitsu
Toll - : 1-512-225-3050
code: 89772
Agenda will follow.
Minutes Feb 9 attached.
Here are a couple of issues we
discussed last time: please review,
and Mike, does that challenge the current design?
Jacques
-------------------------------------
1. GetMessage behavior for multiple messages:
- Assume we want to verify that 3 message - no less no
more - with @attribute="XYZ" have been received,
after a PutMessage step, within 300 seconds.
- The count()=3 test condition should NOT be
in the filter, but in the Assertion part of the test step.
[MIKE] - Agreed
Indeed, we want to select as many messages
with "XYZ" as we can, within 300 sec. So we set stepDuration =300,
and we set getMultiple="true". Then only,
after messages have been read, we verify if count()=3, in the
Assertion.
If yes, case "pass" if not
case "fail".
[MIKE] - I agree with this.
I am also inclined to simply eliminate the "getMultiple" attribute
completely, since an XPath query will
return 0 or more messages that satisfy the query I believe we should
leave it up to the test writer to determine whether more than one returned
message (i.e. a duplicate) is a problem or not. XPath is
robust enough to allow someone to count the number of messages that match
their filter, and fail a <TestStep> if too many
are returned. Comments?
<JD> Yet
it is not enough: GetMessage is supposed to "wait" for a message, i.e. if
its filter is not satisfied on the current message store, it will "try"
again each time the store gets updated (new message coming in), until
either (1) filter is satisfied, or (2) timeout is expired.
[MIKE2] - This is how it is supposed to
work. GetMessage will "poll" the MessageStore until (a) XPath
condition is satisfied (b)Stepduration period has been reached (300
seconds)
So maybe we can
get rid of "getMultiple", assuming that the filter behavior is as
follows: the XPath filter will apply to a single message at a time, and
normally succeed as soon as one or more message in the store satisfies it.
It returns then a node set of all (un-hidden) messages that satisfy
it in the store (I think that is the way it workds actually?) Then the
Assertion will apply to the nodeset. And if we want to select ALL the
matching messages within 300 sec, we should use "sleep 300" before doing
GetMessage, and the stepDuration should be
short.
[MKE2] - I see what you are trying to do.. I
would agree with you, that if you want to get "all" messages, than a
<Sleep> prior to the <GetMessage> will accomplish what you
want.. you can then select "all" messages using a generalized XPath query
that says ....select *... from the MessageStore. I think that
the "getMultiple" attribute really just "overloads" and complicates what
XPath can already do, and would vote to remove it.
But the
botttom line is, as long as stepDuration is not expired, if the filter
fails on the store when doing GetMessage, it should be reapplied each time
a new message comes in. I think we need to nail down the semantics of
GetMessage, as it is entitled to "succeed" as long as it has not timed
out.
[MIKE2] - I am doing that
now. I believe that viewing <GetMessage> as a "polling"
mechanism on the MessageStore, that times-out after the stepDuration has
expired is the best way to visualize how <GetMessage>
works.
2. "Exclusive threads":
How can we implement a test case that will have to run
one thread
out of two or more
possible threads, not knowing which one in advance,
and must "fail" if more than one have actually been
completed / run?
(this is the meaning
of BPSS fork "XOR" I think)
Do we only
need this?
Here is a (not so good)
example: a test case that will send a Purchase Order to the remote
party,
and expect either one of two
responses "accept" or "reject", and with a specific
sequence of exchanges for each response type. We want to
fail in case we get both responses.
One
way to implement this, on the Test Driver side, is to run:
step1: PutMessage()
step 2: split (A, R) (each thread A and R will do
a GetMessage filtering resp. on "accept" and "reject")
step 3 orJoin (A, R)
(but how can we express that in case we get there via A, we
don't even want R to gets its message or
else we fail?)
[MIKE] - Why not introcude
an <XORJoin> element? I find XORJoin is also an operator
used in workflow. By replacing orJoin (A, R) with
xorJoin(A,R) in step 3 above you could introduce
the samntics you want. Comments?
step1:
PutMessage()
step 2: split (A, R)
(each thread A and R will do a GetMessage filtering resp. on "accept" and
"reject")
step 3 xorJoin
(A, R)
<JD> I also thought about "XORjoin"... but that would help
only in cases where threads execute completely.
[MKE2] - My question is: what is wrong with having both threads
execute completely? If a <Thread> does not execute completely,
isnt everything after that "moot" at that point
anyway? The only way our testing logic flow can been
interrupted is because of an "undetermined" cause, so how can we
really continue with an xorJoin, or anything that follows
that anyway?
In case we don't even accept that thread R does GetMessage
successfully if A did, we need to be able to "fail" the case. I see an
Exception thread being useful here. That could be combined with setting a
"variable":
first thread to succeed doing GetMessage will set "ResponseDone",
and every thread will check this var before setting it: if it is alrady
set, that will cause failure.
[MIKE2] - I'm confused here. I thought the point of running a
<Split> is to concurrently run independent <Threads>
( as a useful way to optimize performance ). But is sounds like you
are saying you wish to "short circuit" the xor logic by having concurrent
<Threads> check the value of a "flag" variable, and not finish
execution if one has already succeeded. Wouldn't this throw off
the xor evaluation of the results of <Thread>s A and R? The
boolean result of <Thread>s A and R cannot both be "true" in an xor
evaluation, but we would have no way of knowing if that may be the case
because we "short circuited" the execution of one of the
<Thread>s?
Otherwise, XORjoin can be useful, but I am wondering if it is worth
it, as we can do liek above more generally.
Note that we can
also implement this case with :
step1:
PutMessage()
step 2: GetMessage()
, if ("accept") then thread A else thread R end;
step 3: ...
Although
in this second script additional unwanted messages would not be detected
(in case we get both "accept" and "reject") as the 1st message
received would decide where to go.
[MIKE] - I would opt for the
xorJoin option I suggest above to handle this
One way to implement this "XOR" is , in each
thread A and R, start an exception thread that would "fail" if the
"other"
message is received. Any way to
do that more simply?
[MIKE2] - I wouldn't call this
"simpler", but it would work with the current scripting
schema::
<PutMessage>
<If> <GetMessage
="accept"/>
<Then>
<If><GetMessage =
"reject"/><Then><ThreadRef="exception"/><Else><ThreadRef="A"/></If>
</Then>
<ElseIf><GetMessage="reject"/>
<Then>
<If><GetMessage =
"accept"/><Then><ThreadRef="exception"/><Else><ThreadRef="R"/></If>
</Then>
</If>
[MIKE] - I would opt for the
xorJoin option I suggest above to handle this
<<IIC_February_09_04_minutes.txt>>
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/ebxml-iic/members/leave_workgroup.php.