RE: [ebxml-msg] Pull messaging

ebxml-msg message

From: Raja Kailar, Business Networks [mailto:kailar@bnetal.com]
Sent: Thursday, December 07, 2006 11:23 AM
To: ebxml-msg@lists.oasis-open.org
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).

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)

<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)