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 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 On 13/03/07, Dennis Djenfer <[EMAIL PROTECTED]> wrote:
Michael Poulin wrote: Ann wrote: "IBM has created a central notification system that ensures that lots of applications that contain redundant capabilities are notified of a changes that impacts all of them. If the system were truly service orientated, it would no longer have redundant capabilities implemented in all these applications. There would in fact be only one system that maintains delivery date information." I disagree. If SOA reflects business model, then it has to accept concurrent redundancy of the services. Does it make sense for an individual enterprise - it is the business of the enterprise. However, SOA solution should be capable of changing provider (and/or services) if current one violates Service Contract and/or Service SLA. If an enterprise maintains only one service for a business functions, it is not much different from an application: the service owner will be able to dictate usability to the consumers and we will get the UK 'service' model instead of US service model. - Michael Michael, I guess you have read the article from ZapThink about "Competitive SOA", http://www.zapthink.com/report.html?id=ZAPFLASH-2007220, which, frankly speaking, doesn't make much sense to me. Most shared services have some kind of persistent state and even if two services conforms to the same service description, contract and policys, they will not respond in the same way to a consumer request if their persistent state are not the same. I can't see how I would justify using more than one service for a particular business object that should be shared over the enterprise, unless there are other reasons, like geographical circumstances that justifies the overhead and complexity of synchronizing the data. My problem today is "Competing Applications" that persists and provides the same business object which leads to errors, inconsistences, duplication of work, discontention among the staff, increasing expenditures and so on. // Dennis *Anne Thomas Manes <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>* wrote: Great examples of cost-effective applications, and I've heard Sandy recite them before, but I'd like to point out that both applications could also be implemented using traditional development approaches. They are, in fact, applications -- and I'm not convinced the they are especially service orientated. In the first example, IBM has created a central notification system that ensures that lots of applications that contain redundant capabilities are notified of a changes that impacts all of them. If the system were truly service orientated, it would no longer have redundant capabilities implemented in all these applications. There would in fact be only one system that maintains delivery date information. The second example is a simply case of automating a formerly manual process. Implementing this automated process using pervasive protocols is an obviously good decision. But where's the service-orientation here? Anne On 3/9/07, Gervas Douglas <[EMAIL PROTECTED]> wrote: > > Some of you new to SOA have probably wondered what exactly it was > about, what the fuss was about, and what were the benefits. Joe here > quotes a couple of usage examples: > > <<A centralized delivery-date service. How many times have you been > given the wrong date on an order you were expecting? One retailer was > struggling with a fulfillment chain that comprised multiple systems - > each of which could update the promised delivery date for an order. > However, when someone changed a delivery date in one of the many > fulfillment applications, the information wasn't consistently updated > in the order-processing system. The result, naturally, was customer > confusion, and mangled delivery schedules. > > The solution was to implement a centralized delivery date service -- a > SOAP over HTTP service managed by an ESB. Now, when a delivery date is > changed, the fulfillment system sends a delivery-change notification > to this event-driven service through ESB, and as a result, the order > system database - and any other system that subscribes to this service > - is immediately updated. The total effort to create two centralized > services and build an ESB required four developers for four months, > Carter said. > > Charge dispute service. Have you ever disputed a credit card charge > and wondered why it sometimes took months to resolve? Maybe SOA could > speed things up. Carter cites the example of a financial services > organization had a manual-intensive process for handling disputed > charges from customers of its large retail partners. When a retail > customer disputed a transaction, the financial services organization > would manually print all transactions and send them through ground > mail to the customer to identify which transactions were being > challenged. The customer would then have to sign these papers and send > them back through ground mail to the financial services organization, > which would then package them and send selected documents to the > retail institution. After this paperwork was received, the retail > institution would decide whether the charge should be removed. This > process could take up to 20 days to complete and typically cost the > organizations involved between $400 and $700 per transaction. > > Carter reports that the financial services organization deployed a > service in front of its core transaction system that now enables > retail partners to transmit dispute claims to the financial services > organization on behalf of the partners' retail customers. To register > a dispute, customers now simply log into the retail institution's > Website and view a list of transactions that have posted to their > account. Customers can then select the transactions they wish to > dispute. The Website sends this request to the financial services > organization's transaction-dispute service. The authentication that > customers provide while logging on to the Web site enables the > financial services organization to eliminate the need for paper > documentation with a handwritten signature. > > Carter reports that the transaction-dispute process now averages a > total of three hours, reduced from 20 days, and costs only US $40 to > $70 per transaction, instead of the previous $400-$700 per > transaction, representing a 90 percent reduction in costs. "Automating > this process by creating a centralized service helped enable the > organization to realize estimated cost savings of more than $200 > million per year," she says.>> > > You can read Joe's blog at: > > http://www.soainaction.com/blog/2007/03/post_4.php > > If you, dear reader, have any interesting examples of SOA in Action, > perhaps you would like to share them with us. > > Gervas > > ------------------------------ TV dinner still cooling? Check out "Tonight's Picks"<http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/>on Yahoo! TV. ------------------------------ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.10/720 - Release Date: 2007-03-12 19:19
