On Mar 23, 2010, at 2:56 PM, Gregg Wonderly wrote: > > Pluggable endpoint, marshalling and invocation platforms excel at making this > kind of detail unimportant until deployment. > > > If one makes a call/send message/issue communication and the call > > returns an Error, does this means that the communication was not > > received? Maybe. It much easier to design in-house service than across > > legal boundery services > > Idempotent service design is a very important detail so that anything can be > retried. In the JERI stack available in Jini 2.0, there are some pretty good > exception layering things that happen that help you understand whether the > error > came from the server side or the transport layer. With dynamic service > discovery and smart proxies, you can also then find another service > implementation, from the client end, and try that one. Rotating DNS A-records > can provide some remedial retry capabilities, but TCP connection timeouts for > "unavailable servers" can delay retries. Service discovery mechanisms like > Jini's automatically, through leases, expire "unavailable server" > registrations > so that the system can repair itself to remove these delays without > intervention. Some dynamic DNS implementations might employ similar > strategies > to remove broken A-records. >
Yes its an important design solution/realisation, improving quality and redundancy is relevant. Although this works foremost when both sides are within the same organisation without any legal boundries to consider. When an legal boundry is introduces the game changes a bit. It can still be agreed that a party is the controller and has the right to rollback but in many case this is not an relevant options (or balance of risk). Errors are not always a good indication of the reality (legal) since if a document has been transferred, it has been transferred, not matter what the IT-system reports. This subtlety becomes relevant in many scenarios where the receiver (or sender) cannot be responsible for how good or bad the other party has been implemented their (IT-) system. In a legally relevant transaction-protocol there are more end states to consider such as dispute. So technically protocols and solution can be improved to be more business like an handle more scenarios. /anders
