As you mentioned, a policy usually does not cover the entire contract, but
I personally don't like the idea of a "policy" turning into a contract.
I view a policy to be a set of conditions a consumer and provider brings to
a "table" to negotiate on the terms of a contract. We usually don't
negotiate
to change the other's policy, we use policy to negotiate on the contract.
Consequently, terms of a contract may end up being different on each
negotiation, but a policy usually remains the same across several
negotiations.
Additionally in my view, an ESB acts as a "intermediary" between a consumer
and a provider.
H.Ozawa
Dennis Djenfer wrote:
> Steve,
>
> I would like to add a comment to my first response to your answer. I
> like your "simplistic" way of discriminating between a policy and a
> contract, however I don't see that a policy on its own can turn into a
> contract. Before something can turn into a contract there must be
> enough information to make a successfull interaction between the
> parties, hence a policy is only a part of a whole that will turn into
> a contract when the actual interaction occurs.
>
> I think that an exemple of something that could turn into a contract
> when the interaction occurs is a WSDL-file together with adequate
> assertions (policies).
>
> // Dennis Djenfer
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
