Next call, minutes for today

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

Title: Next call, minutes for today

All:

Apologies for the lack of notice about the call today: my notice email
apparently did not get through last Friday (sent from a wireless PDA, I may have turned-off
the thing too quickly...)

So the call today does not count as a formal meeting.

Here are the minutes attached.

Next call will be:

Time: Monday January 12, 2004, 2pm PT
Host: Fujitsu
Toll - :  1-512-225-3050
Participant code: 89772

Regards,

Jacques
<<IIC_January_01_04_minutes.txt>>

IIC Conference Call Minutes: 
Monday, January 5, 2004
 
Attendance:

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

Minutes taker: Jacques Durand

Time: Monday January 5, 2004, 2pm PT
Host: Fujitsu
Toll - :  1-512-225-3050
Participant code: 89772


Agenda: 

1. TestFramework status:

Mike sent out an updated version addressing latest feedback: to review.
Pending issues:

1.1 APIs: today, an implementation under test (say MSH) needs to provide additional
wrapper code in order to be controlled by a Test Framework (e.g. to interface with 
a Test Service implementation.) This wrapper code is specific to a Test Service 
implementation, so if a different Test Framework is to be used later, a different
interface code needs be written. Should the T.Fk specify the proper way to interface
between components, starting with Test Service <---> MSH?
One approach is to move the complexity of the "API" in the parameter vs. in the functions.
So one could propose 2 simple operations: 
- pass a message to MSH (send),
- pass a message to Test Service (receive).
Each would have a single argument: an XML doc containing everything: header attributes
 (in form of a list name/value pairs, something like ConfigurationItem in T.Fk 1.0),
and payload data. So if the Test Service is using this format to communicate back and
forth with the interface code that sits on top of an MSH, then the interface code 
will be fairly similar from one instance of Test Service to the other (only the mode
of doing the transfer may change, e.g. callback vs. queuing.
- payload items in such a general envelope, could be references to files, as these
files may be large and of format other than XML.
- In the name-value pairs, the names have to be decided and part of the "API" standardization.
- Mike mentioned that HongKong Univ have designed "ebXML Object" that may be close
to what we describe. 
 
1.2 Branching: Mike has added IF-THEN-ELSE statement. This was needed but may not be enough: 
do we have a "repeat"? Serm says this is needed by BPSS.
Mike says the repeat we have is limited to a single test step. 
It seems that a condition + "goto-step" might do?
Jacques: the IF-THEN-ELSE statement should remain simple so that implementors don't
have to implement a complex language... (e.g. no need for nesting).

1.3 Concurrency, and Exceptions:
Another form of branching, is the "split" / "join" operators in workflow.
A test case should be able to start several concurrent threads which will execute
in parallel, i.e. their put/get messages are intertwined over time. 
When an external event occurs (reception of a message), the Test Driver
just needs to be able to correlate this event to the right thread (i.e. to the step
that was pending). That same model could apply to Exceptions: an exception (the processing
of which may involve several steps) is a waiting thread that will be triggered by a 
particular event.

2. Applying the Test Framework, interop tests:

- ETSI (see www.etsi.org) is organizing an ebMS testing event in Europe,
showing interoperability between vendors products. 
The event is not just a marketing demo: the demo must be significant
in terms of interoperability of products, and preceded by some formal testing
on site. (yet not pretending to cover as much as other certification programs)
IIC is invited to submit a proposal, by ~ January 16.
Jacques will draft it, co-authors welcome.
- Could this proposal also support the notion of "global interop testing"
that ebXML Asia would like to promote?
- We need to know what would be available in terms of Test Framework support:
any Test Framework "freeware" that our members could provide to support this event?
That could be seen also as beta-testing of Test Framework products.
Minimum support to Test Framework users expected (e.g. how to interface an MSH
with the test framework).
- OASIS (and Jacques) proposed tentatively mid-April for this event, so it could be followed
by a demo at XML Europe (Apr 18-21). That is a tight schedule.
- will publish next ETSI call info on our list (to occur ~ January 21).