[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] SOA RA Management Section
|
I am not even trying to argue with this point. The question is to which extent service implementation is really
part of the service ecosystems. In other words does service ecosystem’s role is
to provide support for service’s interaction or both service’s interactions
and implementation? Where do we need to draw the line? From: mpoulin@usa.com
[mailto:mpoulin@usa.com] Yes, Boris, it is a balanced act. However, Implementer is not the
main role in the service development. The main role is designer and it is
design responsibility to address dependencies properly. Moreover, dependencies
should not be expressed via other services but, instead, via required
functionality (whoever provides it and agrees to sign the Service Contract with
me). - Michael -----Original Message----- Dependencies management becomes a double edged sword. On one hand a service is opaque to its user and its functioning is visible only to service implementer. On another hand, an implementer does care a lot about dependencies. I assume that from the ecosystem point of view this becomes a balancing act. -----Original Message-----From: Hestand, Dan [mailto:phestand@mitre.org] Sent: Monday, September 13, 2010 1:46 PMTo: Laskey, Ken; soa-rm-ra@lists.oasis-open.orgSubject: RE: [soa-rm-ra] SOA RA Management SectionKen,Thanks for the response. I'll try to address your questions here:I don't expect that there should or will be a single lifecycle used by all. In fact, there are probably multiple lifecycles involved in just a single organization. However, 1) Consideration for how to manage the lifecycle of services must be made, and 2) those considerations must be reconciled or have some mapping into the larger concerns of the ecosystem. It is a (hard) part of governance to ensure that those concerns have been clearly defined and agreed within the ecosystem.The main goal of management in the SOA ecosystem should be to create an environment in which all of the participants present a consistent picture of managed capabilities. To do otherwise could undermine trust, particularly if there is a perception of inequitable treatment. So governance specifies what it requires of participation within the ecosystem with respect to management such that there is consistency in the data and representation. Management then uses that consistency to support the operation of the ecosystem through e.g., enforcement or at least alerting of SLA violations. Management must ensure conformance to governance policies and record/report incidences of non-conformance. In the case of peer-peer environments, the question of who this information is reported to must be resolved through governance policies.What I was trying to convey with the "description of dependencies" is the need for management services to potentially have insight into dependencies that are generated within the ecosystem, not within the implementation of services because management is concerned with the global view of the ecosystem. In this regard, I believe management services have a somewhat privileged status (despite my fair and equitable clauses), and because of that also require careful consideration about what access is permitted to the management information. If the management services consume data that might not be available to other services, then the infrastructure must protect that information. What is made available to non-management consumers is processed to a normalized form that is appropriate for activities such as service discovery. The limits to transparency, I think, are to perhaps only consider first order dependencies, i.e., those that are immediately adjacent in a dependency graph. Certainly that is what most systems I've seen do. If you manage the first order dependencies of each node, then any changes or effects can be propagated through those connections to their immediate dependencies. I understand the limitations of this but practically it's easier and ultimately makes use of the trust inherent in the ecosystem (assuming no malicious intent).Summary: Management in the SOA ecosystem should not overly constrain capabilities but should state requirements for what's expected. Because of the unique perspective management (and security) have of the ecosystem, there may be a need for a more detailed understanding of the ecosystem.Maybe more verbiage than you expected but I'm still in dissertation mode. Sorry! I hope I've at least answered your concerns.Dan HestandLead Software Systems EngineerThe MITRE Corp781.271.3755phestand@mitre.org-----Original Message-----From: Laskey, Ken Sent: Monday, September 13, 2010 12:14 PMTo: Hestand, Dan; soa-rm-ra@lists.oasis-open.orgSubject: RE: [soa-rm-ra] SOA RA Management SectionDan,Thanks for getting this out. In general, it seems pretty consistent withwhat else we've been saying throughout the PR2 document, but I'll leave itto those more involved in management to debate details.The one part where I'd like some clarification is Lifecycle Management. Inparticular, are you saying there has to be be one lifecycle used byeveryone? From current experience with numerous agencies, I know that willnot fly.When you talk about "managed capabilities applicable to a SOA ecosystem",can these be structure or underlying assumptions that guide specificsgenerated by individual organizations, with the intent of having someconsistency in what is generated and how it is represented? For example,Lifecycle Management in concept may be fundamental but different groups mayhave different defined lifecycles or different levels of detail for specificparts of the lifecycle, e.g. developers having more development details.Management could define "requirements" of a lifecycle without specifying THElifecycle.One other point: when you talk about "a description of the dependencies", towhat extent is this hidden by opacity? A provider says a service averageavailability over, say, a 4 wk period will be at least 92%. The providerknows its dependencies and states 92%, and the consumer trusts that number(or not) based on information that is limited in detail at some level.Furthermore, if A depends on B and C, and B depends on D and E, and Cdepends on ..., stating "all" dependencies doesn't scale. Where should wehave visibility and where does opacity set in?Ken---------------------------------------------------------------------------Dr. Kenneth LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347515 Colshire Drive fax:703-983-1379McLean VA 22102-7508-----Original Message-----From: Hestand, Dan [mailto:phestand@mitre.org] Sent: Friday, September 10, 2010 12:57 AMTo: soa-rm-ra@lists.oasis-open.orgSubject: [soa-rm-ra] SOA RA Management SectionI'm delivering the management section in a standalone form. It is not in thetemplate form so I did not want to put it directly in the site because itdoesn't fit in any bin there. It also does not include UML models. I havepurchased MagicDraw Personal Edition but given the time and the otherdemands on my priority list, the images will have to follow with the correcttemplate format later.I apologize for not getting this out earlier but I was diverted by a taskingthat was marketed as a high priority.Anyway, here it is. Take it apart. It resembles the old section in structurebecause I made my notes as I read through the old section and that is theorder they came in. It contains material that I feel is necessary to sayabout management and its relationship to other aspects of SOA. I also tookliberties with the term "Manageability Capability" which I find cumbersomeand not very informative, mostly because to me "manageability" is acapability and adding "capability" to it is like naming an interfaceTheInterface interface. My opinion, so feel free to disagree. Much of thestuff is from my experiences going into different organizations and seeingthings that were either appalling or enlightening. Odd that it was nevermoderated to the middle of those.Feel free to email me directly with comments, criticisms, or questions. Orwe can do it in the telecon later.Thank you for your patience.Dan HestandLead Software Systems EngineerThe MITRE Corporationphestand@mitre.org781.271.3755---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 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.---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 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]