[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [Revisiting "Concepts from which you can support any business process"] RE: [soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service "Veneer"?
Ken: I chose #1 – I think we have
sufficiently dealt with this. To me, this is no different than the constraints
on a service acting on other functionality. The service providers will have to
make a decision in each case on which relevant pieces of information to include
in the service description and policies. Duane From: Ken Laskey
[mailto:klaskey@mitre.org] It appears we begin with the idea of a service which has a
corresponding service description, that description providing (either
explicitly or through reference links) information on Spectrum is Green…. From:
marchadr@wellsfargo.com [ mailto:marchadr@wellsfargo.com] -----Original Message----- From: Matt MacKenzie [ mailto:mattm@adobe.com] Sent: Tuesday, October 25, 2005
4:54 AM To: peter@justbrown.net; Jones,
Steve G; Chiusano Joseph Cc: soa-rm@lists.oasis-open.org; REICHE
Henrik Subject: RE: [soa-rm] [Revisiting
"Concepts from which you can support any business process"] RE:
[soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"? Wow
guys…I am impressed. I honestly thought that I would have to spend
a lot of time convincing folks that orchestration is clearly complimentary to
SOA, so much so that I don’t want to bore our readers in SOA-RM with it J Steve – love the parallel you drew with Visual
COBOL. Bad then, bad now, bad later…even if Frank can come up with
reasons why his company is still in the business J -matt From: Peter F Brown [ mailto:peter@justbrown.net]
Sent: Monday, October 24, 2005 3:48
PM To: 'Jones, Steve G'; 'Chiusano
Joseph' Cc: soa-rm@lists.oasis-open.org;
'REICHE Henrik' Subject: RE: [soa-rm] [Revisiting
"Concepts from which you can support any business process"] RE:
[soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service "Veneer"? No need for
high horses....My point was "simply" that BP!=workflow, and that in
terms of levels of abstraction, it is similar to the debate about
RM!=RA....Sorry for any confusion!! I agree that
our work on the RM has been spot on and that these concepts have no place in
it... Peter From: Jones, Steve G [
mailto:steve.g.jones@capgemini.com] Sent: 24 October 2005 16:01 To: peter@justbrown.net; Chiusano
Joseph Cc: soa-rm@lists.oasis-open.org;
REICHE Henrik Subject: RE: [soa-rm] [Revisiting
"Concepts from which you can support any business process"] RE:
[soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"? I’ll get
on a high horse here. Workflow and
BP only make sense in an SOA context, otherwise its just Visual COBOL that is
being proposed onto an enterprise. SOA gives the structure to the
workflow and BP which ensures that it has the correct hierarchy and granularity
to enable effective change. All a workflow
or BP actual gives is an ordering and tracking of the invocation steps between
services and actors, I’ve spent so much time cleaning up after process
driven architectures its not funny (except after four drinks). So
I’d say that the RM has been spot on in not dealing with these elements
as they should be a secondary concern of the structure that SOA can give.
I agree that the paper doesn’t appear to address the challenge of
abstraction, but it could be relevant as a description of a standard
“state” manager for distributed process (but that is definitely not
RM). VISUAL COBOL,
a bad idea in 1980… a bad idea today. Steve From: Peter F Brown [ mailto:peter@justbrown.net]
Sent: 24 October 2005 14:36 To: 'Chiusano Joseph' Cc: soa-rm@lists.oasis-open.org;
'REICHE Henrik' Subject: RE: [soa-rm] [Revisiting
"Concepts from which you can support any business process"] RE:
[soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"? Joe: This reminds
me of similar debates and battles we had in the European Parliament some moons
ago when I was still working in I would
content that the list of concepts relates to workflow (at an implementation
design layer) and not business processes (as an abstract, higher layer). The
major problem we found with many so-called BPM tools is that hard-wired
detailed implementation concepts right from the start, such as requiring name
or ID of a person initiating a "process" rather than an identifier
for the functional responsibility, etc. This makes it nearly impossible to
re-use high level value chains in different processes,because too much context
dependency is hard-wired. At first sight, they seem to be making the same
"mistake", at least if the attempt really is to define abstract
business process concepts. In this sense,
the Semantion concepts probably map closer to a Reference Architecture than a
Reference Model... Peter From: Chiusano Joseph [
mailto:chiusano_joseph@bah.com] Sent: 24 October 2005 15:03 To: soa-rm@lists.oasis-open.org Subject: [soa-rm] [Revisiting
"Concepts from which you can support any business process"] RE:
[soa-rm] Amazon.com and Hurricane Catrina - Service Context? Service
"Veneer"? Revisiting the Sept 6th e-mail below which mentioned
that challenge of identifying "the concepts from which you can support any
business process. (Question: have the previous drafts of SOA-RM missed any of
these concepts?)". This past Friday, Goran Zugic of Semantion sent the
attached e-mail to the ebSOA TC list (many in this TC have already seen it). I
reviewed some of the specs over the weekend, including the SOA Information
Model[1]. This SOA Information Model spec looks more to me like a "Process
Information Model" that is actually independent of SOA (that is, I did not
see anything that restricted it to SOA). If that is an accurate view, would this SOA
Information Model spec perhaps fit the bill described above? (i.e. identifying
the concepts from which you can support any business process). Joe [1] http://www.semantion.com/specs/soa/SOA_IM_V0.2.doc
Joseph Chiusano Associate Booz Allen Hamilton O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com 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 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 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 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
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 | | \
----------------------------------------------------------------------------------
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. 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]