This is a quick-and-dirty Groovy scriptlet I created yesterday to transform all my delicious tags to lowercase:
Now someone should “dash-separatize” all my compound keywords! Duh!
A few days ago I was busy removing our project’s dependency on Apache Xalan and Xerces (we wanted to use Java’s built-in implementation of XML and XSL APIs). In some of our XSL files, we use Xalan-Java Extensions to call Java methods from the stylesheet file. After removing the Xalan and Xerces JAR files from the class-path and deleting all the references to Xalan specific namespaces and tags from the stylesheet files, all stylesheet parsing and compilation errors disappeared, but the output generated by Java’s built-in version of XSL [cci lang="java"]TransformerFactory[/cci] was different to what used to be generated by Xalan.
After some investigation it turned out that some calls to Java code from the XSLT files are being ignored by the transformer. Debugging the code and stepping through all the method calls down to XSLTC and other internal classes did not uncover the reason for the mysterious skipping of these Java calls.
Suddenly something came to my attention: in some of the XSLT files, we are not interested in the value returned by the Java call; we only call a method to modify the state of the Java class. To do so, we declare a variable in the form of:
To call [cci lang="java"]aUtilityMethod()[/cci] and then never use [cci lang="XML"]$ununsedVariable[/cci] anywhere in the XSLT file again. I decided to use one of these variables in the XSLT file to see if that forces the XSL transformer to call the method, so I added a harmless comment right after the variable declaration in the form of:
Voila! Now the transformer is calling [cci lang="java"]aUtilityMethod()[/cci]. It turned out that Java’s default built-in version of [cci lang="Java"]TransformerFactory[/cci] is either skipping running the select expression for unused variables or is doing it lazily. Considering that XPath expressions are side-effect free and that they only return a set of nodes, it makes sense to implement suchlike optimizations, but the optimizer should check the select expression and omit the optimization if it is a Java call.
But is it a bug? Well, yes and no. The truth is that it’s not working correctly. But on the other hand, as this feature is an undocumented and internal feature of the default XSLT implementation of the JDK, it is an unsupported feature and it is better to avoid its use.
Some architects use the term “layer” when they to refer to logical grouping of components and “tier” to refer to their physical grouping. However Mark Cede and Humphrey Sheil, in their book on the SCEA exam, define layer and tier somewhat differently. They define tier as … logical or physical organization of components into an ordered chain of service providers and consumers
. They refer to client, web/presentation, business, integration, and resource as traditional tiers in architecture. Makes sense.
Then they define a layer as a piece of the hardware and software stack that hoses services within a given tier. This definition of layer is different to other definitions I’ve seen so far. They list virtual platform, application, infrastructure, enterprise services, compute and storage, and networking structure as typical layers of an architecture.
While this definition is somehow different, it makes total sense to consider all these aspects when designing an architecture: Are we going to deploy to Weblogic or JBoss? Are we deploying to Windows or Linux? Will we deploy the application on one or more many-core servers or cheaper multi-core systems? Will we use a high performance PCI-e based solid state storage as our storage system or are we going to use traditional rack-based NAS storages? What DBMS are we going to choose and why?
Decomposition by “coupling and cohesion” and “volatility” are two architectural decomposition methods that are unlikely to be used together in the same project. However it’s possible to first decompose by CoC and identify the parts of the system that should be kept together, and then use decomposition by volatility to isolate the parts that are likely to change in the future. This means that we might need to reduce the cohesion of the system to some extent, but it should make changing or replacing the volatile parts of the system less of a hassle.