Raja:
my view on this:
From: Raja Kailar, Business Networks
[mailto:]
Sent: Thursday, December 07, 2006 11:23
AM
To:
Subject: [ebxml-msg]
Pull messaging - questions
A few questions about "pull" mode messaging. Some of this may be due to the
fact that I am joining this discussion at the finishing stage, so please bear
with me if all this has been discussed before.
1) Does this support a scenario wherein the Producer, the Responder MSH and
the Initiator MSH are in three different sites on the Internet? That is, the
Responder MSH acts as a gateway. The Producer and Initiator MSH only have
outbound connections. This is the scenario that CDC uses to route messages
between National Labs (e.g., LabCorp) and State DOHs. LabCorp (Producer) sends
to CDC (Gateway, or Responder MSH) and State DOHs (Initiator MSH) poll from
CDC.
<JD> that sounds like an intermediary scheme (multi-hop). To keep
as a requirement for part 2: an MSH intermediary must be able to share its MPFs
in a way that some parties can use it for pushing messages, and other party(ies)
may use it to pull messages from. Today, an MSH can share an MPF between several
of its partners, but the flow is always to this MSH (i.e. this MSH
exclusively acts as receiver, on this MPF).
So an
intermediary role for an MSH would require sharing an MPF for both sending and
receiving.
2) How is status information (i.e., that a SOAP response was successfully
received and
delivered by the Initiator of a "pull") fed back to the
Responding MSH and/or to the Producer of the message?
<JD> reliable messaging handles this (the pulled message may be
acknowledged like any other message). Acks will be sent
back from Initiator to
Responder.
3) How is reliability guaranteed on a SOAP response? What happens if the
SOAP response
times out or the integrity check on the response fails? If
there is no feedback (item 2 above), it is possible that the Responder MSH
thinks that the message was delivered, but the SOAP response is not actually
received.
<JD> see previous: the RM module supports RM for the "
synchronous response" (acks
to be sent back on a separate request)
4) When the Producer sends message to the Responder MSH, how does the
Producer address the message to a specific polling MSH (Initiator MSH)? That is,
can the Producer
specify the MPF? If so, the syntax of this message may need
to be specified (I was not
able to find it in the spec).
<JD> when a message is submitted by a Producer application, it is
associated with an MPF either (a) by the Producer, via proper API parameter, or
(b) by the MSH, based on the P-Mode associated with this message (in turn, the
P-Mode may be specified by Producer, or just matched to the message based on
other header info, e.g. eb:To/PartyId, or Service/Action). But the detail
of this is left out of scope of the spec (does not afffect interoperability, and
some implementations have their own views on how to support it, e.g.
API-specific)
5) Can the MPF be the partyID of a specific Initiator of a pull
message?
<JD> An MPF and a PartyId can both have same value. But a
PullRequest has a special element to specify the MPF it pulls from anyway. Note
that a PullRequest does not have PartyInfo, as thepulling is not selective based
on FromParty.
6) Assuming that the Producer is a separate node, is the Producer's CPA
with the Responder MSH only, or does it also need a CPA with the Initiator of
the pull?
<JD> by " separate node" do you mean it is itself an
MSH? Is this a 3-or-more MSH scheme? If yes, CPA should probably be
between the busienss
partners, but needs to be extended to handle multi-hop case (with possibly
pushing on one side, and pulling on the other).
7) Is end-to-end (persistent) confidentiality / integrity between Producer
and the Initiator of the PullRequest envisioned? In CDC's use case (described in
1 above), this is a definite need since the Producer (LabCorp) sends the data to
intermediary (CDC) intended for the State DOH (Initiator of PullRequest) but
does not intend for the data to be read by CDC. This requires encrypting the
message with the Initiator's key so that the Responder MSH does not get to read
the message contents. How does the Producer find the Responder MSHs key?
<JD> secure routing schemes need be sorted out in Part 2. But we
already know that ebms header data (or part of it) should not be encrypted for the MSH intermediary to do the
job. Or it can be encrypted but for the intermediary to decrypt, then forward
(e.g. two security headers: 1 for the intermediary, possibly covering all ebms
header, 1 for the ultimate receiver, moslty covering teh
payload)
Thanks,
Raja
______________________________
Raja Kailar,
Ph.D.
CTO, Business Networks International, Inc.
Ph: (770) 399
0433
Cell: (678) 358 6553
Fax: (770) 234
6685
http://www.bnetal.com
http://www.managesecure.net
