On Wednesday, October 2, 2002, at 08:31  AM, Cutler, Roger
(RogerCutler) wrote:


<excerpt>OK, I can buy the idea of looking toward the future.  Here
are some thoughts

that use this diagram as a starting point.

</excerpt>

I am happy to engage on this.


<excerpt>

1 - I think that SOAP belongs in the right column, not the left, and
that it

deserves another row.  I believe that row might be something like:

</excerpt>

The motivation for the columns was the classical operations/data
split. On that basis, SOAP can be interpreted both ways: as an
on-the-wire format for messaging and as a way of denoting APIs. I
leave it to others to decide which is the `real' view.


<excerpt>

Message Transmission    ........    SOAP, GET, Reliable Messaging

</excerpt>

+1



<excerpt>

The next row up might then be


Service Description     ........    WSDL, natural language

</excerpt>

Perhaps Service Description (at the level of WSDL anyway) is a
specification of an operational element and SOAP is a protocol.


<excerpt>

2 - I think that the right column might more usefully be labelled

"protocols" than "meta-data".  Perhaps the left row is "Service
Description"

or "Service Category"?

</excerpt>

There might be a place for an additional column, but descriptions and
data formats are not the same thing as protocols. Data is transmitted,
protocols are the rules of the game; this does get difficult to keep a
hold of when the rules of the game require sending a string with HTTP
1.0 GET at the front of it :-)


(Aside: another, more abstract/obscure kind of vertical line could be
drawn as the object-level/meta-level distinction. This could be what
is really going on; I need a little more time to consider that.)



<excerpt>

3 - UDDI should appear somewhere in the right column, I'm not quite
sure

where.  Possibly on the top row, which is very interesting because it
seems

to indicate that there is a need for something, currently undefined,
between

UDDI and choreography.  Actually, I think that this might be a pretty
useful

insight.

</excerpt>

UDDI is a mechanism and IMO belongs on the operational side: it is a
means of publishing and discovering. Its real thrust (again IMO) is
that it represents a <italic><fixed>mechanism</fixed></italic> whereby
automatic parties can find each other. I too was somewhat surprised
when I realized that UDDI was a top-row element: the lesson being that
being `higher' up does not automatically require it to be more complex
or `smarter'.


BTW I appreciate your engagement in this conversation; I do not
pretend to have all the answers. (As I tell my 6 yr old son, no-one
knows everything, not even everyone in the world altogether know
everything.)


Frank