It looks like we agree on point 3, Boris.
For point 1, "service invocation manageability" manages mechnaisms that trigger service execution. An inercia of thinking recognises only one way of service invocation - via a request from the consumer. However, the REW (its shareable side) tells us that not all consumers have to request the service explicitly to reach its values. So, a service can be invoked in one part explicitly to start monitoring the events while the real execution of the service's business functionality (capability) is based on the observed events. These mechanisms and related events are the subject of this manageability.
Are these explanations enough to agree on point 1?
For point 2, I disagree that composability is so natural aspect of the service that it does not require management. I think that this aspect is provided beacuse of the proper management. Then, I did not agree that service is always a business/human functions implementing thing. I do "allow" some technical utility services to exist; they mind their own technical business.
Also, the "kitchen sink" is what has to be properly managed if you want to get a good combined service. Placing a Web Service pigskin on a legacy application (known as a Composit Application) never delivered a good service...
So, I do not see principle objections to the point 2. Are we in agreemnt?
- Michael
-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: mpoulin@usa.com <mpoulin@usa.com>; boris.lublinsky@navteq.com <boris.lublinsky@navteq.com>; soa-rm-ra@lists.oasis-open.org <soa-rm-ra@lists.oasis-open.org>
Sent: Thu, Mar 31, 2011 3:01 pm
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
See below:
I think that our task is not to set a status of "disagree" but to find a solution to resolve the disagreement.
1. About Event Manageability. It seems to me that "service invocation manageability" might work because I certainly do not want to manage events that may be even outside of SOA ecosystem. Also, I do distinguish (despite of EDA vision) between the event and reporting of this event. A consideration I use is this: if nobody (in given realm) listens to/monitors the event, this does not mean that the event has not happened; one event may cause another event - a sad example: an earthquake causes a tsunami - and, if we discard the initial event as non-existed but we recognise the caused event, we have to deal with things without reasons, out of the blue, which is not natural and unacceptable to me.
So, an events selection manageability is a sort of a view inside and outside the SOA ecosystem for the service invocation triggers.
What does service invocation manageability means – what does it manage exactly?
2. I do respect IBM’s viewpoint but they proofed they are not very fast with changes and they still take SOA service as a Web Service in several of their even modern applications and papers while others (e.g. Dr. Marc Fiammante) are quite in synch with what we do in OASIS.
So, a service, even a composite or aggregate service depends only on functionality it needs from others. Considering an explicit contracts and a possibility of the trusted realm, a service (and its implementation like a process) may not and do not need to know who actually provides required functionality.
By Combination or Composability Management I mean (but may be did not use proper words to articulate) a management of service capabilities to be used in the combinations or to combine others for providing solution for common task. (This is a basic service property, that does not need to be managed) This, particularly, includes: special relationship between business services and Data Services / Data Access Layer (I thought we agreed that services are always business services.), enforcement of policies related to the granularity of interfaces, management of information stores/repositories for meta-data, management of the processes and procedures – development and run-time – that result in new service combinations (which may include as integration as testing aspects), (I am sorry, but first this is a kitchen sink, and second those a design concerns, which are not quite subject of manageability) and so on. I hope, you’ve got the picture. Configuration management may also take place among others in this domain but, IMO, it is certainly not the major one.
3. The last one – management of business performances – do require and use SLA and SLA management but the letter is not always a visible part of the former. This is why I put them separately: the SLA management can still be provisioned at many different levels (including pure technical ones) while management of business performances may be more laid around business KPI. I am not saying that they are the same. I am saing that they are related.
Do you see events manageability as service invocation manageability? I do not think I see it this way
Let’s see we agree to disagree
What you call composability I call dependence – see IBM’s service model – a service can have both interfaces and dependencies
For me also, business performance requires SLA
- Event Monitoring Manageability is mandatory IMO because it is not about notifications but about managing selection of events that trigger the services.
- I do not understand "Dependency manageability" because service do not depend on other services; instead, they depend on functionality of an arbitrary trusted provider (IBM Dynamic Process Edition allowed having a 'basket' of potential providers where the process picked up the actual one when needed on the fly 9not a discovery mechanism); no end-points were configured up-front). This is not a programmatic dependency, which many would read into.
- Combination or Composability Management is about managing combinations of services that might be realised w/ or w/o configuration, i.e. via design (composition) or orchestration (aggregation), by both service provider and consumer. The fact that existing BPM tools require configuration does not mean that they are the only possible ways of doing combinations. Also, do not forget about business domain where a service combination may requires just a new organisational chart :-)
- Business Performance and Service Level Agreement are very different things, e.g. the former may have monetary expression while the latter - pure technical expression. Also, the best technical expressions (measurements and matrix) do not necessary lead to the best monetary expressions.
Here is my manageability proposal:
· Lifecycle Manageability
· Configuration manageability
o Dependency manageability
· Contracts manageability
· Business Performance manageability
Event Monitoring Manageability is really about reporting and should not be there
I have incorporated all comments and chnages into attached document. In some places, I have repeated the text (in different font) just to save and show the comments that I responeded insted but didn't change the text.
I am not sure what tactics we prefer now - to go through all left comments together in the meeting or for me to resolve each comment with particular author (in some cases I disagree with the comment, however).
The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]