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.
May also have conditions on the path that are not directly related to the ends, e.g. government regulations.
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.
The agreement may be less formal than Contract with a capital C, but I follow your thoughts.
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
The WHERE clause still assumes a lot of pre-established context. While the execution context will not be a complete description (as we've noted that completeness is impossible), it will probably contain or reference more than the WHERE.
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.
Not unreasonable but still need to consider when this may be something other than what would be represented by policy.
Jeff and I were talking about the difference between description and execution context, and we came to the point that description may contain options whereas the EC documents the option chosen. So, for example, consider the privacy policies you get from every bank, credit card, mutual fund, ... you deal with. There may be three options for privacy policy and the default one says they can share your data internally to identify products or services with which you may have some interest. (Isn't that nice of them!) This is their description. If I do nothing, the default becomes part of our execution context and they can share my information. If I choose the option that says not to share my information, that instead become part of our EC.
But that is still policy related. What if I am willing to receive your information encrypted or not encrypted? We agree in advance on one or the other and then proceed with the interaction. If neither of us requires additional validation and we simply follow through on our agreement, we have execution content information that doesn't require policy evaluation.
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.
Again, this is one example but we need to consider use cases that wander from this pattern.
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
Thanks for the ideas.
Ken
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508