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