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, 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
