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]>/* 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]
<mailto:[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
<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
