Comments in line below... Anders Tell wrote: > > > Hi Gregg, > > > I haven't followed all the twists and turns of this discussion but I > though would comment on one (often overlooked) fragment you mentioned. > > On Jan 24, 2010, at 3:41 AM, Gregg Wonderly wrote: >> >> >> The communication mechanism of all the information between the pieces is >> frankly, immaterial. But everything a computer system does has a >> "beginning" >> (the call out to do the work) and an end (the return to the point of >> the call). >> That is the model that helps make it very visible when a >> responsibility is >> passed off to another party. >> because there is no imaginary handoff. It's in your face as you look >> at it. >> > > The issue of passing responsibilities is usually more intricate than > most SOA standards/frameworks today can handle. > > From a legal point of view, communication across legal boundries, > possibly across national borders, may be/is regulated in law. This in a > ways that most implementation technologies such as SOAP HTTP and REST > HTTP dont handle directly. > > The legally relevant "reach-the mind" and "reach-the-desk" events are > most often dug out from IT system after they have been build. These > events are "business" concerns and should be explicitly discovered and > defined.
These handoffs are often not considered early enough, and by using a model for your architectural rendering, which includes the literal actions, and by the code having these actions represented, exactly, at some level, the ability to address these needs becomes much easier. The exchange over a communications path can then be immaterial of how the path was established, and the establishment of the path and the management of the bandwidth utilization, etc can all be part of what legally has to be dealt with, immaterial of what the software is doing. 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. Gregg Wonderly
