[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: understanding of SOA ecosystem scope
Michael, I have seen ridiculous description templates that ask for every bit of information the template designer could think of whether that information was readily available or maintainable. I’ve seen SLA based on measurements that are not collected. So there are obvious limits to what is able to be seen. I think Boris agrees that to a large extent compositions are known by the composer but not necessarily the consumer of the composition; it is the characteristics of the composition and not necessarily the parts that is visible. We are not over-designing to say the ecosystem does not have unlimited visibility, we are stating fact. Ken From: mpoulin@usa.com [mailto:mpoulin@usa.com] Ken, may I ask you to translate "there are limits beyond which we would violateopacity in the name of possible value of arbitrary informatio.", or, at least, give me an example. I think, there is a quite grey area (unexpectedly). If a consumer may not see the details of service body (implementation) but the stakeholder that owns the service can, do these details are 'made' visible to the SOA ecosystem? I am afraid that saying "The ecosystem does not have unlimited visibility and insight into everything within the ecosystem", we are over-designing the thing. - Michael -----Original Message----- The ecosystem does not have unlimited visibility and insight into everything within the ecosystem. It only has visibility to the extent that details are made available to it. Part of governance and management may be specifying what is required to be visible but there are limits beyond which we would violate opacity in the name of possible value of arbitrary information.Ken---------------------------------------------------------------------------Dr. Kenneth LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347515 Colshire Drive fax: 703-983-1379McLean VA 22102-7508________________________________________From: mpoulin@usa.com [mpoulin@usa.com]Sent: Saturday, April 02, 2011 8:05 AMTo: Bashioum, Christopher D; Laskey, Ken; [email protected]; [email protected]Subject: understanding of SOA ecosystem scopethe last FULL version (17 an) of RAF stated:the SOA-RAF makes key49 assumptions that SOA-based systems involve:50 • Use of resources that are distributed across ownership boundaries;51 • people and systems interacting with each other, also across ownership52 boundaries;53 • security, management and governance that are similarly distributed across54 ownership boundaries; and55 • interaction between people and systems that is primarily through the exchange of56 messages with reliability that is appropriate for the intended uses and purposes.57 Even in apparently homogenous structures, such as within a single organization,58 different groups and departments nonetheless often have ownership boundaries59 between them. This reflects organizational reality as well as the real motivations and60 desires of the people running those organizations.61 Such an environment as described above is an ecosystem and, specifically in the62 context of SOA-based systems, is a SOA ecosystem.(I have not found explicit definition of SOA ecosystem in the Peter/Chris definition spreadsheets)The things is red are, IMO, the reasons of my understanding that a SOA ecosystem has full visibility into everything it includes. This relates to the logical and functional aspects of the implementaiton of the service. For example, to list just a few, interactions with non-service resources, interactions with other services engaged in the controlled combinations (orchestration and choreography), security controls that contribute to the business trust between services.I'd like to ask for your comments on whether this understanding of SOA ecosystem in RAF matches yours (though I know that Boris disagrees with me already).Cheers,- Michael-----Original Message-----From: Bashioum, Christopher D <[email protected]>To: Laskey, Ken <[email protected]>; 'Lublinsky, Boris' <[email protected]>; mpoulin@usa.com <mpoulin@usa.com>; [email protected] <[email protected]>Sent: Sat, Apr 2, 2011 3:42 amSubject: RE: [soa-rm-ra] Management Model section after comments of this weekThis is interesting. Turns out that management determines what it needs, but monitoring may only be able to monitor primitives that don’t map directly to management needs. There will likely be an algorithm (or two or three) that combines monitoring primitives into information that is helpful for management decisions.From: Ken Laskey [mailto:[email protected]<mailto:[email protected]?>]Sent: Friday, April 01, 2011 4:20 PMTo: 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekIs there a management capability that applies to the existence and adequacy of monitoring? That is what I had in mind.KenFrom: Lublinsky, Boris [mailto:[email protected]<mailto:[email protected]?>]Sent: Friday, April 01, 2011 3:57 PMTo: Laskey, Ken; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekMonitoring is a means – you can’t manage what you do not measureFrom: Ken Laskey [mailto:[email protected]<mailto:[email protected]?>]Sent: Friday, April 01, 2011 2:20 PMTo: mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekI think the point is monitoring is a required manageability. Otherwise, you don’t have the information to do the other manageability.KenFrom: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]Sent: Friday, April 01, 2011 12:03 PMTo: Laskey, Ken; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: Re: [soa-rm-ra] Management Model section after comments of this weekNow is my tern to follow the discusstion and figure out what is sold ( and whome to).Will come back with my comments (if any) later. At the mean time, I can only point that means cannot drive the subject[http://o.aolcdn.com/cdn.webmail.aol.com/resources/core/images/indecision.png]: monitoring cannot drive management - it has to be the other way around- Michael-----Original Message-----From: Ken Laskey <[email protected]<mailto:[email protected]>>To: 'Lublinsky, Boris' <[email protected]<mailto:[email protected]>>; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>Sent: Fri, Apr 1, 2011 4:00 amSubject: RE: [soa-rm-ra] Management Model section after comments of this weekSold!From: Lublinsky, Boris [mailto:[email protected]<mailto:[email protected]?>]Sent: Thursday, March 31, 2011 10:59 PMTo: Laskey, Ken; 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekActually this brings one more manageability, that Michael does not have – usage manageability and metering. I will buy this oneFrom: Ken Laskey [mailto:[email protected]<mailto:[email protected]?>]Sent: Thursday, March 31, 2011 9:57 PMTo: 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekI 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 LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347515 Colshire Drive fax: 703-983-1379McLean VA 22102-7508From: Lublinsky, Boris [mailto:[email protected]<mailto:[email protected]?>]Sent: Thursday, March 31, 2011 10:52 PMTo: Laskey, Ken; mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this weekKen,Michael already has network management, that will react at you situation number 1. So I am still not buying events thingyFrom: Ken Laskey [mailto:[email protected]<mailto:[email protected]?>]Sent: Thursday, March 31, 2011 9:45 PMTo: mpoulin@usa.com<mailto:mpoulin@usa.com>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: RE: [soa-rm-ra] Management Model section after comments of this week1. 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 LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347515 Colshire Drive fax: 703-983-1379McLean VA 22102-7508From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]Sent: Thursday, March 31, 2011 7:44 AMTo: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: Re: [soa-rm-ra] Management Model section after comments of this weekBoris,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 <[email protected]<mailto:[email protected]>>To: mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com<mailto:mpoulin@usa.com>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>Sent: Thu, Mar 31, 2011 12:25 amSubject: RE: [soa-rm-ra] Management Model section after comments of this weekDo you see events manageability as service invocation manageability? I do not think I see it this wayOn everything else,Let’s see we agree to disagreeWhat you call composability I call dependence – see IBM’s service model – a service can have both interfaces and dependenciesFor me also, business performance requires SLAFrom: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]Sent: Wednesday, March 30, 2011 5:18 PMTo: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>Subject: Re: [soa-rm-ra] Management Model section after comments of this weekBoris, 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 <[email protected]<mailto:[email protected]>>To: mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com<mailto:mpoulin@usa.com>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>Sent: Wed, Mar 30, 2011 5:58 pmSubject: RE: [soa-rm-ra] Management Model section after comments of this weekHere is my manageability proposal:• Lifecycle Manageability• Configuration manageabilityo Dependency manageability• Policies Manageability• Contracts manageability• Business Performance manageabilityo SLA ManageabilityEvent Monitoring Manageability is really about reporting and should not be thereFrom: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]Sent: Wednesday, March 30, 2011 5:52 AMTo: [email protected]<mailto:[email protected]>Subject: [soa-rm-ra] Management Model section after comments of this weekFolks,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]