mca blog

the exyus web engine works on an XML transformation pipeline model. although it does not implement the W3C XML Pipeline standard, it works in a similar way. now that the engine is starting reach a steady-state, i figured is was worth the time to outline the details of the pipeline as it is currently implemented.

the big picture

in exyus, there are several 'transformation/validation points' that can be implemented. most of them are optional. they are (in order):

argument validation

all incoming arguments are captured as an XML document and can be validated using XSD. this is usually done in order to make sure all the required arguments were supplied by the client. these arguments are also available as a list of XSL parameters for the life for the request (see below)

request body validation

the body sent with the request is captured as an XML document and can be validated using XSD. this is usually done to make sure any incoming request has the proper input fields, that the fields contain the proper data types, ranges, etc.

request body transformation

the body sent with the request can be transformed using XSL. this is usually done in order to convert the incoming data into a format suitable for executing the request. for example, the incoming request can be transformed into a valid T-SQL call or it can be transformed into the final format needed to save the information to disk. the list of arguments is also available for this transformation as a set of XSL parameters.

response body transformation

the result of the cxommand execution can be transformed using XSL. this is usually done in order to convert the response of the back-end storage system (T-SQL, file system, etc.) into a valid representation for the client. the list of arguments is also available for this transformation as a set of XSL parameters. any additional state information that results from the execution of the command (new document id, date-time stamp, location on disk, etc.) is also available as an XSL argument.

ok, so much for the general pattern. below is a step-by-step set of transformation and validation points for the four key HTTP Methods supported by the exyus web engine. note that in almost all cases, these validation and transformation steps are optional.

workflow for handling HTTP DELETE

1. collect URL + arguments
2. convert into -args- document
3. validate -args- document
4. transform -args- into valid delete document (t-sql, physical file)
5. execute delete
6. return 204 (no content)

workflow for handling HTTP GET

1. collect URL + arguments
2. convert into -args- document
3. validate -args- document
4. transform -args- into valid read document (t-sql, physical file)
5. execute read
6. transform results into valid response representation
7. return 200 + representation

workflow for handling HTTP POST

1. collect URL + arguments
2. convert into -args- document
3. validate -args- document
4. collect body entity
5. convert into -body- document
6. validate -body- document
7. transform -body- into valid save document (t-sql, physical file)
8. execute save
9. transform results into valid response representation
10. if redirect-on-create, then send 302 (found) + new URL
11. else return 200 + representation

workflow for handling HTTP PUT

1. collect URL + arguments
2. convert into -args- document
3. validate -args- document
4. collect body entity
5. convert into -body- document
6. validate -body- document
7. collect headers (if-match, if-unmodified-since, content-type)
8. compose HEAD call (w/ headers) to existing URL
9. collect resulting headers (etag, last-modified)
10. evaluate results
    1. HEAD = 200 OK, it's ok to update
    2. HEAD = 304 not-modified, it's ok to update
    3. HEAD = 404 not found, not an update, check if it's OK to create
11. if not-ok-to-save, send 412 (pre-condition failed) and exit
12. else transform -body- into valid save document (t-sql, physical file)
13. execute save
14. transform results into valid response representation
15. return 200 + representation