W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Processing which is not triggered by blocks?

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 21 Jul 2001 11:22:40 -0700
To: Glen Daniels <gdaniels@macromedia.com>
Cc: xml-dist-app@w3.org
Message-ID: <20010721112236.A1491@mnot.net>

Definately. Such nodes aren't targetted as SOAP intermediaries
(instead using mechanisms out-of-message to determine targetting),
but they can still process messages. As such, they aren't SOAP
intermediaries, but they still may perform SOAP processing.

You bring up a good point, in that we need to assure that faults and
other mechanisms that touch such intermediaries can still
interoperate correctly.

For example:

Akamai might have a customer which wishes to direct SOAP messages
through our network, to add services (caching, non-repudiation,
whatever). However, they don't want to specifically call out the
Akamai intermediary in messages from the client; perhaps they want
the flexibility to swap us out, or they don't want it to be known
that they're using us, or there's other information they don't want
the client to see.

So, they can manipulate their DNS records for the SOAP server to
point (and therefore route) to our servers, without changing the
client implementations. Furthermore, we can use our own, out-of-band
metadata to determine when to apply processing.


On Sat, Jul 21, 2001 at 02:01:52AM -0400, Glen Daniels wrote:
> In a conversation today (well, yesterday :)) the following issue came up,
> which I would appreciate the group's input on.
> Is it possible for a node (say an intermediary) to perform
> processing on a SOAP message purely as a result of receiving the
> message, and not because any particular blocks in the message are
> targeted at that node?
> For instance, I can imagine a digital signature intermediary whose
> job is simply to sign any message it receives and forward it, with
> an extra trailer block containing the signature, to a fixed
> endpoint for which it acts as a proxy.  Although our model for this
> sort of thing has traditionally contained a header block targeted
> at the intermediary to trigger this processing, it seems to me that
> there may be nothing which actually requires such a block.
> This would also make the case for the "fault on mustUnderstand
> blocks which are targeted elsewhere" easier to explain, since the
> endpoint could simply perform this (or any other custom) processing
> as a part of its standard way of dealing with messages.
> So, what do you think?  Is it OK for a processor/node to do work
> without explicitly being told to do so by a block?  And if we think
> it is, should we call that out in the processing model?
> --Glen

Mark Nottingham
Received on Saturday, 21 July 2001 14:22:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC