[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, This is a good approach.
The idea of the composite have contracts with the services it invokes as well as a particular contract with its client is appropriate.
This should cover a lot of areas, while keeping it flexible enough to add the appropriate term associated with the composite.
Client -> Service Contract -> Composite
Composite -> Service Contract -> Service X
-> Service Contract -> Service Y
...
So in a sense the Composite is an extension of a client with more meat
The what the service does is the question, should it include the dependencies it has on other services?
This may be required if client is trying to understand its availability based on using a particular service and the services it calls.
There is may be a degradation of the client SLA based on use of a service that needs to be planned for as a consumer of a service.
- Dan
-----Original Message-----
From: Ken Laskey [ mailto:klaskey@mitre.org]
Sent: Tuesday, October 25, 2005 8:54 AM
To: Jones, Steve G; marchadr@wellsfargo.com; mattm@adobe.com; peter@justbrown.net; chiusano_joseph@bah.com
Cc: soa-rm@lists.oasis-open.org; HReiche@europarl.eu.int
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"?
--
- 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
- - what the service does (functionality/real world effects)
- - its constraints and policies
- - means to interact with the service
- A separate question is then if I have a service that invokes several other services, what elements of the component service descriptions should show up in the composite service. (The composite is the invoking service.) In most cases, I would expect very little. If the composite can comply with the constraints and policies of the components, it does not have to make these visible through the composite service description. If the composite has worked out all the interface details with the components, those would also not need to be visible through the composite. Now there are likely situations when passing component description elements through to the composite description will be useful, but this seems like something very situation dependent and will likely be facilitated by appropriate tools. (I can imagine a tool that allows a user (human or machine) to identify component services, then the tool "displays" the component service descriptions, and then allows the user to indicate which elements the composite will satisfy and which need to be made visible (passed on) via the composite description for the user of the composite to satisfy. This could be elements of policy or elements of interface communications.)
- As far as ontology is concerned, I think one should reference the defining vocabulary whenever one uses a term. Think of this as namespace-qualifying, where the target of the namespace can range from text notes to a full-blown ontology. A service should be free to use terms from any vocabulary and mix from several if that makes sense for the service in question. Now, if the composite service uses a vocabulary introduced from a component service, then the fact that the use originated from the component is probably irrelevant (although it may give some implied information). If the composite does an internal mediation to its own vocabulary, passing on information about the component vocabulary is again probably not necessary.
- Given this view of combining services
- 1. is it sufficient?
- 2. does it indicate needed RM concept?
- Ken
- At 11:14 AM 10/25/2005, Jones, Steve G wrote:
- Spectrum is Green....
- From: marchadr@wellsfargo.com [ mailto:marchadr@wellsfargo.com]
- Sent: 25 October 2005 15:55
- To: mattm@adobe.com; peter@justbrown.net; Jones, Steve G; chiusano_joseph@bah.com
- Cc: soa-rm@lists.oasis-open.org; HReiche@europarl.eu.int
- 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"?
- In some ways I thin the concept of orchestration could be used at a high-level for defining how the service model defines the "interaction model"
- and the "contracts". In some ways the contract between services is derived from an overall process that is trying to be achieved.
- Not to try and sound like a "process architect" which I vow not to be, but the concept of business architecture takes into account a holistic view of the system in which service contracts, service descriptions, etc. will be initiated from.
- Quote from the Overview of the Ref model:
- "...it is necessary to know that it exists, what is accomplished if the service is invoked, how the service is invoked, and other characteristics...service description.."
- This to me implies that if a service is invoked within a composite service or orchestration (dare I say it) bus than it would need to feed the service description and service agreements that service has. Being part of an orchestrated process means there are certain constraints on the service within the context of that process this ties into what the service functionality consists of in certain cases.
- [Jones, Steve G] Whether a service is an orchestrated process using a technology like BPEL, or in a "standard" Java invocation should be irrelevant to the service. There is a difference between invocation and encapsulation of services (or process) as encapsulation can result in the inheritance of properties from the surrounding (controlling) service. BUT that is to do with the nature of service hierarchy IMO rather than being to do with whether its process orchestration or some other mechanism that enables that. If a process adds constraints to a service that should be based on its agree contract rather than an imposition of process, otherwise one service when calling another must be able to make the same restrictions and constraints.
- In my simple world a service is a collection of processes (methods) the implementation language of which is down to the most appropriate choice for the service. In this view therefore orchestration wouldn't be applicable for the RM as its just a service constraint whether by service or process.
- Also since there is some discussion about ontology within the reference model it may be a good idea to talk about how that relates to service discovery or routing since ontology could not only describe the data by the service relationships. Some services may require another service to be invoked feeding data to the service that could be describe within an ontology discussion or part of an orchestration process definition. Also there is some talk around services invocations in the services in context section maybe there could be more eloboration within this section on execution context within a BP.
- [Jones, Steve G] In my mind what you have described is a higher order service that co-ordinates lower level services to achieve a given set of goals, rather than there being a separation of things that are process and things that are service
- By the way why are banks the only example people can come up with? A supply chain example would be nice.
- :)
- [Jones, Steve G]
- Vendor managed inventory is my favourite SOA example as its got dynamic internal and external interactions, its also a tricky problem with clear domains of control with different technical and economic drivers.
- Some thoughts to consider.
- - Dan
- -----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 Brussels....
- 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
- 700 13th St. NW
- Washington, DC 20005
- 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 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 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]