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

[michael.poulin@uk.fid-intl.com]

Putting arms around the run-time aspects needed to support interaction is quite understandable placeholder. Also *have* a SOA in this case means the definition of the arms, doesnt it? 

However the  original EC idea to be unpacked means that arms were not just a placeholder. 

I guess my interpretation of EC as a composition of Policies is not enough though it is nothing more than a little detail added to the Jeffs interpretation (the PEP and PDP are not more than certain architectural infrastructural elements of Policy execution and do not constitute a business contexts for the service). Modified diagram may be found at http://www.oasis-open.org/apps/org/workgroup/soa-rm-ra/download.php/22576/ExecutionContextDiagram-extended.jpg


So, the messaging between consumer and provider as well as the service discovery ought to define the service execution context

- Michael



> 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