On Feb 23, 2007, at 3:53 PM, Francis McCabe wrote:
I think that is exactly what we discussed.
In the context of an electronically mediated environment for action, this includes messaging, policies,
double shots of expresso, extra whipped cream on the lattes,
etc. Whatever is needed to make it work.
The important thing for an execution context is to make sure you capture the critical factors :-)
On Feb 23, 2007, at 12:28 PM, Duane Nickull wrote:
What I always inferred from execution context is the set of specific
circumstances in which an execution or attempt thereof takes place.
Using the starbucks example, they provide a service (coffee procurement),
describe the service (via the menu), visibility(starbucks logo over store
visible from high traffic areas), reachability (door you can enter), have a
very specific service interaction model (enter premise, stand in order
queue, place order, pay, stand in coffee delivery queue, get coffee,...),
policy (open 06:00-20:00, no queue cutting etc.) etc etc.
The execution context is akin to what happens based on the context. In the
USA, you pay with US $$ and can read today's USA Today along with your
drink. In Canada, you pay with CAD$ and discuss ice hockey in the queue
with other people....
The execution is affected by the context based on the role of the
participants. A person who only serves drinks cannot also take your order
and ring it in. IN times when Starbucks get busy, you often can place your
order so the barrista can start your order before you actually pay, a
variation which may not happen at times when they are not busy.
Damn - all this makes me thirsty. Going to get another starbucks...
D
On 2/23/07 8:41 AM, "Francis McCabe" <> wrote:
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
--
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc. *
Chair - OASIS SOA Reference Model Technical Committee *
Blog: http://technoracle.blogspot.com *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
