8 messages in org.oasis-open.lists.ebxml-iic-msgRe: [ebxml-iic-msg] MS Conformance ch...| From | Sent On | Attachments |
|---|---|---|
| Jacques Durand | Mar 27, 2002 7:33 pm | |
| Matthew MacKenzie | Mar 27, 2002 11:14 pm | |
| Jacques Durand | Mar 28, 2002 6:55 pm | |
| Matthew MacKenzie | Mar 28, 2002 10:30 pm | |
| Jacques Durand | Mar 29, 2002 5:09 pm | |
| Matthew MacKenzie | Mar 30, 2002 7:40 pm | |
| Jacques Durand | Mar 31, 2002 10:20 pm | |
| Michael Kass | Apr 3, 2002 7:48 am |
| Subject: | Re: [ebxml-iic-msg] MS Conformance checklist: comments | |
|---|---|---|
| From: | Matthew MacKenzie (ma...@xmlglobal.com) | |
| Date: | Mar 28, 2002 10:30:23 pm | |
| List: | org.oasis-open.lists.ebxml-iic-msg | |
On Thursday, March 28, 2002, at 06:46 PM, Jacques Durand wrote:
Why not just have a library of ebXML Message templates that we want to send, and use a simple preprocessor and a tool like netcat to send the messages to the MSH? I don't think we care to test a candidate MSH's client side API, just the behaviour of the MSH itself.
That seems fine for sending test messages to the candidate MSH, ("send-and-receive" test scenario) but in order to fully test the behavior of the MSH, don't you think we need also to drive it, in some cases, from the app side (how are we going to get the candidate MSH generate the kind of message we need to check? )
I think a "Conformance service" is probably a better way to request that the MSH create messages and that sort of thing to be tested. It seems impractical to me to have custom code for each vendor in the conformance test suite.
We were thinking of defining a journal or log format that candidate msh's would write during conformance testing. We would define the format of the log, and all of the points where a log must be written. There would also be a Conformance service that the MSH would implement allowing the conformance test suite to "download" the journal after a test run. e.g.
<journal start="2002-8-6T12:43:45"> <entry time="2002-8-6T12:43:47" type="msg_recv"> <![CDATA[ message here ]]> </entry>
<entry time="2002-8-6T12:44:00" type="ack_sent"> <![CDATA[ ack here ]]> </entry> </journal>
I agree that would make our life much easier, as conformance testers, but my concern is that we cannot require implementors to produce such a log: that is not required by the standard (we may want to make it an implementation guideline item - but even so, our test procedure should be able to handle MSHs that do not write such logs...) Other MSH implementors may have strong opinions about what kind of log they want to produce.
I'm not suggesting we require vendors to adopt a certain log format, what I am referring to here is more of a tracing format. In the absence of a reference implementation, we need to do this, or employ network sniffing. Maybe I have my head in the mud, please set me straight if I am missing an easier way to capture a complete exchange/transaction.
4. We may have a similar approach for defining the CPA under which a test is to be performed (i.e. we define an XML format that encodes the subset of CPA needed to "configure" the MSH).
A simple property file will likely suffice.
Or we could reuse a CPA XML doc itself (and extract what we need) so we do not have ot define a format that I was suggesting above. I'm concerned that a property file may be too much implementation-specific. (same issue as the log trace above.)
A property file is lowest common denominator IMO, e.g.
RetryInterval=30000 Idempotency=true
Either way, it doesn't really matter. Extracting from an actual CPA is a breeze.
Regards,
-- Matthew MacKenzie XML Global R&D PGP Key available upon request.