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

Re: SOAP 1.2 types of intermediaries

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Tue, 01 Oct 2002 15:47:52 +0200
Message-ID: <3D99A788.5050401@crf.canon.fr>
To: Heather Kreger <kreger@us.ibm.com>
CC: www-ws-arch@w3.org

It may be worth also pointing that SOAP intermediaries are subjet 
to the SOAP processing model. As such, and before any forwarding, 
they must first obtain and process the header blocks targetted to 
them. If they find a mandatory (mustUnderstand="true") header 
block that they do not understand, or if processing fails, no 
further processing is performed and the message is not relayed to 
the next receiver. A fault is generated and may eventually be 
sent back to the initial sender.

Further details in Section 2.6[1]; but in general the whole of 
section 2[2] is worth reading.


[1] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs
[2] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#msgexchngmdl

Heather Kreger wrote:
> I thought Colleen pulled togather a good summary of the SOAP 1.2
> intermediaries
> (She did this for the MTF work)
> Heather Kreger
> Web Services Lead Architect
> STSM, SWG Emerging Technology
> kreger@us.ibm.com
> 919-543-3211 (t/l 441)  cell:919-496-9572
> ---------------------- Forwarded by Heather Kreger/Raleigh/IBM on
> 09/27/2002 04:07 PM ---------------------------
> Colleen Evans <cevans@sonicsoftware.com> on 09/24/2002 05:24:25 PM
> To:    Heather Kreger/Raleigh/IBM@IBMUS, Prasad Yendluri
>        <pyendluri@webmethods.com>, Zulah Eckert <zulah_eckert@hp.com>, Jim
>        Willits <jim.willits@hp.com>, Hao he <hao.he@thomson.com.com>,
>        Yin-Leng Husband <Yin-leng.Husband@hp.com>, Igor Sedukhin
>        <igor.sedukhin@ca.com>, "k. schopmeyer"
>        <k.schopmeyer@opengroup.org>, Sandeep Kumar <sandkuma@cisco.com>
> cc:
> Subject:    SOAP 1.2 types of intermediaries
> On today's call I took an AI to get details on intermediaries as defined in
> SOAP 1.2.  Below is the excerpt from the LC draft.  It seems that the
> management aspects between these may vary, but perhaps I'm wrong and we
> only need a basic SOAP node view, without distinguishing between SOAP
> sender, SOAP receiver, or the two kinds of SOAP intermediaries.
> (SOAP 1.2, part 1, section 2.7 -
> http://www.w3.org/TR/2002/WD-soap12-part1-20020626/)
> "SOAP defines two different types of intermediaries: forwarding
> intermediaries and active intermediaries. These two types of intermediary
> are described below.
> 2.7.1 Forwarding Intermediaries
> The semantics of one or more SOAP header blocks in a SOAP message, or the
> SOAP MEP used MAY require that the SOAP message be forwarded to another
> SOAP node on behalf of the initiator of the inbound SOAP message. In this
> case, the processing SOAP node acts in the role of a SOAP forwarding
> intermediary.
> Forwarding intermediaries MUST process the message according to the SOAP
> processing model defined in 2.6 Processing SOAP Messages. They MUST also
> remove from the message all SOAP header blocks targeted at themselves,
> prior to forwarding, regardless of whether these header blocks were
> processed or ignored.
> In addition, forwarding intermediaries MUST also obey the specification for
> the SOAP forwarding feature being used. The specification for such a
> feature MUST describe the required semantics, including the rules
> describing how the forwarded message is constructed. Such rules MAY
> describe placement of inserted or reinserted SOAP header blocks. Inserted
> SOAP header blocks might be indistinguishable from one or more of the
> header blocks removed above. Re-inserting processed SOAP header blocks in
> this manner effectively leaves them in place, but emphasizes the need to
> process them at each SOAP node along the SOAP message path.
> 2.7.2 Active Intermediaries
> In addition to the processing performed by forwarding intermediaries,
> active intermediaries undertake additional processing that can modify the
> outbound message in ways not described in the inbound message. That is,
> they can undertake processing not described by SOAP header blocks in the
> incoming message. The potential set of services provided by an active
> intermediary includes, but is not limited to: security services, annotation
> services, and content manipulation services.
> The results of such active processing could impact the interpretation of
> messages by downstream nodes. For example, as part of generating an
> outbound message, an active intermediary might have removed and encrypted
> some or all of the SOAP header blocks found in the inbound message. It is
> strongly recommended that features provided by active intermediaries be
> described in a manner that allows such modifications to be detected by
> affected SOAP nodes in the message path.
> One mechanism by which an active intermediary can describe the
> modifications performed on a message is by inserting header blocks into the
> outbound SOAP message. These header blocks can inform downstream SOAP nodes
> acting in roles whose correct operation depends on receiving such
> notification. In this case, the semantics of such inserted header blocks
> should also call for either the same or other header blocks to be
> (re)inserted at subsequent intermediaries as necessary to ensure that the
> message can be safely processed by nodes yet further downstream. For
> example, if a message with header blocks removed for encryption passes
> through a second intermediary (without the original header blocks being
> decrypted and reconstructed), then indication that the encryption has
> occurred must be retained in the second relayed message."
Received on Tuesday, 1 October 2002 09:47:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:41 UTC