An Abstract Model for Module Processing

Concepts

  1. An XML Protocol Message consists of one or more blocks.
  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.
  3. A module application may result in a fault or a successful evaluation.
  4. The result of a successful evaluation may be void or a response block.
  5. The specification of the module application should indicate whether the response block is to be included in a return message.
  6. A module may be applied to more than one block (in a single evaluation of the module).
  7. The response block block generated by one module application may also serve as an input for another module application.  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.
  8. The ordering among module evaluations could be total or partial, permitting parallelism if the processor is capable of it.

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)		 application of  module M1 to block A
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) }		 sequence, 2 modules/same block
sequence, 1 module/different blocks
sequence, 2 modules/different blocks
sequence, 2 modules/different blocks/reverse order
4. par { M1(A), M1(B) } parallel
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. Should a module application be allowed to apply to zero or more modargs?   Maybe the module application is triggered purely for side-effect.
  2. 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. 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

 

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.