David,
You're right. As I mentioned earlier, PHINMS has some custom extensions, including:
(1) Chunking (handling of large messages)
(2) Push/pull messaging via a gateway (we call it "Route-Not-Read", since the intermediary only routes the message but does not read it since it is encrypted with the polling site's key)
These extensions were needed since ebMS 2.0 did not include them. These extensions are used only by a small percentage of PHIN messaging use cases though. Majority of our messaging uses "direct-send" (sending node sends directly to receiving node, which has an Internet presence). However, a few nodes do not allow inbound connections, hence they can only receive by polling an intermediary, and to support this, we are using the Route-not-Read approach.
Raja,
We may need to go back to some basics on this for you...
How CDC have implemented their ebXML client - I'm fairly certain that is atypical - and I'm not sure how close that is to the actual specification?!
I know they did the ebXML certification - but - when we look at the tests they passed - not sure what their partners had to disable / do / to get it to cover off the CDC use case?
More typically you have the Hermes implementation - where the client really is a full-function server acting as a client.
This was the big differences we saw when we reviewed Hermes / vis CDC - and connected the two together to try see what was happening.
Now - in our case - using Hermes - the push / pull models works differently. The push consists of a initial message that goes to the partner. It contains the release information for the real payloads. We called this "staged delivery" - its push/pull. So when the remote system is ready to receive - it sends the response back - and that then causes the initiator to queue up the delivery to that partner of the actual payloads.
That's obviously a different model to a pure client model that can only receive - not initiate - unless you've changed that in the past year?
If you are really worried about security - then those encryption keys need to be exchanged directly via alternate trusted methods. I believe the ebXML spec's call that out somewhere.
Just trying to distill what the actual landscape is compared to what the specification is
doing with push/pull.
Thanks, DW
"The way to be is to do" - Confucius (551-472 B.C.)
Original Message --------
Subject: [ebxml-msg] Pull messaging - questions
From: "Raja Kailar, Business Networks" <kailar@bnetal.com>
Date: Thu, December 07, 2006 2:23 pm
To: ebxml-msg@lists.oasis-open.org
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.
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?
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.
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).
5) Can the MPF be the partyID of a specific Initiator of a pull message?
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?
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?
Thanks,
Raja
______________________________
Raja Kailar, Ph.D.
CTO, Business Networks International, Inc.
Ph: (770) 399 0433
Cell: (678) 358 6553
Fax: (770) 234 6685
kailar@bnetal.com
http://www.bnetal.com
http://www.managesecure.net
______________________________
Raja Kailar, Ph.D.
CTO, Business Networks International, Inc.
Ph: (770) 399 0433
Cell: (678) 358 6553
Fax: (770) 234 6685
kailar@bnetal.com
http://www.bnetal.com
http://www.managesecure.net