From: Ken Laskey
[mailto:klaskey@mitre.org]
Sent: 06 September 2005 18:11
To:
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Amazon.com and
Hurricane Catrina - Service Context? Service "Veneer"?
Joe,
I think what was decided was that a
detailed discussion of orchestration was beyond the scope of the RM but we
didn't necessarily ban the term. I expect the fact that services can
call other services will have some mention but not a discussion of how it
would be done.
Ken
At 12:57 PM 9/6/2005, Chiusano Joseph
wrote:
John,
I believe this was determined several
months ago (I say that in a helpful way, not in a criticizing way). I don't
believe we are limited at all in our capability to define service. It's just
that we need to define certain "basic" aspects first, and have other TCs (or
perhaps this one in a later phase) extend our RM to include capabilities such
as orchestration. We've sometimes referred to this as a POA (Process-Oriented
Architecture).
Hang in there, we'll get
there.....
Joe
Joseph Chiusano
Booz Allen Hamilton
O:
703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: John Harby [ mailto:jharby@gmail.com]
Sent: Tuesday, September 06, 2005
12:44 PM
To:
soa-rm@lists.oasis-open.org
Subject:
Re: [soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"?
I'm surprised that orchestration is out
of scope. I could understand how specifics such as BPEL
would be out of scope but many people
will call things services that are lorchestrations of other
services. If
orchestration is out of scope then are we limited in our capability to define
"service"?
On 9/6/05, Chiusano Joseph < chiusano_joseph@bah.com> wrote:
Emphasizing that orchestration is out of
scope for our RM (it's for another RM that can be built on top of ours), and
speaking only of Web Services: I would say that all Web Services are
orchestrable, but not all Web Services are "orchestration-ready". That is, in
order to be "orchestration-ready" a Web Service may need to have the ability
to participate in a certain protocol (e.g. the OASIS WS-CAF coordination
protocol, which can be part of orchestration) by implementing that protocol.
For example, a Web Service may need to
have the capability to register itself with a coordinator
service.
Joe
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: John Harby [ mailto:jharby@gmail.com]
Sent: Tuesday, September 06, 2005
12:03 PM
To: soa-rm@lists.oasis-open.org
Subject:
Re: [soa-rm] Amazon.com and Hurricane Catrina
- Service Context? Service "Veneer"?
One question I had
was can all services be orchestrated or are there "orchestratable services"
and "non-orchestratable services". If there is a distinction, would this
orchestration capability be mitigated via policy?
John
Harby
On 9/6/05, Ken Laskey <klaskey@mitre.org> wrote:
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
/
----------------------------------------------------------------------------------
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-983-7934 |
| 7515
Colshire
Drive
fax: 703-983-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------