A desire path is what a person wants rather than what an architect builds. The term desire path originated from landscape architecture, but it’s an increasingly important concept for software architects to grasp. If you understand desire paths, you understand the future of software development.

Large corporations are often slow to respond to change. In no space is this more evident than technology. If you’re a developer and have used both ClearCase and Git(Hub) for version control, you know exactly what I’m talking about. The big business version of source control is painful to use compared to the next generation of light and nimble apps crafted by small or open source development shops. Git and GitHub are a true pleasure to work with, while ClearCase is known to cause nightmares, paranoia, insomnia, dry mouth, anxiety attacks, and lethargy. (They should put a warning label on the box, just sayin’.)

This is a fairly accurate portrait of the future of software and software development; an increasingly polarized space where the next generation of software developers duke it out with their predecessors. A space where resting on your laurels may mean going out of business or watching your professional software development career come to an abrupt end. A space where developing crappy applications will get an organization or developer laughed out of the industry. A space where kids who grew up with a laptop in their baby crib become consumers (and even the heads of corporations) and have a completely different expectation of what software should do.

Yeah, that’s a bit general. Let’s get specific. Mobile computing will continue to have a profound impact on how users interact with apps. More users are turning to native applications: think Twitter, Facebook, etc. How many people use Twitter’s web UI? Hardly any. Most people use a native application instead. Desktop and laptop computers are slowly being outnumbered by PDAs, cell phones, tablets, and a variety of other gadgets, especially outside of North America where cost is a much bigger issue. Web-based user interfaces are becoming less important while APIs are becoming more important. Don’t get me wrong, web-based interfaces will be around for quite a long time, but users will depend on them less. If software were fashion, APIs would be the new black.

Integration and continuous improvement are becoming the two most important aspects of software development today, and will only increase in importance over the next decade. Simple, light, extensible, and integrated; big bang development may continue, but smart companies realize that there is no such thing as a finished application. Applications are no more finished than the people who build them! Think evolution rather than revolution. “Application oriented” development will replace “object oriented” development in terms of developer mindset.

The gap between the haves and the have nots will grow significantly. Organizations that fail to adapt will fall quickly behind their more adaptable competition and bleed market share.

Flexibility is key. Your architecture must be flexible enough to adapt to the changing whims of the marketplace in a moments notice. Flexibility has always been important, but five years from now, it could mean the difference between your organization being #1 or being out of business.

Don’t dictate to your users, listen to them, and let them guide your design, not the other way around. Anyone who keeps this in the back of their mind is already ahead of the curve and ready for the changing software landscape.

if (statusIsNotValid.compareTo( Boolean.FALSE ) != 0) skipValidation = false;

I don’t know what’s more shocking, that someone who calls themselves a professional programmer wrote that piece of… whatever… or that it wasn’t clubbed to death like a baby seal during a code review. If you ever find yourself working in a team that doesn’t see the importance of code reviews, remind them that they could easily wind up with a few million lines of… that.

(Taken from The Daily WTF.)

This tutorial will show how to painlessly integrate Uploadify and Java using Apache Wicket. You should have at least beginner-level knowledge of Wicket before moving forward, but feel free to dive right in even if you’ve never used Wicket before. (If you haven’t used Wicket before, I can’t suggest it strongly enough for developing stateful Java-based web applications.)

A number of excellent Flash-based multiple file upload plugins are available, including the excellent Uploadify. Uploadify is essentially a jQuery wrapper for SWFUpload. I already use jQuery quite extensively so I chose Uploadify as my multiple upload plugin, but if you use a different JavaScript framework or simply prefer plain old JavaScript, SWFUpload might be a better choice.

The only catch is that most of these plugins are geared towards PHP developers/apps and not all that intuitive to integrate with Java-based solutions.

A few more things to consider: Before jumping in with both feet, the use of Flash is a stopgap measure until HTML5 is more widely supported. HTML5 supports the attribute “multiple” in the input tag, offering true native multiple file upload support. Also, with Apple fully throwing its weight behind HTML5 and actively attacking Flash, it’s only a matter of time before Flash-based solutions go the way of the bond market in Greece.

While HTML5 supports the attribute “multiple” in the input tag, browser support for HTML5 is far from ubiquitous. To make matters worse, the HTML5 standard won’t officially be signed off on until 2022. Yes, 12 more years, and yes, it’s completely insane, but you know how design-by-committee works.

Getting Started

Preamble complete, let’s get down to business. Our strategy will be to create a re-usable Apache Wicket “multiple file upload” component. In our case, because we will be re-using both Java code and HTML, we’ll create a Wicket panel to do this.

Step 1 – Dependencies

We don’t need everything included in the Uploadify download. We’ll create new packages for the components, CSS, and scripts, and cherry-pick the Uploadify artifacts to copy to the new project. Depending on how you have Wicket configured, your scripts, CSS, and HTML files may be separate from Java source files. The default in Wicket is to place them together in the same package, so we’ll be using that paradigm for this tutorial. When you’re done with the tutorial, your package hierarchy will look something like below.

Step 2 – Re-usable HTML

The next step is to create the HTML for our Panel. Create a new file called UploadifyPanel.html with the following source:

<wicket:panel>
 
<div id="fileQueue">
	<p><strong>Click browse to select files for uploading.</strong></p>
	<p><em>To select more than one file, hold down control or shift.</em></p>
	<p><input type="file" name="uploadify" id="uploadify" /></p>
</div>
 
</wicket:panel>

Most of what you see above is standard HTML and CSS. The only item of note is the input tag, which will be replaced with the Flash component by the Uploadify script. If the user does not have Flash installed, the above input tag will be used as-is without replacement, so make sure the tag is valid for graceful downgrading.

If you want to enhance the tutorial, you should use Wicket’s excellent localization support to add fully configurable dynamic text to the re-usable component.

Step 3 – Java components for re-usable Panel

UploadifyPanel.java

package org.rocketpages.wicket.component.uploadify;
 
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.JavascriptPackageResource;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.util.template.TextTemplateHeaderContributor;
 
public class UploadifyPanel extends Panel {
 
private static final long serialVersionUID = 1L;
 
    public UploadifyPanel(String id, UploadifyPanelBehaviour behaviour) {
 
	super(id);
 
	add(JavascriptPackageResource.getHeaderContribution(UploadifyPanel.class, 
		"scripts/swfobject.js"));	
 
	add(JavascriptPackageResource.getHeaderContribution(UploadifyPanel.class, 
		"scripts/jquery.uploadify.v2.1.0.js"));
 
	/* TextTemplateHeaderContributor performs text substitution of values located
	 in multiupload.js with the values obtained from the behaviour, and
	 inserts the processed .js in the header. */
	add(TextTemplateHeaderContributor.forJavaScript(
		UploadifyPanel.class, "multiupload.js", behaviour.getVariables()));
 
	add(CSSPackageResource.getHeaderContribution(UploadifyPanel.class, 
		"css/uploadify.css"));
    }   
}

For those of you familiar with Wicket, most of this will look straightforward enough. We’re encapsulating all of our configuration variables in a behaviour, which keeps our code clean and generic. Of special interest is the call to TextTemplateHeaderContributor.forJavaScript(). This is a handy little method that allows you to pass in a Map of variables (key/value) and a reference to a JavaScript file. This results in token substitution in the JavaScript file based on the values in the Map. It’s much more simple than performing manual string concatenation to achieve the same result.

UploadifyPanelBehaviour.java

package org.rocketpages.wicket.component.uploadify;
 
import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
 
import org.apache.wicket.RequestCycle;
import org.apache.wicket.markup.html.resources.CompressedResourceReference;
import org.apache.wicket.model.AbstractReadOnlyModel;
import org.apache.wicket.model.IModel;
 
public class UploadifyPanelBehaviour implements Serializable {
 
    private String fileExt = "";
    private String fileDesc = "";
    private String sizeLimit = "";
 
    //manditory
    private final String formTokenId;
    private final String formSessionId;
 
    private Class<? extends UploadifyFileProcessPage> fileProcessPageClass;
 
    public UploadifyPanelBehaviour(Class<? extends UploadifyFileProcessPage> fileProcessPageClass, String tokenId, String sessionId)
    {
	this.fileProcessPageClass = fileProcessPageClass;
	this.formSessionId = sessionId;
	this.formTokenId = tokenId;
    }
 
    /**
     * Sets the valid file extensions for the uploader.
     * 
     * Do not include leading or trailing quotes, only semi-colon
     * separated wildcards. 
     * 
     * Example usage:
     * *.doc;*.docx;*.pdf;*.jpg;*.png;*.zip
     * 
     * @param validExts
     */
    public void setFileExt(String validExts)
    {
	this.fileExt = validExts;
    }
 
    /**
     * Sets the message to be displayed when selecting files.
     * 
     * Example message:
     * Select files of type .doc, .pdf, .jpg, .png, or .zip
     * 
     * @param fileDesc
     */
    public void setFileDesc(String fileDesc)
    {
	this.fileDesc = fileDesc;
    }
 
    /**
     * Sets the size limit, in bytes.
     * 
     * Example: 3072000
     * 
     * @param sizeLimit
     */
    public void setSizeLimit(String sizeLimit)
    {
	this.sizeLimit = sizeLimit;
    }
 
    /**
     * Builds a variables model in order to perform text substitution
     * on values located in JavaScript (multiupload.js)
     * 
     * The key values in the Map must match the tokens in the .js file. 
     * 
     * @return
     */
    protected IModel getVariables() {
 
	IModel variablesModel = new AbstractReadOnlyModel() {
	    public Map getObject() {
 
		Map<String, CharSequence> variables = 
		    new HashMap<String, CharSequence>();
 
		//Mandatory configuration
		variables.put("uploader", RequestCycle.get().urlFor(new CompressedResourceReference(UploadifyPanel.class, "scripts/uploadify.swf")).toString());
		variables.put("cancelImg", RequestCycle.get().urlFor(new CompressedResourceReference(UploadifyPanel.class, "cancel.png")).toString());
		variables.put("script", ";jsessionid=" + formSessionId + RequestCycle.get().urlFor(fileProcessPageClass, null));
		variables.put("tokenId", formTokenId);
 
		//Optional configuration
		variables.put("fileExt", fileExt);
		variables.put("fileDesc", fileDesc);
		variables.put("sizeLimit", sizeLimit);
 
		return variables;
	    }
	};
 
	return variablesModel;
    }
}

The behaviour captures configuration options, which correspond to the available options within Uploadify. You can add more configuration options (or remove some) depending on your specific requirements.

Another quirk to pay attention to is the token and session id values. This is a kludge we’ve added to avoid the messy problem of Flash losing a reference to the HttpSession. Because the end result of this script will be a call to a stateless page to process our uploads, we’ll need some way to retrieve the user’s session. Because of this, we need to include the session ID as a value in the JavaScript file and pass this as a parameter to our stateless file processing page.

Finally, make special note of the class we’re passing to our behaviour object. We do this because Wicket needs to “mount” our stateless file processing page so it can be accessed by the plugin. Wicket instantiates the page “just in time”, not before, otherwise it would hang around in memory doing nothing (kinda like a TTC collector). Note the call to RequestCycle.get().urlFor().

UploadFileProcessPage.java

package org.rocketpages.wicket.component.uploadify;
 
import java.util.Map;
 
import javax.servlet.http.HttpServletRequest;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.Session;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.http.WebRequest;
import org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest;
import org.apache.wicket.util.lang.Bytes;
import org.apache.wicket.util.upload.FileItem;
 
import com.stuffahoy.UserSession;
import com.stuffahoy.data.pojo.user.User;
import com.stuffahoy.services.impl.UserServiceImpl;
import com.stuffahoy.wicket.component.security.FormToken;
 
public abstract class UploadifyFileProcessPage extends WebPage {
 
    protected User user;
 
    public UploadifyFileProcessPage(PageParameters params) {
	HttpServletRequest r = ((WebRequest) RequestCycle.get().getRequest()).getHttpServletRequest();
	try
	{
	    MultipartServletWebRequest r2 = new MultipartServletWebRequest(r, Bytes.MAX);
 
	    Map paramMap = r2.getParameterMap();
	    String[] tokenIdParms = (String[]) paramMap.get("tokenId");
 
	    String tokenId = tokenIdParms[0];
	    UserSession session = (UserSession) Session.get();
	    FormToken token = session.getFormToken();
 
	    if (token.isValid(tokenId, r.getRemoteAddr()))
	    {
		long userId = session.getUser().getId();
		user = new UserServiceImpl().getUser(userId);
 
		for (FileItem fi : r2.getFiles().values())
		{
		    processFileItem(fi);
		    fi.delete();
		}
	    }
	    else
	    {
		throw new Exception("Invalid token!");
	    }
	}
	catch (Exception e)
	{
	    e.printStackTrace();
	}
    }
 
    protected abstract void processFileItem(FileItem fileItem) throws Exception;
}

In order to bridge our plugin with Java, we’re creating a stateless page by extending WebPage. This base code is fairly straightforward, pulling out the file data from the request, and passing it to the yet-to-be-defined abstract method processFileItem(). The only other thing to note is the token logic. This is simply an example/placeholder to draw your attention to security when dealing with jsessionid directly. This leaves a small window open for hackers to perform a session hijacking, so in our scenario, we associate a jsessionid with an IP address and an additional token value.

multiupload.js

$(document).ready(function() { 
	$('#uploadify').uploadify({ 
		'uploader':  '${uploader}', 
		'script':	'${script}',
		'scriptData': {'tokenId': '${tokenId}'}, 
		'folder': '/var/photos/stuffahoy', 
		'cancelImg': '${cancelImg}',
		'fileExt' : '${fileExt}',
		'fileDesc' : '${fileDesc}',
		'sizeLimit' : '${sizeLimit}',
		'auto': true,
		'multi': true,
		onAllComplete: function(event, queueID, fileObj, response, data) {
                    uploadCompleted(); 
                }
	}); 
});

If you’re familiar with JavaScript, you’ll see we’re essentially passing an object to the uploadify() method. The key values of the object correspond to the Uploadify options. The token values on the right correlate to our behaviour class and the key values we defined. Text substitution is done on these when we include the JavaScript file via the call to TextTemplateHeaderContributor.

Step 4 – Business Logic

AddPhotosProcessingPage.java

package com.stuffahoy.wicket.page.addstuff;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.form.upload.FileUpload;
import org.apache.wicket.util.upload.FileItem;
import org.rocketpages.wicket.component.uploadify.UploadifyFileProcessPage;
 
import com.stuffahoy.data.pojo.thing.Photo;
import com.stuffahoy.services.PhotoService;
import com.stuffahoy.services.impl.PhotoServiceImpl;
 
public class AddPhotosProcessingPage extends UploadifyFileProcessPage {
 
    public AddPhotosProcessingPage(PageParameters params)
    {
	super(params);
    }
 
    @Override
    protected void processFileItem(FileItem fileItem) throws Exception
    {
	//Wrap the Apache Commons FileItem type in a Wicket FileUpload type
	FileUpload upload = new FileUpload(fileItem);
 
	//Get a service reference, store the photo, and create a new Photo record
	PhotoService photoService = new PhotoServiceImpl();
	Photo photo = photoService.saveUploadedPhoto(upload, true);
	photo.setUser(user);
	photoService.savePhoto(photo);
    }
 
}

This is our actual stateless page that extends our more generic file processor. The code is an example of business logic you may execute on each file. In this case, we’re processing image files, so we pass the file reference to a service which in turn writes the file to disk (or Amazon S3, etc) and persists the information in our database.

AddPhotosPage.java

package com.stuffahoy.wicket.page.addstuff;
 
import javax.servlet.http.HttpServletRequest;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.ResourceReference;
import org.apache.wicket.Session;
import org.apache.wicket.ajax.AbstractDefaultAjaxBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.behavior.IBehavior;
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.image.Image;
import org.apache.wicket.protocol.http.WebRequest;
import org.rocketpages.wicket.component.uploadify.UploadifyPanel;
import org.rocketpages.wicket.component.uploadify.UploadifyPanelBehaviour;
 
import com.stuffahoy.UserSession;
import com.stuffahoy.pages.loggedin.UserRoleSuperPage;
import com.stuffahoy.wicket.component.photoselect.UnprocessedPhotosPanel;
 
public class AddPhotosPage extends UserRoleSuperPage {
 
    private static final long serialVersionUID = 1L;
 
    private Label noPhotosLabel;
 
    public AddPhotosPage(final PageParameters parameters) {
	this();
    }
 
    public AddPhotosPage() {
 
	super(null);
 
	add(CSSPackageResource.getHeaderContribution(AddPhotosPage.class, 
		"css/AddPhotosPage.css"));
 
	UserSession session = (UserSession) Session.get();
	long userId = session.getUser().getId();
 
	HttpServletRequest r = ((WebRequest) RequestCycle.get().getRequest()).getHttpServletRequest();
	session.createFormToken(r.getRemoteAddr());
 
	String tokenId = session.getFormToken().getToken();
	String sessionId = session.getId();
 
	// Configure the panel
	UploadifyPanelBehaviour behaviour = new UploadifyPanelBehaviour(AddPhotosProcessingPage.class, tokenId,
		sessionId);
	behaviour.setFileExt("*.jpg;*.jpeg;*.gif;*.png");
	behaviour.setFileDesc("Select files of type *.jpg, *.jpeg, *.gif, *.png");
	behaviour.setSizeLimit("3000000");
 
	add(new UploadifyPanel("uploads", behaviour));
 
	final UnprocessedPhotosPanel unprocessedPanel;
	add(unprocessedPanel = new UnprocessedPhotosPanel("unprocessedPhotos", userId));
	unprocessedPanel.setOutputMarkupId(true);
 
	final Label noPhotosLabel;
	add(noPhotosLabel = new Label("noPhotosLabel", "You haven't uploaded any new photos!"));
	noPhotosLabel.setOutputMarkupId(true);
 
	if (unprocessedPanel.getUnprocessedPhotosCount() > 0) {
	    noPhotosLabel.setVisible(false);
	}
	else {
	    noPhotosLabel.setVisible(true);
	}
 
	final IBehavior repaintBehavior = new AbstractDefaultAjaxBehavior() {
	    @Override
	    protected void respond(AjaxRequestTarget target)
	    {
		// this repaints the list view
		// this requires your model to always get the most
		// up-to-date list
		if (unprocessedPanel.getUnprocessedPhotosCount() > 0) {
		    noPhotosLabel.setVisible(false);
		}
		else {
		    noPhotosLabel.setVisible(true);
		}
 
		target.addComponent(noPhotosLabel);
		target.addComponent(unprocessedPanel);
	    }
 
	    @Override
	    public void renderHead(IHeaderResponse response)
	    {
		super.renderHead(response);
		CharSequence callback = getCallbackScript();
		response.renderJavascript("function uploadCompleted() { " + callback + "}", "customUploadCompleted");
	    }
	};
 
	add(repaintBehavior);
 
	add(new Image("easy", new ResourceReference(AddPhotosPage.class, "easy.png")));	
    }
}

This example is a little long-winded, but it ties everything together and shows a few key concepts. Most interesting is our ability to asynchronously invoke a piece of code when all uploads are complete by using Wicket’s fantastic built in Ajax support. We do this by creating a new repaintBehaviour object and overriding both respond (which contains the actual code we want to invoke asynchronously) and renderHead (which injects this callback method inside our HTML).

Other than that, most things are quite straightforward. We tie everything together by configuring our behaviour object and instantiating the processing page.

Conclusion

Enabling true multiple upload support is fairly straightforward with the Flash plugins readily available. Uploadify is my favourite, but there are a ton to choose from. Integrating with Apache Wicket is a piece of cake, and as always, Wicket just makes life a little easier for Java developers.

In the past, companies relied on putting out a solid product or offering a quality service. Their internet presence may have been a little clumsy and unreliable, but customers were willing to forgive a painful online experience. After all, doing business on the internet was something that very few companies were doing perfectly. There was a time when a mediocre online presence was better than no online presence at all.

Times have changed. Customers have high expectations of web applications, and especially web applications that take their money. A failed transaction on the internet is no less frustrating than a failed transaction at a brick and mortar store.

The entire end-to-end customer experience surrounding a product or service is just as important as the product or service itself.

An interesting quote that comes to mind about this subject is from Gordon Ramsey, who waxes poetically about quality in his own special way:

“It doesn’t matter how amazing the steak is, if it’s served on a cold plate it’s crap. If it’s served with a dull knife it’s crap. If the gravy isn’t piping hot, it’s crap. If you’re eating it on an uncomfortable chair, it’s crap. If it’s served by an ugly waiter who just came in from a smoke break, it’s crap. Because I care about the steak, I have to care about everything around it.“

We take for granted how seamless doing business on the internet usually is. I’ve been buying and selling online since Amazon first opened their doors. In them old days (less than 10 years ago), things were pretty sketchy. Transactions failed routinely and websites often provided a frustrating customer experience. Things have changed significantly since then. Now when I do business online it almost always just works. But once in awhile a company does the equivalent of serving a beautiful steak on a cold plate, with a dull knife, by a waiter who ashed all over my gravy.

A real life example

I recently tried to buy a product from Native Instruments via their online shop. I downloaded a trial version of Guitar Rig 4 Pro, used it, and loved it enough that I decided that I wanted to give them $199 USD of my hard earned money. They obviously spent a lot of time producing a nice demo to entice a purchase, but they dropped the ball on a crucial aspect of the purchase chain; their online shop. I wanted to start rocking out, immediately. I wanted to pay them.

Convincing a customer to give you money is the hard part.

Taking it should be easy.

I’ve bought a number of excellent music-related products over the internet from wonderful companies including XLN Audio, iZotope, Ableton, and the list goes on. Software companies are, generally speaking, remarkably good at making sure customers have no problem giving them money. They are software companies, after all, it’s their bread and butter. Their web-based software should be of the same quality as the rest of the software they produce and sell.

Trying out the demo version

First off, Guitar Rig 4 Pro rocks. I wanted to give my money to Native Instruments so I could party like it was 1999. I took the demo version for a spin and fell in love. The demo version clearly explains how to go about becoming a paid customer:

So far, so good. The dialog clearly communicates the ordering options. I can either go to the store (reseller), or grab a copy from the online shop. Obviously, I decide on the online shop. I want to rock out, now! I’m figuring it’s a simple credit card transaction before I can click on that nice little Activate button and be well on my way to playing arenas!

Spending money

I click Buy, and instead of being taken to a page specifically related to purchasing Guitar Rig 4, I was taken to their main site. Interesting. They’ve just put multiple steps in between their customer and their customer’s money. This is always a bad idea from a usability perspective. If you’re selling a product or service online, repeat after me: taking money should be easy. As few clicks as possible. Keep it simple. Regardless, I find what I’m looking for quick enough, the download version of Guitar Rig 4 Pro.

I make my selection and attempt to check out. I enter all of my personal details, my credit card information, and complete the multi-step check out process. I anxiously await a serial number, or at least the promise of a serial number. I’m mere moments away from rocking out!

Instead, catastrophe! I’m redirected to an error page that instructs me to contact order support. I don’t receive any kind of e-mail notification of the error, or even a helpful phone number to call. Not even a link to an order support contact form! Just a cryptic sentence, “contact order support.”

At this point I have no idea what stage of the transaction failed. Was the error related to processing my credit card? Was the transaction itself successful but an error occurred during acknowledgment? Did something go horribly wrong and they’re shipping a boxed version to me instead? At this point I simply want to cancel the entire transaction and go buy a boxed version from a retail outlet, but I don’t want to wind up owning two copies of Guitar Rig 4 Pro, as much as I like it. I obediently fill out the support form to enquire about the error. I anxiously await a response. Here’s part of the automated response letter I receive a few moments later:

“Dear Customer,

thanks for your e-mail. A new ticket has been created for your request. We will reply to your request as soon as possible.
We are currently reorganizing our whole Order Management System in order to provide you with an even better and improved service. Due to the complex technical migration, delays in delivery and billing can emerge in individual cases.
We are working intensely on the fluent implementation of the new system, and we would like to apologize for possible inconveniences.”

This response brings up a few interesting points concerning the end-to-end customer experience of an e-commerce site:

• Always provide a clear timeframe for a human response. Expectations count. Will a response arrive within an hour? 24 hours? A business day? 48 hours? A month? “As soon as possible” is about the same as “whenever we feel like it”.
• Technical debt is evil. Native Instruments incurred technical debt with their existing ordering system and are “working intensely on the fluent implementation of the new system”. Their technical debt is bad enough that they communicate it to all customers that request support. Decisions like this are organizational, and can always be avoided. There’s no need to ever be in a position that a major overhaul of any system is required to simply keep the lights on.
• Be like Oz. Sometimes it’s better for the wizard to hide behind the curtain. It’s perfectly alright not to tell your customers everything about your internal systems. Then again, customers don’t care what lurks behind the curtain when your systems actually work.
• Simple things should be simple. We’ve been accepting payments over the interweb for well over a decade. This is trivial stuff. Don’t focus so intensely on the difficult aspects of your business (such as developing a guitar amp simulator) that you’re forced to neglect the easy stuff (providing prompt responses to support enquires).
• Don’t make your problems your customer’s problems. Native Instruments is obviously having issues with their payment system. The technical migration of their online system is complex. They told me all about it! All of a sudden their complex technical migration became my problem. Fix problems, don’t explain them. Obviously, nothing is perfect, and once in awhile issues crop up that demand solutions. Having spent over a decade developing web-applications for banks, I’ve dealt with my share of technical issues that required immediate solutions. If a “payment system” was so broken that we felt compelled to offer an explanation in an auto-response e-mail, we would have simply shut it down until the problem was resolved. And trust me, we would have been working rotating 24/7 shifts to get the payment system back to full health.

At the bottom of the auto-responder e-mail I received is a phone number, so I decided to call it.

“Native Instruments North America, Inc.
5631 Hollywood Blvd.
Los Angeles, CA 90028
USA
http://www.native-instruments.com

Tel +1.866.556.6487
Fax +1.866.556.6490″

Unfortunately, no go. I’m from Canada. That 1-866 number they sent me is only reachable from the USA. Even though I entered my location information on their support contact form, they still provide me with a support number that I’m unable to reach.

• Make sure the entire experience of your site is custom tailored to your customers. If you ask for personal details, use them. Small details count. If you ask for someone’s full name, use it in all your communications with them, including auto-response e-mails.
• Localization counts. The world is a small place. It’s not USA-centric. It should be easy and clear for customers to contact you no matter where they live. If your 1-800 number only works in the USA, but your customer lives in South America, make sure to provide them with a number they can actually call.

Doing it right

Companies like Rackspace get customer service right. They go even further than providing prompt e-mail and phone support; they provide live, 24/7, human-to-human text chat via their site with guaranteed response times. These types of services are available for next to nothing for any site and are a great way to boost customer satisfaction. Get Satisfaction is another company whose entire purpose is customer support, or more accurately, customer-centric support.

Doing it wrong

After digging around on the Native Instruments site a little while longer, I found a local Los Angeles number to call for support. I dialed them up and dug through the menu options, finally to be told that “all available operators are busy” and that if I’m calling during regular business hours to “try again later”.

No thanks. I’m at the point where it’s easier to deal with the credit card company if anything funky shows up on my statement.

Moral of the story? Pay attention to the entire customer experience. Every single detail that surrounds the product or service you offer is just as important as the product or service itself. You usually only get one shot to take someone’s money. The hard part is convincing them to give it to you to in the first place. Don’t refuse to accept it.

Don’t get me wrong. Native Instruments produces some wonderful software. Guitar Rig 4 Pro is awesome, which is why I wanted to buy it in the first place. I just wish the plate they served it on was warmer, the chair was more comfortable, and the waiter didn’t ash all over my gravy.

The outcome

I sent the e-mail to order support over a week ago and still haven’t heard back from Native Instruments. The great thing about the internet is that a competing product is never far away…

Luckily for me, IK Multimedia recently released AmpliTube 3. I hadn’t tried the demo out before I attempted my Guitar Rig purchase, but holy f#!@, am I glad I found this thing! I’ve never heard tone like it, it’s amazing! The box shot sums up exactly how I feel right now…

Sometimes you only get one chance to make a sale. Sometimes you get a second chance. If you screw both up, remember that there’s always a competing company ready to take your customer’s money.

Also remember that no matter how good your product is, the entire experience surrounding the purchase and ongoing use of a product is just as important as the product itself. Coffee shops manage to get this right, otherwise we’d all be drinking 25 cent coffee at home.

Building great software requires all of these things, albeit nothing is perfect. There is no perfect methodology, language, or tool. At times we focus so much on the most complex things that we forget how to do the most simple things, like designing software that people actually enjoy using. In some large organizations it can feel like a single line of code is a million miles away from the person using the application. In some large organizations it can feel like everyone is more interested in delivering projects than applications, meeting targets rather than delivering an amazing user experience.

Good developers always try to deliver amazing software in spite of these obstacles. The perfect methodology for our team may not integrate well with the rest of the organization. The perfect programming language may be unknown to most developers on the team. The perfect architecture may require three months to develop but the deadline is three weeks away. Eventually we discover a harmonious balance between pragmatism and idealism, or we struggle to produce quality software. How does a team who is forced to compromise eventually triumph and deliver software that is reliable, easy to maintain, and a pleasure to use?

Morale.

I recently watched the movie Che by Steven Soderbergh. I’m trying to avoid writing a lame analogy that compares software development to war, I’ve heard them before; I worked with a guy that served in the military briefly, or at least dreamt that he did. He endlessly compared software development to building an aircraft, taking off in an aircraft, piloting an aircraft, dropping bombs from an aircraft, eating a snack in an aircraft, and landing an aircraft. I never did quite figure out what he was talking about, but I assure you I’m not going to compare software to a plane. Or a bomb. Or snacks.

That being said, a specific quote from the movie Che caught my attention:

“In War and Peace, Tolstoy remarks that military science assumes that the bigger the army, the stronger it is. On the other hand, only vaguely do they recognize that during military combat the final strength of an army is also its true physical capacity multiplied by one unknown x. This x is none other than the spirit of the troops measured as the greater or lesser desire to fight and confront danger. Men with the desire to fight, who also understand why they are fighting, regardless of who they are fighting, whether under the command of military geniuses or those of normal intelligence, fighting with clubs or with machine guns that fire thirty rounds a minute, these men will put themselves under the most advantageous conditions for fighting and they will triumph.”

The effect morale has on team performance is staggering.

I once worked on a project that was practically doomed to failure from the very beginning. The design had been bounced around and re-assigned from developer to developer like a hot potato. It was underfunded, underestimated, and practically written off by upper management. All of a sudden the client had to have it delivered yesterday. By the time our team took over, it resembled a stray cat that had been sleeping in an alley for five years. The team was feeling low, real low, but we had one previously unknown x on our side. Our manager. For the next eight weeks, he refused to go home if a member of the development team was still at work. He brought us dinner, checked to see if we needed coffee, offered unrelenting encouragement, and stood up for us when upper management wondered why it hadn’t been completed ten days before we even started. A number of small gestures added up to become something much larger. He understood the constraints we were under, but more importantly, we knew that he understood. He didn’t just understand from an ivory tower perspective, he understood from a human perspective. He understood the toll the project took on our time with our families, on our hobbies, and on our sleep. He reminded us that there was a light at the end of the tunnel. We did our absolute best under some fairly dismal circumstances, and we eventually succeeded as a team.

Obviously, it’s impossible to work under these conditions forever. But working with a great team, with a great manager, and on projects you believe in will give you the motivation to push through some fairly insane obstacles; even the corporate-imposed inertia variety.

Another quote from the movie Che:

“A real revolutionary goes where he is needed. It may not be direct combat. Sometimes it’s about doing other tasks; finding food, dressing wounds, carrying comrades for miles, and then taking care of them until they can take care of themselves.”

A real developer feels the same way. So does a real architect, and a real manager. Sometimes it’s not about the task of writing code, but the task of helping others. When I was first starting out in development, I came to work feeling under the weather. I didn’t want to miss a day and burden the team. It was brutal cold outside, so my manager brought me lunch without even asking if I needed anything; she remembered that I always went across the street to buy it. She refused to take my money when I offered to pay her back. She also reminded me that I was part of a team, and that coming to work sick was counterproductive. If everyone else became sick, we would be far worse off than if I had taken some time off to get better. I never forgot those small gestures. Eventually she was promoted higher up the corporate hierarchy, and trust me, I did everything in my power to help along the way. From that day forward I was her code ninja assassin. Moral of the story? Morale. It’s no different than a developer staying late to help out another developer, a tester learning how to automate regression tests, or an architect digging into code if the team is behind schedule. Teams with high morale do all of this. Teams with low morale, regardless of any technological or process advantages, do none of this. Teams with low morale stick to job titles and commuter schedules. High performing teams recognize and foster a culture of support rather than rewarding the heroic efforts of any one individual superstar.

I don’t think there is a one-size fits all approach to boosting morale. There are some universal, common sense things that everyone should do, like treating people with respect, asking questions instead of pointing fingers when things go wrong, and making sure to acknowledge people when they lend you a helping hand. But everyone has a different agenda at work, so something that boosts my morale may have the opposite effect on someone else. Some folks only write code for the paycheque, while others are passionate about development and really want to make great software. As a manager, I think it’s critical to identify who is who and assign them to the right roles. Empower the people with passion and they will constantly strive to make the organization better. Assign the paycheque developers to tasks that need to get done but aren’t very challenging or interesting (assuming you can’t simply replace them, which is easier said than done). As a developer, you can do great things if you work with a great team, a great manager, and on projects you believe in. Cut yourself loose if all three of these conditions aren’t met, otherwise you’re just wasting time.

Motivated people with high morale will always put themselves under the most advantageous conditions to succeed, regardless of the challenges they face.

“Aries will offer an enterprise OSGi application programming model that enables applications to leverage Java EE and other enterprise technologies and to benefit from the modularity, dynamism and versioning capabilities of OSGi.”

This is fantastic news! OSGi is quite an amazing technology, but even though mature, lacks support in the enterprise world due to a lack of application server support. The support for enterprise OSGi looks to be increasing, especially when you see the organizations represented in the committer list: LinkedIn, IBM, SAP, etc. One of the issues affecting the adoption rate of OSGi is the lack of commercial app server support; in other words, the inability to hot-deploy an OSGi bundle in your favourite app server.

A few more noteworthy highlights:

• “A significant feature of Aries will be a container for OSGi Blueprint components – an implementation of the new OSGi v4.2 Blueprint component model that defines a standard dependency injection mechanism for Java components, which is derived from the Spring framework and extended for OSGi to declaratively register component interfaces as services in the OSGi service registry.”

• • It looks like the functionality provided by Spring DM (Dynamic Modules) is part of the official spec now. This is nice, because one of the challenges with plain old OSGi is managing the availability and injection of service references. The interesting thing is that this functionality will be offered by the container in a standard way (for portability between runtimes). <MrBurns>Excellent…</MrBurns>

• “Message-driven Blueprint components.”

• • This is very interesting, because one of the challenges with OSGi is the dynamic nature of services. Dealing with dynamic services synchronously with no guarantee a bundle is running can be challenging. Even with Spring as a proxy to the real OSGi service, there’s always the dilemma of how long is a reasonable amount of time to wait for an unavailable service. For operations that aren’t critical, handling them asynchronously is the way to go; fire, forget, call me back later.

• “Federation of lookup mechanisms between local JNDI and the OSGi service registry.”

• • Either I’m misinterpreting what they mean by federation, or it sounds like they’re building a layer of abstraction on top of the OSGi service registry and the JNDI registry. What I’m not quite clear on is if they’re providing a new API, or if OSGi lookups will be done via the JNDI API. I’m hoping it’s the latter.

• “the Geronimo blueprint sandbox .. contains an implementation of the OSGi Blueprint container which will be moved to Aries..”

• • The OSGi Blueprint container being moved from Geronimo to Aries is significant in the fact that, theoretically, Aries can be run on any Java EE app server. This would be huge and take away a major roadblack to OSGi adoption for most people. Simply put, deploying OSGi applications to productive is either too complicated (if you want to embed and make use of Java EE features), or too limiting (running natively and losing out on EE + container managed everything).

In this tutorial we’re going to set up an OSGi container, create a sample OSGi bundle that uses the Wicket framework, and deploy the bundle to our container.

Hello, OSGi

As modular as your code is at compile and build time using super-creative archiving and package-naming cleverness, all your objects wind up in the same bowl of runtime soup. It’s kind of like taking the time to cook a wonderful meal, only to throw it in a blender before serving it. Sure, creating modular Java applications is possible without OSGi by creating a physical or logical separation between components; packaging classes in different EARs/WARs, and/or the tried-and-true “common artifact” bundle. Sounds great, but the logical separation achieved by the common artefact strategy dissolves at runtime. Creating a true physical separation via distributed communications (WS, REST, etc) cleanly separates entities at runtime, but comes with a performance penalty. Also, the latter strategy only works for webapps; embedded or desktop apps can’t make use of distributed communications. Imagine if all the Eclipse plugins you have installed needed to communicate via WS* or REST?

All we really need is a way to modularize our runtime environment in the same way we do with our build artifacts.

Enter the dragon: OSGi.

Cleanly separated bundles. Hidden internal classes. Explicitly defined inter-bundle dependencies. I’m so happy! It’s like plain old Java, but zen. I hear WebSphere, JBoss, et al. are built on top of OSGi containers now. How about I go ahead, create an OSGi bundle, deploy it to my most favourite-ist enterprise app server, and celebrate with some Doritos and Cherry Coke!

Wait… there’s a catch.

At the present time, OSGi doesn’t have the tooling and app server support as of now to make it a reasonable solution for most enterprise web development projects. There, I said it. :p

One of the interesting facts about the current generation of app servers is that while most vendors have spent a huge amount of effort and resources refactoring their offerings and building them on OSGi containers, the developers using said app servers cannot take advantage of all this internal vendor OSGi goodness. At the time of this writing, the only enterprise app server ready to gobble up your OSGi bundles is the SpringSource dm Server. It supports both complete OSGi bundle support (RFC-124) and also OSGi web bundles (RFC-66). The folks at IBM and Oracle (BEA) haven’t bothered to pass on all the OSGi goodness to mere mortals like myself who actually develop and deploy functional web applications for a living.

So… if you work at a massively-massive corporation like I do, you’re probably using an app server from one of the big-boys (WebSphere, Weblogic, or something equally enterprise-y). Introducing a new app server to your production environment isn’t going to happen for technological reasons. Unless you’re lucky and have more flexibility than most of us (or work at a small company), I recommend looking at OSGi in terms of long-term strategic planning rather than a short-term tactical decision. So, why am I spending time with OSGi then? As soon as the major app server vendors start to fully support OSGi, the shift towards this technology will be fast and totally rational (in my humble opinion). In other words…

OSGi is fantastic!

The lack of server support is the only thing holding back the OSGi adoption rate. I highly recommend learning and using OSGi for specific projects; just be careful not to commit “design-by-buzzword” and clobber together a half-baked OSGi solution into your enterprise ecosystem.

With that said, building an OSGi-fied “Hello World” Wicket app seems like a good first step towards OSGi nirvana!

Word of warning: Most of this tutorial relies on the magic provided by Spring DM. My understanding is that as of version 2.0, Spring DM will deprecate support for web bundles and Tomcat / Jetty integration in favour of supporting official OSGi standards. Basically, this means that Spring DM will expect your OSGi container to provide these services (RFC-66 specifically). Make sure to use Spring DM 1.2.x or above, but not 2.x.

Apache Wicket

Wicket makes it cool to be a Java developer again, seriously! Apache Wicket is simply the most fun and productive UI framework I’ve ever worked with. Yes, that’s a strong statement, but it’s true! I wish Wicket happened a decade ago. Until now Java developers have been burdened with overly complex view technologies (like JSF) that almost guaranteed the success of lightweight frameworks like RoR and Grails.

Beyond the cool factor, Wicket finally gives us Java-heads an opportunity to take a deep breath and harness the epic (and underutilized) powers of our tasty Java + OOA/D knowledge… and we can wield these powers on the UI now. Holy doodle!

Tutorial (On with the show!)

Before we go much further, I assume you have a working-level knowledge of both OSGi and Wicket and are looking to wire them together without using any magic. If you’re completely new to OSGi, I recommend reading this article.

And don’t forget to check out the Wicket site if you’re new to Wicket.

Step 1: Get your OSGi container Tomcat-ified

We’re going to make a few assumptions. The first is that you’re going to use Pax Construct rather than create OSGi bindings and configuration files by hand, the second is that you’re going to use Apache Felix as your OSGi container, and the third is that you’re going to use Tomcat as your Java/JSP container.

Pax Construct is like the Yoda of OSGi development. It simply does stuff. Epic stuff. Learn it, know it, love it. There is also a project called Pax Wicket that you may want to check out. It accomplishes a different goal that what I’m going for, which is simply trying to decide if A) Wicket would even work in an OSGi container, and B) If it was worth the effort to explore deeper. The answer is yes, and yes!

Step 2: Creating a new OSGi project

Okay, so enough with the preamble. Let’s get rolling.

• Download and install the latest version of Pax Construct from here. At the time of writing, the latest version is 1.4.
• Make sure you have Maven installed and configured properly.
• Execute the following at your command line to create your OSGi project:

  pax-create-project -g org.itypeincaps -a osgilywicket -v 1.0-SNAPSHOT

• Add Java 1.5 support to your Maven POM. Edit the pom.xml file in osgilywicket root and add:

  <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-compiler-plugin</artifactId>
     <configuration>
       <source>1.5</source>
       <target>1.5</target>
     </configuration>
  </plugin>

Step 3: Add the SpringSource OSGi bundle repository

A significant number — the majority — of dependencies are not distributed as proper OSGi bundles. However, SpringSource has a repository with a number of OSGi bundles.

Check to see if the version of your dependency exists in the SpringSource repository first. For instance, if you want to use version 1.4.3 of Wicket, check SpringSource first. If it exists, fantastic. If it doesn’t, you’ll need to use Pax Construct to wrap the non-OSGi JAR obtained from the original source. Before we worry about wrapping JARs, we need to make a few changes to our Maven build file to locate the proper repositories.

• Cut and paste (or use the pax-add-repository command) to add the following repositories to the pom.xml file in your main project folder:

  <repositories>
    <repository>
      <id>com.springsource.repository.bundles.external</id>
      <name>SpringSource Enterprise Bundle Repository - External Bundle Releases</name>
      <url>http://repository.springsource.com/maven/bundles/external</url>
    </repository>
    <repository>
      <id>com.springsource.repository.bundles.release</id>
      <name>SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases</name>
      <url>http://repository.springsource.com/maven/bundles/release</url>
    </repository>
    <repository>
      <id>spring-osgi</id>
      <url>http://s3.amazonaws.com/maven.springframework.org/osgi</url>
    </repository>
  </repositories>

• Execute the following four commands at the command line:

  pax-import-bundle -g org.apache.commons -a com.springsource.org.apache.commons.logging -v 1.1.1
  pax-import-bundle -g org.springframework.osgi -a catalina.osgi -v 6.0.16-SNAPSHOT
  pax-import-bundle -g org.springframework.osgi -a catalina.start.osgi -v 1.0.0
  pax-import-bundle -g org.springframework.osgi -a servlet-api.osgi -v 2.5-SNAPSHOT

• Now you should have a functioning Tomcat instance running in your OSGi container. To test:

  mvn pax:provision

• Point a browser at http://localhost:8080 and you should get a blank page. If you do, you’re ready to move forward. The blank page is good. If you get anything other than a blank page, uh-oh! Game over? Not quite, inspect your console output.

Step 4: Wicket up that container!

If you take a look in the SpringSource OSGi repository, you’ll notice a version of Wicket exists. Unfortunately, it’s old. Real old. 1.3.3 to be exact. So the real question is how do you bundle the latest version of Wicket so it works properly in OSGi-land?

We need to build our own OSGi-fied Wicket bundle, of course!

We’ll use Pax Construct to help us get off on the right foot. pax-wrap-jar is a handy feature that allows us to wrap a regular JAR as an OSGi JAR by properly creating an OSGi manifest. Luckily, Pax Construct does this for us (or at the very least gets us off on the right foot).

• Wrap the latest version of Wicket (which is 1.4.3 at the moment of this writing):

  pax-wrap-jar -g org.apache.wicket -a wicket -v 1.4.3

• We’ll need to make some changes though. The manifest that pax-wrap-jar creates is virtually empty and not quite what we’ll need for Wicket to properly work as a bundle. maven-bundle-plugin to the rescue! If you want to learn more read this article. Otherwise, let’s proceed to wrapping a JAR.

Step 5: Wrapping a JAR

Most of the time executing pax-wrap-jar is sufficient for getting a regular JAR ready to be dropped into your OSGi container. But I always like to understand the library I’m using, and most importantly figure out what packages it needs to import and export. It’s possible Wicket will work fine without the next steps, but I recommend doing this simply as a learning exercise.

Instead of starting from scratch, we’ll take a look at the manifest in the OSGi-fied Wicket JAR at SpringSource.

The next three steps are optional. If you want to fast-track, skip them and proceed to editing your pom.xml.

• Download the binary version and extract it.
• Take a look at the manifest, it will give us a very good idea about what imports need to be done. Don’t worry about exports, because the maven-bundle-plugin will help us take care of that.
• If you try copying the list of imports as-is, it will fail. So we’ll need to add sun.misc and sun.reflect to the imports. We’ll make these optional, because the sun.* packages are only available on Sun JDKs, and I like to keep things vendor agnostic whenever possible.

If you hack around on your own, you’ll probably wind up with a maven-build-plugin configuration like below. This will go inside the pom.xml created inside the wrapped JAR folder.

• When you wrapped the jar, it created a new folder called org.apache.wicket in your OSGi project root. This folder contains a pom.xml file.
• Copy the plugin config below to the pom.xml file:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>1.4.0</version>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}
            </Bundle-SymbolicName>
            <Bundle-Name>${pom.name}</Bundle-Name>
            <Bundle-Version>${pom.version}</Bundle-Version>
            <Bundle-ClassPath>.</Bundle-ClassPath>
            <Import-Package>sun.misc;resolution:=optional,
              sun.reflect;resolution:=optional,
              javax.crypto,javax.crypto.spec,javax.imageio,
              javax.portlet;resolution:=optional,javax.servlet;version="[2.5.0,
              3.0.0)", javax.servlet.http;version="[2.5.0, 3.0.0)",
              javax.swing.event,javax.swing.text,javax.swing.tree,
              javax.xml.parsers,javax.xml.transform,javax.xml.transform.stream,
              junit.framework;version="[3.8.2, 4.0.0)";resolution:=optional,
              org.slf4j;version="[1.5.0, 2.0.0)",org.w3c.dom,org.xml.sax
            </Import-Package>
          </instructions>
        </configuration>
      </plugin>
    </plugins>
  </build>

• Try an mvn install from the wrapped JAR folder (org.apache.wicket). If everything goes smoothly, execute an mvn pax:provision from the project root folder. Ensure the bundle starts up successfully and the Wicket bundle is active.

We’ll need to resolve some runtime issues before going much further. If you fire up your OSGi container, it looks like slf4j is going to be an issue, so let’s add it. If you take a look at the import package instructions, it appears that Wicket depends on 1.5.0. Lucky, there’s an already OSGi-fied version at SpringSource.

• Execute the following command:

  pax-import-bundle -g org.slf4j -a com.springsource.slf4j.jcl -v 1.5.0 -- -DimportTransitive -DwidenScope

• It’s very important that you don’t import two different slf4j bindings at the same time, otherwise you’ll receive a nasty StackOverflowError surprise. Check out the slf4j manual for more info.
• Now if you run mvn pax:provision, everything should start up nicely.
• We also need to make sure Tomcat can handle JSP, as Wicket requires this. Execute the following two statements on the command line:

  pax-import-bundle -g org.springframework.osgi -a jasper.osgi -v 6.0.16-SNAPSHOT
  pax-import-bundle -g org.mortbay.jetty -a jsp-api-2.1 -v 6.1.14

Step 6: Install Spring DM

If we just try to go ahead and fire up our webapp without Spring DM, nothing very exciting will happen. We need to install the Spring DM web extender; that’s where the real magic happens. To make a long story short, the Spring DM web extender checks for WAR bundles deployed to your OSGi container and automatically deploys them to embedded Tomcat or Jetty instance. It’s the glue that ties your WAR bundle to your JSP/Servlet container in the world of OSGi. An OSGi standard does exist so in the future containers will take care of this themselves, but for now, Apache Felix does not support this automatically. Just remember that it doesn’t matter if your app does not using the Spring framework, you still need Spring DM.

• First, install the Spring DM Web Extender with the Maven switch to pull in all dependencies. We’ll also install the Spring Web bundle.

  pax-import-bundle -g org.springframework.osgi -a spring-osgi-web-extender -v 1.2.0 -- -DimportTransitive -DwidenScope
  pax-import-bundle -g javax.el -a com.springsource.javax.el -v 1.0.0
  pax-import-bundle -g org.springframework -a org.springframework.web -v 2.5.6.A

Step 7: Creating our Hello World bundle!

Now we’re going to create a new WAR bundle. We’ll create our Hello World OSGi bundle using Pax Construct. But we’ll need to modify the automatically generated Maven build settings in order to properly package our OSGi bundle as a WAR file instead of the default JAR file. Luckily, there is a Maven plugin available that makes this task fairly trivial.

• Execute the following command to create a new Wicket Hello World project:

  pax-create-bundle -p osgilywicket.web -n wicket-helloworld.war -g org.itypeincaps -v 1.0-SNAPSHOT

• Spring DM used to rely on the project name ending with .war in order for it to pick up and deploy it properly. You may be able to name it something else, but I can’t guarantee this will work. If anyone can verify if this is no longer the case, please leave a comment.
• Next we’ll make the necessary modifications for WAR packaging. The main thing to understand is how to package your bundle as a war file. If you’d like more details about this, check out this article.
• Add the following to the pom.xml file in the your Hello World bundle root folder:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <executions>
          <execution>
            <id>bundle-manifest</id>
            <phase>process-classes</phase>
            <goals>
              <goal>manifest</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <supportedProjectTypes>
            <supportedProjectType>jar</supportedProjectType>
            <supportedProjectType>bundle</supportedProjectType>
            <supportedProjectType>war</supportedProjectType>
          </supportedProjectTypes>
          <instructions>
            <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
            <Bundle-Version>${pom.version}</Bundle-Version>
            <Export-Package>${bundle.namespace}.*;version="${pom.version}"</Export-Package>
            <_include>-osgi.bnd</_include>
          </instructions>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <archive>
            <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestfile>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>

• Change the packaging type from bundle to war in pom.xml:

  <packaging>war</packaging>

• Make Wicket available to the webapp by adding this to the pom.xml:

  <dependency>
    <groupId>org.apache.wicket</groupId>
    <artifactId>wicket</artifactId>
    <version>1.4.3</version>
    <scope>provided</scope>
  </dependency>

• Create the following web.xml under src/main/webapp/WEB-INF:

  <?xml version="1.0" encoding="ISO-8859-1"?>
    <web-app xsi:schemalocation="http://java.sun.com/xml/ns/j2ee
      http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://java.sun.com/xml/ns/j2ee">
   
    <display-name>HelloWorld</display-name>
   
    <context-param>
      <param-name>contextClass</param-name>
      <param-value>org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext</param-value>
    </context-param>
   
    <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
   
    <filter>
      <filter-name>wicket.wicketTest</filter-name>
      <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
      <init-param>
        <param-name>applicationClassName</param-name>
        <param-value>org.itypeincaps.osgilywicket.WicketApplication</param-value>
      </init-param>
    </filter>
   
    <filter-mapping>
      <filter-name>wicket.wicketTest</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
   
  </web-app>

• Create the following applicationContext.xml under src/main/webapp/WEB-INF. For some reason I was having a hell of a time with XSD validation (more on this later), so I grabbed this from one of Matt Riable’s excellent demos as a sanity check just to make sure I wasn’t losing my mind.

  <?xml version="1.0" encoding="UTF-8"?>
  <beans xsi:schemalocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
      http://www.springframework.org/schema/osgi
      http://www.springframework.org/schema/osgi/spring-osgi.xsd" xmlns:osgi="http://www.springframework.org/schema/osgi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans">
   
      <!--osgi:reference id="jobsBPS"
          interface="org.appfuse.bps.api.MyBPS" timeout="10000" cardinality="0..1"/-->
   
  </beans>

• Edit osgi.bnd to import all necessary packages. In order for our XML config files to pass XSD validation we need to make the factory package available:

  Bundle-ClassPath: .,WEB-INF/classes
  Import-Package: *,org.springframework.web.context,\
  org.springframework.osgi.web.context.support,\
  org.springframework.beans.factory.xml
  Web-ContextPath: osgi

• Optional step. Take note of line 4 above. For those of us behind a proxy or without a connection to the internet, a strange anomaly exists with Spring that makes it impossible for the applicationContext schema to validate. This package may not be required for everyone, but I’m going to put it here for the heck of it. Plus, I really dislike the idea of relying out external resources simply to fire up my app, so this ensures we keep all validation dependencies local. Just keep in mind as you build your app, you should include the package names of your XSD files required by any Spring XML configuration files. If you don’t, your container will connect to the net during XSD validation, which may significantly increase the amount of time required during app startup. Keep in mind that for those of us behind a proxy, your OSGi container will need to be properly configured to support your proxy settings. For those using Apache Felix, take a look at the Apache Felix usage documentation.
• Optional step. As above, an error exists when trying to validate schemas with no web connection available. Those of us behind a proxy are the most likely to notice the problem. The workaround is to extract spring.handlers and spring.schemas and place them in the src/main/webapp/META-INF folder of your bundle. This is a particularly distasteful kludge, so hopefully the issue is resolved and this step is unnecessary by the time you’re reading this.

Now we need to create the standard Wicket stuff in order for our page to actually do anything. This step will seem fairly trivial compared to everything we’ve done so far. We’ll create three new files in the source folder of our project using the package name org.itypeincaps.osgilywicket. We’ll need our main Wicket application file (WicketApplication.java), and our component Java/HTML pair (Index.java and Index.html).

• WicketApplication.java

  package org.itypeincaps.osgilywicket;
   
  import org.apache.wicket.Page;
  import org.apache.wicket.protocol.http.WebApplication;
   
  public class WicketApplication extends WebApplication {
   
      @Override
      public Class<? extends Page> getHomePage() {
          return Index.class;
      }
  }

• Index.java

  package org.itypeincaps.osgilywicket;
   
  import org.apache.wicket.markup.html.WebPage;
  import org.apache.wicket.markup.html.basic.Label;
   
  public class Index extends WebPage {
      /**
       * Constructor
       */
      public Index()
      {
          add(new Label("message", "Hello OSGi-land!"));
      }
  }

• Index.html

  <html>
      <head>
          <title>Wickety OSGi!</title>
      </head>
      <body>
          <p wicket:id="message">replace me</p>
      </body>
  </html>

The moment of truth has arrived. Execute an mvn install in your bundle folder, execute another mvn install in your OSGi (root) project folder, execute an mvn pax:provision to fire up your container, and see if it works. Fingers crossed!

Step 8: Fire it up!

It looks like we’re finished! Go ahead and launch your OSGi container, open your browser, and point to http://localhost:8080/osgi. If you see Hello World!, that means our great success journey has come to a successful conclusion. If not, download the full working example, peer review at your convenience, and let me know if I forget a step somewhere along the way.

I used TextMate as my editor when writing this tutorial. If you’d like to use Eclipse, execute the following command to create your project files. Then you can simply import your Hello World bundle as an existing project.

mvn pax:eclipse -DdownloadSources=true -DdownloadJavadocs=true

Final thoughts on OSGi and Wicket

If you made it this far, congratulations. You may also be wondering if this “stack” is ready for prime-time, enterprise, mission critical production applications. The short answer is no. The long answer is not quite yet.

OSGi does a number of things amazingly. I won’t go into the benefits of OSGi, because I assume if you got this far you already know what they are. :p The problem isn’t with OSGi as a technology, the problem is with the adoption rate of vendors. If the big commercial app server vendors — mainly IBM and Oracle (BEA) — would provide world-class OSGi support in their products for developers, I think a lot of us would jump all over OSGi. As you may have figured out from this tutorial, putting together a functional OSGi stack with your favourite UI framework is a bit of a hassle. And we’ve only tackled a development stack. Putting something like this into production would be a disaster without some major securing and planning for load + availability. The other option of embedding OSGi inside your webapp (which is the complete opposite of what we did here) is also simply too kludge-y for most organizations to greenlight.

With all of that being said, I wouldn’t hesitate to use a Wicket/Spring/OSGi stack for complex internal applications. (For trivial internal applications, OSGi is overkill; use PHP or RoR or Grails or… something else!)

Moving into 2010, dynamic Java is going to play a major role in new enterprise development. Even though we have to do a lot more work than we should to get our environment ready, the benefits of OSGi are enormous, and the configuration tedium will slowly die down as tooling and server support become more mature.

Janie Chang at Microsoft Research wrote an excellent article recently that touched on the same subject. (A Mac-owning Java developer reading a Microsoft Research blog? Seriously!)

To quote Janie, “the system will resemble the organization building the system”. I agree with this assertion completely. Team culture and structure can vary widely even within the same organization. Over the past ten years I’ve worked in a variety of teams, some that were incredibly flexible and passionate (a strong focus on best practices, evolving processes, geographically distributed workforce, engaged developers), and others that are quite reluctant — or unable — to change (Waterfall to the core, local workforce, no telecommuting or flex-hours, rigid processes owned at a high-level of the organization, disengaged developers). In my experience I’ve always noticed that flexible and adaptable organizations produce flexible and adaptable applications. Rigid and inflexible organizations tend to produce rigid and inflexible applications. Co-incidence?

Another interesting observation Janie made is how the geographical distance of team members affects software quality.

I’ve worked in teams that have varying opinions on this. One team in particular stressed telecommuting as the norm; if you didn’t have a face-to-face meeting, you were encouraged to work wherever you felt you’d be the most productive that day. For me, telecommuting isn’t that big of a deal; I live and work downtown, so I usually walk to work. But rolling out telecommuting had a noticeable, positive impact on my co-workers. They seemed much less stressed and much more engaged. As one put it, “I could spend three hours in the car, or an extra hour coding and two extra hours with my kids”. My own experience in this team was extraordinarily positive. Instead of measuring success by the number of hours spent at a desk, the team measured success by results. Communication was a highly-valued skill and team members tended to communicate heavily — via Skype, instant messaging, and the regular old telephone. Actually, the team tended to communicate with each other more when they were out of the office than when they were in the office. I still can’t explain this one, but Janie mentioned the same phenomenon, “Most people preferred to talk to someone from their own organization 4,000 miles away rather than someone only five doors down the hall but from a different organization. Organizational cohesiveness played a bigger role than geographical distance.” The days that everyone spent together at the office together simply re-enforced the overall cohesiveness of the team.

On the flip side, I’ve worked in a team where the motto was, “If your job could be done from home, your job could be done from India”. Needless to say the organizational structure was rigid, and so were the applications they produced; not necessarily the fault of the developers, they were just completely disengaged due to an old-school mentality towards software development. It’s essentially the difference between an industrial age management style versus an information age management style. Time versus results.

This leads me to believe that while the technology itself is a critical aspect of a project, organizations that fail to innovate structurally and culturally as well as technically are failing to see the big picture.

SOA has become one of the most commonly-heard buzzwords around the water-cooler over the past few years. It seems like everyone is talking about SOA these days. Architects, developers, business folks, management, non-management, and everyone in-between. I hear about SOA more than I hear about AJAX and Web 2.0 put together. I wouldn’t be surprised if my Dad calls me up out of the blue to chat about SOA — and he sells shopping carts; the real ones made of metal, not the e-ones!

I love nothing more than applying an elegant solution to a difficult problem, but I’m concerned when a misunderstood solution is applied to an unknown problem.

At the root of SOA are some extremely useful technologies. An average SOA stack includes: services, a service registry, some form of orchestration, data transportation and transformation (whether done with an ESB or not), persistence, authentication and authorization, administration, event notification, business intelligence, and governance.

You may disagree with my above list. “Are you kidding, ESB is SOA! Why didn’t you mention Quality of Service? Are you sure you mean orchestration, or do you mean choreography?” Those are potentially valid points. The thing is, I’m not really all that concerned about what true SOA should be, but whether or not SOA, pieces of SOA, or something entirely different is the most appropriate technical solution to a business opportunity.

I’m by no means an SOA expert. I’ve been involved in a number of WS initiatives, and one project with the SOA label applied to it. I also spent a month attending training sessions provided by Software AG on their webMethods product. Recently I’ve attended a number of strategy sessions to come up with an SOA migration path for our department.

To me, this is what SOA is not: a silver bullet, an easy way to pay off years of accumulated technical debt, the answer to all your prayers, a way to double your business in 24 hours, a way to get rich quick, the magic diet that will help you lose weight but still allow you to eat as much pie as you want, something you have to deliver. Yet, when I speak to friends and colleagues about SOA, this is how it’s being communicated. Interestingly enough, in some cases it’s being pushed by business rather than the technical staff. At first glance this may sound reasonable; after all, it’s a good thing for a business case to exist when spending millions of dollars. But the scary thing is the way it’s being marketed. “Company X just unveiled their SOA solution, we need one to stay competitive…”

If you take a look at the technology stack I listed above, none of the concepts or technologies are particularly complex or difficult. But wiring them together to accomplish a specific business objective is complicated, especially when crossing organizational boundaries. From my (albeit limited) SOA experience, the most difficult aspect of an SOA project is governance, and one that I’m shocked to see so overlooked.

Is true SOA simply too ambitious for most companies to deliver? Is it a clash of paradigms? Most organizations undertaking SOA initiatives are, at their heart, stove-piped; siloed departments with siloed applications and processes. Can an architecture whose goal is to promote rapid adaptation to changing business conditions and flexibility work in an organization whose entire structure is reluctant to adapt and inflexible by nature? These are questions I can’t answer, but questions I’m surprised more people aren’t asking.

My opinion is this: unless the stakeholders of an SOA initiative can provide clear and reasonable ROI estimates at specific milestones of an SOA migration, the project is most likely doomed to failure. If I bought a bus ticket and the destination read “You’ll know when you get there”, I’d ask for a refund.

Unfortunately, SOA itself will be blamed for the failure of SOA initiatives. Until the SOA buzzword became so hot, I’d never heard of a project funded without specific business objectives: reduce support costs; prepare for increased usage; provide a new business feature that would generate X number of new customers; generate X amount of new revenue per customer, and so forth. On the flip side, I’ve chatted with a number of friends who are involved in SOA projects, and most of them can’t figure out what the actual, concrete, measurable goals of their SOA initiatives are.

I think SOA will become a bad word sooner or later. Next time someone mentions SOA, focus less on the acronym and more on the spirit of what you’re trying to accomplish. Paying attention to the latest and greatest buzz is important, but just be careful not to commit “design by buzzword”.

Oh, and if you think an ESB is going to solve all your problems, I’ve got some magic beans to sell you.

http://neilbartlett.name/blog/osgibook/

I’m about half-way through so far, a fantastic read. It’s great to see self-published books like this. Maybe one day I’ll move to a log cabin and work on my own masterpiece.