Stephan Schwab

Software development and farm life

Archive for March 2007

Java stack for all purpose development

leave a comment »

You can’t know everything and have experience with any and all technologies that might be used to solve a given problem. Instead it is a good idea to limit yourself to a certain set and become in an expert in those. The deep knowledge you will gain will allow you to solve problems quickly and at reasonable cost, because instead of struggling with technologies that are new to you, you will be working on the problem itself. Seldom clients pay for research, but expect a product in short time.

For the needs of Caimito we’ve defined a stack of Java technologies for three tier applications on the web (thin client) or on the desktop (thick client).

3TierArchitecture.png

Presentation Layer

For thick client applications the choice is relatively easy. Java comes with Swing, although there is RCP (rich client platform) from the Eclipse Foundation. RCP might provide technical advantages through the use of platform-specific native libraries for UI elements, but I believe it will always be easier to maintain Swing code as there will probably be more people with Swing knowledge than those who know Eclipse RCP.

For thin clients on the web a large number of technologies is available and almost every other month something changes or is added to the list. At some point you may think that building web frameworks is the favorite hobby of the Java community. Our stack contains three web frameworks and two different rendering technologies for the request-based frameworks Spring MVC and Struts.

Struts is the oldest and probably the most well-known web framework for Java. It is request-based and is action driven. Recently another web framework called WebWork has been renamed to Struts 2 after the original Struts team and the folks from WebWork decided to join forces. Now there is the old Struts with a large number of applications built with it and the new Struts 2, which is essentially WebWorks at the moment.

Spring MVC is part of the Spring Framework and request-based as well. It’s prominent feature is good data binding capability. Form data gets bounds to a domain model object that is passed into a controller class where the data can be processed. Spring MVC is very light weight and can as well be used for remoting purposes to process data POSTed from non-browser clients.

JSP and Velocity are two rendering technologies that can be used to create web pages enriched with data from your domain objects. JSP requires the Java compiler to be present on the web server, as this Sun technology uses template files (HTML with additional markup) that are pre-compiled to Java classes. Velocity is a template engine available from the Apache Foundation. With Velocity not only can be used to enrich HTML pages with domain model data, but as well to create emails and any other kind of file as it doesn’t care about the file’s content but its own tags.

Tapestry is a completely different animal. Tapestry is a component-based framework – and to be honest – is way ahead of any request-based framework. Instead of carefully matching the content of HTML pages to your Java code, you use Java components to create HTML pages. Those components contain HTML fragments. Layout and appearance are added via layout templates and CSS stylesheets. You can have a web designer take care of that part and let Java developers create the application without running the risk that they are stepping on eachothers toes. Tapestry doesn’t need any rendering technology due to its component-based approach and direct rendering of HTML. The latest version, Tapestry 5, allows to develop with a speed usually known from scripting environments due to its unique dynamic class loading feature.

Business Layer

In the business layer we make sure to have no dependencies on any presentation or infrastructure technology at all. The business layer is comprised of pure POJO classes that are small, do one thing well and can easily be unit-tested with JUnit.

As past experiences have shown techniques such as TDD (test driven development) and DDD (domain driven development) help in the design of a good domain model, which is well suited for the purpose of the application without getting bloated or hard to maintain. Instead of trying to come up with a great design upfront and then implement it (that would be waterfall), writing unit-tests to solve problems at a high abstraction level is really a good idea and very agile.

Infrastructure Layer

Our infrastructure layer is hidden behind the Spring Framework to reduce the amount of intimate knowledge of all the different and constantly emerging Jwhatever technologies. Spring Framework provides a unified and simplified way of accessing important middleware technologies via its templates. For a lot of third-party libraries documentation is available how to wire them up with Spring. A developer with good knowledge about how to use the Spring Framework doesn’t need to become an expert in a large number of infrastructure APIs. Instead he can concentrate on the upper two layers (business and presentation) that appear to be more important to the client. The implementors of the Spring Framework have done most of the work beneath the hood.

Similar as the Spring Framework the Hibernate project has created a wonderful ORM (object-relational mapping) tool, which can be used through Spring templates. As our stack is Java 5 based we use EJB3 Java Persistence annotations to configure entity classes that get mapped by Hibernate to the database. That way are don’t depend on the Hibernate implementation of EJB3 directly and could exchange it for something else. At the same time we don’t depend on any particular database implementation thanks to Hibernate’s support for various SQL dialects. So whether MySQL is enough or it need to be Microsoft SQL Server or Oracle, we are prepared and our client can benefit from a wise choice of technology.

Written by Stephan Schwab

March 19, 2007 at 11:43 pm

Posted in Caimito

Evaluating technologies for new product development

leave a comment »

We are working on a new software product, which will be maintained over several iterations. Although we’ve created a small working prototype, we are still evaluating technologies we want to use or, as one might want to say, bet on. When you develop a product – and in fact software development is always new product development – you should spend some time thinking about the dependencies your product will have and how these dependencies might affect you and your users. If your solution relies on some third party library and the vendor of that library changes important features or stops development, then that undoubtedly affects you. At the very least you need to provide yourself an answer to the question how dramatically that might affect you and what your ability to cope with it is.

This post is about some of the things we are currently thinking about.

Platform neutral UI

Future customers will use the product locally and remotely accessing a central server over the Internet. The UI needs to be platform neutral. Both requirements lead to a web application. Web applications can be installed locally and offered using the ASP business model. Web applications have a platform neutral UI, as the client application is the web browser and most platforms offer such a software.

10 minutes test

Installation of the product should be as simple as possible to make evaluation a painless process. It’s very important that a potential customer can install, set up the product, and play around with it in less than 10 minutes and it should just work. If the product fails the 10 minute test, we might loose a potential customer right from the start and would never hear from him to be able to offer help.

Deployment as standalone application

We can’t expect a certain environment other than the JVM to be installed on the machine where the customer wants to evaluate our product. We can say Java 5 is required, but telling the customer to install a complex thing like JBoss, Tomcat, Geronimo or commercial application servers like IBM Websphere or BEA Weblogic would be prohibitive. The best way to get around this problem is to provide a standalone version of the product by using an embedded servlet container like Jetty. The server application can then be installed and started as it were a regular Unix daemon. On Windows it can be deployed as a service.

Data storage

Our prototype was created in good TDD/DDD manner using a file-based repository (hash maps and data objects stored as XML files via the built-in XMLEncoder/XMLDecoder) instead of a complex ORM tool talking to a real database. We wanted to model key objects, learn about their relationship and come up with a basic design very fast. So instead of working on the data layer, we worked on the business objects and created some web UI for the basic workflow of the application.

We then came to the point where we would be putting too much work into our file-based repository and started thinking about using an ORM tool. Hibernate is the most prominent one and we have some experience with the 3.x versions and the XML configuration of the object mappings.

When Hibernate was developed XML configuration was the only choice on JDK 1.4. XML configuration can be quite excessive and the developer needs to maintain the Java code and the corresponding XML mapping files in sync. Java 5 introduced annotations to express metadata to the language. As we are working on a completely new product and Java 5 has been out long enough (Java is now at version 6), we decided to go with Java Persistence and the implementation Hibernate Annotations. We are still using Hibernate, but don’t tie ourselves to a single vendor implementation. Others might provide an alternative implementation of Java Persistence and our changes to substitute Hibernate, if the need arises, are much better.

The old XML approach used by classic Hibernate doesn’t tie the application to Hibernate either, but we want to XML as much as possible. Still we believe Hibernate is a good tool and did not want to switch to something completely unknown. So Hibernate Annotations seems to be a good choice.

Web framework

When you develop a web application you should use a web framework and not work directly with servlets. :-) Request-based frameworks were discarded as we want our application to make use of Ajax for a compelling and responsive user interface. Component-based frameworks seem to have better support for Ajax and our first experiments with Tapestry 4 were successful so far. Instead of writing XML configuration to describe the workflow of the application, we can deal with pages, components, and actions in Java code. For now we can use simple HTML templates and later on let a skilled and creative web designer enhance the look of the application. As Tapestry uses templates that can be manipulated, without damage to the markup required to interface to the Java code, in web designer tools like Dreamweaver that should be a breeze.

Written by Stephan Schwab

March 11, 2007 at 10:18 pm

Posted in Caimito

Starting to love EJB3 Hibernate Annotations

leave a comment »

As our current project allows for some experimentation and adoption of recent technologies, we spent today with EJB3 Hibernate Annotations to get away from the XML configuration one used to create with Hibernate before.

The annotations need to be placed in the same compilation unit as the entity class lives in. The result is that these POJOs now are no longer POJOs in a very tight sense. That has been criticized as polluting the codebase with ORM specific annotations. That’s certainly right, but one does not replace one ORM tool for another very often and going with the EJB3 Java Persistence annotation one can replace ORM tools, as Hibernate is just one implementation of that API. So I wouldn’t fear too much. After all those classes that become entity classes are meant to be stored into a database and somewhere I have to put the mapping. Doing so in Java code instead of an external XML file appears to be clearer and more appealing to a developer.

Here is something we learned today.

Let’s define a persistent entity class called Issue.

@Entity
@Table(name="issue")
@NamedQueries( { @NamedQuery(name = "findIssueById", query = "from Issue i where i.id = ?") })
public class Issue implements IdentifiableObject {

  @Id @GeneratedValue
  private long id ;

[...]
}

This entity will be persisted into the table issue and you see that it has an id field. Other fields are omitted for clarity. Further we define a named query findIssueById.

In a generic DAO class using Spring’s Hibernate template we create a method findById as follows.

public Object findById(String query, long id) {
  List list = getHibernateTemplate().findByNamedQuery(query, id);
  if (list.isEmpty())
    return null ;
  else
    return list.get(0) ;
}

Elsewhere in the application we can the find any entity by calling findById passing in the name of the named query and of course the query criteria id.

Issue issueRead = (Issue) repository.findById("findIssueById", someId) ;

In your Spring application context configure your session factory using the AnnotationSessionFactoryBean.

  
  
    
      org.hibernate.dialect.HSQLDialect
      [...]
    
  
  
    
      net.caimito.savila.Issue
    
  

Written by Stephan Schwab

March 9, 2007 at 3:24 am

Follow

Get every new post delivered to your Inbox.

Join 259 other followers