On Mar 13, 2007, at 7:42 PM, 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 >
I'd like to add 4) Reality Since whatever you do to get rid of redundancy, reality is going to kick it all to pieces (through COTS software, mergers, acquisitions, legacy tradeoffs, other good reasons, and and plain stupidity). Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ > All of these are (IMO) valid reasons to have multiple (potentially > different) instances of a "service" ( i.e. one that offers the same > interface and basic contract). This is before we get into more > esoteric areas such as safety critical where having three different > implementations of the same service specification and having a > "what I tell you three times is true" approach to the "right answer". > > DNS on the internet is a great example of a federated set of services. > > Steve > >
