[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: v98b formal ballot comments
Chris,
In my comments, I equate "SOAP application" with "SOAP Processor". I
envision a 'generic' SOAP application/processor that will parse the SOAP
Header. This generic processor will maintain knowledge of the Namespace
handlers, and will pass to these handlers their respective first level
elements. This model supports a clean interface between the SOAP
application/processor and the supporting handlers, such as the ebXML
handler.
Consider then a SOAP message constructed as follows:
SOAP:Header
ebXML:Header SOAP:mustUnderstand="1"
ebXML:Via SOAP:actor=[next] SOAP:mustUnderstand="1"
DSIG:Header SOAP:mustUnderstand="1"
ebXML:Trace SOAP:actor=[next] SOAP:mustUnderstand="1"
NOTE: For simplicity, I have ignored the ebXML:Manifest and any
other ebXML first level elements for this discussion.
A SOAP processor would identify the four first level elements and verify
that handlers exist for each, since each has mustUnderstand="1".
A SOAP processor would then dispatch some handlers. How it would do this is
not clear. Let's suppose the SOAP applicaiton/processor interface to the
handler was:
Call HandlerForNamespace(FirstLevelElement(i),MIMEBodyParts)
for i=1,4
Let's now assume that the ebXML handler was acting in the role of an
intermediary.
i=1 The ebXML handler would process the ebXML:Header element, note
that it was not the intended recipient, and return to the SOAP processor the
result.
i=2 The ebXML handler would process he ebXML Via element, act upon
the element, and return a 'next-destination' result to the SOAP processor.
Note that this invocation does not have access to the
ebXML:Header element
i=3 The DSIG Handler would process the DSIG:Header element, note that
it was not the intended recipeint, and return to the SOAP processor the
result.
i=4 The ebXML handler would process the ebXML:Trace element, act upon
the element, and return a new ebXML:Trace element to the SOAP processor
The SOAP Processor would reconstruct the SOAP message, discarding the two
'spent' elements, adding the new ebXML:Trace element. It would then invoke
lower level processes to construct the MIME envelope and transport the
message to the new destination.
In this scenario, each invocation of the ebXML handler would have implied
access to the ebXML:Header (via the first MIMEBodyPart), but there would be
three separate instantiations of the ebXML handler, and the handler fould
have to parse the entire SOAP header to locate information of interest to
it. I don't like the scenario, but I cannot fault such a SOAP Processor
implementation.
Now consider the same information, arranged as follows:
SOAP:Header
ebXML:Header SOAP:mustUnderstand="1" SOAP:actor=[next]
ebXML:Via
DSIG:Header SOAP:mustUnderstand="1"
ebXML:Trace
In this scenario, the SOAP processor makes a single dispatch, to the ebXML
handler. The ebXML handler is in control of invocation of the DSIG handler.
It has access to the entire ebXML:Header construct in a single element.
The handler processes the entire ebXML:Header message, returns a new
ebXML:Header message and new destination. The ebXML handler decides whether
to invoke the DSIG handler and if it does invoke that handler, it decides
what to do with the returned results. Of course, if the DSIG signatues had
not originated from actions of an ebXML handler in the first place, it would
have appeared in the SOAP envelope as a first level element, and been
handled independently from the ebXML header element. But based on my
understanding of the ebXML architecture, it is the ebXML handler that would
have invoked the DSIG handler (figure at line 155 of TRP spec).
As I've said, I don't really know how the SOAP architecture is expected to
process the SOAP envelope content. So the above is just conjecture on my
part based on my many years of systems design. But from the above, you
should now have a better understanding of my comments to the TRP
specification. One could integrate the SOAP processing and handlers in a
single SOAP application (I really don't like that! On the other hand, my
guess also is that this strikes nearer the truth of current SOAP
processors/applications. Has anyone actually tried putting two first level
elements for differing namespaces in a Soap message and seeing what the
receving SOAP application did with them?), or the SOAP handler could
recognize that only two handlers were required, and pass each handler the
entire message in some perdetermied invocation order. Regardeless, I
believe the organization of elements in the second scenario is preferable to
the ordering in the first scenario, and it certainly makes moot the question
of how the SOAP processor performs its tasks.
By the way, ebXML:Via looks like something that should more appropriately be
SOAP:Via, since its applicability would seem to extend beyond ebXML to other
SOAP-based applications. As it is not part of SOAP now, it has to be
ebXML:Via, but I hope we have requrested W3 consider adding it to the SOAP
wish list.
You did not comment on my argument that ebXML:Manifest should be located in
the SOAP:Header area (as it might change as it passes through
intermediaries).
You appear not to have understood my argument on positioning the
Acknowledgment and StatusData elements in the SOAP Header. My argument on
each of the ebXML elements that appear in the SOAP:Body is that they may be
intended for processing (and removal or replacement) by an intermediary.
Placing them in the SOAP:Header accomodates the use of the SOAP:Actor
attribute to enable such removal/replacement. None of the message flow
diagrams explored use of the Acknowledgement and StatusData elements in a
multi-hop environment. I relied therefore on wording of the stated
'purpose' (see lines 1074-1075 and 1118-1119) of these elements to infer
that they need not be limited only to exchange with the recipient MSH. In
an A-B-C-D MSH scenario, either A or B could request Status Data from
either/both C and/or D by appropriately using the actor attribute to
determine "who dropped the ball". I think the SOAP requirement that the
SOAP Body is mandatory so colored the discussions on placement of ebXML
elements that the usefulness of the actor attribute was overlooked.
WRT to my comment on the use of the actor attribute on Via, you state that
the team specifically avoided the issue of 'source routing'. But wait a
minute, I thought the intent of 'Via' was in fact to control routing, and
since a Via doesn't magically 'materialize' in a message after it is
received by an MSH, it must have been put there by the [source] MSH. Sounds
like that means the source is doing some routing there somehow! I would
certainly expect that a 'business model' would encompass the routing of a
message from its source, through any intermediaries required by the model to
the recipient. For example, the model might provide a routing
Sender-SendersBank-RecipientsBank-Recipient. Note that these are logical
addresses, not physical addresses. The intermediate MSH's would accept the
Via directed by their role, and would effect the translation from logical
desitination to physical destination for the next hop of the message
journey.
That seems sensible to me, and more likely than using a single [actor=next],
which fails to make full intneded business routing. Please note by the wasy
that the argument for relocating these elements within the SOAP Header is
independent of the argument to locate them specifically within the ebXML
header.
WRT to who is responsible for removing the 'spent-actor' elements, SOAP is
clear that they 'must' be removed, whereas the TRP specification says
'Recommended'.
Cheers,
Bob
-----Original Message-----
From: Chris Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, March 29, 2001 5:37 PM
To: Miller, Robert (GXS); ebxml-transport@lists.ebxml.org
Subject: Re: v98b formal ballot comments
Bob,
Thanks for the thoughtful review of the specification.
Some comments follow interspersed in the text of your
submitted comments in italics and indented.
Cheers,
Chris
Line Reference Comments
Entire Document (NOTE: Specific reference comments follow this comment)
The late-in-process introduction of the SOAP protocol layer requires more
thought be given to process flow and message organization. This
specification as currently written does not adequately address multi-hop
processing, and it locates some elements of the ebXML header information
where they are not addressable by Actor roles other than the Default Actor
role. Also, it introduces multiple first level SOAP Envelope elements
within the same Namespace and intended for processing by the same SOAP
actor. This may cause a SOAP Processor to invoke the ebXML processor
multiple times to process the single message.
My understanding of the SOAP protocol is that at each intermediate hop in a
multi-hop transmission, the entire SOAP Header (but not the SOAP Body) is
screened by a generic SOAP MSH looking for elements whose Actor attribute
match a supported Actor role of the MSH. Every intermediate MSH must support
the Actor role 'Next'.
I would expect that at least one ebXML element directed to an intermediate
ebXML MSH would be required to trigger execution of the ebXML MSH. That is,
an ebXML elemetn directed to the default actor would not trigger ebXML
processing within an intermediate MSH.
The Via element is intended to serve this purpose. Possibly, there should be
some language added that makes this more clear and that requires use of the
Via element when messages are to be processed by intermediary MSH nodes.
It is not clear to me from the SOAP specification whether the ebXML MSH
would have access to the entire SOAP envelope content, or would only have
access to the specific element directed to the ebXML MSH. The SOAP
specification does provide some instruction on this in its documentation
section 2. It states it will:
1)Identify all parts of the SOAP message intended for that application (see
section 4.2.2)
2)Verify that all mandatory parts identified in step 1 are supported by the
application for this message (see section 4.2.3) and process them
accordingly. ...
3)If the SOAP application is not the ultimate destination of the message
then remove all parts identified in step 1 before forwarding the message.
It is not clear from the above what is implied in 2) by "process them
accordingly". Mandatory parts are indicated by the mustUnderstand
attrubute.
But elements may belong to multiple Namespaces, each of which has its own
associated application.
Each of which MAY have its own associated handler.
Whether all of the elements associated with a single Namespace are to be
handled by a single invocation, or each is to be handled by a separate
invocation is not clear. Rather, the SOAP specification simply states in
the text succeeding the above list:
Processing a message or a part of a message requires that the SOAP processor
understands, among other things, the exchange pattern being used (one way,
request/response, multicast, etc.), the role of the recipient in that
pattern, the employmnet (if any) of RPC mechanisms such as the one
documented in section 7, the representation or encoding of data, as well as
other semantics necessary for correct processing.
How the SOAP processor will acquire this 'understanding' is not clear. Some
if not all of this information may be available in the ebXML TPA, but
neither this specification nor the TPA specification speaks to the need to
map this information to the [apparently implementation dependent] SOAP
interface for providing this information.
An ebXML MSH would then process those parts of the SOAP envelope that were
defined in the ebXML Namespace, and the SOAP processor would remove those
ebXML parts specifically directed to the ebXML MSH acting as an
intermediary. The ebXML MSH might add other content to the SOAP Header,
SOAP Body, or MIME Payload as it returned the message to the SOAP processor
for further processing and dispatch to the next MSH.
The SOAP Processor is not responsible for, nor identified as being the
entity that removes SOAP:Header element content that has an actor attribute
with the meaning of 'next'. From the
SOAP 1.1 W3C NOTE:
"Not all parts of a SOAP message may be intended for the ultimate
destination of the SOAP message but,
instead, may be intended for one or more of the intermediaries on
the message path. The role of a recipient of
a header element is similar to that of accepting a contract in that
it cannot be extended beyond the recipient.
That is, a recipient receiving a header element MUST NOT forward
that header element to the next application
in the SOAP message path. The recipient MAY insert a similar header
element but in that case, the contract is
between that application and the recipient of that header element."
I will grant that the language used here is a little loose as the term
'recipient' is not formally defined as being the either SOAP application or
the SOAP processor. I would interpret this statement as meaning that it is
the responsibility of the recipient SOAP application to remove the element
content that was designated to it by virtue of an actor attribute of 'next'
or of the URI of the SOAP application itself. In any event, I would be
suspect of a SOAP processor that implemented functionality to modify the
message by removing such content of the message. How would it distinguish
between the original element and a similar header element that just happened
to be identical to the original?
A SOAP envelope may include elements from multiple Namespaces. SOAP
provides little advice regarding the order in which services addressed by
such Namespaces are invoked. For this reason, this specification should
declare whether the services performed by an ebXML MSH are considered to be
independent of any services provided by another MSH. Also for this reason,
if an intermediate ebXML MSH is invoked, all ebXML constructs in the SOAP
envelope should be contained within a single ebXML element.
It is true that the SOAP specification is a little unclear as to
whether or not the element content of a SOAP Message that
belongs to a foriegn namespace w/r/t the namespace of the
declared handler for a given element is available to that
handler. However, in my experience, each processor provides
access to the "whole" message, not just the namespace
qualified content that matches the namespace of the
registered handler and the actor URI.
This assumption may be a bit broad, since I've only
direct experience with two SOAP toolkit implementations,
(Apache and IBM's TRLSOAP) but it would seem to me to
be a valid assumption with any successful implementation.
Take the example of signing or validating the signature
of a message. The handler/application processing the signature
MUST have access to all of the content over which the
signature has digested/signed. Without it, the signature is a fairly
useless thing.
I also believe that omitting an actor attribute (thus,
establishing it as destined to the ultimate destination
of the message or default actor) for the ebXML namespace
qualified content of the SOAP:Header element is appropriate
for our use.
As you noted in your comments, the Via element provides
support for intermediary MSH by use of the 'next' actor.
The intermediate MSH node will still have access to the
other content of the SOAP message, but clearly, an intermediary
will need to "know" that it is an intermediary and not an
ultimate destination. Certainly, by inspecting the To/PartyId
it can clearly discern that the message is destined for another
MSH than itself;-)
In my opinion, the integration of the SOAP protocol into the ebXML
Transport, Routing, and Packaging Specifications raises both SOAP and ebXML
issues which have neither been identified nor addressed in these two
specifications. These issues in turn prevent successful implementation of at
least some of the features defined in the specification.
I certainly concur that the adoption of SOAP by ebXML will highlight some of
the issues, known or unknown, with both SOAP and ebXML's use of SOAP.
I believe that all issues related to the use of the SOAP envelope can be
resolved, and I also believe that use of the SOAP protocol is advantageous.,
However, I doubt there is time to address all of the SOAP-related issues in
the time remaining before the May ebXML meeting.
I also concur with this comment. We can certainly endeavor to explore the
issues that you and others raise, but it is not clear that we'll have time
to address them fully, especially if they involve significant change.
I also believe that many of the issues I identify in this comment submission
can be readily addressed by packaging all ebXML elements within a single
outer level ebXML Header element, and by imbedding in this same ebXML
element those XMLDSIG elements used to provide security services for ebXML
messages.
Of this I am not so certain. Please see my ensuing comments.
If the issues raised in this comment cannot be satisfactorily addressed in
the time remaining before the May ebXML meeting, I recommend the outstanding
issues and their impact upon implementation of the specification be made
explicit in the document as it is submitted for approval.
This certainly sounds reasonable.
176, 245-246,968,972-1072
The Manifest element belongs in the SOAP Header section, not in the SOAP
body section.
Argument supporting comment:
1)Per the SOAP specification, the SOAP body is: "a container for mandatory
information intended for the ultimate recipient of the message"
2)Each ebXML message handler in the path between the sending and recipient
parties may have need to:
3)Access content referenced in the current manifest
4)Delete content from the message and manifest
5)Add content to the message and manifest
Example Usage:
An ebXML message handler for a bank might need to access the ebXML payload,
and then add to the payload a NACHA message instructing funds transfer to a
bank account at a bank used by the recipient
1)Intermediate ebXML messsage handlers are not "the ultimate recipient of
the message"
I would also like to note that multiple Manifest elements directed to the
end recipient might be an appropriate choice to address the functionality of
2)C) above. In that way, signatures over the original manifest may be
maintained, and the added manifest may be separately signed by the parties
adding content.
763
The statement: "The Via element is a SOAP Header ..." is incorrect.
The Via element is an ebXML header composite element that resides within the
SOAP Header
241-242,976
First reference says an application payload must be carried in a Payload
Container, whereas second reference says "It is RECOMMENDED that no payload
data be present in the SOAP-ENV:Body." With respect to this inconsistency,
I favor the 'RECOMMENDED" wording.
1073-1116
The StatusData Element belongs in the SOAP Header section, not in the SOAP
Body section.
Argument supporting comment:
1)1074-1075 states: "The StatusData element is used by one MSH to ..."
2)Data directed to an intermediate MSH must be located in the SOAP Header so
that it may accept the SOAP actor attribute.
1117-1173
The Acknowledgment Element belongs in the SOAP Header section, not in the
SOAP Body section.
Argument Supporting Comment :
1)As with the Manifest and StatusData elements, this message is intended for
message service handlers, of which there may be several.
276,341-347,958-1202
Although the Manifest, StatusData, and Acknowledgment elements may be of
specific interest to a given MSH, and so may be required to reside in the
SOAP Header area , the SOAP specification states in 4.3.1 that "A body entry
is semantically equivalent to a header entry intended for the default actor
and with a SOAP mustUnderstand attribute with a value of "1".
Therefore, it could be acceptable to allow these three ebXML elements to
reside in the SOAP Body in the case that they are directed to the default
actor, if the designers so wish. Of course by that argument the other ebXML
elements now located in the SOAP Header area could just as well appear in
the SOAP Body if the default Actor is implied.
For simplicity, I recommend that this specification prohibit the appearance
in the SOAP Body of any of the ebXML elements defined in this specification.
Assuming this restriction is made, all appearances of the term 'Body' must
be located, and changes made as appropriate.
Your suggestion that all ebXML extension element content
currently specified as being child elements of the SOAP:Body
element (Acknowledgment, StatusData and Manifest) should
instead be child elements of the SOAP:Header based upon the
fact that element content of the SOAP:Body is syntactically
equivalent to having an mustUnderstand=1 and the default
actor (the ultimate destination of the message) seems to me
to be a more compelling argument for inclusion of these
elements in the SOAP:Body than not.
An ebXML MSH is essentially an application to the SOAP
processor. It in turn is responsible for dispatch the contents of the
received
message to the aplication component that it determines should
handle the message.
All of the ebXML defined content of the SOAP:Body is designated as being
directed
TO the MSH itself, including the Manifest, Acknowledgment, and StatusData
elements. Thus, the terminal MSH *is* the ultimate destination (SOAP
application) of the messages containing these elements.
1202
Whereas the Via element is SOAP Actor 'next' qualified, the limitation of
"One-and-only-one Via element MAY be present" is true since the MSH which
processes a Via element must remove it. But of course, the MSH may
construct a new Via element prior to forwarding the message.
In fact, it MUST as per the SOAP specification. Technically, it could leave
the existing Via element as it is in the case that the MSH would be
inserting a "similar" element.
Since the restriction noted here is an implied result of the SOAP
specification and the requried use of the SOAP Actor 'next' attribute on
that element, I recommend this paragraph be deleted. Separately, I question
whether it is appropriate to restrict the Via element use of the SOAP Actor
to 'next'.
We have explicitly avoided "source routing" of messages, which is what would
be implied if we were to provide for a) multiple Via elements and/or b) use
of alternate values for the actor attribute.
791
'SHOULD NOT be forwarded' conflicts with SOAP specification 4.2.2 "MUST NOT
forward' Note also that the SOAP Specification accepts responsibility for
removing the local actor directed element before forwarding.
SOAP Specification? See my comment above. I think you meant SOAP Processor,
but as I have indicated, I don't believe that 'recipient' was intended to be
interpreted as meaning the SOAP processor, but rather the SOAP application
or handler.
155
It is not clear to me why the box lableled "Authentication, authorization
and repudiation services" feeds into "Header Processing", rather than being
directed from "Header Processing" as is done for "Encryption and/or Digital
Signatures". I was unable to find any supporting (or contradicting) this
interface positioning elsewhere in this specification.
271-273
The reporting of MIME errors in SOAP protocol as specified in [SOAP] is
outside the scope of this specification. The reporting of errors in ebXML
protocol, whether such errors originate in MIME or in SOAP is within the
scope of this specification. Such reporting is addressed in a separate
section of the specification. This section (7.6) should be removed from the
specification.
658-761
As defined, the TraceHeaderList element needs SOAP attribute actor=[next] in
the case of multi-hop, so that it may be consumed and rewritten at each
intermediate hop. Properly defined, the TraceHeaderList element should be a
child of the ebXML Header element, and it is that element that should carry
the SOAP attribute actor=[next]
This makes sense to me. I concur that we should add the actor attribute to
the TraceHeaderList element.
762-850
As I understand the SOAP specification, the SOAP processor will separately
invoke handlers for each element it encounters within a SOAP Header, based
upon the Namespace of that handler. If multiple first level ebXML elements
exists, that furhter suggests that the SOAP Processor will invoke the ebXML
handler multiple times. I conclude that there should be just one ebXML
Namespace element (at least for a given Actor attribute) within a SOAP
Header, and that all other ebXML namespace elements should be descendants of
this 'Header' ebXML Namespace element. Note that this comment also appies
to other ebXML elements in this specification not specifically referenced in
this comment reference range.
This issue needs further exploration.
787-792
Why does this specification preclude the use of the SOAP actor attribute
with a value other than [next]. Might not a business model require that a
named actor effect a Via service directed by the sender to other than the
first intermediate MSH?
The purpose of the Via element is to provide for intermediary support. I
think I see where you are going with this comment. If there is a
non-MSH-aware SOAP intermediary that does not understand the ebXML
namespace, then what would be the expected behavior of that node? This needs
to be further explored.
870
"0.98b" matches the current specification version, and presumably will be
updated to "1.0" when this specifcation is approved for publication. In any
event, I don't think a letter should appear in the final version.
The final draft will have "1.0" which will be consistent with the version of
the specification upon its approval.
155,176,907-909,1565-1577
The specification is not clear regarding the interaction between the MIME
Error Reporting and Processing, the SOAP Error Reporting and Handling and
the ebXML Error Reporting and Handling.
"SOAP Messages with Attachments" declares SOAP's independence from MIME
wrappers. That is, SOAP appears not to provide a means to report MIME
errors through the SOAP Fault Code mechanism.
The diagram at line 155 shows a single interface from the [ebXML] Header
Processing to the [presumably SOAP] Message Packaging.
The first set of reference lines provides instruction on how to report a
MIME error location, which presumably (see diagrams at line 155 and 176) has
been extracted from a SOAP error which in turn is reporting a MIME error.
(NOTE: This information should be located within the second referenced
section.)
The ebXML error codes (line 946) include "DeliveryFailure" which presumably
encompasses both MIME errors reported through the SOAP interface, and other
errors originating in the SOAP service processor. Reference lines 907-909
give specific instruction on reporting MIME errors, but no such specific
instruction is given on reporting SOAP generated errors.
Additional material, and possibly changes to the depicted architecture are
needed to provide sufficient advice on handling of errors occurring at or
below the level of "Message Packaging".
155,947-957
The diagram at line 155 shows that [ebXML] Header Processing invokes
"Encryption and/or Digital Signatures" processing services. The text of
947-957 states that the XMLDSIG elements resides as a standalone SOAP Header
element in the XMLDSIG Namespace.. That in turn implies that it is the SOAP
Processor that invokes "Digital Signautre" services, not the ebXML
processor. Also, since the SOAP processor does not specify the order in
which multiple Namespace services are performed, it is not clear that the
architecture as presented will work properly.
The interface diagram suggests that he Signature Element (in the XMLDSIG
Namespace) be a dependent of some ebXML Header element, such that the SOAP
processor does not 'see' that Namespace.
None
In submitting these comments prior to the close of the ballot period, I
reserve the right to submit additional comments on this specification prior
to the close of the ballot period on April 6, 2001.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC