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
/
----------------------------------------------------------------------------------