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