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
Anne Thomas Manes <[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" on Yahoo! TV.
