FrontPage Feature

Digg This!

Page 1 of 3   next page »

The Jedi mind trick is a Force power that can influence the actions of weak-minded sentient beings. Vendors will often try to apply the Jedi mind trick in selling silver-bullet software solutions that solve global warming and stop celebrity feuding while enabling service-based architecture development. Let's quickly put on our aluminum foil caps and repel the Jedi mind trick by turning to open source solutions. Service-based architectures are being touted as the next step in reaching programming nirvana. With these marching orders it's often difficult to build a framework that allows for simple service creation. This framework should also be flexible, scalable, and lightweight as well as easy in exposing services externally. Without the correct framework(s) and guardrails in place your application services can quickly become a jumbled mess. Circular dependencies, massive Ant scripts, zero component reuse, and painful Web Service creation are just some of the problems faced by developers today. This article will demonstrate concepts on software lifecycle automation as well as a lightweight approach to creating a service-based architecture.

Building a Better Death Star
Everyone has worked on a software project delivered late (if at all) and over budget. I'm sure building the Death Star was no different. This article will demonstrate how to alleviate some of that pain by building a modular, reusable, and service-based architecture using a combination of open source projects. Maven, XFire, Spring, and Hibernate are all powerful frameworks when used alone. The real power is realized when they are used in conjunction. Maven is a software management tool that allows for module inheritance, dependency management, and overall project comprehension. XFire is a simple yet feature-rich framework that can expose any plain old Java object (POJO) as a Web Service. Spring is a layered Java application framework used to wire services together. Hibernate is an object-relational-mapping persistence and query service for Java.

You Say Jabba Desilijic Tiure, I Say Jabba the Hutt
Jabba Desilijic Tiure was one of the most notorious crime lords in the Star Wars galaxy. You probably didn't know who the term Jabba Desilijic Tiure referred to but if Jabba the Hutt was mentioned you'd know right away the creature in question. A common data dictionary is beneficial on any project or document. Before we continue a few key terms should be defined so it doesn't sound like this article was written in Shyriiwook (Wookiespeak).

• Service: The term service refers to a "discretely defined set of contiguous and autonomous business or technical functionality." One of the goals in creating a robust application framework is the ability to expose services through a number of different protocols. Creating services as POJOs will let us use other frameworks either to expose these externally or consume them internally.
• POM (Project Object Model): The POM is an XML representation of a Maven project. A POM consists of information regarding dependencies, defect tracking, repository metadata, mailing lists, plug-in goals, and any other configuration details used to encompass fully the complete lifecycle of a project.
• Module: A module is a logical as well as physical part of your application. Layers and services in your application can be represented by physical Maven modules that logically make up the different components of your architecture.
• Build Dependencies: Maven manages different types of build dependencies for projects and cross-projects. A dependency is typically a jar file that a project needs for compilation, testing, or runtime behavior. Dependencies can be managed declaratively in your Maven project file. Maven also seamlessly manages transitive dependencies (dependencies of dependencies) and circular dependencies. Transitive dependencies are impossible to manage in Ant. Circular dependencies are particularly hard to manage in Ant since most of the time the source code for an application is compiled in one big mess. No feedback is given if, for example, the core layer of your architecture has a dependency on your service layer.
• Build Lifecycle: Software projects typically need the same tasks done to build and deploy code. Maven has a predefined set of phases each performing a series of actions to encompass a build lifecycle. Some common phases are validate, generate resources, compile, test, package, integration test, and deploy. Maven plug-ins can be used to add functionality to a standard build lifecycle. Lifecycle phases should be managed by your software project management tool and not bolted onto a tool like Ant. Figure 1 shows some common lifecycle phases and the tasks they perform.

Just Say No to a 'Jabba the Hut' Architecture
It's more than likely that everyone has worked on an application that suffered from this syndrome. All it took was consuming one or two salacious crumbs a day without giving the application the care and feeding it needed. Bloating, circular dependencies, and the absence of separation of concerns are telltale signs that your architecture is turning into Jabba the Hut. Anyone using Java has surely written a few Ant files in the course of their career each consisting of thousands of lines of XML. Everything seems fine until your code base grows or more developers are added to the project. It's not simple to manage modules (or sub-projects) and dependencies using Ant as your build system. It's a great tool but it's outdated and too many people have tried to turn it into something it shouldn't be. A good analogy of Maven compared to Ant is the symbiotic relationship between Hibernate and JDBC. Hibernate provides an abstraction layer on top of JDBC and can provide a broader scope and range of features than the JDBC framework. The Maven plug-ins provide all the features of Ant as well as a standard way of interfacing with external tools and frameworks like Cargo (application container management), configuration management repositories, Hibernate, XFire, etc. Maven also brings a much broader set of features and concepts to the table than Ant.

Star Wars Convention? No, Not That Kind of Convention...
Maven's magic in building software is similar to the Ruby on Rails approach to programming in that most common tasks have default sensible strategies in place. This philosophy is called "Convention over Configuration." Trading flexibility at the infrastructure level by having standard directory layouts, standard naming conventions, and standard lifecycle phases promotes less emphasis on mundane details like building and deploying and allows for more time spent on the application's design and implementation. The guardrails Maven puts in place are necessary for a tight application but often don't get installed and are typically not given the care and feeding they need.

Software build structure layering should be the foundation of your application. This layering is prevalent at many levels in your ecosystem. It starts at your build system and feeds into your application. At an even broader scale this can be seen from your application into the enterprise. This was all made possible by a well structured build system.

I Am Your Father Luke
Project inheritance? Are you crazy? Wouldn't it be nice if there was a build system that handled software management lifecycle tasks and had some familiar and powerful object-oriented constructs like inheritance, encapsulation, cohesion, composition, and aggregation? I first used Maven 1 on an open source project solely for dependency management and site documentation. Frankly, I thought everything else it did was pretty miserable. I found myself always needing to drop into Ant to do trivial things. With the release of Maven 2 these highly desired features are present along with a lot more. This article is by no means a Maven tutorial but will show some key concepts as well as how to integrate it with some other important open source frameworks.

Maven comes with a feature rich set of plug-ins that provide core as well as enhanced functionality. Plug-ins are executed as part of the build lifecycle to perform tasks necessary to build a project. These plug-ins run unit tests, compile code, package software, and generate project reports among other things. Maven also has an extensible architecture that allows one to write any number of custom plug-ins to integrate with third-party tools or fulfill special tasks. One of the main benefits of using Maven is the ability to define a large amount of your build infrastructure in a parent project and inherit these dependencies and preconfigured plug-ins as well as any other lifecycle logic in your sub-modules. Here's a quote from Better Builds with Maven that sums up the tool, "Maven is a way of approaching a set of software as a collection of highly interdependent components that can be described in a common format. It's the next step in the evolution of how individuals and organizations collaborate to create software systems."

Page 1 of 3   next page »