+1 to Jean-Jacques's reply. The SOAP headers are a general
extensibility and modularity mechanism just as suitable for modularly
constructed applications as for use by the "messaging" layer. Indeed,
until general standards for security, reliability, asynchronous
messaging, conversations, etc. are in place, these are all being
currently handled at the application level, often using SOAP headers.
My feeling is that this is analogous to programming language
libraries. Common, useful functionality is eventually standardized
into widely supported standard libraries so that each application does
not have to re-invent such things, so that code will be more portable,
etc. Application-specific libraries are also often a useful thing,
too.
--mark
Mark A. Jones
AT&T Labs -- Strategic Standards Division
Shannon Laboratory
Room 2A02
180 Park Ave.
Florham Park, NJ 07932-0971
email: [email protected]
phone: (973) 360-8326
fax: (973) 236-6453
From [email protected] Mon Feb 17 03:17 EST 2003
Delivered-To: [email protected]
X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to [email protected] using -f
Resent-Date: Mon, 17 Feb 2003 03:16:55 -0500 (EST)
Resent-Message-Id: <[email protected]>
X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to <[email protected]> using -f
Date: Mon, 17 Feb 2003 09:15:57 +0100
From: "Jean-Jacques Moreau" <[email protected]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Cutler Roger (RogerCutler)" <[email protected]>
Cc: [email protected]
Content-Transfer-Encoding: 7bit
Subject: Applications are allowed to process SOAP header blocks (was: Messaging Service Layer)
X-Archived-At: http://www.w3.org/mid/[email protected]
Resent-From: [email protected]
X-Mailing-List: <[email protected]> archive/latest/4354
X-Loop: [email protected]
Resent-Sender: [email protected]
List-Id: <www-ws-arch.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
X-Spam-Status: No, hits=-3.5 required=5.0
tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,
SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA,
X_ACCEPT_LANG,X_AUTH_WARNING,X_LOOP,X_MAILING_LIST
version=2.43-cvs
X-Spam-Level:
I have to disagree. There is nothing in the SOAP specification
that indicates that header blocks are to be processed only by the
messaging layer and not by the application. The SOAP
specification is mute on that aspect and is only concerned with
what happens at a given (SOAP) node, independently of what layer
performs the processing. Quoting section 2.6, Processing SOAP
Messages:
<quote>
Process all mandatory SOAP header blocks targeted at the node
and, in the case of an ultimate SOAP receiver, the SOAP body. A
SOAP node MAY also choose to process non-mandatory SOAP header
blocks targeted at it.
</quote>
Jean-Jacques.
[1]
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#procsoapmsgs
Cutler, Roger (RogerCutler) wrote:
> The messaging layer is in charge of what
> is in the SOAP headers, whereas the application layer is responsible for
> the body. More specifically, the messaging layer might mess around with
> the body by doing things like encrypting it, but after decryption the
> messaging layer would hand the body to the application layer of the
> receiver exactly as the body was given to it by the sender. The
> messaging layer has no business changing the data in the body -- as far
> as it is concerned the body is just bits or characters. And I think
> that it also has no business trying to analyze the contents of the data
> in the body.
>
> If you agree with the preceding statements I think it may have
> consequences down the line that are non-trivial. The last statement may
> be a bit strong, but that's the way it seems to me other layers work.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.