SOAP 1.2 types of intermediaries

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 Friday, 27 September 2002 16:11:23 UTC