[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] SOA RA Management Section
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.
environment in which all of the participants present a consistent picture of
Ken, 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 Hestand Lead Software Systems Engineer The MITRE Corp 781.271.3755 phestand@mitre.org -----Original Message----- From: Laskey, Ken Sent: Monday, September 13, 2010 12:14 PM To: Hestand, Dan; soa-rm-ra@lists.oasis-open.org Subject: RE: [soa-rm-ra] SOA RA Management Section Dan, Thanks for getting this out. In general, it seems pretty consistent with what else we've been saying throughout the PR2 document, but I'll leave it to those more involved in management to debate details. The one part where I'd like some clarification is Lifecycle Management. In particular, are you saying there has to be be one lifecycle used by everyone? From current experience with numerous agencies, I know that will not fly. When you talk about "managed capabilities applicable to a SOA ecosystem", can these be structure or underlying assumptions that guide specifics generated by individual organizations, with the intent of having some consistency in what is generated and how it is represented? For example, Lifecycle Management in concept may be fundamental but different groups may have different defined lifecycles or different levels of detail for specific parts of the lifecycle, e.g. developers having more development details. Management could define "requirements" of a lifecycle without specifying THE lifecycle. One other point: when you talk about "a description of the dependencies", to what extent is this hidden by opacity? A provider says a service average availability over, say, a 4 wk period will be at least 92%. The provider knows 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 C depends on ..., stating "all" dependencies doesn't scale. Where should we have visibility and where does opacity set in? Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 -----Original Message----- From: Hestand, Dan [mailto:phestand@mitre.org] Sent: Friday, September 10, 2010 12:57 AM To: soa-rm-ra@lists.oasis-open.org Subject: [soa-rm-ra] SOA RA Management Section I'm delivering the management section in a standalone form. It is not in the template form so I did not want to put it directly in the site because it doesn't fit in any bin there. It also does not include UML models. I have purchased MagicDraw Personal Edition but given the time and the other demands on my priority list, the images will have to follow with the correct template format later. I apologize for not getting this out earlier but I was diverted by a tasking that was marketed as a high priority. Anyway, here it is. Take it apart. It resembles the old section in structure because I made my notes as I read through the old section and that is the order they came in. It contains material that I feel is necessary to say about management and its relationship to other aspects of SOA. I also took liberties with the term "Manageability Capability" which I find cumbersome and not very informative, mostly because to me "manageability" is a capability and adding "capability" to it is like naming an interface TheInterface interface. My opinion, so feel free to disagree. Much of the stuff is from my experiences going into different organizations and seeing things that were either appalling or enlightening. Odd that it was never moderated to the middle of those. Feel free to email me directly with comments, criticisms, or questions. Or we can do it in the telecon later. Thank you for your patience. Dan Hestand Lead Software Systems Engineer The MITRE Corporation phestand@mitre.org 781.271.3755 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]