[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-iic-framework] 1/26/2003: Test Framework and Interoperability
Comments:
Test Framework 0.92
(Note: Didn't review the entire document just the sections from Jacques
with tracked changes - assuming other comments had been integrated).
Section 3. - modes of Test Service - the verbage should be consistent
with the diagrams that support it. For example, Responder interface vs.
Receive. Correct? (If yes, this applies on all references). The
sentence after the driver and non-driver bullets is also a bit
confusing.
Section 3.3.5.2.8: Verb missing.
"Or, the roles of two Test Service instances may need to be switched
during an interoperability test, yet the switching MAY? be controlled
from the same location."
Section 7.1.3: Suggest you leave this paragraph:
ebXML Message data: ebXML message content MUST be created or modified
using the declarative syntax described in the ebXMLTestSuite.xsd schema
described in Appendix C. How the actual ebXML message is constructed by
the Test Driver is implementation dependent. Test drivers operating in
both "CONNECTION" and "SERVICE"modes MUST properly interpret the ebXML
portion of a Message Declaration, and generate the appropriate ebXML
content.
Agree on separation of MIME and SOAP (non-extensions) override by MSH
for service mode.
Section 2:
Isn't it true that we need the Test Service in order to fully test
interoperability? In this section, we say that the Test Driver can
complete this function. Otherwise, this section looks fine.
Interoperability 0.62
No real comments at this time.
Thanks.
Monica
-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Friday, January 24, 2003 8:01 PM
To: 'Michael Kass'
Cc: ebxml-iic-framework@lists.oasis-open.org
Subject: [ebxml-iic-framework] RE: Re-ordering precedence rules
Mike: inline
-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Friday, January 24, 2003 3:57 PM
To: Jacques Durand
Cc: ebxml-iic-framework@lists.oasis-open.org
Subject: RE: Re-ordering precedence rules
Jacques,
More comments below
At 02:16 PM 1/24/2003 -0800, you wrote:
inline <Jacques>
-----Original Message-----
From: Michael Kass [ mailto:michael.kass@nist.gov
<mailto:michael.kass@nist.gov> ]
Sent: Friday, January 24, 2003 12:12 PM
To: jacques Durand
Cc: ebxml-iic-framework@lists.oasis-open.org
Subject: Re-ordering precedence rules
Jacques,
I had the order reversed on rule precedence for the Config
parameters.
Here is the correct selection rules for the Test Driver. The logic is:
For "non-driver mode" ( stand-alone Test Driver)
If someone explicitly declares any of these values in the actual XML
PutMessage declaration, then that value should be used by the Test
Driver
to construct
the message.
If the value is not in the PutMessage declaration, then the
Configuration
Parameter, if present is used to assign the value.
For parameters that are "auto-generated" by the Test Driver ( e.g.
Timestamp ), if there is no XML declaration, and no Config parameter
value
set, then the Test Driver "auto-generated" value is used.
For parameters that are also present in the CPPA ( SenderParty and
ReceiverParty) , an explicit XML PutMessage declaration takes
precedence. If an XML message declaration is not present, then if a
Config
parameter is present, it is used. If neither a message declaration nor
a
Config parameter is set, the the CPPA value is used.
<Jacques> that seems to cover it all. Bottom line is that XML PutMessage
script
should have precedence. For some of these paraemters however,
the ebXML implementation will even have higher precedence, like
MesageId.
as it has the "last word" before sending the message.
[MIKE] - Understood. "service mode" is a different animal.
Only thing I think we don't need to refer to here:
the CPA doc (not CPPA, which is the name of the spec and of the TC...)
probably should not be relied upon (not supposed to be interpreted by
Test Driver - so far in this Framework 1.0).
[MIKE] - CPA ( meaning CPAId ) is provided only to pass the ID to the
Test Driver to build the message.
(in connection mode) And in "service mode", won't the "interfaced MSH"
have to know the semantic meaning of the CPAId
and configure itself appropriately? So the Test Driver has to tell the
MSH the id of the cpa, that it will
"implicitly" understand and load. Since the implementation will likely
send out the majority of "first messages", it would
need to know the CPAId to use, and configure itself appropriately, I
would think. Comments?
[Jacques Durand] Right. CPAId is used. the CPA content itself does not
need to be known outside the
ebXML implementation. (But do we agree this CPAId can be passed and
specified separately from CPA doc?)
[MIKE] - In connection mode, I know we are NOT expecting a Test Driver
to load a CPA, or CPA-like document. However, much of the info in a CPA
( like endPoint, PartyId, SyncReplyMode, Retries, RetryInterval,
AckRequested ) would really help in writing tests.
Particularly for timing ( calculating timeouts ). I do not believe
that we could formally "parameterize" all that is needed
to configure a Test Driver ( i.e expand our list of parameters that
we've agreed upon )
We can, however "informally" do so through the "wildcard"
<ConfigurationItem> element,
with its name/value pair. So if we "change a CPA" during for a new
<ConfigurationGroup/>, we would also have to change the
"timeout" <ConfigurationItem/> parameter, if the CPA
retries/retry-interval changes. ( i.e. the Test Driver, while basically
"dumb"
may have to store data that it can use for XPath evaluation.. such as
determining if a message arrived too late.
Does this seem reasonable?
[Jacques Durand] You are talking about two problems it seems:
(a)- how to conveniently specify header data in "connection" mode, where
the Test Driver has to do it all by itself.
(b)-flexibility in changing CPA data.
For (a), before considering something like adding a "CPA interpreter" to
Test Driver, I'd consider low-key solutions
of the kind: recommending explicitly the use of parameterized message
header docs, like we used for illustartion.
A test suite would use as many as needed, given that the current
parameterization ($parameter, substituted by values in
COnfigurationGroup) is not enough to render changes in XML header needed
to reflect various CPAs, e.g. presence of
new elements related to signature, acks, reliability, etc. I think that
is quite acceptable for this version, if
you do not want to build all this header in a cumbersome message
expression.
So some predefined parameterized header name could be referred to in the
putMessage op, and override or modified
at will in the message expression (or declaration). Actually, the
Interop test cases currently use such references
but mostly for sake of documentation. We could make that more
processeable by Test Driver...
Opinion?
For (b), not sure if I understand well your point, but it's OK to
require in this version of TestFramework, that
CPA contetn is fixed (except for overrides that are allow in the ebMS
spec, in message header) and will not vary for
a test case execution. In any case, change in parameterized headers +
putMessage dcl,
might again facilitate the script writing for generation of messages,
that should accompany a change in CPA.
[MIKE] - It seems logical that we could do this, since we are following
the "spirit/semantics" of a CPA, using our own defined parameters to get
the
job done. However, our Test Suite would not be portable, unless someone
else implemented a Test Driver that
understands our "timeout" <ConfigurationItem> parameter... i.e.. it
hasn't been "formalized" as a parameter
Comments?
In fact, CPA data will be relied
upon through the implementation where it is installed: we know
this will determine some header attributes (security, reliability,
possibly
sender and receiver...) Things that we cannot control anyway by Test
Driver in "service" mode.
[MIKE] - Assuming we are in "service mode" yes. However, even in
"service mode", the Test Driver
could no doubt benefit from the data in the CPA. However I understand
that at this point
CPA is at best an abstraction to the Test Driver.
In your table below:
- i'd replace "CPA" more generally by "ebXML implementation",
and that would be the highest precedence, possibly for senderparty,
receiverparty,
messageId, timestamp.
- I dont think we need "Test Driver autogenerates": all parameters are
actually
set by test suite or by ebXML implementation itself, including
Timestamp.
[MIKE] - I disagree that we will be coding Timestamps by hand in
"connection mode". I agree that in
"service mode", the implementation does the auto-generation.
But in "connection mode", I'd much rather have a Test Driver pound out
the clock times.
The Test Suite is just an XML file. The Test Driver will generate
Timestamps and MessageIds by default,
unless we "override" them with a Configuration parameter, or explicitly
declare them in the Test Suite document.
[Jacques Durand] You may be right. I still believe that a testbed
shou7ld allow to manipulate everything
including timestamps, but we should also be able to generate
"clock-based" timestamps as well. So I guess we allow for both...
We must say then that a Test Driver MUST be able to generate a default,
clock-based timestamp value in case
no value is specified in test cases (either config, or putMessage..).
And our test scripting (including config data)
should include keywords that refer to such predefined function, like
"TestDriver.function.timestamp".
Maybe I'm not interpreting what you said correctly?
The table below illustrates this:
Parameter Name CPPA Equivalent Precedence1
Precedence2 Precedence3
------------------------
-------------------------
------------------- -------------------
-------------------
$SenderParty <tp:PartyInfo><tp:PartyId/></tp:PartyInfo>
XML PutMessage
Declaration Config Param CPPA
$ReceiverParty <tp:PartyInfo><PartyId/></tp:PartyInfo> XML
PutMessage
Declaration Config Param CPPA
$CPA (Id)
XML PutMessage Declaration Config Param
$ConversationId XML
PutMessage Declaration Config Param Test Driver
auto-generates
$Action XML
PutMessage Declaration Config Param
$MessageId
XML PutMessage Declaration Config Param Test Driver
auto-generates
$Timestamp
XML PutMessage Declaration Config Param Test Driver
auto-generates
For "driver mode" ( Test Driver coupled with MSH ) the same rules as
above
would hold, however the Test Driver may not be able to set these values
through the MSH interface.
[MIKE] - Understood
<Jacques> for Test Driver in "connection" mode (generating duirectly the
message on wire),
I believe precedences are same (except ebXML implementation e.g. MSH is
not involved anymore
on driver side)
Cheers,
Jacques
\
Do you agree with this?
Thanks,
Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC