[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
Actually this brings one more manageability, that Michael does
not have – usage manageability and metering. I will buy this one From: Ken Laskey
[mailto:klaskey@mitre.org] I concede on the example but I’m still inclined to think
monitoring needs to be broader than invocation events. Too tired to be more creative. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S
H305
phone: 703-983-7934 7515 Colshire
Drive
fax: 703-983-1379 McLean VA 22102-7508 From: Lublinsky, Boris
[mailto:boris.lublinsky@navteq.com] Ken, Michael already has network
management, that will react at you situation number 1. So I am still not buying
events thingy From: Ken Laskey [mailto:klaskey@mitre.org] 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. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S
H305
phone: 703-983-7934 7515 Colshire
Drive
fax: 703-983-1379 McLean VA 22102-7508 From: mpoulin@usa.com [mailto:mpoulin@usa.com] Boris, 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. What do
you think? - Michael -----Original Message----- Do you see events
manageability as service invocation manageability? I do not think I see it this
way On everything else, 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 From: mpoulin@usa.com [mailto:mpoulin@usa.com] Boris, at a glance: ·
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.
-----Original Message----- Here is my manageability
proposal: ·
Lifecycle Manageability ·
Configuration manageability o
Dependency manageability ·
Policies Manageability ·
Contracts manageability ·
Business Performance manageability o
SLA Manageability Event Monitoring Manageability is
really about reporting and should not be there From: mpoulin@usa.com [mailto:mpoulin@usa.com] Folks, 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). Cheers, - Michael 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]