Tag Archives: Open Source

Sony Pictures Imageworks Five Open Source Projects

Open Source: It’s always been a part of what makes Imageworks tick. However, up until now we haven’t had a chance to contribute back to the open source community. We’re beginning to change that now.

We’ve chosen 5 projects to release as open source. This software can be freely used by large and small studios around the world. We’ve intentionally chosen popular non-restrictive licensing models to help ensure you have lots of options.

Each of these projects have passionate people behind them who are interested in seeing the code widely used. We’re into the idea of building small development communities around this code. If you’re interested in contributing, join the respective mailing lists and introduce yourself.

Take a moment to familiarize yourself with Imageworks’ open source offerings. I hope you find something useful.

Rob Bredow
Sony Pictures Imageworks

50 Awesome Open Source Resources for Writers and Writing Majors

With the popularity of blogging and online journals, writers working in the online realm have a growing number of opportunities all the time to practice and refine their craft, and maybe even get paid for it. And if you’re a writing major, why not take advantage of all the opportunities to get great free and open source resources that can help you to write, edit and organize your work? Here’s a list of fifty open source tools that you can use to make your writing even better.

Word Processors

Why pay for expensive word processing programs when you can get high quality and open source alternatives for much less? Here are a few programs to try.

  1. yWriter: This word processor is designed especially for writers. Created and maintained by a novelist, writers will enjoy the features that are specialy tailored to their needs that help writers stay organized and focused.
  2. OpenOffice Writer: Part of the incredibly popular OpenOffice suite, this word processor is a great alternative to more traditional options like Microsoft Word. Writer is just as fully featured and easy to use, making it a powerful choice for writers.
  3. wikidPad: This tool is a wiki-style notepad that allows users to to quickly and easily jot down their ideas and notes. Perhaps one of the best features of it is that it allows you to easily cross-reference information, helping you more easily draw plot points and facts together.
  4. NeoOffice: Similar to OpenOffice, this open source suite contains a word processor that allows Mac users to enjoy great functionality and ease of use when typing up manuscripts or anything else.
  5. TiddlyWiki: Another wiki style notebook, TiddlyWiki allows users to take notes or jot down ideas anywhere they have an Internet connection. Users can easily link and organize their thoughts using the program.
  6. NotePad++: An open source version of Microsoft’s NotePad, NotePad++ has more features and functionality for users built right in. For writers looking for a very simple way to get their ideas written down, this can be a good, lightweight choice.
  7. Scribus: Scribus has much more than just word processing capabilities, it’s also a great open source desktop publishing solution. Whether you’re printing your own writings out or want to organize documents for online viewing, Scribus can be perfect tool.
  8. RoughDraft: Created with writers in mind, this free tool is a great way to organize a story or screenplay. Writers will enjoy formatting, instant backups and automatic generation of cover pages.
  9. AbiWord: One of the most popular open source word processors, AbiWord can be a great alternative to Microsoft Word. It’s available in a number of languages and for a wide variety of operation systems for writers of all kinds.
  10. Kword: Create great literary works using this fully-featured word processing program. You’ll be able to write and organize your writings easily in the program’s frame-based setting.
  11. Bean: Bean is an incredibly lightweight word processing program for Mac OS X that can make it easy to type up and edit your writings.
  12. WordIt: This small word processor is ideal for students or business writers. The program is simple to use and provides advanced features like PDF exports.

Continue reading

11 Free And Useful Open-Source Alternatives For Designers



Alternative: Adobe After Effects

Jahshaka give you the power of movie editing and effects in open source environment. You can edit with flexibility and speed and can create Effects in real time. With this software animate with unlimited features and Paint/design on moving video. It will let you work in any format at any resolution as well.

Continue reading

Googe Android Open Source

When Google announced Android, its software platform for mobile devices, it released an SDK for developers to work with, but it also promised to eventually release the code under an open-source license. Today, Google and its partners in the Open Handset Alliance did exactly that. You can now download the code and help Google and its partners to develop it further. The source code has been released under the Apache 2.0 license and consists of the complete codebase of Android, including all the libraries, media codecs, and applications.

The timing of this announcement coincides with the release of the first Android phone, the T-Mobile G1, which will go on sale tomorrow.

Apache License

androids_logos.pngThe Apache License allows developers to distribute and modify the source code in any way they want, and developers are not required to distribute the new code under the same license. The new license does not even have to be an open-source license, which will give companies the option to develop their own, proprietary platforms on the basis of Android.

iPhone and Android Compete for Developers

It will be interesting to see where developers will take the Android platform now that they have full access to it. We have already seen the release of quite a few very interesting programs for Android in anticipation of the G1 launch.

This announcement also sets Google apart from Apple, which is trying to keep complete control over its iPhone platform. While most users probably don’t care about the politics behind the scenes, the Android platform might siphon off quite a few developers from the iPhone – especially given Apple’s erratic behavior around including applications in the iTunes store lately.

Read Video Here

Movable Type Open Source

As of today, and forever forward, Movable Type is open source. This means you can freely modify, redistribute, and use Movable Type for any purpose you choose.

Just want the details and downloads? Skip to the bottom. But you might like the story of how we got here.

Like many of us on the team, some of you have been waiting for this moment for years. For a business, an open source license affects boring things like how a product is created, updated, and distributed. But the open source movement has always been about something more important: Freedom. With a name like “Movable Type”, we’ve always been keenly aware of the importance of freedom, as that name echoes both the birth of the printing press and the creation of independent media that an individual can control.

Our goal has always been to create the best blogging platform in the world and to put that power in the hands of as many people as possible. And we want to honor a tradition of openness that Movable Type has embodied for over six years:

  • From TrackBack to Atom to OpenID, we’ve always invented and popularized key technologies that were delivered with open source implementations, freely-available specs, and no patents.
  • Movable Type has always had all of its source code freely available for review, from its first release.
  • MT’s license has always permitted users to modify the code for any reason.
  • Every major release of Movable Type, from version 1.0, has included contributions or patches created by outside developers in the community.
  • Many members of today’s MT team began as contributors to the MT code or creators of MT plugins.
  • There was a public code repository with nightly builds of Movable Type as far back as four years ago, though it lacked dedicated resources.
  • There’s always been a free (as in beer) version of Movable Type.
  • We’ve always wanted people who pay for a Movable Type license to do so because they believe in what we’re doing — whether that’s standing behind our work with professional support, or the new era of benefits like plugins and themes for paid users.

Fighting For Openness

And so, while this is a milestone for Movable Type and for our community, this is something of an evolution for the platform, not a revolution. In fact one story stands out from the earliest days of our company. I got to witness the conversations between our cofounders Ben and Mena Trott (who were then the entire staff of Six Apart) and Joi Ito, who would go on to lead the initial investment in Six Apart from his company Neoteny.

mt-logo-small.gifBack in late 2002 and early 2003, Ben and Mena had both been adamant about one particular point from the very beginning of the negotiations: That there would always be a free version of Movable Type with the source code freely available. To their credit, the team at Neoteny was always wholeheartedly behind the idea. Of course, Joi Ito’s reputation in supporting and fighting for openness on the web since then is well-documented, from his work with Creative Commons to ICANN to the Mozilla Foundation to the Open Source Initiative itself.

But as a passionate MT user, it struck me that, even in those days when there were only a few thousand bloggers out there and the whole idea of starting a business around blogging was extremely risky, Ben and Mena were really committed to setting the standard that Movable Type would always be open, and would always be free, just as much as they were committed to making sure Six Apart would be a solid company that could hire passionate members of the community to stand behind its products.

That’s the truth, but of course, that might not have always been our reputation. Ever since the changes with our version 3.0 launch three years ago, there have been those who are quick to judge or quick to question whether the intention of openness was ever there. And of course, we’ve since learned a lot about how to communicate better with our community, and how to build a sustainable business that we’re proud of, so that we can ensure even greater investments in Movable Type. We hope that it’s not just the launch of MTOS that demonstrates our commitment to openness — from our community feedback process (which has already yielded a completely new MT wiki) to our creation and promotion of open standards for the web to our genuine interest in dialogue with the communities we serve, we truly believe Movable Type is the most open platform around.

Movable Type 4.0′s release earlier this year has been the most successful launch of a new version of MT ever. It’s been one of the milestones in the history of Six Apart, too, by re-establishing our flagship platform as an unquestioned leader in blogging, and demonstrating what the tool can do when we’ve worked with our community to invest a tremendous amount of resources in the platform.

And stay tuned: There’s even more exciting news for MT coming soon! You’ll want to subscribe to the movabletype.org XML feed for all the updates.

Thank You

The Movable Type Open Source project exists thanks to the passion, dedication, and inspiration of a community that has been incredibly generous for more than six years. We thank you for all the work leading up to this launch, and especially for the valuable contributions you’ll be making in the future. Today, we’re honoring the spirit of openness that’s always been part of the Movable Type community and taking it to its logical conclusion: Please welcome Movable Type Open Source.

A few quick answers to questions you might have about MTOS:


  • MTOS has every feature in Movable Type 4.0 along with several new minor improvements and bug fixes.
  • All plugins, themes, templates, designs, and APIs that work with MT4 work with MTOS. MTOS also works with other Six Apart open source technologies such as memcached.
  • MTOS is one of the only open source blogging tools with built-in support for an unlimited number of blogs, an unlimited number of authors, and sign-in with OpenID, with no plugins needed.
  • We’ll be adding additional paid benefits for people who’ve paid for commercial licenses for Movable Type, with benefits like improved technical support and custom add-ons such as plugins or themes.
  • MTOS is complemented by the paid software products we sell on top of the MT platform, such as our Enterprise Solution, Community Solution and personal and commercial licenses which include support.
  • There’s a public Subversion repository for getting the MTOS code and nightly builds.
  • Once there are stable public builds, those downloads will be on movabletype.org as well.
  • You can find out how to contribute to the MTOS project and the MT community at movabletype.org.
  • MTOS support is provided by other members of the community. (A great place to start is the new Movable Type Wiki.) You can buy a standard paid license for one of the existing Movable Type products if you’d like professional support directly from Six Apart.
  • Movable Type Open Source is being released under the standard GPL license.
  • We welcome and encourage the distribution and reuse of all or part of MTOS in other open source projects. Get in touch if you want to work together.

Be sure to check out the full MTOS details for more details on how MTOS works, a list of Frequently Asked Questions, and information about how you can contribute.

[via Movable Type]

Google Launches Gears Open Source Project to Bring Offline Capabilities to Web Applications

At Google Developer Day, New Browser Extension Provided to Developer Community

Google Developer Day 2007

SYDNEY, Australia–(BUSINESS WIRE)–Google Inc. (NASDAQ:GOOG) today announced at Google Developer Day 2007 that it is providing developers with Google Gears??, an open source technology for creating offline web applications. This new browser extension is being made available in its early stages so that everyone can test its capabilities and limitations and help improve upon it. The long-term hope is that Google Gears can help the industry as a whole move toward a single standard for offline capabilities that all developers can use.

Google Gears marks an important step in the evolution of web applications because it addresses a major user concern: availability of data and applications when theres no Internet connection available, or when a connection is slow or unreliable. As application developers and users alike want to do more on the webwhether its email or CRM or photo editingenhancements that make the browser environment itself more powerful are increasingly important.

“With Google Gears we’re tackling a key limitation of the browser in order to make it a stronger platform for deploying all types of applications and enabling a better user experience in the cloud,” said Eric Schmidt, Chief Executive Officer of Google. We believe strongly in the power of the community to stretch this new technology to the limits of whats possible and ultimately emerge with an open standard that benefits everyone.

Google is offering Google Gears as a free, fully open source technology in order to help every web application, not just Google applications. As a first example of what is possible, the Google Reader feed reader (http://reader.google.com) is available today with Gears-enabled offline capabilities.

Industry support

Google will be working closely with all members of the web community to converge upon a standard so developers have one consistent API for offline functionality.

“We’re very excited to be collaborating with Google to move the industry forward to a standard cross-platform, cross-browser local storage capability,” said Kevin Lynch, senior vice president and chief software architect at Adobe. “The Gears API will also be available in Apollo, which enables web applications to run on the desktop, providing developers with consistent offline and local database solutions.”

“This announcement is a significant step forward for web applications,” said Brendan Eich, CTO at Mozilla Corporation. “We’re pleased to see Google working with open source and open standards bodies on offline web applications.”

“Opera and Google share the common goal of making Web applications richer and more robust,” said Håkon Wium Lie, CTO, Opera Software. “Developers have long desired the functionality and flexibility Google Gears can offer browsers. Because Opera has always prioritized giving our users what they want, we’re excited to work with Google to extend the reach and power of Web applications.”

Another tool in the application development toolbox

Google Gears builds on the web’s existing programming model by introducing new JavaScript APIs for sophisticated data storage, application caching, and multi-threading features. With these APIs, developers can bring offline capabilities to even their most complex web applications. Google Gears works with all major browsers on all major platforms: Windows, Mac and Linux.

Google Gears is available now at http://gears.google.com/.

About Google Inc.

Googles innovative search technologies connect millions of people around the world with information every day. Founded in 1998 by Stanford Ph.D. students Larry Page and Sergey Brin, Google today is a top web property in all major global markets. Googles targeted advertising program provides businesses of all sizes with measurable results, while enhancing the overall web experience for users. Google is headquartered in Silicon Valley with offices throughout the Americas, Europe and Asia. For more information, visit www.google.com.

Google, Google Gears, and Google Reader are trademarks of Google Inc. in the United States and/or other countries. Other trademarks are the property of their respective owners.

Wiring Your Web Application with Open Source Java

by Mark Eagle
Building non-trivial web applications with Java is no trivial task. There are many things to consider when structuring an architecture to house an application. From a high-level, developers are faced with decisions about how they are going to construct user interfaces, where the business logic will reside, and how to persist application data. Each of these three layers has their own questions to be answered. What technologies should be implemented across each layer? How can the application be designed so that it is loosely coupled and flexible to change? Does the architecture allow layers to be replaced without affecting other layers? How will the application handle container level services such as transactions? 

There are definitely a number of questions that need to be addressed when creating an architecture for your web application. Fortunately, there have been developers that have run into these reoccurring problems and built frameworks to address these issues. A good framework relieves developers from attempting to reinvent the wheel for complex problems; it is extensible for internal customization; and it has a strong user community to support it. Frameworks generally address one problem well. However, your application will have several layers that might require their own framework. Just solving your UI problem does not mean that you should couple your business logic and persistence logic into a UI component. For example, you should not have business logic with JDBC code inside of a controller. This is not the functionality that a controller was intended to provide. A UI controller should be a lightweight component that delegates calls to other application layers for services outside the UI scope. Good frameworks naturally form guidelines where code should be placed. More importantly, frameworks alleviate developers from building code such as persistence from scratch and allow them to concentrate on the application logic that is important to a client.

This article will discuss how to combine several well-known frameworks to achieve loose coupling, how to structure your architecture, and how to enforce a consistent design across all application layers. The challenge is combining frameworks so that each layer is exposed to each other in a loosely coupled manner, regardless of the underlying technologies. This article will discuss one strategy for combining frameworks using three popular open source frameworks. For the presentation layer we will use Struts; for our business layer we will use Spring; and for our persistence layer we will use Hibernate. You should be able to substitute any one of these frameworks in your application and get the same effect. Figure 1 shows what this looks like from a high level when the frameworks are combined.

Figure 1. Overview of framework architecture with Struts, Spring, and Hibernate.

Application Layering
Most non-trivial web applications can be divided into at least four layers of responsibility. These layers are the presentation, persistence, business, and domain model layers. Each layer has a distinct responsibility in the application and should not mix functionality with other layers. Each application layer should be isolated from other layers but allow an interface for communication between them. Let’s start by inspecting each of these layers and discuss what these layers should provide and what they should not provide.

At one end of a typical web application is the presentation layer. Many Java developers understand what Struts provides. However, too often, coupled code such as business logic is placed into an org.apache.struts.Action. So, let’s agree on what a framework like Struts should provide. Here is what Struts is responsible for:

Managing requests and responses for a user.
Providing a controller to delegate calls to business logic and other upstream processes.
Handling exceptions from other tiers that throw exceptions to a Struts Action.
Assembling a model that can be presented in a view.
Performing UI validation.
Here are some items that are often coded using Struts but should not be associated with the presentation layer:

Direct communication with the database, such as JDBC calls.
Business logic and validation related to your application.
Transaction management.
Introducing this type of code in the presentation layer leads to type coupling and cumbersome maintenance.

The Persistence Layer
At the other end of a typical web application is the persistence layer. This is usually where things get out of control fast. Developers underestimate the challenges in building their own persistence frameworks. A custom, in-house persistence layer not only requires a great amount of development time, but also often lacks functionality and becomes unmanageable. There are several open source object-to-relational mapping (ORM) frameworks that solve much of this problem. In particular, the Hibernate framework allows object-to-relational persistence and query service for Java. Hibernate has a medium learning curve for Java developers who are already familiar with SQL and the JDBC API. Hibernate persistent objects are based on plain-old Java objects and Java collections. Furthermore, using Hibernate does not interfere with your IDE. The following list contains the type of code that you would write inside a persistence framework:

Querying relational information into objects. Hibernate does this through an OO query language called HQL, or by using an expressive criteria API. HQL is very similar to SQL except you use objects instead of tables and fields instead of columns. There are some new specific HQL language elements to learn; however, they are easy to understand and well documented. HQL is a natural language to use for querying objects that require a small learning curve.

Saving, updating, and deleting information stored in a database.

Advanced object-to-relational mapping frameworks like Hibernate have support for most major SQL databases, and they support parent/child relationships, transactions, inheritance, and polymorphism.

Here are some items that should be avoided in the persistence layer:

Business logic should be in a higher layer of your application. Only data access operations should be permitted.

You should not have persistence logic coupled with your presentation logic. Avoid logic in presentation components such as JSPs or servlet-based classes that communicate with data access directly. By isolating persistence logic into its own layer, the application becomes flexible to change without affecting code in other layers. For example, Hibernate could be replaced with another persistence framework or API without modification to the code in any other layer.

The Business Layer
The middle component of a typical web application is the business or service layer. This service layer is often the most ignored layer from a coding perspective. It is not uncommon to find this type of code scattered around in the UI layer or in the persistence layer. This is not the correct place because it leads to tightly coupled applications and code that can be hard to maintain over time. Fortunately, several frameworks exist that address these issues. Two of the most popular frameworks in this space are Spring and PicoContainer. These are referred to as microcontainers that have a very small footprint and determine how you wire your objects together. Both of these frameworks work on a simple concept of dependency injection (also known as inversion of control). This article will focus on Spring’s use of setter injection through bean properties for named configuration parameters. Spring also allows a sophisticated form of constructor injection as an alternative to setter injection as well. The objects are wired together by a simple XML file that contains references to objects such as the transaction management handler, object factories, service objects that contain business logic, and data access objects (DAO).

The way Spring uses these concepts will be made clearer with examples later in this article. The business layer should be responsible for the following:

Handling application business logic and business validation
Managing transactions
Allowing interfaces for interaction with other layers
Managing dependencies between business level objects
Adding flexibility between the presentation and the persistence layer so they do not directly communicate with each other
Exposing a context to the business layer from the presentation layer to obtain business services
Managing implementations from the business logic to the persistence layer
The Domain Model Layer
Finally, since we are addressing non-trivial, web-based applications we need a set of objects that can move between the different layers. The domain object layer consists of objects that represent real-world business objects such as an Order, OrderLineItem, Product, and so on. This layer allows developers to stop building and maintaining unnecessary data transfer objects, or DTOs, to match their domain objects. For example, Hibernate allows you to read database information into an object graph of domain objects, so that you can present it to your UI layer in a disconnected manner. Those objects can be updated and sent back across to the persistence layer and updated within the database. Furthermore, you do not have to transform objects into DTOs, which can get lost in translation as they are moved between different application layers. This model allows Java developers to work with objects naturally in an OO fashion without additional coding.

Wiring Together a Simple Example
Now that we understand the components from a high level, let’s put this into practice. Again, for this example, we will combine the Struts, Spring, and Hibernate frameworks. Each one of these frameworks has too much detail to cover in one article. Instead of going into many details about each framework, this article will show how to wire them together with simple example code. The sample application will demonstrate how a request is serviced across each layer. A user of this sample application can save a new order to the database and view an existing order in the database. Further enhancements might allow the user to update or delete an existing order.

You can download the source code of the application.

First, we will create our domain objects since they will interoperate with each layer. These objects will allow us to define what should be persisted, what business logic should be provided, and what type of presentation interface should be designed. Next, we will configure the persistence layer and define object-to-relational mappings with Hibernate for our domain objects. Then we will define and configure our business objects. After we have these components we can discuss wiring these layers using Spring. Finally, we will provide a presentation layer that knows how to communicate with the business service layer and knows how to handle exceptions that arise from other layers.

Domain Object Layer
Since these objects will interoperate across all layers this might be a good place to start coding. This simple domain model will contain an object that represents an order and an object that represents a line item for an order. The order object will have a one-to-many relationship to a collection of line item objects. The example code has two simple objects in the domain layer:

com.meagle.bo.Order.java: contains the header-level information for an order.
com.meagle.bo.OrderLineItem.java: contains the detail-level information for an order.
Consider choosing package names for your objects that reflect how your application is layered. For example, the domain objects in the sample application can be located in the com.meagle.bo package. More specialized domain objects would be located in subpackages under the com.meagle.bo package. The business logic begins in the com.meagle.service package and DAO objects are located in the com.meagle.service.dao.hibernate package. The presentation classes for forms and actions reside in com.meagle.action and com.meagle.forms, respectively. Accurate package naming provides a clear separation for the functionality that your classes provide, allows for easier maintenance when troubleshooting, and provides consistency when adding new classes or packages to the application.

Persistence Layer Configuration
There are several steps involved in setting up the persistence layer with Hibernate. The first step is to configure our domain business objects to be persisted. Since Hibernate works with POJOs we will use our domain objects for persistence. Therefore the Order and OrderLineItem objects will need to provide getter and setter methods for all fields that they contain. The Order object would contain setter and getter methods such as ID, UserName, Total, and OrderLineItems in a standard JavaBean format. The OrderLineItem would similarly follow the JavaBean format for its fields.

Hibernate maps domain objects-to-relational databases in XML files. For our Order and OrderLineItem objects there will be two mapping files to express this. There are tools such as XDoclet to assist with this mapping. Hibernate will map the domain objects to these files:

You will find these generated files in the WebContent/WEB-INF/classes/com/meagle/bo directory. The Hibernate SessionFactory is configured to know which database it is communicating with, the DataSource or connection pool to use, and what persistent objects are available for persistence. Session objects provided by the SessionFactory are the interface used to translate between Java objects and persistence functions such as selecting, saving, updating, and deleting objects. We will discuss configuring the SessionFactory that Hibernate requires to handle Session objects in a later section.

Business Layer Configuration
Now that we have our domain objects we need to have business service objects that perform application logic, make calls to the persistence layer, take requests from the UI layer, deal with transactions, and handle exceptions. To wire all of this together and make this easy to manage we will use the bean management aspect of the Spring framework. Spring uses inversion of control (IoC), or setter dependency injection, to wire up objects that are referenced in an external XML file. Inversion of control is a simple concept that allows objects to accept other objects that are created at a higher level. This way your object is free from having to create objects and reduces object coupling.

Here is an example of an object creating its dependencies without IoC, which leads to tight object coupling:

Figure 2. Objects arranged without IoC. Object A creates objects B and C.

And here is an example with IoC that allows objects to be created at higher levels and passed into objects so that they can use the implementations directly:

Figure 3. Objects arranged with IoC. Object A contains setter methods that accept interfaces to objects B and C. This could have also been achieved with constructors in object A that accepts objects B and C.

Building Our Business Service Objects
The setters we will use in our business objects accept interfaces that allow loosely defined implementations of the objects that will be set, or injected. In our case we will allow our business service object to accept a DAO to handle the persistence of our domain objects. While the examples in this article use Hibernate, we can easily switch implementations to a different persistence framework and inform Spring of the new implementation DAO object to use. You can see how programming to interfaces and using the dependency injection pattern loosely couples your business logic from your persistence mechanism.

Here is the interface for the business service object that is stubbed for a DAO object dependency:

public interface IOrderService {
public abstract Order saveNewOrder(Order order)
throws OrderException,

public abstract List findOrderByUser(
String user)
throws OrderException;

public abstract Order findOrderById(int id)
throws OrderException;

public abstract void setOrderDAO(
IOrderDAO orderDAO);

Notice that the code above has a setter for a DAO object. There is not a getOrderDAO method because it is not necessary since there is often no need to access the wired OrderDAO object from the outside. The DAO object will be used to communicate with our persistence layer. We will wire the business service object and the DAO object together with Spring. Because we are coding to interfaces, we do not tightly couple the implementation.

The next step is to code our DAO implementation object. Since Spring has built-in support for Hibernate this example DAO will extend the HibernateDaoSupport class, which allows us to easily get a reference to a HibernateTemplate, which is a helper class that simplifies coding with a Hibernate Session and handles HibernateExceptions. Here is the interface for the DAO:

public interface IOrderDAO {

public abstract Order findOrderById(
final int id);

public abstract List findOrdersPlaceByUser(
final String placedBy);

public abstract Order saveOrder(
final Order order);

We still have a couple more objects to wire together for our business layer. This includes the HibernateSessionFactory and a TransactionManager object. This is done directly in the Spring configuration file. Spring provides a HibernateTransactionManager, which will bind a Hibernate Session from the factory to a thread to support transactions (see ThreadLocal for more information). Here is the Spring configuration of the HibernateSessionFactory and the HibernateTransactionManager:

<bean id=”mySessionFactory”
<property name=”mappingResources”>

<property name=”hibernateProperties”>
<prop key=”hibernate.dialect”>
<prop key=”hibernate.show_sql”>
<prop key=”hibernate.proxool.xml”>
<prop key=”hibernate.proxool.pool_alias”>

<!– Transaction manager for a single Hibernate
SessionFactory (alternative to JTA) –>
<bean id=”myTransactionManager”
<property name=”sessionFactory”>
<ref local=”mySessionFactory”/>

Each object can be referenced in the Spring configuration within a <bean> tag. In this case the bean mySessionFactory represents a HibernateSessionFactory and the bean myTransactionManager represents a Hibernate transaction manager. Notice that the transactionManger bean has a property element called sessionFactory. The HibernateTransactionManager class has a setter and getter for sessionFactory, which is used for dependency injection when the Spring container starts. The sessionFactory property references the mySessionFactory bean. These two objects will now be wired together when the Spring container initializes. This wiring relieves you from creating singleton objects and factories for referencing and creating these objects, which reduces code maintenance in your application. The mySessionFactory bean has two property elements, which translate to setters for mappingResources and hibernatePropertes. Normally, this configuration would be stored in the hibernate.cfg.xml file if you were using Hibernate outside of Spring. However, Spring provides an easy way to incorporate the Hibernate configuration within the Spring configuration file. For more information see the Spring API.

Now that we have our container service beans configured and wired together we need to wire our business service object and our DAO object together. Then we need to wire these objects to the transaction manager.

Here is what this looks like in the Spring configuration file:

<bean id=”orderService”
<property name=”transactionManager”>
<ref local=”myTransactionManager”/>
<property name=”target”>
<ref local=”orderTarget”/>
<property name=”transactionAttributes”>
<prop key=”find*”>
<prop key=”save*”>

Hibernate implementation –>
<bean id=”orderTarget”
<property name=”orderDAO”>
<ref local=”orderDAO”/>

<bean id=”orderDAO”
<property name=”sessionFactory”>
<ref local=”mySessionFactory”/>

Figure 4 is an overview of what we have wired together. This shows how each object is related and set into other objects by Spring. Compare this with the Spring configuration file in the sample application to see these relationships.

Figure 4. This is how Spring will assemble the beans based on this configuration.

This example uses a TransactionProxyFactoryBean, which has a setter for a transaction manager that we have already defined. This is a convenience object that knows how to deal with declarative transaction handling and your service objects. You can define how transactions are handled through the transactionAttributes property, which defines patterns for method names, and how they participate in a transaction. For more information about configuring isolation levels and commits or rollbacks on a transaction see TransactionAttributeEditor.

The class TransactionProxyFactoryBean also has a setter for a target, which will be a reference to our business service object called orderTarget. The orderTarget bean defines which business service class to use and it has a property which refers to setOrderDAO(). This property will populate the orderDAO bean that is our DAO object to communicate with our persistence layer.

One more note about Spring and beans is that beans can operate in two modes. These are defined as singleton and prototype. The default mode for a bean is singleton that means that one shared instance of the bean will be managed. This is used for stateless operations like a stateless session bean would provide. The prototype mode allows new instances of the bean to be create when the bean is served through Spring. You should only use prototype mode when each user needs their own copy of the bean.

Providing a Service Locator
Now that we have wired up our services with our DAO we need to expose our services to other layers. This is generally used from code in a layer such as UI that uses Struts or Swing. An easy way to handle this is with a service locator patterned class to return resources from a Spring context. This can also be done directly through Spring by referencing the bean ID.

Here is an example of how a service locator can be configured in a Struts Action:

public abstract class BaseAction extends Action {

private IOrderService orderService;

public void setServlet(ActionServlet
actionServlet) {
ServletContext servletContext =

WebApplicationContext wac =

this.orderService = (IOrderService)

protected IOrderService getOrderService() {
return orderService;

UI Layer Configuration
The UI Layer for the example application uses the Struts framework. Here we will discuss what is related to Struts when layering an application. Let’s begin by examining an Action configuration within the struts-config.xml file.

<action path=”/SaveNewOrder”
<display-name>Save New Order</display-name>
<exception key=”error.order.save”
<exception key=”error.order.not.enough.money”
<forward name=”success” path=”/ViewOrder.jsp”/>
<forward name=”failure” path=”/NewOrder.jsp”/>

The SaveNewOrder Action is used to persist an order that the user submitted from the UI layer. This is a typical Struts Action; however, notice the exception configuration for this action. These exceptions are also configured in the Spring configuration file, applicationContext-hibernate.xml, for our business service objects in the transactionAttributes property. When these exceptions get thrown back from the business layer we can handle them appropriately in our UI. The first exception, OrderException, will be used by this action when there is a failure saving the order object in the persistence layer. This will cause the transaction to rollback and propagate the exception back through the business object to the Struts layer. The OrderMinimumAmountException will also be handled in a transaction within the business object logic that fails when the order placed does not meet the minimum order amount. Again, the transaction will rollback and this exception can be handled properly by the UI layer.

The last wiring step is to allow our presentation layer to interact with our business layer. This is done by using the service locator that was previously discussed. The service layer acts as an interface to our business logic and persistence layer. Here is how the SaveNewOrder Action in Struts might use a service locator to invoke a business method:

public ActionForward execute(
ActionMapping mapping,
ActionForm form,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws java.lang.Exception {

OrderForm oForm = (OrderForm) form;

// Use the form to build an Order object that
// can be saved in the persistence layer.
// See the full source code in the sample app.

// Obtain the wired business service object
// from the service locator configuration
// in BaseAction.
// Delegate the save to the service layer and
// further upstream to save the Order object.


ActionMessages messages = new ActionMessages();
new ActionMessage(

saveMessages(request, messages);

return mapping.findForward(“success”);

This article covers a lot of ground in terms of technology and architecture. The main concept to take away is how to better separate your application, user interface, persistence logic, and any other application layer you require. Doing this will decouple your code, allow new code components to be added, and make your application more maintainable in the future. The technologies covered here address specific problems well. However, by using this type of architecture you can replace application layers with other technologies. For example, you might not want to use Hibernate for persistence. Since you are coding to interfaces in your DAO objects it should be apparent to you how you might use another technology or framework, such as iBATIS, as a substitute. Or you might want to replace your UI layer with a different framework than Struts. Switching UI layer implementations should not directly affect your business logic or your persistence layer. Replacing your persistence layer should not affect your UI logic or business service layer. Wiring a web application is not a trivial task but it can be made easier to deal with by decoupling your application layers and wiring it together with suitable frameworks.

Mark Eagle is a Senior Software Engineer at MATRIX Resources, Inc. in Atlanta, GA.
Make the best forever.