On bundling headers with messages

I'm concerned about packaging both header entries and application 
messages in the same XML document, and I'm looking for someone to allay 
my concern.  It seems that a bit of a predicament arises when all of 
the following conditions hold:

(1) The protocol riding on SOAP is asynchronous.

(2) A header entry identifies the reply-to address.

(3) The message body contains XML that is not wellformed.

(4) The XML parser on which the SOAP engine is based does not emit 
partial information for documents that are not wellformed.

How does the server receiving the non-wellformed document report the 
wellformedness problem to the SOAP client?  If the header is also 
responsible for identifying the originator, how does the server track 
client errors?  When such an error occurs, the server has valuable 
information that should be communicated to the client and perhaps 
logged by both client and server.  I'm sure many other header entries 
will pose similar problems.

I expect that many non-wellformed documents will pass over SOAP 
protocols, especially during the development phases of 
projects.  Developers would greatly appreciate the error localization 
feedback.  Non-wellformed documents will also pass through production 
systems, although much less frequently.  When they pass through 
production systems, it will be extremely important to quickly identify, 
isolate, and correct the problem.  Reporting wellformed errors would be 
such a huge plus that I'd hope it would be universally doable through 
SOAP, if not actually a requirement of SOAP.

One solution to the problem is to require that any transport receiving 
a SOAP message test the message for wellformedness before acknowledging 
the message.  If the message is not wellformed, the server knows 
exactly who to inform.  But the introductory paragraphs of section 6, 
"Using SOAP in HTTP," seems to suggest that an intermediate HTTP server 
need not do anything with the SOAP message.  Unless I'm missing 
something (which is quite likely), if an intermediate HTTP server 
forwards the message to another server, I'd think that the originating 
address would be lost.  In asynchronous protocols, we are likely 
reliant on a reply-to header entry, which the receiving parser may not surface.

Another solution is to use a sufficiently capable XML parser.  Is it 
reasonable for SOAP to create pressure for XML parsers to have certain 
features?

I'm also trying to make sense about what SOAP itself says about the 
handling of non-wellformed XML.  Section 4.4.1, "Fault Codes," says 
that the Client fault code is to be used, among other things, to report 
an "incorrectly formed" message.  Is this intended to include 
non-wellformed XML?  Is this considered to be a "SOAP error?"  Section 
6.2, "SOAP HTTP Response," says that a SOAP server must send a fault 
message in the case of a SOAP error.  If SOAP servers are required to 
deliver fault messages on wellformedness errors, even in asynchronous 
protocols, we have SOAP imposing requirements on XML parsers.

Okay, what am I missing?  How do we deal with this situation?  Thanks!!

--
Joe Lapp
Principal Architect
webMethods, Inc.
http://www.webMethods.com

Received on Friday, 7 July 2000 18:29:37 UTC