minutes, next call Monday 23, and more

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: 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.
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".

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

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?

<<IIC_February_09_04_minutes.txt>>

IIC Conference Call Minutes: 
Monday, February 9, 2004
 
Attendance:

Mike Kass (NIST)
Jacques Durand (Fujitsu)
Serm Kulvatunyou (NIST)
Monica Martin (Sun)
Steve Yung (Sun)
Tim Sakach (DrakeC)

Excused:
Pete Wenzel (SeeBeyond)


Minutes taker: Jacques Durand

Time: Monday February 9, 2004, 2pm PT
Host: Fujitsu
Toll - :  1-512-225-3050

Agenda: 

1. Test Case scripting: Status on remaining issues, summary of updates (Mike Kass, Jacques) 
- "sleep" step. 
- split/join, final position. 
- if-then-else: where usable. 
- management of the message store, semantics of putting and getting messages. 
- test case exit values: "pass/fail/notapplicable"? Exit statements. 
- the PreCondition role in GetMessage. 

2. Test Framework interfaces: 
- position on standard interface/API Test Service - MSH (see notes Jan 5th) 
- the "message wrapper" document (header fields + payloads) 

3. Other: 
- Update on IIC Test plan proposal for ETSI European test event. 
- "light" IIC f-2-f New Orleans April 28-29 details. 

--------------------------

1. TestFramework status:

Summary of issues and upgrades for Control flow:
- "sleep" step: OK, usable as a step. timeouts (stepDuration) not really necessary for 
GetMessage: when several msg are expected within some time window, 
we can just "sleep" for that time before doing GetMessage.
However, that forces to wait until timeout before reading. So a timeout is convenient.
- split/join: we agree on a single "split" (asynchronous), even for forking a single thread.
All synchronization control done with join ("or" or "and"). Still a use case to investigate:
when splitting several threads, what if we want to test that only one was actually executed?
Jacques will state the problem. 
- if-then-else: where usable? inside a thread. 
- management of the message store: GetMessage will decide whether to "hide" or not
the messages it consumes. Note that messages are not physically "deleted", only "masked"
(e.g. still in store for a log)
- semantics of GetMessage when several messages are expected: say filter with count()=3,
then do we check every time a message comes in, until condition satisfied or timeout?
That would not achieve expected behavior: we might receive 4 and that is not OK.
But in that case, the filter should not state the count() condition: the Assertion should.
- test case exit values: "pass/fail/undetermined"? All possible Exit statements. 
Undetermined meaning that the material under test was  not apppropriate for a
conclusive output.
- the PreCondition role in GetMessage: useful. Mostly to identify the "undetermined" cases.

2. Test Framework interfaces: 
- position on standard interface/API Test Service - MSH (see notes Jan 5th) 
We will describe such interfaces. Mike already drafted them. The intf will remain
very "abstract": a single call for each kind of transfer, with single argt: a "wrapper"
cocument that will hold message + header attrs.
- Mike sees this wrapper as same obejct we pass to the "Initiator" action.
That should work.
- However, this wrapper should be indepdt from ebMS format: apps as well as Test Service
are not expected to parse - or to generate - any ebMS header. In addition that would
induce more ebMS dependency (V#, etc.)


3. Other: 
- Update on IIC Test plan proposal for ETSI European test event: 
- Tim says test plan not complete enough. Test cases missing. Korbit will
complete. A subset only will be used. Drke also has implemented a subset.
- "light" IIC f-2-f New Orleans April 28-29 details: we have Thu 29 from 1pm to 5pm.
We'll have a 1 or 2 hour  meeting. The theme would be more "higher level" than
technical:
. current feedback on test framework implementations, their usage (e.g. for ETSI round).
. perspectives in using T.Fk for other OASIS specs.
. the role of IIC if a new ebMS arch or coordination group emerges.