Using Spring Interceptors to Reuse Functionality

August 29, 2010

Spring MVC interceptors (learn more about interceptor design pattern here) can be used to plug in functionality that needs to be executed as part of handling a request. These interceptors can be an ideal place to reuse functionality that is applicable for non-web application related scenarios. Interceptors can be used to execute horizontal, cross cutting concerns – e.g. security, metrics, logging, etc. If you have an existing component that was developed for a command-line application or a JMS event handler and need to reuse it in a web app, an interceptor would be an ideal choice.

Here is an example implementation for a a Spring Interceptor extending the HandlerInterceptorAdapter:

package com.yourapp.learn;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

public class LoginInterceptor extends HandlerInterceptorAdapter {

 public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
 Object handler) throws Exception {

 Boolean userAuthenticated = (Boolean)request.getSession().getAttribute("userAuthenticated");

 if (userAuthenticated) {
    return true;
 } else {
    return false;


This interceptor simply checks to see if the user is authenticated by looking for a session attribute. If the result is true, the request is processed further.
Here is an example bean definition fragment for utilizing the above:

<bean id="testInterceptor" />

<bean id="testSimpleUrlHandlerMapping"

<property name="interceptors">
 <ref bean="testInterceptor"/>

 <property name="mappings">
 <prop key="/test">someController</prop>

The actual logic can be in another component that is leveraged in the interceptor. The component itself could be reused across several apps. If such a component isn’t available, you can refactor existing logic to carve out the common functionality.

Systematic Reuse Panacea?

August 28, 2010

I received an email the other day from a professional asking if there was any new technology that I recommend for achieving immediate, widespread software reuse. The short answer is no 🙂

Technology is an important, essential, and necessary ingredient for systematic reuse. However, it isn’t sufficient to achieve widespread reuse. Hyperbole? No – widespread reuse is being touted from the days of mainframe routines, functions, object oriented design, and component based development to service oriented architecture and domain specific languages. Yes, the level of abstraction is inching closer to the business domain and the tools have certainly gotten richer and more reuse-friendly (for instance, refactoring support in IDEs).

So why hasn’t systematic reuse happened? There are equally relevant considerations with systematic reuse (ones that often get ignored):

  • Process – are your teams performing design and code reviews? how much thought is given to architecture – not only at a system level but when systems interact and exchange data? are requirements reused across projects? if not, are overlapping/similar requirements resulting in duplicate functionality?
  • Training- how can a new developer who joins the organization come to know about reusable assets? how do we reduce the learning curve and demonstrate utility of existing assets? how do we align architecture efforts to better leverage reusable assets?
  • Infrastructure – how are reusable assets identified, developed, managed, and retired? what if a team needs to contribute a patch to an existing asset? are there continuous/daily builds and automated tests for reusable assets? who ensures the quality of reusable assets? who “owns” these assets and how do they get supported?
  • Culture– do your teams collaborate and cross-pollinate ideas? is there a not-invented-here syndrome prevalent when it comes to leveraging existing solutions? how do technical leads and developers come to know about reusable assets?
  • Resource – how are resources allocated when they are meant to be useful for multiple applications? are there incentives for developing and leveraging reusable assets? are there resources allocated for horizontal components that are non-functional in nature – but extremely useful for several apps?

This is only scratching the surface and is meant to illustrate that technology alone isn’t a silver bullet to achieving systematic reuse. No single product or technology can guarantee reuse to happen organization-wide overnight. You can make it easier with the right set of technology tools/libraries/products but time, sustained effort, and calibrated strategy (one that takes into account your organization’s challenges and constraints) are essential for enduring success.

The Software Product Line (SPL) practices from Software Engineering Institute pursues a comprehensive set of practices that address the above considerations. It takes a holistic view of reuse covering multiple perspectives including people, process, technology, and places a common architecture at the heart of achieving widespread reuse. It isn’t promising a panacea and is a much better approach than buying a technology that is being touted to hand you reuse success.

Transforming Object to XML using Freemarker

August 22, 2010

I wrote earlier about using open source software for fulfilling functionality prior to building a custom implementation. Many projects have the need to transform object to text or XML – e.g. return XML response for REST-based services or return JSON string to support a web application etc.

Freemarker is a templating engine that can be leveraged to perform object to text transformations – with freemarker it is easy to generate RSS feeds or delimited text or plain old XML very easily. Below are some code fragments that illustrate freemarker usage:

Below is a code fragment for setting up the template configuration:

try {
	// Initialize configuration;
	cfg = new Configuration();
	cfg.setDirectoryForTemplateLoading(new File(templatesLocation));
	//Use beans wrapper (recommmended for most applications)
	//charset of the output
	//default locale

} catch (Exception e) {
	//handle the exception

The templatesLocation variable is the path to a folder with freemarker templates (referred to as FTL templates). These are similar to templates used with frameworks such as Velocity. For example, below is a template fragment:

<Name>${myBean.firstName?xml} ${myBean.lastName?xml}</Name>

“myBean” is the java object that has first name and last name properties supported by JavaBeans style getXYZ() methods. The ?xml built-in function is used to encode any special XML characters.

Below is the code fragment when trying to invoke a template with a java object – the template file name is hard-coded for below example – it can be fetched from an input parameter or injected directly into this object as necessary:

// loading the template file
String templateFileName = "test-template.ftl";
Template template = cfg.getTemplate(templateFileName);
Writer out = new StringWriter();
template.process(dataObject, out);
String strResponse = out.toString();

The above code fragment essentially takes a java object (dataObject) as input and creates a string as output. Using the template above, the output for example could be:

<Name>John Smith</Name>

Freemarker also supports loops and conditions and offers a rich library of built-in functions as well.

5 Signs Indicating Need for Service Governance

August 21, 2010

The word ‘governance’ seems to conjure up all sorts of negative images for IT folks – needless bureaucracy seems to top that list. However, without lightweight governance, SOA and systematic reuse efforts will fail to achieve their full potential. Can you spot signs that indicate need for governance? I believe so and here are five:

  1. Every project seems to reinvent business abstractions that are fundamental to your problem domain. No sharing or consistency of information models – this will be painfully evident when projects are happening back to back and your teams seem to be running into overlapping data modeling, data definition, and data validation issues.
  2. Directly linked to above – is service definitions seem to not reuse schemas – i.e. each service has a unique schema definition for a customer or product (or some key object from your domain) and your service consumers are forced to deal with multiple conflicting schemas.
  3. Legacy capabilities are leveraged as-is without mediation – increasing coupling between consumers and legacy systems. Tell tale sign here is if you see arcane naming and needless legacy data attributes sprinkled all over service interfaces.
  4. Services seem to have inconsistent runtime characteristics – new service capabilities are added without regard to performance requirements – issues tend to manifest in production where users or entire processes/applications get impacted to service behavior.
  5. Business processes bypass a service layer and directly access underlying data stores – if you have seen a business process invoking several stored procedures, doing FTP, publishing to multiple messaging destinations – all from a monolithic process definition that is a clear sign that governance is non existent.

These are few signs but key indicators that services are being built in a tactical fashion. In a follow up post, will expand on how governance can be leveraged appropriately to address these issues.

Article: SOA Adoption using Agile Practices

August 18, 2010

SOA Adoption Using Agile

Part 1 of a two part Article series on SOA adoption is up on the SOA magazine

In a hurry to decide if something is reusable?

August 15, 2010

I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

  • is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
  • is the capability making something incredibly hard/defect prone simpler and/or easier?
  • is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
  • is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
  • is the capability only available in a particular technical platform but is solving  an often needed problem?
  • is it automating boiler plate code generation or preventing defects?
  • is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.

Think Capabilities Not Technologies

August 14, 2010

There is a reason why your team builds software – most likely, you are either building a product for external customers or supporting technology solutions for internal stakeholders within the organization. Systematic reuse cannot be achieved if we focus exclusively on technologies. Focus on capabilities, more specifically, business capabilities instead.

This is a simple but significantly useful perspective to adopt. Capabilities are tangible units of functionality – regardless of implementation technologies used or systems that they are part of. When capabilities are identified, you can make more informed decisions about whether or not it is a reuse candidate. This is also handy every time there is a discussion on which part of a functionality should reside in a server component or a presentation component etc. Capabilities, when aligned with business needs, gives you the right level of abstraction when considering refactoring efforts. Are we refactoring the right capabilities from a legacy codebase? is this a capability that is useful as-is or is it only relevant within the context of a specific business process? is the current implementation assuming (aka coupling) too much about a business capability?

These are extremely relevant questions – and notice how we haven’t talked about technology implementation decisions. That is on purpose – if we are not careful, impatient technology choices could adversely constrain business capabilities. Once you are clear on the capabilities – technology decisions and need for variability, agility, and other quality attributes can be made appropriately.

%d bloggers like this: