Eric,
Jacques will be on travel shortly, but will probably
respond to your message, however I will add my understanding of this
issue to the response:
I believe that the "Configurator" Action will receive an ebXML
message with a payload containing a CPA, or CPA-like XML document
describing the messaging agreement between the test driver application
and the test candidate MSH. The candidate MSH will read in
the CPA
payload and configure itself to operate in the mode described by the
payload. The messages that follow this step ( from both the test
driver as well
as the candidate MSH ) will utilize the new CPAId and its implied
configuration in their messages. The test driver and candidate MSH
are "bound" to that agreement. The testing driver may,
however alter its messages to break from that agreement in order to
elicit what it expects to be the proper (error or otherwise) response
from the candidate party.
So the "Configurator" action will actually
do both of the actions that you describe: alter the CPA payload document
to reflect the changes in
messaging configuration, as well as create a new CPAId to reflect that
change in subsequent messages.
Hope this helps,
Mike
At 11:59 AM 7/24/2002 -0700, Eric VanLydegraf wrote:
Overall,
I think this draft is good and look forward to seeing the rest of the
profiles detailed.
I do have a question on the
section
Lines 341-347
Configurator
What is meant by "change
the collaboration agreement for the conversation related to a test case
or a set of test cases"
is the idea to switch out CPAID
on an "Initiator" action for a test case or set of test cases
or is the idea to actually change the contents of a CPA document itself
refered to by a CPAID ?
-----Original Message-----
From: Steven Yung
[mailto:]
Sent: Sunday, July 21, 2002 11:22 PM
To: Jacques Durand
Cc: ''; '';
''
Subject: Re: [ebxml-iic-interop] MS interop draft and some test
cases / profile
Hi All,
Sorry this took so long. I have taken a first crack at the
various profiles for Interop test, please review (for the purposes of the
draft, I have indicated where it matches the Drummond test, these
comments will be removed in the final draft, but a statement will be
place into the document to acknowledge the contributions that the
Drummond Group have made).
I will continue to work on this document this week and hope to have
another draft out before the end of the week.
Cheers,
Steve
--
Steve Yung,
Market Development Manager
Web Services/XML Development
Sun Microsystems
Phone: +1-650-786-8469
Fax: +1-650-786-3674
Jacques Durand wrote:
Steve, Prakash:
Here is an updated draft of MS Interop test Suite doc.
Note that I have not merged yet all material from the earlier draft of Prakash.
(I leave it to you guys to do that).
things to look at in particular:
1- We need to define some Interoperability Profiles (I only defined one very basic, to review/extend).
(the "interop profiles" we discussed this morning on the call.)
I have assumed so far a very basic interoperability profile (see Section 4, "IP 1"),
that mostly checks the ability to exchange various types of messages.
(Now, should some security, e.g. DSig, etc. be added? maybe.)
Some possible approaches when defining profiles:
- only one transport is adressed in a profile (HTTP, SMTP, HTTPS),
(so it could be we replicate our HTTP profile suite for SMTP?)
- as focus is on interop, we assume conformance tests have been done before.
(but some conformance tests may have an interop aspect:
e.g. proper Ack generation is a conformance test supposed to be done before,
but ability to receive an Ack from another MSH and process it correctly is an interop issue.)
- base profile(s) should only require core features in MSH.
- its OK for a profile A test suite to include/refer to another profile B test suite (if A extend B)
(e.g. secure profile extend base profile?)
- we could have a "standard" profile, and an "enterprise" one that tests advanced reqs, like passing large payloads, etc.
2- Look at the test Case material (section 4)
So far I have described 4 Test Cases for profile IP1 (a small subset of Steve's test list)
Each Test Case is complete with test steps and message material.
Also See if the Test Service actions are clear enough and sufficient.
Then if its OK you can use these as examples to build other test cases.
3- Could you review that draft, possibly do some update ( refine / add profile definitions, some test cases,
possibly do more merging with Prakash earlier draft ) by end of this week?
Then I'll add whatever latest version to our OASIS site as a work in progress.
Regards,
Jacques
<<ebXML_MS_Interoperability_TestSuite.doc>>
