OK, I understand. English is not my native language which means that I have at least a 30% semantic handicap. I thought Michael was thinking along ZapThink's "Competitive SOA" philosophy, but I understand he was talking more along the lines of redundancy or other business requirements, which I fully agree with.
Thanks for making it clear, // Dennis --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> 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 > > 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 > > > > > > > > >
