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: minutes and more


Title: minutes and more

All:

1. We have Mike Kass nominating for IIC secretary.
Please vote: send YES / NO / ABS vote by email by Wednesday May 19, 6pm PT.

2. Minutes attached.
A few action items: use case material (Monica / BPSS)
 we need to keep solving existing use cases in the simplest way.

3. Next meeting Monday May 24th (no meeting next week)

Host: Fujitsu
Time: 2pm PT, Monday May 24
Toll only : 1-512-225-3050
Participant code: 716071
--------------------- Agenda

1- secretarial position: results on vote for Michael Kass.

2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting, based on use cases.
- timeout control: primitives, design patterns.
- conditional branching: redesign (which place in the scrip language?).
- loops: (iterating several test steps, is that a particular branching?)
- covering BPSS test requirements.
3- TestFramework 1.1 : test configurations for BSI (BPSS engine)
- role of existing Test Service.
- role(s) of Test Driver,  simulating  busienss activities.

4- Schedule for releasing TestFramework 1.1
Regards,
jacques
<<IIC_May_10_04_minutes.txt>>

Time: Monday May 10, 2004, 2pm PT 
(joint with New Orleans f-2-f, Thu Apr 29)
Host: Fujitsu 
Toll only : 1-512-225-3050 
Participant code: 716071 

Attendees: 

Michael Kass (NIST)
Monica Martin (Sun)
Jacques Durand (Fujitsu)
Pete Wenzel (SeeBeyond)

excused:
Steve Yung (Sun)

Agenda: 

1- secretarial position: only Michael Kass nominated, so we will vote if we have quorum, 
else we open a mail vote (1 week). 

2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting. 
- go through use cases (see attached) and decide which operators in TFk1.1 are sufficient to best script them.
- recap of BPSS choreography patterns and what operators are most familiar to workflow. 
- outline what simplifications can we do to TFk1.1 scripting, while covering BPSS test requirements. 
3- TestFramework 1.1 : what Test Service for BSI (BPSS engine)? 
- at f-2-f, we have outlined the possibility of using a subset of Test Driver, to simulate the application components 
that process and send payloads via the BSI. 
-------------------------- minutes ---------------------------------

1. Secretary
- Mike only nominee. Will open the vote by email.

2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting

2.a: time control
- we reviewed the use cases. Use case #1: timing operators today cannot handle "TimeToPerform" (BPSS)
- we need more powerful primitives (not necessarily higher level)
- Pete> need also to control timing of "retries", e.g. reliability. That is, duration of an iteration. (need use case #4)
- Mike> XPath 3.0 support time conditions.
- Test log couldbe queried - but not everything goes to the log.
- issue: we need to be able to time any arbitrary sequence of steps. SOme of these sequences may
also overlap. Cannot just associate timeouts with threads.
- Monica> need to time bus transactions, and the entire bus collaboration that include these (nesting), and
we don't want to "wait" until a timeout to fail/pass the test case.
- outline of a solution: need a primitive to log a date/time value (with identifier), and then at any point
in the test case, a testAssertion can compare this to current time (we can always specify a primitive
that gives current date/time), and make fail/continue decision. An exception thread
could be started just to loop on this check and fail the test case if timeout expired.
- Accommodating BPSS opeators and concepts? (i.e. having these built-in the framework?) Monica and Jacques
believe we don't have to: we don't want the test driver to become a BPSS engine (and just that).
But if the test case script language uses more general and low-level primitives that can test any
BPSS bus transaction or collaboration, then it should be possible to generate such a test case script
(concrete syntax) from a BPSS definition.

2.b: Conditional statements:
- Monica will provide input on conditional branching for bus collaborations.
- The concept of "if <thread> then ..." is unnatural to Workflow users. It seems what we need is 
"if <assertion> then..." where <assertion> if XPath based, on same nature as regular test assertion elements.
- Does not have to be part of (nested in) existing test steps ops either: could be an extenal branching op like split.

2:c: loops:
- not good support for this yet: need looping over several test steps.
- Monica will get Dale Moberg white paper on this. 

3- TestFramework 1.1 : what Test Service for BSI (BPSS engine)? 
- Testing BSI can be considered at two levels:
(1) conformance testing where a BSI is tested from the "other party" side.
Test Driver then simulates one side of the process "on the wire"
(2) interop testing where two BSIs are communicating according to a BPSS def.
Test driver then has to simulate one of the applications (i.e. implements "business activities" that
consume and generate messages.)



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