RE: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework

["David RR Webber \(XML\)" <david@drrw.info>]

Roger,

OK - see my clarifications below!

Thanks, DW

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

 -------- Original Message --------
David,

re your Sandesha comments, not sure I get it.
a) you say database persistence is "essential"... is it?  Sure, there
needs to be some ability to recall "did I get this message already",
but if a goal is lightweight implementation (and I'm suggesting it
should be), then a full embedded database maybe overkill. It needs to
be a black box, automatically purging any history beyond some short
period.
>>> essentially the embedded DerbyDB is this - its completely lightweight - no DBA support needed - but the critical thing is - it maintains state across a system power out / crash / re-boot - whereas obviously in-memory persistence is not able to do that.  
<<<

b) if Sandesha is delivering reliability, surely it must be doing
something like what I describe above, even if there's no db. If you
think it falls short feature-wise, can you say exactly where?
>>> No persistence across re-boot / power-up / failure (e.g. null pointer exception). Becuase its built 
    from original SOAP - synchronous model - the memory persistance
works there - but asynchronous 
    requires DB - especially for outbound queue obviously! <<<

c) is it an implementation of WS-Reliability or not? if so, surely it
interoperates with other such implementations, or at least will do once
interop testing happens
<<< From the documentation it appears to use its own protocols
asynchronously to handle the ack/nak methods 
    and more. So even if its using the WS-R for control - the actual
mechanisms only work between 
    2 Sandesha's.
<<<

Aside from that, your description of the NIH client seems to acknowledge
that it's not actually doing secure, reliable P2P messaging - the
servers are doing much of the work.  For a lightweight client, I think
the model used for online banking / payment services can apply - i.e.
the server is the definitive record, the client just needs a robust way
to recover if there's an error.

>>> Yes - CDC/PHIN locked down the P2P piece - business / legal decision - but the software could have that "switched on".  We realized when we did Hermes/CDC interop' testing that the CDC was deliberately
disabled to prevent it doing certain things.  The model is however the
important thing - shows that
you can implement it that way.  And its just as important to be able to
switch stuff off - that you
determine should not be allowed.  

Vis recovery - certainly the client would need to request
re-transmission - and again - we've done that
for Hermes with our staged delivery - and CDC/PHIN has it for their
large message delivery mechanism.
This is something that ebMS v3.0 has now put into the new spec' - so
ebMS v3.0 will do this out-the-box.
<<<