RE: [ebxml-iic] Call tomorrow Thu 15

["Michael Kass" <michael.kass@nist.gov>]

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

IIC_ebXMLTestFramework_V1.1_07_14_04_final_draft.pdf