OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] service execution context


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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]