RE: [ebxml-iic] Call tomorrow Thu 15

Jacques,

Attached is the latest update to the Test Framework document. I have added a few proposals in the spec (particularly the <PutMessage> content).

I’ve modified all the schemas and descriptions to reflect our discussion/resolution regarding scripting. My comments for today’s meeting below:

Thanks,

Mike

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, July 14, 2004 7:17 PM
To: 'ebxml-iic@lists.oasis-open.org'
Cc: 'tsakach@certivo.net'
Subject: [ebxml-iic] Call tomorrow Thu 15

Next call exceptionally tomorrow Thursday 15:

Time: Thursday July 15, 2004, 2pm PT
Host: Fujitsu
Toll only : 1-512-225-3050
Participant code: 716071

Agenda:

1. Update on ETSI tests,
- use of IIC test suites,
- remote testbed ( Korbit).

2. Test Framework 1.1 technical:
- wrap-up the approach we use to message building:
in case we want to use Test Driver to drive a message interface
at "application-level" (e.g. a JMS provider, or a WS client), can we? (we'll have to
say how in spec). Role of XSLT.

[MIKE] – As we have implemented it here at NIST, the Test Driver first “Mutates” via XSLT the <Declaration> content ( providing such things as Timestamp, ConversationID..etc ), then passes the transformed (mutated) document back to the Test Driver. Based upon <ConfigurationGroup> settings of Transport = HTTP… or SMTP , Envelope = ebXML .. or MIME… or SOAP, the Test Driver takes the mutated document object, and makes calls to its API based upon the assumptions of what transport and envelope have been defined.

So if a JMS or WS API is to be used, then they would have to be added as <ConfigurationGroup> types.

- latest feedback from NIST developers, thread name vs instance ID.

[MIKE] – We think that instance ID is better choice, and will change schemas to use that instead.

- BPSS requirements: are we OK?

[MIKE] – I am concerned about modeling <Splits> and <Joins> in the Test Framework execution model with semantic meaning of <Forks> and <Joins> in the BPSS domain. I think that we need a few use cases to define how we will handle the conditional execution based upon test results returned by 3 concurrent transaction Threads.

- looping cases: same as "recursive split"? (conditioned by an Assertion)

[MIKE] – We have implemented this, but not yet tested it on real cases.

3. Test Framework 1.1 spec:
- levels of conformance, if any?

I think that we can list the features that a Test Framework MUST support to be considered “complete”… and perhaps create subsets of features for various types of testing (e.g. A2A, MS conformance testing, P2P Interop testing). Clearly not all features will be necessary for all types of testing.

- any "binding" to consider? (optional, but normative)

I created a WSDL binding for SOAP with attachments for Test Driver/Test Service notification messages.

4. Other?

We will need to define additional normative schemas for describing message <Declaration> content for various message envelope types.

Regards,

jacques

ebxml-iic message