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.
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. 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=""cid:payload_1""
fileName="payload_1.xml" />
<eb:Reference xlink:href=""cid:payload_2""
fileName="payload_2.gif"/>
<eb:Reference xlink:href=""cid:payload_3""
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.)
<MessagePayload>
<PayloadVerifyResponse>
<Payload>
<CID>cid:payload_1</CID>
<Result>pass</Result>
</Payload>
<Payload>
<CID>cid:payload_2</CID>
<Result>pass</Result>
</Payload>
<Payload>
<CID>cid:payload_3</CID>
<Result>fail</Result>
</Payload>
</PayloadVerifyResponse>
</MessagePayload>
We would pass/fail this test with the following TestStep
( We can go one step further, and verify returned payloads on Test Driver
against their original computed values if we have the
Test Driver store Signature/CID pairs for any payloads sent to the
"PayloadVerify" or "Reflector" Action. )
<ebTest:TestStep ebTest:mode="driver">
- <ebTest:GetMessage
ebTest:description="Correlate returned messages">
<ebTest:Filter>eb:CPAId='cpa_basic' and
eb:Conversationid=$ConversationId </ebTest:Filter>
- <ebTest:GetPayload
ebTest:description="Find payload in message">
<ebTest:Content-ID>cid:payload_1</ebTest:Content-ID>
- <ebTest:TestAssertion
ebTest:description="Verify that PayloadVerify computed signature
correctly">
<ebTest:VerifyContent
method="XPath">/MessagePayload/PayloadVerifyResponse/Payload[CID="cid:payload_1"
and Result="pass"]</ebTest:VerifyContent>
</ebTest:TestAssertion>
- <ebTest:TestAssertion
ebTest:description="Verify returned payload
contents">
<ebTest:VerifyContent method="Signature"/> ( assumption
is that Signature of this payload is already stored by Test Driver, using
payload's unique CID as identifier )
</ebTest:TestAssertion>
</ebTest:GetPayload>
- <ebTest:GetPayload
ebTest:description="Find payload in message">
<ebTest:Content-ID>cid:payload_2</ebTest:Content-ID>
- <ebTest:TestAssertion
ebTest:description="Verify that PayloadVerify computed signature
correctly">
<ebTest:VerifyContent
method="XPath">/MessagePayload/PayloadVerifyResponse/Payload[CID="cid:payload_2"
and Result="pass"]</ebTest:VerifyContent>
</ebTest:TestAssertion>
- <ebTest:TestAssertion
ebTest:description="Verify returned payload
contents">
<ebTest:VerifyContent method="Signature"/>
</ebTest:TestAssertion>
</ebTest:GetPayload>
- <ebTest:GetPayload
ebTest:description="Find payload in message">
<ebTest:Content-ID>cid:payload_3</ebTest:Content-ID>
- <ebTest:TestAssertion
ebTest:description="Verify that PayloadVerify computed signature
correctly">
<ebTest:VerifyContent
method="XPath">/MessagePayload/PayloadVerifyResponse/Payload[CID="cid:payload_3"
and Result="pass"]</ebTest:VerifyContent>
</ebTest:TestAssertion>
- <ebTest:TestAssertion
ebTest:description="Verify returned payload
contents">
<ebTest:VerifyContent method="Signature"/>
</ebTest:TestAssertion>
</ebTest:GetPayload>
</ebTest:GetMessage>
What is nice about this is that this method only requires specifying what
the TestDriver will do when it encounters a "PayloadVerify"
message declaration
