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