OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-msg message

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

Subject: Re: [ebxml-iic-msg] MS Conformance checklist: comments

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 
> >> 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.


Either way, it doesn't really matter.  Extracting from an actual CPA is 
a breeze.


Matthew MacKenzie
XML Global R&D
PGP Key available upon request.

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

Powered by eList eXpress LLC