RE: [ebxml-msg] Pull messaging - questions

Raja,

 

Good clarifications.

 

Actually you can use the CPA to setup the type of route-not-read
handling you describe - because internally we're doing this at NIH -
where we have ebMS deployed in two places - so the CPA is used
thus:

 

 (External party) CPA' - ebMS (NIH Msg gateway) - CPA'' -
ebMS (NIH app server) - CPA''' - NIH App

 

Each CPA is tailored for the role and msg handling required. 
Admittedly the specification is somewhat quiet on this usage - perhaps
this is something we could spell out in a FAQ or use notes...

 

The chunking handling is similar to stage delivery - except that
once the stream of chunks is started - the push continues until
its done. Persumably the first chunk contains information about how
many more chunks will follow?

 

Thanks, DW

"The way to be is to do" - Confucius (551-472
B.C.)

-------- Original Message --------
Subject: RE:
[ebxml-msg] Pull messaging - questions
From: "Raja Kailar, Business
Networks" <>
Date: Fri, December 08, 2006
8:07 am
To: "David RR Webber (XML)" <>
Cc:


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

"David RR Webber (XML)"
<> wrote:

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" <>
Date: Thu, December 07, 2006
2:23 pm
To: 

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

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

http://www.bnetal.com
http://www.managesecure.net