EE Server versus Tomcat/Jetty

First off, I like Tomcat.  It starts fast, is a solid JSP/Servlet container and, when coupled with Spring, gives a well rounded application development framework.  However, I also like Weblogic, Glassfish and JBoss.  EE6 containers with EJB3, CDI/Weld and JSF/Facelets also gives a solid application development framework.  So what's the difference, and why or when should you use one over the other?

1. Connection Pooling vs C3PO
2. JTA vs Atomikos
3. JMS vs ActiveMQ/RabbitMQ
4. JAX-RS/WS vs Metro or CXF
5. EE Security (5 specs) vs JSecurity or Spring Security
6. EE Interceptors vs Spring Events

So it appears as though you can add in each of the EE stack specs into Tomcat as needed.  The real question becomes what is as needed and do you design your application around what's missing as much as what's there?

Lightweight
Tomcat/Jetty/Resin will all start using less memory than Glassfish/JBoss.  If however, you need connection to a database(s) (issues 1 and 2 above), asynchronous processing (issue 3), restful web services (issue 4), security (5) and loose coupling (6) then you'll need to add Spring to your web app on Tomcat/Jetty/Resin and then the startup times and memory footprint begins to look similar.

Vendor Independence
Tomcat with Spring gives you lots of configuration options.  Different implementations of JCA, JMS, Web Services, Security, Persistence can all be wired in to the environment.  This is a great advantage when dealing with existing application infrastructure where synergy to other applications is required.  As much as JEE vendors purport that the EE spec isolates you from vendor lockin, it's more difficult to perform than the color glossy brochure would have you believe.  The ability to deploy a war on multiple JEE servers does exist, so there is that level of independence, but it's generally much easier to use the vendor's chosen implementations of security, persistence, jms, etc.

Testing
Spring has a great test framework to allow testing from junit or testng without a container.  Since Spring is independent of container provided services, you can pretty easily spin up a Spring configuration in the JVM.  JEE testing requires a container.  With frameworks like arquillian, it's easier to spin up a embedded container for testing, but Spring has a definite advantage here.

Free
What a misnomer.  Often we think that because we can download a product and use it without paying, that it is free.  Well, I guess if we already knew everything we needed to know to use the product -- it would be free.  But, when you try to use the software you just download for the first time, there's usually some learning curve.  Documentation, community involvement, support and professional services can all come into play in order to get you up and running.  My opinion is that the Spring documentation is pretty good here.  The JEE documentation (link below) is good also, but note quite as polished as Spring's.  The issue with Spring, is that the variety of implementations for any of the basic services, means you will be dependent on additional vendor documentation, unless you simply use what Spring recommends.  So the vendor independence advantage may be a little diluted.

Why Use JEE
If you have a clean slate to start with, i.e. very few mandates to use a particular implementation of Security, WebService engine, etc.  Also, if you really don't care who provides your connection pooling, JMS, JCA, JTA, etc. then a JEE server will provide all of those basic services.   You have development and deployment hardware capable of supporting a reasonably large memory footprint.

Why Use Spring
You want customize and tailor the configuration of the basic application infrastructure.  You want to learn technology that is widely spread.  You want to learn technology that can be used in a variety application ecosystems.  You are severely limited in the development or deployment hardware.


references:
EE Doc: http://download.oracle.com/javaee/6/tutorial/doc/gfirp.html
Spring Doc: http://static.springsource.org/spring/docs/3.1.0.M2/spring-framework-reference/html/

Think Objectively

What does ORM stand for?  Object Relational Mapping.

What is an Object?  Data and behavior.

What is a DAO?  Data access object.

If an Object is data and behavior, why is there such a thing as a "data" access object?  Why not an Object access Object?  Does a DAO have any place in an object oriented architecture?

Good questions.  I don't pretend to have the answers, but I have a few observations.

First, if you use DAO layer, then something has to reassemble your object model from the "data" you just accessed.  Now you have a DAO, a DTO and an assembler just to get data from a database into a usable object model.  Seems like a lot of work.  Also sort of inflexible to change as we are prone to omit details from the model that we are not currently interested in, and leave it up to the next person.

Second, hibernate is a good ORM but it has a steep learning curve and a few limitations.  There is no cure for having to learn things and I get that, but it's pretty weird that the ORM market is still evolving some 35 years after OO design and development began.  It seems pretty fundamental to software development to be able to get  and store data.  JPA is a "standardized" version of Hibernate, but eclipseLink and Hibernate implementations of JPA are not simply swappable.  Don't kid yourself, Oracle wants you to use EclipseLink and Redhat wants you to use Hibernate for a reason $$$$.  They aren't going to make it super easy to change things and cut them out of the loop.

Lastly, I personally would like to think the DAO is dead (DOA).  Spring ROO manual has a section dedicated to the demise of the DAO.  JPA gives a much cleaner transition from data storage to Object model.  It's not perfect, but far better than having three or four architectural layers dedicated to getting data.  Also, I have seen applications where Object classifcation/subclassing is left out altogether in the DAO layers just because it's difficult to implement in that way.  This leads to the visitor pattern to implement object specific behavior.  Now, maybe I'm wrong but doesn't it seem like a bad idea to have a travelling section of business logic that is seperate from the actual object model?  I guess I'd like to see the visitor pattern go the way of the DOA DAO.

l8r

Many To Many Problems

This week I've been struggling with a many to many mapping where the join table has extra columns and the lower side of the many to many should be deleted once all the top side holders are removed.  First the model..

(Gliffy account expired so no pictures.)

• Folder
• Message
• Contents

The basic premise is that a folder can contain many messages.  Messages contain 1 content, but 1 content can be referenced by many messages.  A message represents content in a user's folder.

The test case is to send a message to five people's inbox folder.  So each folder will have a Message and each message will reference the same Content.  So I would expect 5 folders, 5 messages and 1 content in the database.  If the first 4 users delete the message I would expect the 5 folders, 1 message and 1 content remaining.  When the last of the messages are deleted, the content should be deleted too.

We started by mapping the Folder's set of messages as ManyToOne.


@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "folder", orphanRemoval=true)
private Set messages = new HashSet();


The orphanRemoval is the equivalent of hibernate's cascade type DELETE_ORPHAN. Then we map the Message class back to the Folder as a many to one.

@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "FOLDER_ID", nullable = false)
private Folder folder;

@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "CONTENT_ID", nullable = false)
private Content content;


Lastly we map the Contents to Message as a OneToMany and we effectively have a ManyToMany with extra attributes on the Message join table.

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "content", orphanRemoval=true)
private Set messages = new HashSet();


Now we add a few convenience methods to update both sides of the one to many relationships.  When we have mappedBy in the mapping it is equivalent to inverse=true which means the Message is the owning side of the relationships.  Therefore, when we add to the folder.messages collection, we also need to set the message.folder.  Likewise on the content.messages and message.content.

public void addMesage(Message message) {
this.messages.add(message);
message.setFolder(this);
}



Everything worked pretty well when adding although the Content didn't seem to persist automatically and we would get a transient entity error.  The create mesage looks like this

public void createMessaage(List to, Content content) {
for (Folder folder : to) {
Message message = new Message();
folder.addMessage(message);
content.addMessage(message);
}
save();
}

Delete works pretty straightforward also.  Simply remove the message from the folder and the content.   Unfortunately what we encountered were a lot of re-saved entity issues and content either being removed prematurely (the entire graph deleted on first message delete) or never at all (content not deleted after last message reference removed).

My solution has been to make the delete return a boolean as to whether the Content needs removed and then issue session.delete(content) on it.  I don't like it, but it works.

Google AppEngine and JPA/DataNucleus

JPA is provided on Google AppEngine (GAE) via DataNucleus.  DataNucleus data store used on GAE is BigTable.  The solution has a few rough edges.  See the references below for some of the docs from Google.

References
http://code.google.com/appengine/docs/java/overview.html
http://code.google.com/appengine/docs/java/datastore/overview.html
http://code.google.com/appengine/docs/java/datastore/jpa/overview.html

Troubled Dog?

I have this song running thru my head..... there's a line in it "Worry, worry, worry".  It's used on a Travlerers Insurance company commercial where a dog hides his bone in the backyard.  Then frets over it, digs it up and takes it to the bank.  Then the dog worries about it even more.  He goes to the bank and takes out the bone and keeps it in his sight at all times.  Man that dog is troubled!  The song is "Trouble" by Ray LaMontagne. You tube video here.

So my bone these days is software development and why are things so hard.  Recently I've spent a day or two getting a many to many hibernate/jpa mapping to update correctly.  I began to think I had more than just a simple problem, but many to many problems.  That's where Ray LaMontagne comes in. I have a few ideas of things to discuss in upcoming posts such as:

• My Many To Many Problems
• Is ORM the vietnam of software development? 
• Think Objectively - rich entities lead to ORM
• where O = Object which is data and behavior.
• not anemic.
• EE Server versus Tomcat/Jetty/etc.
• Is lightweight lightweight when you have to wire everything together in app config?
• How will this work with ESB?  Every app has it's own def?
• What about change?  Does every app change?
• Ding Dong the DAO is dead
• STS 2.7 Review
• Vendor lock in?
• ORM Testing
• How to verify persistence is mapped correctly
• Spring Testing versus Arquillian
• There's Chocolate in my Peanut Butter
• Are DBAs development or operational?
• The impact DBAs have on ORM mappings
• A dog needs a bone.  Don't worry be happy.

I'll try and get one of these topics out each week for the next 7 weeks.  In the meantime, I'll spend less time worrying and more time listening to Ray.

Seam3 Project Archetype

The jboss-javaee6-webapp archetype from org.jboss.spec.archetypes has a lot of goodies in it.  There is 

1. JSF 2.0
2. Restful Services
3. CDI 1.x
4. EJB 3.1
5. JPA 2.0
6. Bean Validation
7. Arquillian Tests

I created a project from the archetype in eclipse 3.7 with jboss tools 3.3, built and deployed to jboss 7 in under 15 minutes.  With JBoss tools you get code insight when editing the ui pages.  So when you type #{ in an xhtml, the annotated beans are reviewed for matching candidates. Once you select a bean, the available methods are displayed.   Just like working with the java code.  

Some of the other JEE features sprinkled thruout the example are event fire and observe techniques.  Also @Producers (think factory) and @Named beans.  And bean validators, which is just plain cool to me.  Think of it, the same validation that you use on the entities can be used directly by the UI.  One set of rules....  very dry.

So if you're interested in fast approach to java web development, try out eclipse, jboss tools and this archetype and I think you'll be up and running in no time.