----- 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
[MIKE3] - Here is my (
originally Jacques ) proposal for branching inside of a
<TestStep> I agree that this would provide more power, and
simpler scripting, without compromising control flow:
Comments?
<TestCase>
<PutMessage/>
<TestStep>
<GetMessage>
<Filter>/MessageStore//Result[Accept or
Reject]</Filter>
<If>
<TestAssertion>/MessageStore[not(//Result[Accept] and
//Result[Reject])]</TestAssertion> <!-- test for XOR
condition of "both" -->
<Then>
<If>
<TestAssertion>//Result/Accept</TestAssertion>
<!-- if "Accept", then run thread "A" -->
<Then>
<ThreadRef name="A"/>
</Then
<ElseIf>
<TestAssertion>//Result/Reject</TestAssertion>
<!-- if "Reject", then run thread "R" -->
<Then>
<ThreadRef
name="R"/>
</Then>
</ElseIf>
<Else>
<ThreadRef
name="Exception"/> <!--
if neither is found, then run exit with "exception"
thread -->
</Else>
</If>
<Else>
<ThreadRef
name="Exception"/>
<!-- if original XOR condition not met, then exit with
"exception" thread -->
</Else>
</If>
</GetMessage>
</TestStep>
</TestCase>
Also note, that one really
doesn't need to include the <Else><ThreadRef
name="Exception"/></Else>.. they just provide a nice logical
flow. The Test Driver
would also reach the same
conclusion (fail Test Case) if the last leaf node in the logic tree is a
<TestAssertion>.. and that <TestAssertion>
"fails">
I can modify the schema to
reflect branching at the <TestStep> level if all agree that this
provides an easier representation of testing semantics.
I don't see any techical
problems with branching at this level, since the Test Driver MUST still
traverse the logic tree, and gracefully exit at the logical
points that it
should.
<<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.