Re: Line between interface and implementation

Since you folks are talking about contracts I feel moved to intervene:

On Tuesday, October 22, 2002, at 10:03  AM, Assaf Arkin wrote:

>
> Paul,
>
> I'm very flattered that you name a principle after me. This should go 
> down
> in history ;-)

Right on brother!

>
> However, I would like to suggest an alternative priniciple, call it the
> 'value chain' principle, along the following lines:
>
> Given a choreography between SERVICES 1 through N (where N >= 2)
>
> Given a contract expressed in a choreography language called CONTRACT
>
> Given CONTRACT expresses a constraint/condition/sequence called 
> CONSTRAINT

Contracts are about more than messages; in fact they are about a lot 
more than messages. Messages are only the communications medium.

>
> Given any two services I and J, such that I in N, J in N and I is not J
>
> CONSTRAINT is part of the public interface between SERVICE I and 
> SERVICE J
> if it is possible to observe whether the constraint has been upheld or
> violated in the packets on the wire between I or J and any other 
> service in
> the CHOREOGRAPHY

This is only ONE of the potential uses for explicit contracts. Another, 
equally important (IMO) use is in discovery. SLAs -a.k.a. contracts, 
are also used to determine if a given service might meet the 
requirements of the customer. E.g., two different telephone companies 
may describe their current pricing/bandwidth as SLAs in a declarative 
way; a customer can then use these to determine which company to 
`invoke'. This is the `problem solving' use of contracts. Another use 
of the contract notion is in policy consistency computations (important 
in system security).


>
> This should be reworded accurately so it is recusive. That is, if J 
> talks to
> K and K talks to M, and I can prove that J upheld of violated the 
> constraint
> by talking to M, we can show that interaction encompassing I, J, K and 
> M.
> There may be other messages exchanged between I, J, K and M that do not
> prove any constraint for I and are not shown.

There is an extremely hard issue in here. Showing that a contract has 
been violated can be shown -- under general conditions -- to be 
equivalent to the halting problem. Generally, going from a procedural 
model to a declarative model is very hard; on the other hand, going 
from a declarative to a procedural interpretation is much easier. I.e., 
one can show that a software agent (of any description) is fulfilling 
its contracts when they are about declarative propositions more easily 
than when the contract is in the form of a program.

Frank McCabe