RE: Line between interface and implementation

Paul,

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

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

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 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.

For the specific example given in WSCI, the traveller can determine if the
travel agent has upheld or violated the constraint by interacting directly
with the airline. The travel agent agrees to expose its interaction with the
airline, because the traveller can prove whether the constraint has been
upheld or violate by interacting with the airline through a message exchange
that is defined as part of that choreography.

The travel agent exchanges other messages with the airline, however, these
do not reflect directly on the interaction between the traveller and the
airline, hence are not shown in the choreography.

Even more specifically to this principle and example, the traveller knows at
what point it can strive to prove if the constraint has been upheld or
violated, because it knows the logical sequence of events that occur between
all three parties. There is no point in asking the airline for a copy of the
airline ticket before the travel agent has ordered it from the airline. But
it is possible to prove that the travel agent is a fraud by asking the
airline to furnish a copy of the ticket after the travel agent has
supposedly ordered it, as marked by the event of the travel agent returning
a copy of the ticket to the traveller.


One important addition to the 'value chain' principle is:

- A value chain is defined collaboratively by multiple participants in the
choreography, and the choreography occurs as the result of the collaborative
execution of services performed by all the participants.

This makes it very clear that the question her is not 'what would the travel
agent expose?'. On its own, the travel agent is not a value chain. It would
only expose an interface covering it and its customer. This is allowed and
perfectly acceptable.

What we see in this example is a representative of travellers,
representative of travel agents, and representative of airlines (a value
chain), all sitting together and coming up with a choreography that defined
how their services will all work together.

A value chain (and choreography) can consist of two participants, but it can
also consist of more than two participants.

The value chain does not define how each service is executed, only how it is
performed within the larger choreography. I make a conscious distinction
between the term execute (the 'implementation') and the term perform (the
'interface').


My company is indeed in the space of business processes, so we get to speak
to business users on a daily basis and capture their requirements. Two
requirements we have are:

* Capture the way in which any one participant implements its process such
that it can be executed repeatedly to completion. This is where we need a
computational complete execution language.

* Capture the way in which any two or more participants collaborate together
through the exchange of messages over, such that each participant can
understand its constraints to participate in the collaboration, and all
participants understand the result of the collaboration. This is where we
need a constraint language that allows multiple implementations to exist (an
interface) and allows multiple interfaces to be shown in a single
composition (choreography).

Stephen White did an excellent job of capturing the differences in a
previous e-mail.

Don't hate me because businesses want to view choreographies that involve
interaction between multiple partners that all talk to each other. Help me
support their case.

arkin


Assaf Arkin wrote:
>...
>
> [AA] Rule #1 of the interface: what the customer does not care should not
be
> in the interface. WSCI does not force you to include that information in
the
> interface.

Let's call this rule Assaf's Principle. It is similar to Occam's
principle in that it lets us strip away that which is inessential.

Now let's turn it into something measurable and concrete:

Given a SERVICE and a CUSTOMER.

Given a contract expressed in a choreography language called CONTRACT.

Given CONTRACT expresses a constraint/condition/thing called CONSTRAINT.

CONSTRAINT is part of the public interface between CUSTOMER and SERVICE
if and only if it is possible to observe whether constraint has been
upheld or violated in the packets on the wire between CUSTOMER and SERVICE.

I claim that that's the long form of Assaf's principle. So the fact that
the travel agent confirms seats on the airline one leg at a time is
demonstrably not part of the customer interface because the customer
_cannot observe_ whether they do this or not in any data on the wire.

Now this is just the start, but it is an easy, clear starting point. The
harder question is to determine what _should be_ in the interface and
what needs to be declared at design time versus discovered at runtime.
But it would be positive forward progress if we could agree that if
there is _no way_ for a client to know whether a constraint has been
followed or not, then that constraint is NOT relevant to that client and
should therefore not be exposed to them (Rule #1).

>...
> Think value chain processes. Choreographies involving multiple
participants,
> where the relation between the activities performed by all the
participants
> are explicitly modeled. Check out your favorite book about supply chain
> management for some examples.

A supply chain is an _implementation_ of a process.

> No, internal operations are not shown. When a particular participant talks
> to their SAP or Oracle, that is not exposed in the choreography. But the
> model of the value chain often depicts how participant A sends a message
to
> B, and B sends a message to C before coming back with a reply to A. Some
> business user think that information is important. I prefer to fulfill the
> requirement of my customers.
>...

Your company is a business process management company. Of course your
customers come to you for implementations of business proceses. The same
goes for BEA et. al. That doesn't mean that there is no difference
between interface and implementation. It means that it is your job to
help your customers distinguish between them.

  Paul Prescod

Received on Tuesday, 22 October 2002 13:03:01 UTC