The Artima Developer Community
Sponsored Link

Weblogs Forum
An Environment for Flexible Code

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Matt Bauer

Posts: 7
Nickname: mbauer
Registered: Mar, 2003

An Environment for Flexible Code (View in Weblogs)
Posted: Apr 14, 2003 12:08 AM
Reply to this message Reply
Summary
You can run Java on everything from large servers to cell phones, but is your code flexible enough to use databases ranging from Oracle to Nokia?
Advertisement

I enjoy the flexibility of Java. I think it's wonderful I can switch out application servers and databases without much work. I can even switch in and out classes at runtime by just extending ClassLoader. You can even run Java on everything from large servers to cell phones, but is your code flexible enough to use databases ranging from Oracle to Nokia?

One of my current projects requires such flexibility. The same application needs to run on large production servers, disconnected laptops for the sales force, and a custom micro device. The production system accesses data using an Oracle Spatial database while the sales force accesses a subset of data via files and the micro device uses a very small database without spatial features. The solution for this flexibility is a Data Access Object (DAO) defined by an environment variable in a ejb-jar.xml or web.xml file.

SegmentsDAO is an example DAO that I'll use to explain this solution. It includes a method that takes a coverage rectangle and returns all the streets covered by it. The code looks like this.

public interface SegmentsDAO {
    List getSegments(double x, double y, double width, double height) throws MapDAOException;
}

Each method in the DAO throws a generic xxxDAOException. This way the rest of the application only needs to worry about xxxDAOExceptions. It doesn't matter if one implementation calls a database that throws SQLExceptions and another reads a file that throws IOExceptions; they are both wrapped in a xxxDAOException.

The SegmentsDAO sits behind a session façade, or possibly a servlet that uses an environment variable to determine what SegmentsDAO implementation to use. The code looks like this.

public class MapManager implements SessionBean {
    private SegmentsDAO segmentsDAO;

    ...

    public void setSessionContext(SessionContext sessionContext) {
        this.sessionContext = sessionContext;
        Context context = new InitialContext();
        try {
            String segmentsDAOClassname =
                (String)context.lookup("java:comp/env/segmentsDAOClassname");
            SegmentsDAO = (SegmentsDAO)Class.forName(segmentsDAOClassname).newInstance();
        } catch (...) {
            throw new EJBException(...);
        }
    }

    public List getSegments(double x, double y, double width, double height) throws MapException {
        return segmentsDAO.getSegments(x, y, width, height);
    }

    ...
}

In my ejb-jar.xml file I have a block that looks like this.

<env-entry>
    <env-entry-name>segmentsDAOClassname</env-entry-name>
    <env-entry-value>%segmentsDAOClassname%</env-entry-value>
    <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

This way if the installation is for a sales person I can have Ant replace %segmentsDAOClassname% with com.company.map.dao.SegmentsFileDAO or com.company.map.dao.SegmentsOraSoDAO for the production system.

I use this solution whenever I have to deal with code that requires additional flexibility. A nice side benefit is the ability to do quick vendor or implementation comparisons. I recently used this solution to test Java mapping components from various vendors. I could stress test the component within my application, knowing that any differences in performance were attributable to the component. Remember requirements and vendors will change, make sure your code can.

Topic: Sloppy and Forgiving versus Strict Systems Previous Topic   Next Topic Topic: Investing in C and Unix


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us