[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [soa-rm-editors] alternate description of execution context
From: Francis McCabe <frankmccabe@mac.com>
Date: December 6, 2005 11:23:17 PM EST
To: Ken Laskey <klaskey@mitre.org>
Subject: Re: [soa-rm-editors] alternate description of execution context
We are in, as they say, violent agreement.
Frank
On Dec 6, 2005, at 7:01 PM, Ken Laskey wrote:
At 09:03 PM 12/6/2005, Francis McCabe wrote:
I agree that the EC includes the technical and business levels.
Your wording seems to imply that the EC's role is used in deciding
whether to use a service and that is what I was disagreeing with.
To establish an EC, you need to resolve things at a number of levels and one of the major factors in deciding whether to use a service is whether you can establish an EC. A complete EC is a prerequisite for service invocation.
I think the important thing is EC is that airtight, climate-controlled, shielded corridor between two vibrant entities pulsing in the vastness of cold (but not empty because there of tons of other provider and consumers life bubbles) space. The interaction is a set of fragile messengers we send back and forth through that corridor and any unresolved item (technical or business) could doom our interaction messengers.
I will see if I can reword your rewording :)
A little busy though at the moment as I am still in business process
modeling mode.
Frank
P.S. At least the list has woken up!
I also have too much to do before Vienna (including trying to prepare for the ftf) and while I enjoy considering the various perspectives, I could do without the distraction.
On Dec 6, 2005, at 2:20 PM, Ken Laskey wrote:
I had intended for it to speak to both the technical and business/ policy elements that all need to be aligned. It does us no good to
agree on price if there is no way for us to exchange the money.
(Recent questions about doing business in China.) The eventual
invocation occurs in the environment and under the conditions
defined by the EC, but the EC is the product of all the
interactions that lead up to the final alignment. In fact, one can
think of a default EC skeleton that support the first contacts and
grows to sufficiency through the subsequent interactions.
Does this get to what you are talking about?
Ken
At 04:45 PM 12/6/2005, Frank McCabe wrote:
Ken:
I think that the execution context is the set of infrastructure
blah blah that enables interaction itself. It is not enough to talk
about deciding whether to interact or not here -- it is the actual
interaction that is supported by the EC.
Frank
On Dec 4, 2005, at 10:32 PM, Ken Laskey wrote:
In reading v10, I don't believe the current discussion of execution
context is clear and being this is something new we are trying to
explain, I offer below some alternate words, especially for lines
623-630. I figured I'd run it by the editors first to see if we
could come to a consensus among those who have previously discussed
the concept rather than starting the discussion in a room of people
with little if any context.
<suggested>
The execution context of a service interaction is a set of
infrastructure elements, process entities and policy assertions and
a collection of agreements and coordination of conditions, the
result of which enables service consumers and service providers to
establish the appropriateness and explicit mechanisms for the
invocation of a service. As noted in Section 3.2.2, a service
description includes how to use a service, what conditions must be
satisfied to use the service, and what effects will result from
using the service. However, the service consumer has a
corresponding description of the needs which are to be satisfied,
the conditions under which the consumer is willing to have a
service satisfy those needs, and expectations on the effects of
using the service. Visibility alerts the service consumer and
service provider that an interaction may have value, but a matching
of consumer and provider descriptions, policies, and constraints is
necessary for service use to be desired, allowed, and enabled to
occur.
The consumer and provider can be envisioned as separate places on a
map and, for a service to actually be invoked, a path must be
established between those two places. This path is the execution
context. As with a path between places, it can be a temporary
connection (e.g. a tenuous footbridge of a very limited agreement)
or a well-defined coordination (e.g. a super highway) that can be
easily reused in the future.
Note, there may be third parties, for example, government
regulators, who set some of the conditions for the execution
context, but this merely increases the conditions and constraints
needing to be coordinated and may require additional information
exchange to complete the execution context.
The execution context is central to many aspects of a service
interaction. It defines, for example, the decision point for any
policy enforcement relating to the service interaction. Note that a
policy decision point is not necessarily the same as an enforcement
point: an execution context is not by itself something that lends
itself to enforcement. On the other hand, any enforcement mechanism
of a policy is likely to take into account the particulars of the
actual service interaction.
The execution context is likely distinct for a specific service and
prospective consumer. Different instances of the same service
denoting interactions between a given service provider and
different service consumers for example are distinguished by
virtue of the fact that their execution contexts are different.
Finally, the execution context is also the context in which the
interpretation of data that is exchanged takes place it is where
the symbol grounding happens as it were. A particular string has a
particular meaning in a service interaction in a particular context
the execution context.
</suggested>
Note, this is just the result of my reading and I did not check to
see whether others have submitted issues on this section.
Ken
---
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--
---------------------------------------------------------------------- -----------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA
22102-7508 /
---------------------------------------------------------------------- ------------
--
---------------------------------------------------------------------------------
/ Ken Laskey \
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax: 703-983-1379 |
\ McLean VA 22102-7508 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]