[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
See below: From: mpoulin@usa.com
[mailto:mpoulin@usa.com] I think that in point 3 we have a problem in understanding the
difference between composition vs. aggregation. Business performance management
is an aggregation, not a composition. For the long time, the SLA management
existed with no business performance management at all. I disagree with setting SLA management as only an internal part of
business management. Its not internal its one of the faucets If a service implementation is not visible to the service
consumers, it does not mean it is also invisible to the service provider
stakeholders; it is a trivial truth. I believe it is time to stop mixing SOA
ecosystem with the Web Service development practice. SOA ecosystem sees
everything it includes while not every stakeholder and actor can/may see
everything that another stakeholder and actor can see. If we now saying that service implementation is out of the SOA
ecosystem, I do not know what this standard is about and what we are debating
here. Since I do not hear an argument against the point 1 consistent
within SOA ecosystem, I think there is no objections. So, this point stays as
is. This standard is about service/consumers interactions – definitely
not about service implementation. Service implementation is way to specific On the point 2, a kind of reference to the business nature of
service that may ignore all management that enables this nature to realise may
not be serious.We are talking about management of factors that allow for
service combinations and configuration it the last of them. If a configuration
is the thing and a combination is not, we are getting into programming paradise
that is immature for the concept of service orientation. I am looking for more
consistent arguments against the point 2. Until they come, I propose to leave
this point as is and out of debates. - Michael -----Original Message----- Om point three I am saying that SLA manageability is part of the
business performance manageability, so we are still a bit apart Sorry, still not buying number 1 – service execution is opaque
and is implementation that is not visible to ecosystem, hence not manageable by
ecosystem Definition of service, as it put forth is explicitly saying
that service is business meaningful. I do not see a reason to reopen
this. As for managing a kitchen sink – design is a purview of governance, but
not manageability. From: mpoulin@usa.com [mailto:mpoulin@usa.com] 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----- See below: 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. 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. 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:
-----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. 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]