RE: [soa-rm-ra] service execution context

["Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>]

Title: RE: [soa-rm-ra] service execution context

Last week we had a cross Fidelity (all LOBs and countries) discussion on SOA and its perspectives. The EC was one of the most murky topics.

The question is: should we limit EC to the consumer-provider interactions only or EC is a valuable architectural concept that covers service execution conditions as well (behind the interface). I have found signs of the latter in both RM and RA texts but in both cases it requires some interpretation on the side of those who implements the architecture.

Summarising my point, I propose EC to be clearly interpreted as a SOA concept describing:
        - interactions between service participants
        - information needed to establish the interaction
        - information about business conditions which the service executes or being used under

Reasons for the second and third positions are in the EC definition in the RM, which includes policies and agreements. In my initial example I outlined that different business execution contexts affect service results. That is, service reusability is, actually, limited by the EC - service may be reusable as is in the same EC only. If crossing EC boundaries, service has to be re-tested, at least.

- Michael

-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: 24 September 2007 18:38
To: Francis McCabe
Cc: Ken Laskey; Poulin, Michael; soa-rm-ra@lists.oasis-open.org
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