Re: PASWA, Include and Protocol Bindings

> 1. We have indeed considered using headers for activities such as
> encrypt/decrypt
> 2. In most of the discussions I've seen, the decrypting node is modeled
as
> an intermediary.  No one node rewrites the input infoset and then
> reprocesses.  The intermediary takes an input infoset, as a result of
> processing relays a modified one.  In principle, the relay could be to a
> piece of software in the same physical machine, or even on the same
thread
> in the same address space.

If I understand correctly, you're saying that decryption is modeled as an
intermediary so that it effects a pipeline with a defined relationship
(that of an intermediary performing a transformation on an infoset) to
other modules targeted at the same node.


> 3. I would also agree that we give a lot of latitude to header-functions
> in altering the processing model, though I don't think we say anywhere
> that such processing can modify the input infoset in a manner that
alters
> the input to the processing at the same node.  My tentative conclusion
> from this is:  the specification for the decryption header (or
doInclude)
> could call for the equivalent of SOAP processing on the results of the
> decrypt (include), but the spec for that header would in some sense have
> to restate the SOAP spec.  I'm not even sure if it's doable, at least in
> the case of decryption.  What if decryption exposes an mU header you
don't
> understand.  It's at best a somewhat tricky thing to specify properly.

Agreed; hence, the 'pipeline' model above. I don't yet understand why this
pattern could not be applied to include processing, however (I realize
that the optimizations that most people will want to make wouldn't be
possible if this were literally required, but I believe that this can be
circumvented by requiring that further SOAP processing must behave as if
the infoset had been transformed).


> I think there's a very key point to consider:  in my view, what's above
> the binding is portable across transports, and is visible to (some
level)
> of SOAP application.  Indeed, it's part of the contract between senders
> and receivers of envelope infosets.   What's in the binding is private
to
> a single hop, unless the bindings conspire to play games through
> intermediaries.

Agreed.


> My key point is:  I don't want the applications to see the Include.
> Indeed, my understand of PASWA is that the whole point is that
> "attachments" are modeled by value as children.

Post-doInclude, they are.


>  Indeed, one of the claimed benefits of
> PASWA (and it's one I quite like) is that the infoset can be carried by
> bindings that don't play tricks:  our own HTTP binding can send the
> character children.

As can an Infoset that has the included data serialized into it.


> What happens if an xbinc:Include makes it over a "smart" binding to an
> intermediary, and then has to go through a regular HTTP hop?  Putting
the
> includes in the bindings (if at all) makes everything come out right.
The
> first binding uses the Include optimization and sends the children in
> binary.  The intermediary node relays the envelope through the regular
> HTTP binding, the implementation of which (we presume) calls for the
> characters in the children.  This (we presume) causes conversion from
> binary form to canonical lexical.

How is this different from activating inclusion from a header? If it were
a forwarding intermediary, one would need to instruct it to transform the
message appropriately; if it were an active intermediary, it could take
care of this itself.

If I understand correctly, you're arguing that this is a hop-by-hop
feature which provides a service that doesn't carry any application
semantics (i.e., it's necessary that it's present, but doesn't add any
application-specific information to the message context); as a result, it
fits most naturally into a binding (it's "Just Plumbing").

I certainly agree that this would be easier to specify, and easier to
specify correctly, as such. However, a number of such "wire-level"
features are under consideration for Web services (e.g., reliability),
which leads to the concerns I stated earlier. If the means to do something
relatively simple like inclusion doesn't exist, how can people extend SOAP
usefully?

If this feature were already existant in the underlying protocol (in this
case, HTTP, multipart MIME and/or MHTML) I could see including it in the
binding; something like inclusion that deals wholly with XML seems a
likely candidate for being a header feature, to me.

Please understand that I don't have a great objection to actually doing
this as a binding without doInclude; I'm more concerned for the
implications of needing to do so.


> The PASWA model
> is that the envelope is full of characters.  The only time you can play
> the include game is if the binding is using a collection mechanism such
as
> multipart MIME or DIME that allows for carrying multiple parts and
> referencing those parts with a URI.  Since it's the binding that knows
> whether it's doing that, it seems to me that the binding starts out as
the
> natural place to make the decision to do the tricky encoding.

I disagree with the notion that include is only useful in conjunction with
attachments.


> > Furthermore, decomposing the specifications (into a
> > binding that modifies the URI dereference function, and
> > and a header that activates the Include) gives us the
> > benefits of modularity and follows the principle of
> > least power; it may be that some people want to include
> > external representations, whilst others will want
> > attachments to not be evident in the message.
>
> There is a separate header that provides this separation of concerns, I
> think, and that is the swa:Representation element.  that lets you get
some
> transparency between attachments in the message and other web resources,
> and it lets all of them be accessed "by reference" using a URI.  I have
no
> problem at all with that one being in a header, and in fact I quite like
> what's proposed.

Would it be the case that a message transmitted over a non-attachment
binding (as you illustrate above) would need to serialize the included
chilren into the message, but still provide swa:Representations for them
as well?

Received on Tuesday, 6 May 2003 20:41:11 UTC