I am trying to find the common ground.
If you read my explanation again, I hope you find that I stick with 1) can choose events to monitor; 2) use the knowledge about events to trigger service execution or an execution of the part of the service, i.e. with invocation of particular part of the service. However, a "case management of service usage " belongs to the consumer rather than internal mechanisms of the service's body.
"I need to know how many times you invoked my service and potentially manage your invocation quota." - is a good point, which does not work for implicit contracts. Provider can manage an "invocation quota" of the consumer only for explicit contracts and, even in this case, it is not really a management: the quota should be set once- in the contract - and controlled in usage; if the consumer exceeds the quota the provider has to decide how to respond to extra requests but it is no a management of quota (too low level), it is a management of the service contract.
"Choosing which event to monitor depends on your manageability requirement" - yes. "Choosing which event to monitor depends on your manageability requirement", yes, so what this means? I have 'event selection' or 'invoation' manageability already...
- Michael
-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: mpoulin@usa.com <mpoulin@usa.com>; soa-rm-ra@lists.oasis-open.org <soa-rm-ra@lists.oasis-open.org>
Sent: Sat, Apr 2, 2011 4:30 pm
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
Well you keep changing your position, which makes it more
difficult to response. I think we originally agreed that 1 was service
invocations, in which case management of service usage is quite straightforward.
I need to know how many times you invoked my service and potentially manage
your invocation quota.
Choosing which event to monitor depends on your manageability
requirement. Choosing which event to monitor depends on your manageability requirement
- I am not sure how anybody can manage events. IMO,
one can choose which events to observe/monitor/recognise and to react to.
This does require management. If we agree with this, the question is: what
we can do with the knowledge of the event, how we can use it in SOA
ecosystem and whether this usage requires any management? So, my
response to these question is that SOA ecosystem
1) can choose events to monitor; 2) use the knowledge
about events to trigger service execution or an execution of the part of
the service (yes, service has body=implementation and the latter has its
parts that can monitor, recognise, analyse, make decisions and act upon
events, by themselves or by orchestrating other services)
- I've listed the things below just
to explain that management of service combination is much more
than management of configuration; service may be combined not only via
re-configuration.In the document I will not list all mentioned things but
only the ons that specific to SOA/services.
- I agree that Performance Management may be expressed
as one united are with two/three sub-areas and their inter-relationship.
From here, I am going to massage the text and would like to
discuss the scope of SOA ecosystem in general.
- Michael
1. I
think events have to be more than invocations. A service consuming a lot
of bandwidth may be an event that requires a response from management. Deciding
the response likely falls under other management but the monitoring itself is
needed. If everything relates to an invocation, then maybe service invocation
is sufficient, but I don’t think you want to go there. I’d stick with
monitoring.
2. As
you list things below to fall under Combination or Composability, the list
becomes too diverse and has no focus for what is really being managed.
Everything requires some degree of management and when we decide something
needs to specifically be called out, it needs to be clear why the SOA ecosystem
requires something beyond traditional management.
3. I
think all aspects of performance should be in one place. Otherwise, it
seems like you’re splitting hair to break some out and not others.
---------------------------------------------------------------------------
MITRE Corporation, M/S
H305
phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
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.
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, particularly, includes:
special relationship between business services and Data Services / Data
Access Layer, 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), 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.
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.