RE: [ebxml-iic-interop] MS interop draft and some test cases / pr ofile

hello 
Mike (and all), 

one of 
my last mails before I go farther away.. (sorry won't take my laptop to the 
beach :)

 

The 
idea behind the Configurator is that, as Mike said:

- some 
new CPA may need by dynamically "installed" (i.e. made available in some form to 
the MSH, so that 

it 
will be used when any matching CPAId in a message requires it). (some 
implementations may not

switch 
that easily from one to the other...)

 

- I 
should admit that Configurator does not seem really useful, when (a) a 
predefined list of CPAs can

be 
made available to MSH initially, (b) it is easy for the MSH to switch from one 
CPA to the other, without

any 
special reconfiguration, just based on the CPAId, (c) no change or 
resetting (aside CPA) is ever required by MSH, when 

a new 
test case is executed. Indded, Configurator is not exclusively for CPA, but was 
intended to also

support other impl-specific re-configuration, if applicable. (but then 
that would have to be defined...)

 

- but 
also: even if no need to do any config job once a set of CPAs has been deployed 
on an MSH,

teh 
Configurator action allows at least to do a preliminary "check" that the right 
CPA is there for each test case,

so 
that a problem here would not cause an undue and misinterpreted failure of the 
test case.

(should be more explicit in the doc I realize)

 

I do 
not have strong arguments in favor of keeping these "Configuration" steps in 
many test cases,

except 
these above, in case you don't see much use for them. The last suggested use 
could be replaced by

adding initial test case(s) that would exclusively check that all 
CPAs have been well deployed, and are accessible

once 
for all.(so COnfigurator action may still be needed, but does not have to be 
used at beginning of each test case).

 

regards,

 

Jacques

 

 

  
-----Original Message-----
From: Michael Kass 
  [mailto:]
Sent: Wednesday, July 24, 2002 12:59 
  PM
To: Eric VanLydegraf; 'Steven Yung'
Cc: 
  ''; ''; 
  ''
Subject: RE: 
  [ebxml-iic-interop] MS interop draft and some test cases / pr 
  ofile

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