Abstract Models for Module Processing and Attachments

Mark A. Jones, AT&T Labs -- Research

W3C XML Protocol Working Group, Abstract Model subgroup

An Abstract Model for Module Processing

Concepts [and comparison with SOAP 1.1]

  1. An XML Protocol Message consists of zero or more blocks.

    SOAP:  SOAP has optional header blocks and an obligatory body block.
  2. The XML Protocol Message specifies a set of module applications and the order in which they will be carried out by the processor.  The message may also specify a set of RPC conventions that influence the module application

    SOAP:  SOAP doesn't seem to have the notion of a module acting on a block, but rather a destination (intermediary or recipient).  Destinations are specified by attaching a SOAP actor attribute to a header (defaults to the recipient).  The special URI "http://schemas.xmlsoap.org/soap/actor/next" means the first SOAP app that processes the message.  The body can only be inspected by the ultimate recipient.  [What is the real import of the SOAP actor URI?  Is it just an arbitrary name that a SOAP Processor along the way can look for?  Can SOAP actor destinations be mapped onto the notion of  module by giving a distinguishing URI that somehow differentiates modules at a given destination?] 

    The specification of a single SOAP actor for a block appears to mean that a SOAP sender would have to replicate blocks in the message for each intended actor that needed to process it.  Since the actor is a destination, it could be processed in only one way at a particular node.  Furthermore, once a block is processed, it may not be forwarded.  The node that processed it could replace the block with an identical one, but it appears that it would have to be processed by another node.  You can't process the same block in two ways at the same node.  The SOAP spec also makes it clear that a replacement block is a new contract between the intermediary and the next recipient of that header, not the sender and the next recipient. So a sender can't really target two destinations/modules with the same header data without replicating the header data in two physically distinct headers in the message.
  3. A module application may result in a fault or a successful evaluation.

    SOAP:  Similar to header or body processing.
  4. The result of a successful evaluation may be void or a response block.

    SOAP: Reasonably similar. 
  5. The specification of the module application should indicate whether the response block is to be included in a return message.

    SOAP: SOAP actors other than the ultimate recipient cannot (directly) contribute response blocks.  They may be able to forward response info in an inserted header to the ultimate recipient, who could cooperate to return it as part of the return result, but that would take some orchestration.
  6. A module may be applied to zero or more blocks (in a single evaluation of the module).

    SOAP: SOAP would require some dummy header as a placeholder for a SOAP actor who just needed to be invoked for side effect, since that is the only place to hang a SOAP actor attribute..
  7. The response block generated by one module application may also serve as an input for other module applications.  This permits the composition of services.  For example, one module application might do decompression, with its response block fed to a module that did decryption, with its response block fed to an application-specific module.

    SOAP: See #2 above.  There appears to be no way to compose something like independent modules at the same node in the SOAP specification.
  8. The ordering among module evaluations could be total or partial, permitting parallelism if the processor is capable of it.

    SOAP:  A SOAP destination presumably processes the headers intended for it in lexical order.  No explicit provision for parallelism is provided.
  9. A module application (or composition of module applications) may be obligatory or optional.

    SOAP:  Similar.  SOAP has the notion of a mustUnderstand attribute to indicate the processing of a header which is directly associated via SOAPactor to a single destination.  If it is possible to apply different  modules to the same block or the same  module to different blocks, then the optionality of each module application needs to be specified.

Semantic Operations

The following grammar defines an abstract syntax for the semantic operations of block evaluation that satisfies and instantiates the above concepts.  It is emphasized that this is an abstract syntax for the purpose of defining a notation for discussing semantics and defining an abstract  module processing model; the concrete syntax actually used in XML Protocol messages may differ.  

  1. Module application -- a module is applied to one or more blocks and can produce a resulting block
    Composition of module applications -- a module is applied to blocks produced by module applications

    modname ::= < primitive modname syntax >
    block   ::= < primitive block syntax >
    modarg  ::= modapp | block
    modapp  ::= modname "(" [ modarg [ "," modarg]* ] ")"
  2. Return values -- specifying a return value from a module application

    modexpr ::= return modapp | modapp
  3. Sequential application -- the sequential execution of expressions
    Parallel application -- the parallel execution of expressions

    seqexpr ::= seq "{" [ expr [ "," expr]* ] "}"
    parexpr ::= par "{" [ expr [ "," expr]* ] "}"
    expr    ::= [ "?" ] modexpr | seqexpr | parexpr

 

Examples of Abstract Module Operations

[These expressions could be viewed graphically, analogous to the diagram showing handler processing in Figure 5.2.]

1. M1(A)
return M1(A)
? M1(A)
? return M1(A)		 application of  module M1 to block A
application, return value
optional application of  module M1 to block A
optional application, return value
2. M1(M2(A))
return M1(M2(A))		 composition
composition, return composed value
3. seq { M1(A), M2(A) }
seq { M1(A), M1(B) }
seq { M1(A), M2(B) }
seq { M1(B), M2(A) }
seq { M1(A), ? M2(B) }		 sequence, 2 modules/same block
sequence, 1 module/different blocks
sequence, 2 modules/different blocks
sequence, 2 modules/different blocks/reverse order
sequence, M2(B) is optional
4. par { M1(A), M1(B) }
par { M1(A), ? M2(B) }		 parallel
parallel, M2(B) is optional
5. seq {M1(A), return M2(B) }
seq {return M1(A), M2(B) }		 return value from a module application in a sequence
6. par {M1(A), return M2(B) }
par {return M1(A), M2(B) }		 return value from a module application in a parallel execution
7. seq {return M1(A), return M2(B) } multiple return values from a sequence
8. par {return M1(A), return M2(B) } multiple return values from a parallel execution

 

Issues

  1. [YES] Should a module application be allowed to apply to zero or more modargs?   Maybe the module application is triggered purely for side-effect.
  2. [YES] Should we allow an XML Protocol Message to contain zero or more blocks?  The message could exist purely to trigger module applications for their side-effects without any message blocks. (This assumes that modules can be applied to zero modargs.) 
  3. [YES] Should a seq or par be allowed to contain zero or more expressions?  They presumably would have no computational effect, but would be harmless.
  4. Should  return be implicit?  An alternative concept would be to have every module application that is not contained inside another module application return a value (which may be void) for the reply.  Having an explicit  return allows modules to produce a value, but not always require that it be returned.  You can think of return as a "module" that explicitly directs its input (the output of a module application) into the reply message.
  5. Will we ever want to do something like this?  (not allowed by current abstract syntax)
    M1(return M2(A))                                                    composition, but only return value of M2(A)
  6. How would implementations handle multiple parallel returns without unbounded buffering since the return wire format is serialized? (allowed by the current abstract syntax -- should it be?)
    par {return M1(A),(return M2(B)}            parallel, multiple return values
  7. Optionality seems to scope outside of composition since each inner module application must complete before the next application can be performed.  (Inner ones are effectively obligatory.)  An expression such as ? M1(M2(A)) could be considered successful (by the ultimate recipient) even if M2 was evaluated along the way and M1 was not, since the entire expression was optional anyway.

 

 

An Abstract Model for Attachments

Concepts

  1. An XML Protocol Message may be accompanied by zero or more attachments, carried along with the underlying protocol
  2. Each block in the message may reference zero or more attachments.  The links to attachments are "local" in the processing context for the message and will be given an appropriate local url.  The message may also contain links to "external" targets outside of the local processing context.
  3. An attachment may reference other attachments.
  4. Every attachment should be referenced by a block or by some attachment which is referenced by a block.

 

Abstract Attachment Operations

  1. get(url) -- a module can retrieve an attachment from the underlying protocol.  If the form of the URL is a local URL then the reference is to an attachment.