Re: Quick Survey - Use SOAP

        From: "S. Mike Dierken" <mike@knownow.com>
        To: <xml-dist-app@w3.org>
        Date: Fri, 29 Sep 2000 10:42:34 -0700
        Subject: Quick Survey - Use SOAP

        ...

        [1] - synchronous request/response generic XML

This is essential for standard client/server stuff, but it would also
be good to have tagged responses so they can be out of order or be
returned piecemeal.  Think about the types of flexibility observed in
LDAP, for example.

        [3] - synchronous request/response RPC method calls

I'm interested in infocentric/document-centric models whereby
different applications are created by rebinding the methods used to
interpret XML application data.  For such frameworks, the requested
"procedures" are really more like package assertions (that indirectly
specify tag-method symbol tables) rather than direct RPC calls.

This style leads to a more "semantic" web than you tend to get by
thinking in terms of RPC (analogous perhaps to logical vs. physical
HTML markup).  The caller doesn't presume to know how the callee
implements the application -- they only agree on their understanding
of the document structure (DTD/schema) and the semantics of the
selected package.  Interpreting the same data in a different package
can produce dramatically different results.  Document (information)
reuse is emphasized as much as program reuse in this paradigm.

Infocentrism can use general support for various types of C/S negotiation
(package capabilities, document versioning, etc.), for package selection,
and possibly even for overriding/modifying some of the bindings.

It is unclear whether I should care whether this support is designed
into a generic XML system with an interpreter wrapped around it (which
is necessary the interpreting the application data anyway), or whether
it should be expressed in a generic set of RPC method calls that
directly invoke exposed portions of the interpreter.  My
current system simply expresses all data -- meta-data, application
data, and even the protocol itself -- in XML.  Clients and servers just
open up reciprocal XML documents and write their requests/responses
into them in fairly high-level, descriptive terms.  (I understand
that other protocol layers such as HTTP or SMTP would penetrate
firewalls more handily -- for better or worse.)

        [2] - asynchronous message to a queue (single consumer)

Would be good for logging applications.

        [2] - asynchronous message to a topic (multiple subscribers)

Could build publish-subscribe event services out of this.

        [?] - other - describe

Suppose you want to use an XML protocol as a SIP-like control channel
for data in another fundamentally non-XML protocol, such as a
streaming media protocol.  Has there been any thought as to extensible
methods for referencing data (e.g., timecode/frames in a stream) and
even managing protocol operations (e.g., start, stop, rewind, seek,
etc.) in another protocol?  What XML protocol capabilities might be
implied?  Could this also address some of the recent issues regarding
binary data?


Mark A. Jones
AT&T Labs - Research
Shannon Laboratory
Room A201
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 360-8970

Received on Friday, 29 September 2000 16:35:17 UTC