OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-iic] minutes, next call Monday 23, and more


Title: minutes, next call Monday 23, and more
Jacques,
 
    I thought about this more and have a "simpler" solution to this particular problem.  Please see [MIKE3] below:
It would also involvechanging the scripting to allow branching from inside of a <TestStep> ( I was previously opposed to this because I
wanted some "atomic" level of testing from which one could not "branch".. but the result is you get some complex
scripts. If we use the power of XPath to determine branching, it makes for "simpler" scripts.  Please see the example at
the bottom of this message:
 
 
----- Original Message -----
Sent: Wednesday, February 18, 2004 12:43 AM
Subject: Re: [ebxml-iic] minutes, next call Monday 23, and more

Jacques,
 
  My comments below
 
Mike
 
----- Original Message -----
Sent: Tuesday, February 17, 2004 10:56 PM
Subject: RE: [ebxml-iic] minutes, next call Monday 23, and more

Mike: <JD>
 
-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Sunday, February 15, 2004 4:37 PM
To: Jacques Durand; ebXML IIC - main list (E-mail) (E-mail)
Subject: Re: [ebxml-iic] minutes, next call Monday 23, and more

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]