Metering is typically a specific type of monitoring – usage monitoring.
Again, discussion is moving elsewhere. Every aspect of manageability
requires certain type of information, which can be obtained through monitoring.
So you monitor everything that is required as an information for proper
management.
I generally agree with this.
As we have threads passing each other, let me submit this again:
I agree with
You monitor only what you need to measure to adhere to your
manageability requirements
However, I monitor things for other reasons than to figure out
who has to pay me. That leads to the obvious need to monitor more than
invocations.
Ken
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...
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
1.
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)
2.
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.
3.
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.
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.
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.