Archive for March, 2006

The Campaign for Good Markup

Published by
anthony geoghegan
at March 31, 2006 in IT. 0 Comments

You may have the most sophisticated enterprise level web application in the world but I’ll bet a pound to a penny that the backbone of its operation is the humble HTML page.  However it’s generated, created, spawned or written, HTML is the skeleton upon which the beef of a web application hangs.

It seems to me, that throughout my career, most of the designers, programmers, what have you, creating these skeletons have evolved a distaste for writing clean, concise, well documented markup.  Instead, ably abetted by “forgiving” browsers and obesity inducing WYSIWYG web page tools, HTML writers have slipped into habit of palming off partially formatted, non-standard, bloated files that seem okay when viewed in one or two of the most widely used browsers.

Code hygiene is something I feel very strongly about.  Whatever you may say about the ‘art’ of it, it makes sound commercial sense.  Cleanly written applications are much easier to maintain, modify and analyse.  This equates to dollars and cents, because the time spent working on changing something is reduced.  It’s a simple equation.  It’s a fact of life that applications never work, as expected, out-of-the-box, and by making changes simpler, you save money, even if it takes a little extra time and consideration at the beginning.

So in a proactive way, I’m going to produce a series of articles on the much-maligned HTML and how to do it right.  I realise this subject has probably been done to death, but I intend to add my two cents anyway.

Because HTML is such a key component of every web application I feel it’s important to try and make the case again and again for clean markup.  To try and influence the page creators to learn the skills and the self-discipline to make standardised, clean, compact code.  One lives in hope. 

Handy broswer tools that highlight badly written markup:
Mozilla/Firefox plug-in
Internet Explorer plug-in

- Anthony Geoghegan

Technorati Tags: , , , , , ,

Spring 2.0: Hiding Services Behind Custom XML Schema (Part I)

Published by
Brendan Lawlor
at March 29, 2006 in Java and Spring. 0 Comments

In a previous entry, I mentioned our intention to use the Spring 2.0 custom schema support to simplify the use of our Sprung service libraries, when they are called from Sprung clients. In this entry I will describe the complexity that we’re trying to tame and show how we can achieve this from the perspectve of the client code, using a service-specific schema. In a later entry I will describe one way to simplify even how the service code provides that schema.
Continue reading ‘Spring 2.0: Hiding Services Behind Custom XML Schema (Part I)’

Are Interfaces Safe?

Published by
anthony geoghegan
at March 9, 2006 in Java, Security and Spring. 7 Comments

When using the Spring Framework the currently perceived wisdom is that writing your application to use Interfaces instead of implementations is the best practise.  It makes sense in terms of testing and decoupling class usage from particular implementations.  For nearly all the classes used in an application this makes absolute sense and, in fact, it’s recognised as one of the core strengths of the Spring Framework.

It occurs to me that, for classes with security sensitive functions, a possible security flaw exists.  It is conceivable that other nefarious implementations of the Interface could be injected into the application, which could capture data and interfere with the application’s processes.  In fact, were somebody not careful to indicate a sensitive class implementation as final, AOP could be used very handily to circumvent security and eavesdrop on many application activities.

For example, imagine an Interface for classes used to hash passwords similar to this one:

package ie.dsi.security.interfaces;
public interface Encryptor {
  public abstract String hash(String text, byte[] salt);
}

You might inject a SHA or an MD5 implementation when using it properly.  There is, however, nothing stopping someone from introducing their own evil implementation and using it to log passwords in clear text.

Correcting this issue is not as simple as it sounds.  Potentially some key-based nonsense could be implemented to ensure only valid Interface implementations are used, but this seems to invalidate all the gains made by using Interfaces in the first place.

It seems to me that the only safe recourse is to write your application to use the actual implementation in such cases.  Taking care, of course, to mark the implementation as final to prevent any sub-classing vulnerabilities.

 - Anthony Geoghegan

What do you think AJAX is?

Published by
Yagiz Erkan
at March 8, 2006 in IT. 0 Comments

Ajax the Great, son of Telamon, was a Greek hero of the Trojan war. True but he is not the subject of this blog.

Ajax is a liquid or powdered industrial cleaner. Correct but I don’t want to blog about this either.

Ajax is a Dutch football team. Well, this statement is true as well but if I wanted to blog about a big European football team, I’d write about Galatasaray.

These previous points aside, AJAX is probably the most hyped acronym these days. It stands for Asynchronous JavaScript And XML (Jesse James Garrett of Adaptive Path is the one who came up with the term in 2005). So, it is about transferring XML data asynchronously using JavaScript. Let’s elaborate on this:

In desktop application development, we would use multi-threading not to block the user interaction while waiting a task to finish. However, the classic browser interaction model based on HTTP request-response paradigm lacks that richness. The data is submitted after a click and a full page is loaded synchronously. So, finally we found a way to make the Web experience more interactive and this is thanks to AJAX, right? Not really… Long before AJAX became popular, Netscape 4 and IE 4 introduced DHTML (Dynamic HTML). An enhancement over the classic Frameset was the IFrame. The “I” in IFrame stands for “inline” because the frame belongs to the layout of another document instead of being part of a frameset. So, what we did was to create an invisible IFrame in order to contact the server in the background, achieving the asynchronicity. Lesson 1: Before AJAX existed, we knew how to do asynchronous calls to the server. It felt more like a workaround but it did the job.

Later, in Internet Explorer 5, Microsoft implemented an ActiveX object called XMLHttpRequest that was accessible via JavaScript. Mozilla project implemented a native version of XMLHttpRequest in Mozilla 1.0 and Netscape 7.0. Apple has done the same thing starting with Safari 1.2. What was the job of XMLHttpRequest? Asynchronous XML data exchange. Lesson 2: Long before the name AJAX appeared, the underlying XMLHttpRequest object had been around.

Now we have very interactive public Web applications using AJAX. We can interactively create an online photo album or create our web page or spell-check our message before sending, etc. All these killer apps use asynchronous calls to communicate with the server in the background while we can do something else. However, the visible part of the GUI, the most impressive part to the ordinary user is not asynchronous XML data exchange, it is DHTML. The richness of the user interface didn’t come with AJAX, it came with DHTML. And, there’s been alternative technologies, such as Java Applets and Flash to create rich clients. Lesson 3: JavaScript, CSS and the DOM provides all the bells and whistles for the new cool interactive Web applications.

So, is AJAX merely an object used by the browser to do XML data exchange with the server asynchronously? Well, not really. AJAX became more than just Asynchronous JavaScript And XML. We need asynchronous requests, JavaScript, CSS and DOM to have an AJAX application however we can use all of them without doing AJAX. Lesson 4: AJAX is a different Web interaction model. In an AJAX application, the workflow is at least partly contained by the client application and asynchronous XML requests are used in the background while the user performs other tasks. This model can become more complex, just like in Google GMail where the entire application is an interactive system.

For us, the developers, AJAX development comes with various challenges. It requires studying some of the AJAX design patterns. Suddenly JavaScript code becomes the centrepiece of an intelligent client (back to the thick-client days?). Now we’re brought to consider our JavaScript code from different angles: reliability, maintainability and flexibility. Furthermore, there is a fast growing market for AJAX frameworks. Some of them are maturing fast (ZK, Rico, Zimbra, etc.). We need to keep an eye on them not to reinvent the wheel. And for the tooling, give a try to Eclipse WTP (Web Tools Project) + AJAX Toolkit Framework. This couple will give you enough ammunition to start your first AJAX project.

- Yagiz Erkan -

Standardizing on the Spring Framework

Published by
Brendan Lawlor
at March 2, 2006 in Java and Spring. 1 Comment

Standardization should not be understood as a repressive force that prevents creativity. Good standards do the exact opposite - they create a space for innovation. Only bad standards tie your hands. The same can be said of frameworks.

In DSI we use Spring not just as a framework, but as a standard. It forms the backbone of application development in the same way that Ant forms the backbone of our build infrastructure. To see what I mean, here’s an overview of how we use Spring in DSI:

  1. Applications are broken down into standard project types (service, web, ejb etc), each with their own predictable set of Spring files.
  2. Pre-Spring 2.0, all projects offer pre-filled Spring configuration files as part of their API. Post 2.0 projects will export their own schema files and leave it to the user to fill in the blanks.
  3. All project configuration is done through Spring files, which are transparently read using mechanisms specific to the project type.

Let’s look more closely at how Spring reinforces and supports each of these points:

  1. Applications are broken down into standard project types:
    Experience has shown us that all the projects we build can be categorized into a surprisingly small number of standard project types. Whether we’re developing eBusiness platforms, enterprise back-office systems, or high-speed batch processes, our codebase can be predictably sliced into standard independant modules.Our standard project types only have meaning to developers if they are specifically pre-shaped for the job in hand. Web projects, for example, have by convention a directory called ‘web’ into which developers put html, jsp, css files etc. The build system, using common Ant scripts, knows where to find them (and what to do with them - see Larkin’s blog entry on convention over configuration for a discussion on this approach). By adding standard Spring files that are specific to the project type, we fill that shape out even more. The files are templates that effectively templatize the entire project, letting the developer know what lines to follow. In this way Spring supports the project type standards.
  2. All projects offer pre-filled Spring configuration files as part of their API.
    The standard Spring files mentioned above have a drawback: they actually present an obstacle to code reuse! Before Spring came along, designing a good API that could be reused by multiple clients was a well-understood art (though perhaps not always well practiced). Now that you have extracted most of your glue code into xml files, just getting the jar file into their classpath and reading the javadocs isn’t going to be enough to allow others to reuse your project. Again, convention comes to the rescue. There are only a certain number of ways that we can combine our standard project types into an overall standard architecture (see the sidebar below). If every standard project type knows what Spring files it needs from projects in the layer below it, then the obstacle to reuse is overcome.
  3. All project configuration is done through Spring files:
    Configuration files are not sexy. Of all the advantages that Spring brings, it’s hard to get excited about the fact that Spring gives you the opportunity to dispense with ad hoc configuration techniques. But it matters. It matters that project code won’t be littered with IO catch blocks, and mixtures of absolute and relative file names. It matters that everyone in your team will know how and where to add configuration.Moreover, if we always read our Spring files in a way that is transparent to the code, this facilitates the recombination of standard project types - i.e. our overall standard architecture.

Sidebar: Is there One True Architecture?

Why do we break our applications into standard project types? Most system architectures have a shared fundamental idea: the layering or stacking of behaviour - for example from presentation, through service to data. Each layer is built on the one below it (in a loosely coupled fashion), but independent of the layer above. Each layer does a very different job, relying on different libraries, and in fact constructed using different sub-architectures. In a sense it is only when you enter into a layer that there is a real choice about architecture - is the service layer going to be implemented using rules-based programming? Is there any call for an in-memory database? Will we use MVC, AJAX or both on the presentation layer. The overarching layered architecture that joins these together is practically a given. Loose coupling between those layers allows for future reuse and plugability. For these reasons it makes sense to design and develop some of these layers as separate projects, but do so in such a way as to make it easy to recombine them.

It appears to me that the stacked or layered architecture is part of the DNA of computing. The pattern crops up over and over at many different levels. The advent of n-Tier architectures marked the explicit application of this pattern to software architecture. Maybe this will change - maybe the DNA will mutate beyond recognition over the coming years under the evolutionary pressure of innovations like AOP. But for now, I think we can say that no project is truely green field and each new one assumes this defacto standard architecture.

Our ultimate goal in DSI is a kind of Java on Rails, where developers have the freedom to choose between proven layer-specific architectures, while working within one standard overall architecture. Spring helps on both of these levels. Its non-intrusive, whole-stack IoC container behaviour supports the overall standard architecture. And its layer-specific, time-saving wrappers around the technologies we like to use (Hibernate, remoting, AspectJ etc) underpins our standard project types by permiting us to prefill their configuration into standard files.

It is exactly this combination of unintrusive breadth, and technology-specific depth, that has made Spring the ideal basis for standardized software development in DSI.

- brendan lawlor -