[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] service execution context
While the EC is a pervasive concept throughout the RA, I believe that there is considerable merit in keeping the EC as a separate, architectural abstraction in the RA. When Architects are building concrete architectures using the RA, I believe that having the EC as a point of view will be invaluable to them as they describe interactions between service participants. Don Francis McCabe wrote: > Well, could not resist this one ... > > In my mind the EC is the 'beaten path' that must exist for there to be > meaningful interaction between service participants. On that > interpretation, I agree with both Ken and Michael. > > However, I also saw that, in the RM, the EC represented all the 'gorp' > needed to establish the interaction. Necessary but distracting if gone > into in too much detail. > > From this PoV, I believe that a key function of the RA is to unpack > the EC sufficiently to explicate how you might realize a SOA. Hence, > you will not find much direct mention of the EC in the RA: it is > pervasive. > > Frank > > On Sep 24, 2007, at 7:36 AM, Ken Laskey wrote: > >> Michael, >> >> You nailed it all the way! >> >> Both technical (e.g. what are the communications protocols) and >> business (e.g. if I ask for a value and there is a US and a separate >> UK way of calculating the value, which one is chosen) aspects go into >> the execution context. At one point in the RA write-up, I started >> thinking of its relationship to the log of an interaction and had >> some thoughts of the log as a capture of the execution context. >> There may be several decision points that go into sustaining an >> interaction, but if the same interaction is required later, you could >> want to make sure you execute the same conclusions and not re-ask the >> questions that might lead to different answers. >> >> I have a very intuitive feel for the execution context (one I know >> Frank doesn't share ;-) ) so I welcome questions that help clarify it >> and find its right place in the RA. >> >> Ken >> >> >> On Sep 24, 2007, at 8:43 AM, Poulin, Michael wrote: >> >>> Folks, >>> >>> I have another question (which is, probably, not the right time to >>> ask since the period of comments for 0.2 version is closed... but I >>> will try): >>> >>> I've just realised that the RA interprets 'service execution >>> context' from RM as "Within the RM, the execution context stood for >>> all the aspects of an information system that are needed to >>> facilitate interaction. A large part of the goals of the Reference >>> Architecture is to show how interaction is realized". Plus, >>> "Descriptions of the provider and consumer are the essential >>> building blocks for establishing the execution context of an >>> interaction." That is, it is a communication context. >>> >>> In another place: "The execution context can be thought of as a >>> series of answers to the questions of why would the participants be >>> willing to interact and whether such interaction is possible", i.e. >>> one can assume that the context may include business >>> conditions/context as a factor of willingness to interact. This >>> corresponds to the references to the policies in the RM's definition >>> (policies, which may apply as to the communication as to the >>> execution on the provider side and be agreed in the Service Contract). >>> >>> I have read the RM's definition of the execution context as both - >>> information AND business context of execution of the service rather >>> than just communication information system context. For example, >>> assume we have a service for calculating a fund price. We have >>> corporate divisions in the US and in the UK working with different >>> funds but in the same fund category. Besides different policies, the >>> calculation method is different (in the business definition) in the >>> US and the UK. That is, the service execution context from business >>> perspective is different. So, before reusing the service even in the >>> same information infrastructure, it is better to, at least, re-test >>> it even if no one bit of its implementation is changed. >>> >>> I think we have to clear state what is meant by the service >>> execution context in the RA. >>> >>> Cheers, >>> >>> Michael Poulin >>> >>> Head of Business Analysis and Web Architecture >>> >>> Senior Manager, Web Delivery >>> >>> Fidelity Investments International >>> >>> ' +44-173-783-6038 >>> * michael.poulin@uk.fid-intl.com >>> 8 http://www.fidelity.co.uk/ >>> >>> Important: Fidelity Investments International (Reg. No.1448245), >>> Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity >>> Pensions Management (Reg. No. 2015142) and Financial Administration >>> Services Limited (Reg. No. 1629709, a Fidelity Group company) are >>> all registered in England and Wales, are authorised and regulated in >>> the UK by the Financial Services Authority and have their registered >>> offices at Oakhill House, 130 Tonbridge Road, Hildenborough, >>> Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives >>> information on products and does not give investment advice to >>> private clients based on individual circumstances. Any comments or >>> statements made are not necessarily those of Fidelity. The >>> information transmitted is intended only for the person or entity to >>> which it is addressed and may contain confidential and/or privileged >>> material. If you received this in error, please contact the sender >>> and delete the material from any computer. All e-mails sent from or >>> to Fidelity may be subject to our monitoring procedures. Direct link >>> to Fidelity’s website - >>> http://www.fidelity-international.com/world/index.html >>> >> >> >> ------------------------------------------------------------------------------------------ >> >> Ken Laskey >> MITRE Corporation, M/S H305 phone: 703-983-7934 >> 7515 Colshire Drive fax: 703-983-1379 >> McLean VA 22102-7508 >> > > > -- Don Flinn President Mansurus LLC e-mail: flinn@alum.mit.edu Tel: 781-856-7230 http://mansurus.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]