OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded


Michael:

On May 3, 2007, at 1:25 PM, michael.poulin@uk.fid-intl.com wrote:

> Danny, thank you for the detailed explanation.
>
> I do buy into measurable rules or measurable statements instead of  
> executable statements. What still have problem with is the  
> proposition. In the Policy or in the Contract nothing is proposed,  
> the statements are either enforced or agree-and-enforced. Probably,  
> the problem is with the word-name rather than with the entity in  
> the diagram.

Proposition is a technical term that denotes a logical formula.  
Technically, a proposition is a formula written in a language which  
has a interpretation ....

We simplified the terminology to proposition = expression that has a  
truth value.

>
> I can see that an SLA relates to the Service Description but  
> appears in the real world experience via Contract. This is why I  
> put it into the diagram.
>
> As you said, "To do business, a person signs contracts", and I add  
> that person also accepts the Policy, if s/he wants to do business;  
> this is the implicit contract with or without legal recourses. I  
> think, this legal aspect is not a part of the RM. In your example,  
> if a person enters the shop and violates its policy, the person may  
> be not served - no service communication (this may be not a case in  
> the US but I have learned - it is in Europe).

We distinguished agreements from policies in part due to the massive  
confusion that exists around policies. So, we have:

A [policy] constraint is an enforced condition. The condition is a  
proposition, and enforcement is critical. (Unenforced constraints are  
wishes, not policies or anything else.)

A policy is a constraint that is 'owned' by a principal. **Policies  
do not require agreement; they only require enforcement.** This is a  
critically important aspect of policies.

An agreement/contract is a constraint willingly entered into by two  
or more participants.

 From an IT perspective, once you have a constraint, enforcing it may  
(or may not) be any different for policies or for agreements. Where  
it would potentially make a difference is in conflict resolution; or  
in deciding what the appropriate constraints are at a particular  
juncture.

Note that other than two key properties: measurability and  
enforceability, we make no further conditions on the language used to  
express policies and contracts. This is in sharp distinction to WS- 
Policy (for example) where a very strong strong assertion is made as  
to the kind of policies that one can have.

>
> The last point: "A person may have to abide by policies that are  
> not part of a contract" - this is exactly the reason why I  
> mentioned implicit contract. If a person is 'under' a Policy which  
> is not agreed in the contract, this policy is irrelevant to the  
> communication; why the RM should care about such Policy? In other  
> words, if a client and a service provider communicate via a service  
> - there is an explicit or implicit agreement between them; any  
> other policy (internal or external; for client or for provider)  
> that is not in the contract - unrelates to the RM.

Agreement may be explicit or implicit. It is still an agreement. In  
fact, if you stare hard enough at it, it can be hard to distinguish  
implicit and explicit agreements.

Frank


>
> - Michael



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]