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
>>> *
>>> 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:
Tel: 781-856-7230
http://mansurus.com
