More repeats than a kipper breakfast

We've reached escape velocity. We're on our way to the moon. But hold on, we can't fly there in the single-stage heap of junk we built in the last section. Oh no. What we need is a modular multi-stage rocket ... and maybe a scoop of that weird freeze-dried ice-cream.

These applications are getting too big to include inline with the commentary

You can view the application we're going to discuss here
You can try it here

Well our resource browser is starting to look like a real application. It's essentially the same as before but we've added two further filters. A filter to view resources by maximum age and a regular expresion filter.

Commence the execution. Off with his head

You may be thinking, "What's the big deal? Except for the feature creep how's this different from the first version?" Well, hidden between the cracks in the application pavement is a new and precious flower. The dpml instruction.

The dpml instruction executes a sub-idoc, in this case resource_processor.idoc which you can see here.

The sub-idoc resource_processor.idoc contains the data processing instructions we had in the previous version. First the mls request operator is created, this allows the regex to filter to be applied. The mls operator is used in the mls instruction to generate the resource list. This list is then filtered twice; first by applications and then by the age of the resource. The processed list is returned in the response document. In the main idoc the response is assigned to the variable var:list.

The <param> element is used to pass var:myParam as a parameter to the sub-idoc. We can now clarify how <param> and this:param are related. When we use the DPML accessor the <param> in the instruction is available as this:param in the called idoc.

With the use of a sub-idoc our monolithic single-stage application has become modular. We've consigned the data processing to a layer of it's own. The application we interact with is now only handling presentation. We're a little further towards the asymptote of good design.

Why is this important? Because we have the opportunity to extend, modify or just plain maintain the application in much more manageable pieces. It is an important property of Declarative Processing with DPML that applications can be easily maintained and refactored. XML is not called extensible mark-up language for nothing - with XML you generally expect to have adapt your applications to deal with modifications to your XML data structures. Though an enourmously valuable property of Declarative XML applications is their remarkable tolerance to changes in XML data structures.

Performance

Whilst modularity and maintainability are important perhaps the greatest reason to modularize applications is for performance.

With web-sites, performance and scalability are imperative, but it's interesting to speculate how robustness and adaptability may be traded for raw performance when it comes to XML business interchanges. For example, in Rossettanet, the highest volume and most installed XML integration framework, the most commonly used exchange protocol is Purchase Order PIP3A4. This protocol allows for response times in excess of 24 hours. With typical peak demand of 30k transactions per month. A different dimension to performance than that of a web-site and one that demands a different approach to sytem design.

XML processing is performance intensive, but robust and highly adaptive to change. However it's still good to have optimization tricks up your sleave.

It may seem odd to think that performance can come from modularizing XML processes, since surely the same net amount of work is being done either way? However, the NetKernel upon which DPML runs, has a sophisticated dependency-based caching model. That is each resource can be cached and may be invalidated by a change in status of any of the chain of resources which went into producing it.

It follows that since the result of a DPML operation is simply a resource with dependencies, the set of instructions within the idoc, it is cacheable. Provided the dependencies from which the result is derived are unchanged then a subesequent request for that resource could be served from cache. Therefore a modular application is more likely to have units with long validity that do not require recomputing and will be considerably faster to serve from cache. You may have observed how this documentation is served much faster on the second visit, this is because it is taking advantage of the cache.

For the moment we will just state that it is always a good idea to try to build applications in modular units. There is a detailed guide to the dependency based caching model here.

Lastly if your application is absolutely performance critical you may want to consider creating a custom URA - a guide on how to do this is here

Summary

In the next section we branch out.