Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

[Ronald v. K. <rv...@ab...>]

Patrick Yee wrote:

>
>> The reason we do this is that not all our clients are always online 
>> to retrieve messages. Many have dial-up connections and want the 
>> messages pulled as soon as they are online. That is in my opinion 
>> what a postoffice is and why I hope multi-hop will be implemented in 
>> hermes as wel in the 1.1 release or so (any tips what is still 
>> missing or where to start?)
>>
>
> We have been reviewing the ebMS 3.0 white paper lately. Whether 
> multihop is needed or not is still controversial. In fact, as you can 
> see in ebMS 2.0 spec, the behaviour of multi-hop feature is not clear. 
> Therefore, I think this feature will still be on hold until the ebMS 
> TC gets a conclusion on it. :-)

Ok, I've read the whitepaper. What I mean with multi-hop is nothing more 
or less  than reliabilty if a message for one reason or another cannot 
be delivered directly to the end-point msh. In our community we will be 
working with a hub-and-spoke model where everybody delivers their 
messages physically to a central system. That system then delivers the 
message to the recipient, either directly (push) or by a kind of pull 
mechanism. All three systems in this configuration are ebxml compliant 
systems. Ofcourse there needs to be hop-to-hop reliablity. If the 
ws-reliabilty standards will support this, then we do not need a special 
multi-hop mechanism. I think we need (with the emphasis on think) a kind 
of  end-to-end reliability as well, but it could be that should be 
solved by business acknowledgements (which are end-to-end) instead of 
ack's on the msg level. This means delivering the message to the next 
hop and trusting it that it will deliver the message to the next hop. 
End-to-end acks on the messaging level are not needed then.

This last thing also solves the discussion about the overlap between 
end-to-end acks and business-process acks. Although some of our clients 
want to see an end-to-end ack on the message level in their msh logging, 
but that is partly because former x.400 systems had that functionality. 
Hmm... I should give this some more thought.

Still, multi-hop is in the current spec and it could give us some 
benefit it was there, at least the end-to-end (signed) and hop-to-hop 
(non-signed) reliability. I'll start looking a little into the spec and 
hermes code to get some leads.

Ronald