Re: [soa-rm-ra] Execution Context - a few thoughts

[Francis McCabe <frankmccabe@mac.com>]

Michael:
  While interesting, most of the context definitions you mentioned  
are really moot.
  The *purpose* of the execution context was to put arms around the  
run-time aspects needed to support interaction: going into the  
details was distracting to the rest of the RM work.
  In the RA, our task is subtly different: to explain how to actually  
*have* a SOA.
  Thus I fully expect the original EC idea to be unpacked quite a  
bit, and even to the point where the original concept is no longer  
prominent in the document.
  I think with the expansion into messaging, discovery (yet to be  
done properly) and policy mechanisms we will be at the point where we  
need to be wrt EC.
Frank

On Feb 23, 2007, at 3:32 AM, michael.poulin@uk.fid-intl.com wrote:

>
> Hi Folks,
>
> I agree to some extend with the idea that RA should not reflect ALL  
> elements of RM but, I think, that it would be better if RA were  
> addressed all elements that distinguish SOA from another  
> architecture; this will decrease amount of future questions.  The  
> execution context is the one of such elements.
>
> In this message I would like to share my understanding of execution  
> context. I hope, this might facilitate some good ideas of yours.  
> Here is my logic.
>
> 1.	We have, at least, two definitions we can work with:
> a)	SOA-RM: an execution context  the set of technical and business  
> elements that form a path between those with needs and those with  
> capabilities. This permits service providers and consumers to  
> interact and provides a decision point for any policies and  
> contracts that may be in force
> b)	Wikipedia: The context of an event, word, paradigm, change or  
> other reality includes the circumstances and conditions which  
> surround it; context in language use has two meanings: (a) the  
> surrounding text or talk of a word, sentence or turn  also called  
> 'co-text', and (b) the dimensions of the communicative situation  
> that are relevant for the production or comprehension of discourse.
> Both definitions are talking about conditions and policies.
>
> 2.	The path between those with needs and those with capabilities  
> has, at least, two ends, i.e. conditions on the consumer and  
> provider sides ought to be considered. Jumping ahead a little bit,  
> we can say that it is the Contract that combines conditions on the  
> both sides of the path into agreed context.
>
> 3.	The most known example of formalized execution context is  
> represented in SQL (language) by the WHERE clause. Literally, the  
> actions (SELECT/DELETE/ etc.)  gets applied to the subject (FROM   
> clause) under the conditions expressed in the WHERE clause. It is  
> important to notice that the content of the WHERE clause may be  
> easily expressed in the IF THEN format, which is quite similar to  
> the format of a Policy
>
> 4.	Conclusion: an execution context combines consumers and  
> providers conditions and may be consistently expressed in the form  
> of a set of Policies accompanied by a Policy Mediator. The latter  
> gets responsible for managing all dependencies, if any, between  
> Policies.
>
> 5.	The PEP/PDP constitute logical infrastructure for the execution  
> of policies aggregated in the logical execution context.
>
> Example of an execution context case. Lets assume a Logging tool  
> such as Log4j or a similar one offered by JDK. If we want to make a  
> SOA Service from this tool, we have to consider that Log4j may be  
> used as for a Status Reporting in a process/application as in the  
> Financial Audit Reporting. While Log4j is quite adequate to the  
> former case, we have to perform encryption and data signing for the  
> last case in addition to the logging because that one is the  
> subject of financial SOX Regulation. Thus, the execution context  
> may be defined as a Policy like the following IF financial data  
> THEN use Security Data Transmission Service ELSE use Log4j.
>
> I took a freedom to modify the diagram represented by Jeff to  
> illustrate aforementioned line of thinking. Unfortunately, I did  
> not follow UML notation in the extension. I have sent this diagram  
> to  Jeff directly (I have not found a way how to attach a doc to  
> the e-mail).
>
> Thank you,
> - Michael Poulin