re "monitoring management":
So there seems to be a management element that can identify things that
MUST/SHOULD be monitored. Individual services have internal monitoring that may
be made available to the ecosystem but I think this is basically private. The
ecosystem management may specify a guidance, e.g. a uniform way, for making
internal monitoring visible to the ecosystem. Some of this may be necessary for
the ecosystem management to do its job.
Does this make sense and where does it fit in?
I recall that a while back when we were deciding what still needed to be in the
RAF, there was a suggestion for monitoring although there was nothing specific
about what needed to be said.
Ken
________________________________________
From: []
Sent: Saturday, April 02, 2011 7:16 AM
To:
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
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.
- Michael
-----Original Message-----
From: Ken Laskey <>
To: ; ;
Sent: Fri, Apr 1, 2011 3:45 am
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
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: <mailto:> [mailto:<mailto:?>]
Sent: Thursday, March 31, 2011 7:44 AM
To: <mailto:>;
<mailto:>
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
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-----
From: Lublinsky, Boris <<mailto:>>
To: <mailto:> <<mailto:>>;
<mailto:>
<<mailto:>>;
<mailto:>
<<mailto:>>
Sent: Thu, Mar 31, 2011 12:25 am
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
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: <mailto:> [mailto:<mailto:?>]
Sent: Wednesday, March 30, 2011 5:18 PM
To: <mailto:>;
<mailto:>
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
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.
- Michael
-----Original Message-----
From: Lublinsky, Boris <<mailto:>>
To: <mailto:> <<mailto:>>;
<mailto:>
<<mailto:>>
Sent: Wed, Mar 30, 2011 5:58 pm
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
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: <mailto:> [mailto:<mailto:?>]
Sent: Wednesday, March 30, 2011 5:52 AM
To: <mailto:>
Subject: [soa-rm-ra] Management Model section after comments of this week
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.
