Steve Jones wrote: > Three business reasons off the top of my head to have multiple instances > of services > > 1) Redundancy - Primary service unobtainable, switch to backup which > might use "lighter" logic but be less prone to failure > 2) Regulatory separation - Legal and/or governance rules mean different > instances and even implementations (e.g. SOX in the US, not anywhere else) > 3) Data size - Single service would mean a massive, and non-performant, > backend ( e.g. UK Patient Medical records...) therefore federate the > service based on the consumer and/or interaction
4) Separation of reponsibilities to minimize impact caused by device failure. e.g. 4 servers create a higher number of total failures, but a single failure impacts fewer services and if there are redundancies maintained by an SLA fabric such as RIO, then perhaps there is no visible impact. I am finishing up a distributed network system that provides content based routing over a serial network interface. There are limits on the number of ports each machine can host physically. We want to distribute the load across machines to minimize impact of failure. I used the Jini transaction manager to create distributed database synchronization of postgres databases and incore memory structures on all machines. There are 6 machines in the base system that all keep a completely up to date copy of the database on those machines and the routing processes on each machine maintain their memory resident view of the database through distributed transactions as well. Is the system complex? I don't think so. Jini provides the infrastructure to make this kind of thing easy. Gregg Wonderly
