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. 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. 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.
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.
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.
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?
[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.