Mike:
inline
-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Friday, January 24, 2003 3:57
PM
To: Jacques Durand
Cc:
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:]
Sent: Friday, January 24, 2003 12:12 PM
To: jacques Durand
Cc:
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
