Re: Processing which is not triggered by blocks?

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.

Cheers,



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
http://www.mnot.net/

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