W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

D-AC004.3 discussion points

From: Christopher Ferris <chris.ferris@sun.com>
Date: Wed, 08 May 2002 09:18:06 -0400
Message-ID: <3CD9258E.9020504@sun.com>
To: wsawg public <www-ws-arch@w3.org>
ATT: not clear what the critical success factor is.

HP: "Focus..."

This is phrased neither as a CSF nor a requirement.

MITRE: I guess I'm having some trouble understanding the difference between "relationships between
components" and components being defined interms of "interfaces".  I can see "interfaces" being like
a layer 2 (OSI) data link protocol or even a transport (layer 4), and the "relationship" being
higher layer messages and protocols.  Maybe that has too much of a network topology focus.

To use the OSI analogy, we sometimes see a 7 layer stack of boxes with vertical lines between them;
this stack lives in a single end-system.  We also see diagrams showing two end systems (each with a
7 layer stack), and horizontal lines between adjacent layers to reprenent peer-to-peer protocols.
Sometimes the vertical lines are considered "interfaces".

I envision multiple views of the web services architecture: some that represent the components of
the architecture than live within an end-system or intermediary, and other views that show
connections between like architectural components in two or more machines (similar to the horizontal
P2P lines in OSI diagrams).  It may be an end-system publishing to a registry, not necessarily P2P.

Anyway, getting into protocols and messages transmitted among interfaces sounds a little too
concrete for an architecture document.

Maybe using the term "interactions" instead of "protocol" and the term "information exchanges"
instead of "messages" would help set this in the proper abstraction level.  A WG would convert the
interactions into particular protocols sequences, and would map information exchanges into messages.

SOAP 1.2 introduces the "Message Exchange Pattern" (MEP).  Perhaps the architecture would deal with
certain MEPs.  Then, as in SOAP 1.2 Part 2, the MEP can be cast onto a particular binding.

NOK: This is a good goal. However, I do not see strong relevance to
programming models, modes of communication, or even platform independence.
Received on Wednesday, 8 May 2002 09:20:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:56 UTC