Mike:
inline
-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Wednesday, January 15, 2003
9:12 PM
To: Jacques Durand; Jacques Durand
Cc:
''; '';
''
Subject: RE: FW:
[ebxml-iic-interop] comments on Interop suite
At 07:19 PM
1/15/2003 -0800, Jacques Durand wrote:
Mike:
Hope these
answers are useful...
-----Original Message-----
From: Michael Kass [mailto:]
Sent: Wednesday, January 15, 2003 1:05 PM
To: Jacques Durand
Cc: ''; '';
''
Subject: RE: FW: [ebxml-iic-interop] comments on Interop
suite
Jacques,
More comments. Key questions:
1) Need to assign <Manifest><Reference xlink:href ="abc">
at the application level in order to do any
meaningful payload testing for interop, otherwise we have no way of
fetching or evaluating a particular
payload ( no CID to refer to ).
[Jacques Durand] because we are at application level, we know that the
MSH provides us with an interface
(API, queuing, callback...) for:
(a) when building a message to be sent, specifying the payloads we
want to send, and their names,
(b) when receiving a message, getting a list of payload names,
and content, in some way.
The way to do (a) and (b) may differ across MSH implementations, but
given the right adapter,
our test driver can expect to always get/set this data, and in the
current interop set-up, will get/set it like if
it were an application.
So I think this allows for using your GetPaylod() op, just by using
the app-level "name" (not sure if we need
to specify the "cid:" prefix) of the payload.
We may assume that GetMessage() will provide the Test Driver with the
list of received payload names.
But we don't even need this assumption as we know what payloads to
expect when we write test cases.
(does anyone see cases where that would not work?)
2) Fold <SetPayload> operation into <Manifest>
declaration, and eliminate <SetPayload> as an operation..
not needed, and it is cleaner.
[Jacques Durand] I think the SetPayload op is still useful: It tells
which payload file to pick (e.g. a URI),
and will associate with it the payload "name" we want to see in the
message. The Manifest alone can't do that.
In putMessage(), When using Test Driver directly at transport
level, we need to define Manifest.
When using it at application level, Manifest content will be actually
determined by the sequence of
SetPayload ops we do, by sender MSH. So its not important if we don't
mention it, but we can for consistency.
[MIKE] - We could add a <Manifest xlink:href="payload-1"
filename="abc.xml"/> That would solve the problem of needing to
have both a <SetPayload> operation and a <Manifest/>
declaration. <Manifest/> could be used to set payload both
at
either application level, or at transport level, depending on
mode. We would only have to reference the payload one time, in the
<Manifest/> declaration,
and could eliminate SetPayload entirely, for
both conformance and interop testing.
[Jacques
Durand]
[Jacques Durand] I am a
little uncomfortable with this kind of shortcut : this extension to Manifest
elt is no longer compatible with the ebXML envelope schema, which we were
trying to respect, see [TestFramework 7.1.4.11] "...The XML syntax used by the
Test Driver to construct the ebXML Manifest extension content consists of the
declaration of an Manifest element. All required content, as defined in the
schema in the ebXML MS v2.0 Specification, is provided through either default
parameters defined in the ebXMLTestSuite.xsd schema in Appendix C, or by
explicit declaration ...". That might be confusing to people: they may want to
use same esxpression later on when crafting test cases "on the transport", and
that won't be consistent with the message envelope expected by the schema. I
see that not negative at all to have a separate operation to attach
payloads... different from envelope building in putMessage() main message
expression. Is the shortening of test case script the only advantage you see
in removing setPayload?
Frankly, your idea of
adding a setPayload op was not bad
initially!
3) Define a standard message payload format for including the
digest(s) of payloads used in the PayloadVerify
operation, consisting of a list of CIDs and their corresponding Digest
values.
[Jacques Durand] We could do that. Note that in Test Service
definitions, we were assuming that payloadVerify
would compare received payload(s) with local copies of the payload(s),
and just send back a status message.
Drawback is, a copy of the payload(s) has to be pre-installed on each
party host before testing.
[MIKE] - Plus the drawback of additional computation time for
determining signature of pre-installed file... each time we
execute
PayloadVerify
We may assume that, in case there is no local copy to compare with,
the status message is replaced by a
"digest" message that lists the digest values (or signature) for each
received payload.
When getting back this digest message, we would compare
these
in VerifyContent op with digest values created by putMessage() before
sending to payloadVerify() .
Is that what you suggest? (any XML format in mind for this?
)
[MIKE] - Yes. Send a simple payload stating what the digest
values for 1-N payloads, with 1-N CIDs and matching digest values
to the
Test Service PayloadVerify action. The PayloadVerify action could then
verify those signatures against what it computes, and send back a
payload
with a report, as shown above. This would be nice, because
anyone can submit any number of payloads, without the Test Driver or Test
Service already having to
know about it, or have files pre-installed.
[Jacques Durand] Mike: agree except for one
thing: the pre-computed signature (I prefer to call it digest, as this is
actually the part of the signature we need) should be pre-installed in the
Test Service of the remote party. (or send in a separate "administration"
message (to "configurator" action?) - but I'd reserve that to a future
version) Because again we can't piggyback it on a "normal" message - which
again would assume that we add a special payload - that would twist the test
case: technically, when we say "3 payloads", we should send 3 and not 4. Same
if we say 1 payload. So I think it is not really a big deal to require
preinstalling these digests (big improvement from pre-installing the entire
payloads). Opinion?
The XML would
be:
(Send 3 payloads, an XML, gif and Word file.. Test Driver would
recognize the "PayloadVerify" Action declaration, and create an additional
payload that
contains signature values for all 3 payloads along with their
CIDs, and send it to the "PayloadVerify" Action on the Test Service
side.
<MIME:Message>
<MIME:MessageContainer>
<SOAP:Envelope>
<SOAP:Header>
<eb:MessageHeader
eb:Action="PayloadVerify">
<eb:CPAId></eb:CPAId></eb:MessageHeader></SOAP:Header>
<SOAP:Body>
<eb:Manifest>
<eb:Reference
xlink:href="" fileName="payload_1.xml" />
<eb:Reference
xlink:href="" fileName="payload_2.gif"/>
<eb:Reference
xlink:href="" fileName="payload_3.doc"
/>
</eb:Manifest></SOAP:Body>
</SOAP:Envelope>
</MIME:MessageContainer>
</MIME:Message>
(Test
Service "PayloadVerify" Action receives this message, along with 4 payloads (
3 files plus special payload containing their signatures ), and
computes
signatures for 3 files itself, compares their signature values with those sent
in message payload, and sends message back to Test Driver
with pass/fail
result for each payload.)
