Daniel Watrous on Software Engineering

A Collection of Software Problems and Solutions

Posts tagged guice

Software Engineering

Caching in Java using Aspect Oriented Programming (AOP)

As the scale of web applications increases, performance optimization considerations are more frequently included in initial design. One optimization technique used extensively is caching. A cache contains pre-processed data that is ready to use without redoing the processing. Processing may include extensive computation and accessing data over a network or on disk.

Keep the details out of your code

One design consideration when introducing a caching mechanism in your code is to keep the details out of your code. Most caches are just simple key value stores, and so it’s tempting to introduce them where you have a performance issue. Imagine the java method.

    public Shop getShopsNear(Shop shop) {
        Shop returnShop;
        // query google maps api with shop data to get region
        // query database for region
        // calculate center of region
        // sort by distance from center
        returnShop = closestShopToCenter;
        return returnShop;
    }

Obviously that has the potential to take a long time to process. It can also be expected that there are a reasonably small number of shops. Even if there are several thousand, caching several thousand results in memory is very manageable.

Wrong way

It might be tempting to jump right in and introduce caching like this:

    public Shop getShopsNear(Shop shop) {
        Shop returnShop;
        // create a cache key
        String cacheKey = "getShopsNear: " + shop.toString();
        // check for cached result
        Cache cache = CacheProvider.getCache();
        returnShop = cache.get(cacheKey);
        if (returnShop == null) {
            // query google maps api with shop data to get region
            // query database for region
            // calculate center of region
            // sort by distance from center
            returnShop = closestShopToCenter;
            // cache result
            cache.put(cacheKey, returnShop);
        }
        return returnShop;
    }

At first glance, that’s great. It follows most quick start tutorials for caching solutions and it will improve the performance of your code. However, there are several problems with this approach. I highlight some here.

  • Higher risk of key conflicts and debugging since it’s managed at the method level
  • The code is tied to specific cache implementation
  • The method is less clear due to clutter from caching

AOP – a better way

One way to get around the problems above and have a caching mechanism that will grow with your application and provide flexibility is to use Aspect Oriented Programming. Google Guice also refers to this as Method Interception. The idea is that you identify some pre-processing that should take place before calling the actual method.

In this case, we want to put a cache interceptor at the method level and keep the processing of caching, such as key generation, cache provider selection, etc. centralized. Here’s what that might look like.

    @Cached(timeToLiveSeconds = 3600)
    public Shop getShopsNear(Shop shop) {
        Shop returnShop;
        // query google maps api with shop data to get region
        // query database for region
        // calculate center of region
        // sort by distance from center
        returnShop = closestShopToCenter;
        return returnShop;
    }

The only change to your original method is the @Cached annotation. You also have the option of defining the duration of that data in the cache, or leave it out to use the default duration.

The method interceptor code deals with the selection of cache provider, key generation, etc. This makes cache evaluation fast and effortless. It also keeps your application code clear. Changes in the future are now easy to configure.

Getting Started

I’ve created an AOP caching for Guice project. Fork the code or use it as is.

References

My library is based on the initial work by bpoulson.

Software Engineering

Using Java to work with Versioned Data

A few days ago I wrote about how to structure version details in MongoDB. In this and subsequent articles I’m going to present a Java based approach to working with that revision data.

I have published all this work as an open source repository on github. Feel free to fork it:
https://github.com/dwatrous/mongodb-revision-objects

Design Decisions

To begin with, here are a few design rules that should direct the implementation:

  1. Program to interfaces. Choice of datastore or other technologies should not be visible in application code
  2. Application code should never deal with versioned objects. It should only deal with domain objects

Starting with A above, I came up with a design involving only five interfaces. The management of the Person class is managed using VersionedPerson, Person, HistoricalPerson and PersonDAO. A fifth interface, DisplayMode, is used to facilitate display of the correct versioned data in the application. Here’s what the Person interface looks like:

public interface Person {
    PersonName getName();
    void setName(PersonName name);
    Integer getAge();
    void setAge(Integer age);
    String getEmail();
    void setEmail(String email);
    boolean isHappy();
    void setHappy(boolean happy);
    public interface PersonName {
        String getFirstName();
        void setFirstName(String firstName);
        String getLastName();
        void setLastName(String lastName);
    }
}

Note that there is no indication of any datastore related artifacts, such as an ID attribute. It also does not include any specifics about versioning, like historical meta data. This is a clean interface that should be used throughout the application code anywhere a Person is needed.

During implementation you’ll see that using a dependency injection framework makes it easy to write application code against this interface and provide any implementation at run time.

Versioning

Obviously it’s necessary to deal with the versioning somewhere in the code. The question is where and how. According to point B above, I want to conceal any hint of the versioned structure from application code. To illustrate, let’s imagine a bit of code that would retrieve and display a person’s name and email.

First I show you what you want to avoid (i.e. DO NOT DO THIS).

Person personToDisplay;
VersionedPerson versionedPerson = personDao.getPersonByName(personName);
if (displayMode.isPreviewModeActive()) {
    personToDisplay = versionedPerson.getDraft();
} else {
    personToDisplay = versionedPerson.getPublished();
}
System.out.println(personToDisplay.getName().getFirstName());
System.out.println(personToDisplay.getEmail());

There are a few problems with this approach that might not be obvious based on this simple example. One is that by allowing the PersonDAO to return a VersionedPerson, it becomes necessary to include conditional code everyehere in your application that you want to access a Person object. Imagine how costly a simple change to DisplayMode could be over time, not to mention the chance of bugs creeping in.

Another problem is that your application, which deals with Person objects, now has code throughout that introduces concepts of VersionedPerson, HistoricalPerson, etc.

In the end, all of those details relate to data access. In other words, your Data Access Object needs to be aware of these details, but the rest of your application does not. By moving all these details into your DAO, you can rewrite the above example to look like this.

Person personToDisplay = personDao.getPersonByName(personName);
System.out.println(personToDisplay.getName().getFirstName());
System.out.println(personToDisplay.getEmail());

As you can see, this keeps your application code much cleaner. The DAO has the responsibility to determine which Person object to return.

DAO design

Let’s have a closer look at the DAO. Here’s the PersonDAO interface:

public interface PersonDAO {
    void save(Person person);
    void saveDraft(Person person);
    void publish(Person person);
    Person getPersonByName(PersonName name);
    Person getPersonByName(PersonName name, Integer historyMarker);
    List<Person> getPersonsByLastName(String lastName);
}

Notice that the DAO only ever receives or returns Person objects and search parameters. At the interface level, there is no indication of an underlying datastore or other technology. There is also no indication of any versioning. This encourages application developers to keep application code clean.

Despite this clean interface, there are some complexities. Based on the structure of the mongodb document, which stores published, draft and history as nested documents in a single document, there is only one ObjectID that identifies all versions of the Person. That means that the ObjectID exists at the VersionedPerson level, not the Person level. That makes it necessary to pass some information around with the Person that will identify the VersionedPerson for write operations. This comes through in the implementation of the MorphiaPersonDAO.

Download

You can clone or download the mongodb-revision-objects code and dig in to the details yourself on github.

Software Engineering

Wicket + Guice including unittests

Last week I spent way too much time integrating Apache Wicket and Google Guice. Yikes! The most difficult part for me was getting the initialization to happen in the right order. A big Thank You to Dan Retzlaff on the Wicket list for helping work through these details.

The details below were applied to a Wicket quickstart project for Wicket 6.0.0.

Design Decisions

It was important to me to keep the application tier separate from web tier. I actually maintain each in a separate repository. I have several motivations for this, such as:

  • Clean separation of concerns. In other words, prevent logic from ending up in my Wicket pages
  • Independent revisions and release cycles between web tier and application tier
  • Easier to divide work between scrum teams

I include the application tier into the Wicket front end as a jar. By the way, this also makes it easy to include my application tier into a Jersey REST interface and other legacy servlets.

It was also important to maintain a mock package for fast unittests. Since the data providers are managed in the application tier, the mock package lives there, further enforcing the separation of concerns.

Implementation Approach

After some experimentation I decided to use the GuiceServlet approach. I started by adding the following maven dependencies to my pom.xml for the Wicket quickstart.

        <dependency>
            <groupId>com.google.inject</groupId>
            <artifactId>guice</artifactId>
            <version>3.0</version>
        </dependency>
        <dependency>
            <groupId>com.google.inject.extensions</groupId>
            <artifactId>guice-servlet</artifactId>
            <version>3.0</version>
            <type>jar</type>
        </dependency>
        <dependency>
            <groupId>org.apache.wicket</groupId>
            <artifactId>wicket-guice</artifactId>
            <version>6.7.0</version>
            <type>jar</type>
        </dependency>

My web.xml defines only the GuiceFilter and a listener to initialize the injector when the servlet context is created.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
	version="2.5">
 
	<display-name>guicewickettest</display-name>
 
        <listener>
            <listener-class>com.danielwatrous.myapp.web.MyGuiceServletConfig</listener-class>
        </listener>
 
        <filter>
            <filter-name>guiceFilter</filter-name>
            <filter-class>com.google.inject.servlet.GuiceFilter</filter-class>
        </filter>
 
        <filter-mapping>
            <filter-name>guiceFilter</filter-name>
            <url-pattern>/*</url-pattern>
        </filter-mapping>
</web-app>

As you’ll see, this keeps configuration details in code, rather than XML. The web.xml remains simple. That brings us to the GuiceServletConfig, which is where we initialize the injector.

You may recall that listeners receive event notifications at well defined points in the life cycle of a web application or session. Here’s the MyGuiceServletConfig that’s referenced in web.xml:

package com.danielwatrous.myapp.web;
 
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.servlet.GuiceServletContextListener;
import com.danielwatrous.myapp.modules.MongoMyappModule;
 
public class MyGuiceServletConfig extends GuiceServletContextListener {
 
    @Override
    protected Injector getInjector() {
        return Guice.createInjector(new MyappServletModule(), new MongoMyappModule());
    }
 
}

The GuiceServletContextListener implements ServletContextListener, which ends up executing when the application context is created (or destroyed). This way we have the injector available before executing any application code.

Another thing you may notice is that I create the injector with two modules, not just one. The first module is the ServletModule, and I’ll show that to you in a minute. The next module is the application tier module that has been included as a jar in the Wicket application. The single injector available throughout the Wicket application will be able to inject servlet/Wicket related components in addition to application tier components.

Let’s have a closer look at MyappServletModule:

package com.danielwatrous.myapp.web;
 
import com.google.inject.Inject;
import com.google.inject.Provider;
import com.google.inject.Singleton;
import com.google.inject.servlet.ServletModule;
import java.util.HashMap;
import java.util.Map;
import org.apache.wicket.protocol.http.IWebApplicationFactory;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.protocol.http.WicketFilter;
 
public class MyappServletModule extends ServletModule {
    @Override
    protected void configureServlets() {
        filter("/*").through(WicketFilter.class, createWicketFilterInitParams());
        bind(WebApplication.class).to(WicketApplication.class);
        bind(WicketFilter.class).to(CustomWicketFilter.class).in(Scopes.SINGLETON);
    }
 
    @Singleton
    private static class CustomWicketFilter extends WicketFilter {
 
        @Inject
        private Provider<WebApplication> webApplicationProvider;
 
        @Override
        protected IWebApplicationFactory getApplicationFactory() {
            return new IWebApplicationFactory() {
                @Override
                public WebApplication createApplication(WicketFilter filter) {
                    return webApplicationProvider.get();
                }
 
                @Override
                public void destroy(WicketFilter filter) {
                }
            };
        }
    }
 
    private Map<String, String> createWicketFilterInitParams() {
        Map<String, String> wicketFilterParams = new HashMap<String, String>();
        wicketFilterParams.put(WicketFilter.FILTER_MAPPING_PARAM, "/*");
        wicketFilterParams.put("applicationClassName", "com.danielwatrous.myapp.web.WicketApplication");
        return wicketFilterParams;
    }
}

You may notice that I added a mechanism to provide WicketFilter with additional parameters. Next I bind my WebApplication and WicketFilter classes to specific implementations. The CustomWicketFilter overrides the typical behavior of the WicketFilter which usually takes a string reference to the WebApplication class. Instead it now uses the injected WebApplication object.

As you’ll see below, this step of injecting the desired WebApplication is critical to enabling unittests, primarily because it allows us to construct the WebApplication with an injector.

package com.danielwatrous.myapp.web;
 
import com.google.inject.Inject;
import com.google.inject.Injector;
import org.apache.wicket.guice.GuiceComponentInjector;
import org.apache.wicket.protocol.http.WebApplication;
 
public class WicketApplication extends WebApplication {    	
    private final Injector injector;
 
    @Inject
    public WicketApplication(Injector injector) {
        this.injector = injector;
    }
 
    @Override
    public Class<HomePage> getHomePage() {
        return HomePage.class;
    }
 
    @Override
    public void init() {
        super.init();
        getComponentInstantiationListeners().add(new GuiceComponentInjector(this, injector));
    }
}

At this point Wicket and Guice are successfully integrated. Let’s have a look at what needs to happen to make the unittests work.

Unittests

The only real change that’s required to make the unittests work is in the setUp function of the unittest. Since the WebApplication above was modified to receive an injector, all we need to do is create an injector and provide it at instantiation.

package com.danielwatrous.myapp;
 
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.danielwatrous.myapp.modules.TestMyappModule;
import com.danielwatrous.myapp.web.HomePage;
import com.danielwatrous.myapp.web.WicketApplication;
import org.apache.wicket.util.tester.WicketTester;
import org.junit.Before;
import org.junit.Test;
 
public class TestHomePage {
 
    private WicketTester tester;
 
    @Before
    public void setUp() {
        Injector injector = Guice.createInjector(new TestMyappModule());
        tester = new WicketTester(new WicketApplication(injector));
    }
 
    @Test
    public void homepageRendersSuccessfully() {
        //start and render the test page
        tester.startPage(HomePage.class);
 
        //assert rendered page class
        tester.assertRenderedPage(HomePage.class);
    }
}

You’ll notice in this case I create an injector that doesn’t include the ServletModule and uses the TestMyappModule. Since the Wicket unittests don’t operate within a full web context I don’t need the ServletModule. Additionally my TestMayappModule makes use of my mock package. This allows the tests to run without access to any external resources. It also keeps the tests very fast!

Wicket Pages

Accessing the injector in your Wicket pages is easy. All you need to do is inject it. Here’s how that looks:

package com.danielwatrous.myapp.web;
 
import com.google.inject.Inject;
import com.google.inject.Injector;
import com.danielwatrous.myapp.domain.QuickLink;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.request.mapper.parameter.PageParameters;
 
public class HomePage extends WebPage {
    private static final long serialVersionUID = 1L;
    @Inject private Injector injector;
 
    public HomePage(final PageParameters parameters) {
	super(parameters);
 
	add(new Label("version", getApplication().getFrameworkSettings().getVersion()));
 
        // TODO Add your page's components here
        QuickLink quickLink = injector.getInstance(QuickLink.class);
	add(new Label("quickLink ", quickLink.buildQuickLink()));
    }
}

Great Combination

After working through the particulars, this implementation feels clean and flexible. Configuration is in the code and benefits from compile time type checking. Unittests are working and fast with very little modification to the traditional Wicket approach, which keeps the application testable.

Resources:

http://apache-wicket.1842946.n4.nabble.com/Wicket-Guice-unittests-td4652853.html
https://gist.github.com/3880246

Software Engineering

Refactoring to interfaces

The information below was delivered to one of my programmers as direction for how to implement a rather big change in an existing software product that I sell. I thought it was potentially useful to a broader audience, so I’m posting it here:


…The rest of this is rather complicated to explain online. I’ll do my best. I’m going to look at this in a simplistic way and let you work through the details.

First imagine that we have an Authorize.net processing class based largely on their API.

class AuthnetProcessAIMPayment {
	protected $apiKey;
	protected $transactionKey;
	protected $x_first_name;
	protected $cardNumber;
	protected $expDate;
	protected $ccv;
 
	function __construct($apiKey, $transactionKey) {
		// initialize object instance
	}
 
	// getter and setter functions
	function setX_first_name ($x_first_name) {
		$this->x_first_name = $x_first_name;
	}
	function getX_first_name () {
		return $this->x_first_name;
	}
	...
 
	function execute () {
		// process payment here
	}
}

I could use this in a script like authnet_process.php

// get $myApiKey and $myTransactionKey values
$payment = new AuthnetProcessAIMPayment($myApiKey, $myTransactionKey);
$payment->setX_first_name("Daniel");
...
$payment->execute();

Now there’s a problem with this approach when it comes to extending our software. You’re about to create an integration with payflowpro. Let’s imaging that the payflowpro class looks like this.

classPayPalPayflowProPayment {
	protected $securityToken;
	protected $paypalEmailAddress;
	protected $name_first;
	protected $cardNumber;
	protected $expDate;
	protected $ccv;
 
	function __construct($securityToken, $paypalEmailAddress) {
		// initialize object instance
	}
 
	// getter and setter functions
	function setName_first ($name_first) {
		$this->name_first = $name_first;
	}
	function getName_first () {
		return $this->name_first;
	}
	...
 
	function execute () {
		// process payment here
	}
}

Here is what you’ll be tempted to do in authnet_process.php (but it’s a mistake)

$paymentProcessor = get_option("authnet_payment_processor");
if ($paymentProcessor == "authnet") {
	// get $myApiKey and $myTransactionKey values
	$payment = new AuthnetProcessAIMPayment($myApiKey, $myTransactionKey);
	$payment->setX_first_name("Daniel");
	...
	$payment->execute();
} else if ($paymentProcessor == "paypal") {
	// get $mySecurityToken and $myPaypalEmailAddress values
	$payment = new classPayPalPayflowProPayment($mySecurityToken, $myPaypalEmailAddress);
	$payment->setName_first("Daniel");
	...
	$payment->execute();
} else {
	// error out, invalid payment processor
}

There are a few problems with this. First is that you now have several lines of code that are almost duplicate to set name, cardNumber, etc. The other is that for each new payment processor (like bluepay coming up) you now add more conditionals. Conditionals increase the chances of bugs and they make the code less clear. Another problem is that the names for common values are likely to be different between implementations. For example, authnet may call it “x_first_name” and paypal might call it “name_first”. Even though you’re providing the same value to it, each payment processor class receives it a different way. This divergence can make it difficult to identify bugs and know which token to search for when you’re making changes.

The ideal that we’re looking for in this case is a solution that will allow authnet_process.php to remain the same regardless of how many payment processors we implement. In answer to one of your questions, we also want our settings interface to be as insulated as possible. In other words, we don’t want to have a different settings mechanism for each payment processor. In even other words, we want each payment processor to accommodate as many of the settings that we’ve already implemented, so that the user has the most seamless experience possible.

You can think of this as being similar to your autoresponder integration in subscription mate. That was done very well. and it didn’t bleed into other settings. You could change the autoresponder provider without requiring changes anywhere else.

So, how do we do this?

Wouldn’t it be great if we could just give a different processing object to authnet_process.php and it knew what to do with it? That’s exactly what we can do with interfaces. Dependency Injection (DI) can be a huge benefit too, but PHP isn’t wired for DI like other languaes, so let’s start with the interface.

An interface cannot be instantiated. Instead, all it does is say that anyone implementing the interface must provide certain functions. Mind you it doesn’t dictate how those functions should be implemented, but you must provide an implementation, even if it does nothing (e.g. a function that just adds a log entry or simply returns an empty value).

The mapping that you were tempted to do in the conditionals above, meaning mapping the clients first name on to one member function for authnet and another for payflowpro, should instead happen one time in the interface implementation.

Here’s what an interface for the above case might look like.

interface OneTimePayment {
	public function setName($name);
	public function getName();
	...
	public function execute();
}

The payment processing classes above would now look like this (I’m showing only the lines that would change).

class AuthnetProcessAIMPayment implements OneTimePayment {
	...
	// getter and setter functions
	function setName ($x_first_name) {
		$this->x_first_name = $x_first_name;
	}
	function getName () {
		return $this->x_first_name;
	}
	...
}

and for payflow pro

class PayPalPayflowProPayment implements OneTimePayment {
	...
	// getter and setter functions
	function setName ($name_first) {
		$this->name_first = $name_first;
	}
	function getName () {
		return $this->name_first;
	}
	...
}

Now that the method names to set and get a name are identical, the code within the conditionals really is duplicate. authnet_process.php can now be simplified to this:

$paymentProcessor = get_option("authnet_payment_processor");
if ($paymentProcessor == "authnet") {
	// get $myApiKey and $myTransactionKey values
	$payment = new AuthnetProcessAIMPayment($myApiKey, $myTransactionKey);
} else if ($paymentProcessor == "paypal") {
	// get $mySecurityToken and $myPaypalEmailAddress values
	$payment = new classPayPalPayflowProPayment($mySecurityToken, $myPaypalEmailAddress);
} else {
	// error out, invalid payment processor
}
// once you create the object, everything after this 
// point can assume it's dealing with a OneTimePayment
// insead of a specific payment processor
$payment->setName("Daniel");
...
$payment->execute();

At this point, even if that conditional grows to accommodate additional payment processors, each one adds only a handful of lines of code to get authentication values and create the object. None of the work to set values and execute transactions will ever need to change, since it treats everything like a OneTimePayment.

How could DI make this even better?

I haven’t seen any good DI frameworks for PHP. In some ways it goes a bit against the grain for PHP development. If there were, this might be how authnet_process.php would look.

$payment = diFramework.get(OneTimePayment);
$payment->setName("Daniel");
...
$payment->execute();

Elsewhere in the DI framework you would define what a concrete instance of OneTimePayment should be. In other words, something like this might be in an XML file (Spring like) or a module (Guice like).

bind(OneTimePayment).to(AuthnetProcessAIMPayment);

Now, anytime you ask for a OneTimePayment, you’ll get an AuthnetProcessAIMPayment object. Similar injection can be used to provide the authentication values, so that in authnet_process.php you really only ask for a OneTimePayment and you get back a functional, ready to use object.

Refactoring

Refactoring is a key aspect of developing software. In this case, where we started with code that creates instances of Authnet classes and uses them directly, changes to authnet_process.php will be necessary. Changes will also be necessary to the Authnet classes to conform with the new interface that we come up with. That may sound like a lot of work.

It is a lot of work, and may actually be more work than just creating a payflowpro class and adding the conditional that I showed at the top. However, there are some concrete benefits and gains we get from doing this additional work.

First is that once the work is done and authnet_process.php uses the interface based calls, all future changes for new payment processors will be very small and won’t functionally endanger any working code for other payment processors.

Second is that there’s a clear scaffolding for adding new payment processors. You can still add as many private internal functions as are necessary and desired to create an “execute” function, but you know that you need one and when it’s done it will work anywhere in your app that you call execute.

Third unittests can more easily test new payment processors without duplicating a lot of code. You simply provide a different OneTimePayment implementation and run the same test. Test coverage stays high and maintenance remains low.

Where do you start?

The best place to start is by coming up with the interface. You want to look at all the values that the current implementation needs and ask if it can be generalized. For example, “x_first_name” might prompt you to design for “first_name” in your interface. A quick check with the documentation for the other payment processor(s) will help you arrive at a comprehensive interface.

Next, make the changes to the Authnet classes so that they implement the new interface(s). Finally work with your code until the unittests pass.

Now you’re ready to implement the interface for payflowpro. As soon as you have done that, you run your unittests and provide an instance of your payflowpro OneTimePayment object.

Once you’re done there and have passing unittests, move on to authnet_process.php.

At some point you’ll need to modify the settings page so that you can provide payflowpro credentials rather than authnet. I really like how you did multiple autoresponder vendors in subscription mate, so I would suggest that as a possible approach for this.

Feel free to create a branch and be daring. You have the security of unittests and the isolation of a branch in svn. If you end up with a mess the first time through, you can start over. I personally think you’ll do great.

Software Engineering

WordPress plugin licensing: Choose a Java framework

How frameworks came to be

Engineers have a few potentially conflicting tendencies that can become very pronounced in the software they write. One tendency is that we’re empire builders. In other words, we build, enhance, improve and in other ways expand the scope of our software solutions over time. Not to mention that we want our solution to be accepted, embraced and adored as the best possible solution for the problem we set out to solve. The result of this tendency can be seen in the ever growing, ever more complex frameworks available today.

The other tendency is to be overly critical of the software solutions created by other engineers. Sometimes this critical nature comes out as mild concerns related to difficult to test aspects like scalability. At other times it may come out as fundamental objections to the framework architecture. However severe the criticism, many engineers decide to start fresh and build something entirely new that fits their style. The result of this can be seen in the large variety of frameworks available to solve very similar problems.

Two projects that illustrate the points above are the Spring framework based on Rod Johnson’s work, and Google’s Guice framework. Both embrace dependency injection (inversion of control), but they disagree on implementation. While Spring has become an empire, Guice claims to want to remain small and lightweight.

It is very interesting that the tendencies I’ve just discussed have been the subject of academic research. Recently, the Harvard Business School published a paper they entitled “The IKEA effect: When labor leads to love”, referring to the furniture retailer. They found that “When people construct products themselves, from bookshelves to Build-a-Bears, they come to overvalue their (often poorly made) creations”.

You can read this research yourself: Harvard Business Review summary of IKEA effect or ready the full IKEA Effect paper.

I’m not suggesting that frameworks are poorly made. On the contrary, some of them are very mature, show great insight and can save the developer many hours of work and greatly improve the end results of his efforts. What does concern me at times is the quasi-religious adoration some developers afford a particular framework. Before becoming a satellite to a framework, a developer should ask whether it’s a fit for the problem he has in front of him.

Much of the same reasoning applies to discussion of programming languages. Expertise in one language should not rule out other language possibilities if a new problem justifies a new approach.

Do I have to use a framework?

One might ask if it is necessary at all to use a framework. Martin Fowler has encouraged the use of plain old java objects (POJO) for business logic. Rod Johnson’s efforts have the objective of reducing coupling with a framework.

The purpose of the framework is to provide an abstraction for lower level libraries. This often includes scaffolding necessary to perform some common or frequent tasks. Everything that you can do in the framework can also be done directly in plain Java code, but the framework may save you time.

For example, Hibernate may make access to a datastore more object friendly. Spring may make integration more descriptive. GWT can both accelerate the development life cycle for rich web clients and at the same time reduce risk in deployment with Java compile time checks and cross browser issues taken care of.

The complexity of the problem I’m trying to solve will often determine whether or not I use a framework, and which framework might be a fit. If my application will have very little javascript then I probably don’t need GWT (or even jQuery). If there will be very few interface pages and session management is minimal then I probably don’t need Wicket. There are cases when jsp pages with simple includes are more than adequate and even more appropriate.

More on frameworks

I really liked this presentation I came across while looking into frameworks http://www.slideshare.net/mraible/comparing-flex-grails-gwt-seam-struts-2-and-wicket-presentation

Framework choice for WordPress plugin licensing

The focus of the current project is to create an easy to use RESTful API that will enable license generation and verification. That means there is very little Javascript and so GWT seems a poor fit. At this stage I’ve also eliminated Seam and Flex for Java.

Since Google App Engine for Java is the target for initial deployment, I did a review of many of the popular remaining popular frameworks available to see how well they play with GAE. In some cases, this might be a good time to reevaluate the choice of GAE and possibly lean toward Amazon EC2 if there were a compelling reason to choose a framework that didn’t perform as well on GAE.

The most interesting frameworks are wicket and Spring, but due to the low complexity and native support the first iteration of my application will use basic servlets and jsp.