From: Ken Laskey
[mailto:klaskey@mitre.org]
Sent: Tuesday, September 06, 2005 11:40
AM
To:
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Amazon.com and
Hurricane Catrina - Service Context? Service "Veneer"?
The actual collection (orchestration?) of services (or
more basically, capabilities that the services access?) will reflect the
particular business process, but at a reference model level we can't build a
different model for each business process. The challenge is to identify
the concepts from which you can support any business process. (Question:
have the previous drafts of SOA-RM missed any of these concepts?) A
previous difficulty when looking at typical use cases is that not every SOA
challenge will have a purchase order and a credit card number. While
purchasing is an important use case, a SOA tailored to support the variations
of purchasing may fail badly in addressing, say, the need to find and access
real time disaster data.
Ken
At 11:23 AM 9/6/2005,
marchadr@wellsfargo.com wrote:
I tend to agree with Steve's point about
having the model reflect the business processes and then deriving the service
definition from the type of processes the service will aggregate or use. In
theory, the payment of a product, service or donation is not that different
since at the end of the day it becomes a transaction of a total amount from
one account to the other (Amazon's in this case) and the entities (product,
service, or donation) are a means to an end.
The separation of
the order versus the purchasing would probably be the best approach for the
interface design, since the order could vary and have polymorphistic behavior
depending on the type of entities that are a part of the order. (In some
cases, the order would have a possibility of having a donation and a product
in the same order from the UI point of view.) The order would be used to
hold products and start the back office processing, while the purchase would
make the transaction of money based on a total amount of the order.
This brings up an issue in some ways of
whether or not the order triggers the purchase which would result in a service
invoking another service.
The other issue I have been finding is a return
is similar to a purchase since it is the reverse of the transaction (one
account to another with an amount), since usually it is to late to reverse it
before it actual makes a charge. Also in the case of purchasing large amounts
of products and paying for them and in some back office process one product is
determined to be discontinued then the reversal of a transaction will really
be based on the amount of that discontinued transaction and not the total
amount which would almost be like purchasing the product back from the
customer.
Something to think about. The context
seems to be a good approach for the ordering and purchasing
scenario.
Dan
-----Original
Message-----
From: Jones, Steve G [
mailto:steve.g.jones@capgemini.com]
Sent: Monday, September 05, 2005
7:30 AM
To: Ken Laskey;
SOA-RM
Subject:
RE: [soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"?
I’ve found that
the only way to model this is to ensure that you have a hierarchy of service
that models the full business rather than concentrating on the technical
delivery elements. So you must model (but not have to directly
implement) the two types of services, which then act as containers for the
technical services. The higher order service then has different business
processes that give different results, but these are hidden from the service
consumers.
What has been the
biggest problem for me has been how to represent the change in contract (but
not interface) of a service due to its different domain. This isn’t a
huge technical challenge at the moment (as we can’t define contracts at all!)
but could become a much bigger challenge is future. Some concept of
contract inheritance might work here…
I’m wary of
describing groups as things (like a payment service) as a capability rather
than a service as it gets tricky on granularity, unless you mean that a
capability is a single invocation on a service?
If we deal in RM
around Service boundaries and the concept of hierarchy then we don’t have a
new service just a different context. Where it gets tricky for me is
when you have a service that IS clearly re-used but is actually completely
separate. You get this in some compliance sensitive areas where they use
identical solutions but completely separate instances. This is different
to ones where they do that just because they can, there is a broader context
that means they MUST be kept separate… a real bugger to
model.
In part I’m
interested in how we are putting hierarchy into the RM?
Steve
From: Ken Laskey [
mailto:klaskey@mitre.org]
Sent: 05 September 2005
15:12
To: SOA-RM
Subject: Re: [soa-rm] Amazon.com
and Hurricane Catrina - Service Context? Service "Veneer"?
Steve,
I believe we are saying the same
thing. If the service is specifying the item to be purchased by UPC, it
is the same service in a different context. In this case, the donation
would be added to the general catalog and the user interaction would be the
same. I'd consider the "broader service" to be what I call the
underlying capability, i.e. the money collection in return for
something. The consumer sees the real world effect of that capability
existing and there being a service to access it, but never sees the capability
itself.
However, note that with both Amazon and
Apple there are new means to invoke the service (special links) and the
service interacts with the consumer in ways different than the usual.
For these reasons I'd say that for the new context Amazon and Apple created
new services (where here I mean services in the SOA context) to repurpose
existing capability (the provisioning of which may be called a service in the
more general business context). I'm not sure what Amazon and Apple did
made use of any SOA magic but it was nice reuse of
capability.
Does this bugger things up? I think
it does only if we need to be definitive when you cross the line from reusing
a service to having a new one. I'm not sure for the SOA-RM that we need
to draw that line or even acknowledge that it may exist.
Ken
On Sep 5, 2005, at
4:37 AM, Jones, Steve G wrote:
Again not to
raise old threads… but
This for me is
the concept of context, the context has changed which means the impact of the
service is different, its implementation and execution may however remain
identical. So the “Collection” service in this case always results in
Money being taken and added to a general leger with a UPC for the product code
(for example). The difference is that in the charity domain it results
in the further sending of that money onto the charity represented by the UPC,
whereas in the purchasing domain you get a song to download. The actual
collection service therefore remains unchanged but there is a broader service
(whose interface you don’t directly see but assume) which controls the whole
process.
And I can safely
say that these things can be a bugger to model.
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 05 September 2005
01:29
To: SOA-RM
Subject: Re: [soa-rm] Amazon.com
and Hurricane Catrina - Service Context? Service "Veneer"?
And the answer, as always, is it
depends. In my example of buying by UPC symbol, it is the same but
possibly because the use of the UPC symbol has been expanded. In the
case of having a new service that, let's say, automatically substitutes the
charity item number for your choice of a song item number and maybe gives
specialized feedback to the consumer saying thank you for responding to the
hurricane emergency, I'd say it is a different service. It is derived from the
original but I'd say it is different.
Ken
P.S. and with this busy hurricane
season, we are up to Katrina.
P.P.S. Another interesting aspect
is if you had a computer that hadn't already accepted the iTunes terms and
conditions, you were first presented with their click-through agreement before
you contribute. So we also have an interesting reuse of policy and the
need to form a contract.
On Sep 4, 2005, at 7:14 PM, Chiusano
Joseph wrote:
<Quote>
Is there also a
concept of a service having the same interface but by operating in a different
domain (e.g. charity) it acts different for the same
interface?
</Quote>
Which raises
another question we've been through before in the TC (several months ago): Is
it the same service in both cases? That is, are the "normal" Amazon.com order
placement service (with credit card info on file, and selectable each time)
and this new "hurricane donation" service really the same
service?
Joe
P.S. Not trying
to resurrect a permathread - just tying a recent observation in with a past
exchange, to see it in a new light.
From: Jones, Steve G [
mailto:steve.g.jones@capgemini.com]
Sent: Sun 9/4/2005 5:25
PM
To: Ken Laskey; Chiusano
Joseph
Cc: SOA-RM
Subject: RE: [soa-rm] Amazon.com
and Hurricane Catrina - Service Context? Service "Veneer"?
Is there also a
concept of a service having the same interface but by operating in a different
domain (e.g. charity) it acts different for the same interface? In
effect its business contract is changed by a business driver outside of its
scope, while its functionality (collecting money) remains the same its
imperative is changed by the wider business context in which it now
sits.
Steve
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 04 September 2005
21:22
To: Chiusano
Joseph
Cc: SOA-RM
Subject: Re: [soa-rm] Amazon.com
and Hurricane Catrina - Service Context? Service "Veneer"?
Apple also did this with their iTunes
Music Store: click the link and you order a donation instead of a
song.
This is why I keep insisting on
differentiating between the service and the capability. The underlying
capability is to collect money for a purpose. The service provides the
interface for doing that. Typically, you invoke the capability through a
service that enables you to buy a book (or a song) but a new service invokes
that capability (with a new user facing interface for Apple; I haven't checked
Amazon) to "buy" a donation. The power is the capability is reusable by
making it accessible through a different service.
Now note if I buy something through a
service that allowed me to specify the UPC code, I could buy a donation
through their existing service with that UPC, i.e. reusing the service for a
purpose similar to but different from its original purpose. In fact,
several supermarkets around here do support that because they have little
tear-off tablets at the checkout for certain hunger organizations and you can
hand the clerk a page for $1, $5, or $10.
Many interesting variations and our RM
just has to capture the concepts that can describe any of them. I think
I'll mow the lawn and think about this some more.
Ken
On Sep 4, 2005, at 4:06 PM, Chiusano
Joseph wrote:
One thing that I discovered regarding the
horrible catastrophe in the Southern US is that Amazon.com enabled people to
use its online ordering service to make a donation. One could use the credit
card information that Amazon.com already had online to make a donation in what
it called "1-Click Donation" (or something similar).
So instead of placing an order for a
book, CD, etc., your "order" was your donation, and you could view your
"order" online, which (as I recall) would show the amount that you
donated.
Something that came to my mind is: What
would this placing of a "new face" on a existing service be called? Is it a
different context for the ordering service? (i.e. in the context of Hurrican
Katrina) Is it a "veneer" that was placed on top of the existing service? None
of the above?
Joe
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
---
Ken Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean
VA 22102-7508
This message
contains information that may be privileged or confidential and is the
property of the Capgemini Group. It is intended only for the person to whom it
is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the sender
immediately and delete all copies of this message.
---
Ken Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean
VA 22102-7508
This message
contains information that may be privileged or confidential and is the
property of the Capgemini Group. It is intended only for the person to whom it
is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the sender
immediately and delete all copies of this
message.
---
Ken Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean
VA 22102-7508
This message contains information that
may be privileged or confidential and is the property of the Capgemini Group.
It is intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to read, print, retain, copy,
disseminate, distribute, or use this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete
all copies of this message.
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-983-7934 |
| 7515
Colshire
Drive
fax: 703-983-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------