Michael,
The example of RAM is hard to relate because it is really independent of the software vendor: they supply the software and if you are satisfied with running under ½ GB, that’s your business and not theirs.
Indeed, either "when the consumer... accepts those conditions" = agrees with those conditions or the consumer doesn’t care enough to require something else.
Ken
I think that understanding and agreeing are different things. I can read teh conditions in which a product A is running the best, e.g. recommended RAM is 1 G, but it does not mean I ageree to use it on 1 G and I install it on RAN of 0.5 G, and it works.
So, it seems that when RM mentioned 'agreements' it was about agreement on semantics, i.e. understanding of the EC description (it is silly of me to tell you what RM did meant...).
Also, "when the consumer... accepts those conditions" != agrees with those conditions.
Go back to the RM. It definitely states agreements. A service description can point to a default set of conditions, e.g. policies, semantics, response time, but the EC is when the consumer, even if just a click-through, accepts those conditions. How this is all done in general is an art form to be developed. However, we want to make sure that we don’t lose through coupling of policy agreements what we hopefully gained in a looser technical coupling.
---------------------------------------------------------------------------
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
To me, it seems we are talking two (at least) different things.
Understanding of the policy (assuming agreement on the ontology and semantics) has nothing to do with agreement with the policy. When a service provider issues a service, this service is supposed to work as announced in particular EC. At this time, the provider does not ask any consumer to agree with the EC. Moreover, consumers when read Service Description and learn about referred EC may or may not agree with it - this is not about agreement but about information. This is why the consumer can/may use the service in different EC than the one announced in the service description.
EC exists, IMO, outside of the service and service description (but referred in the latter). EC is not the set of policies enforced by the service provider on the consumer with regard to interaction; EC is the environment characteristics expressed via policies. To me, saying that "this collection of agreements ... establish the execution context" is very confusing.
No, we always said EC was all of these agreement, not just policies This is explicit in the RM. If I typically use vocabulary A and you typically use vocabulary B, we better have an agreement to use A or B or agree what exists that we will use to mediate between them. Otherwise, all the policy agreements will go nowhere is we can understand the messages we exchange.
---------------------------------------------------------------------------
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
I am afraid, this is another pearl in the text:
4.1.2.1.3 Service Description, Execution Context, and Service
2019 The service description MUST provide sufficient information to support service visibility,
2020 including the willingness of service participants to interact. However, the corresponding
2021 descriptions for providers and consumers may both contain policies, technical
2022 assumptions, constraints on semantics, and other technical and procedural conditions
2023 that must be aligned to define the terms of willingness. The agreements which
2024 encapsulate the necessary alignment form the basis upon which interactions may
2025 proceed – in the Reference Model, this collection of agreements and the necessary
2026 environmental support establish the execution context.
Since when Execution Context became agreed with service consumer? We used to say that EC is a set of policies, and the latter are non-agreeable entities.