In the future, some types of interactions on the Web will use soap/XML, not
the current techniques:
1. W3C is moving toward a model where Forms submit XML (rather than URL
encoding with Get or name value pairs in a POST as at present). With W3C
XForms, it is likely the XML will be submitted in a SOAP message. In that
case the input for a form that currently comes either url encoded or through
a POST, would come using an HTTP POST with XML form data. An Intermediary
that deals with those form submissions must be at least minimally XML aware.
2. W3C XML Query will provide an SQL level of database Query on XML files
and databases. It's still early in development, but a reasonable
expectation would be that a query could be sent in a SOAP message. Again,
there are consequences for an intermediary that would be involved in
queries.
3. Web Services. SOAP looks to be the basis of future Web Services. A
mobile phone requesting information about what's playing at nearby theaters
is likely to be a SOAP message. Intermiaries involved in web services would
need at least a minimal level of XML parsing.
Where SOAP may be useful in OPES:
1. Sending control messages to the OPES controller (defining new rules).
2. In rules, so a rule could result in sending a SOAP message. (for sending
a predefined message in response to an http request, the opes controller
would need very little understanding of xml or soap.)
3. Receiving SOAP messages from future browsers as noted above and allowing
an Intermediary to transform them. e.g. turn simple format received from
mobile phone into fuller format end service expects, fill in user
preferences for fields.
4. To send a message from the OPES controller to an OPES device requesting
that it to perform some action (like getting the data, doing something to it
and passing the data on to another intermediary in the chain).
**************************
Wayne J. Carr
wayne(_dot_)carr(_at_)intel(_dot_)com
ICL Network Edge Team
Intel Architecture Labs
**************************