The Fallacies of Distributed Computing

I'm working a SOAP heavy project right now so I thought I'd look up the 8 Fallacies of Distributed Computing. These are 8 assumptions people often make in designing network based systems such as a SOA or ESB that simply aren't true.

The following is NOT true:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

Designs should allow for the network to drop in and out, run slowly, take a while to move data around, change with out notice, or deal with multiple operating systems, langauges, or data representations. How often to we just think about the 'best case' scenario and fail to build in allowances for problems?

Groovy Grails and the JPA

If you are using Grails 0.6 or later chances are the tutorials you've found for making EJB3 persistence annotated POJOs work with Grails don't match up exactly. If you're like me, probably need to be made aware of a few differences in configuration. They aren't big... but the little differences could trip you up.

First note my version of myApp/grails-app/conf/DataSource.groovy

import org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsAnnotationConfiguration
dataSource {
    configClass = GrailsAnnotationConfiguration.class
    pooled = true
    dbCreate = "create-drop"
    driverClassName = "com.mysql.jdbc.Driver"
    dialect= org.hibernate.dialect.MySQLInnoDBDialect
    url = "jdbc:mysql://localhost:3306/grails"
    username = "grails"
    password = "grails"
}

Is not the same. Just because configClass = GrailsAnnotationConfiguration.class is set and your IDE says the class is found in this context doesn't mean that it's working for you... that import above still has to happen...

Next, I have added a file under "grails-app/conf/hibernate/hibernate.cfg.xml" and this part goes pretty much like the tutorials from last year... you register each class here one at a time. I need to research this one but I think grails mixes in this hibernate.cfg.xml with another one at run time so just stick to registering your classes. I tried to get fancy here and it didn't work out too well. My working hibernate.cfg.xml looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration SYSTEM
 "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
  <session-factory>
    <mapping package="com.mycompany.shared.domain" />
    <mapping class="com.mycompany.shared.domain.Subject" />
   </session-factory>
</hibernate-configuration>

You'll need your Java files to be in "src/java" and annotated up. I will be trying to make a shared JAR file full of only the shared domain objects for the various projects that need them. I don't know how well this is going to work but my idea is to create one set of JPA annotated EJB3 Entity classes and put them in a JAR and share them between various Spring applications. I don't know if that's a good idea or not...

Finally, you'll need to get the compiled class files for these annotated POJOs into "web-app/WEB-INF/classes" that means you need to do a "grails run-app" or similar first so that the Java files get compiled into classes and dropped into the "web-app/WEB-INF/classes" directory.

Once that is done you can run the "grails generate-all" command on your Java classes.

If you're interested in working through the EJB3 examples I have posted ejb3_grails.zip which uses this tutorial by Jason Rudolph but also uses Grails version 1.0_RC1 and the Groovy Eclipse Plugin.

EDIT: in version 1.0 and higher recent experience shows that if you set the Eclipse Groovy plugin to output to bin and set the build path of the Java compiler to output to project/bin class resolution will work fine for the IDE. When Grails itself goes to run the application or build the WAR file, the right class files will make it into "WEB-INF/classes" since Grails uses a separate class cache anyhow. It seems the reason I advised to output Groovy and Java classes to "web-app/WEB-INF/classes" is no longer true.

Groovy Grails documentation online...

As the much anticipated 1.0 release of Grails approaches, the first release of the official Grails 1.0_RC1 documentation has been released.

3D Linux Desktop

I use a 3D Linux desktop to do my work in. I have a dual monitor setup at work and a nice high-resolution single monitor (shown) at home. The 3D desktop doesn't just give my work a nice sheen of eye-candy it also gives me valuable feedback on the health and status of my OS.

For one thing a busy application gets dimmer and gray in my desktop. So if my browser is busy it doesn't just stop responding to my clicks, I'll know its working hard well before that... I'll see it dim and go gray. If something really bad happens it will burst into flames. A moving application wobbles as it refreshes itself making the move feel substantial.

The 3D cube is a more natural way to deal with multiple desktops. I've been using 4 desktops in KDE for about a decade. But, it was easy to get lost on the desktops since they had no real spatial relationship to each other. This same feature has been ported to Windows and OSX so I'm sure many people are now enjoying multiple desktops. As far as I know these are UI changes that appeared on Linux first.

If you haven't seen Beryl yet you should. I think Beryl and Compiz could revitalize Linux on the desktop.

The humor of Engineers

From the wikipedia entry on Portal the video game:

"at the beginning of the Portal development process, we sat down as a group to decide what philosopher or school of philosophy our game would be based on. That was followed by about fifteen minutes of silence and then someone mentioned that a lot of people like cake."

I wish I worked in a team that had conversations like that. Oh... wait... I do.

Being Presidential

"Nothing in the world can take the place of persistence.
Talent will not; nothing in the world is more common than unsuccessful men with talent.
Genius will not; unrewarded genius is a proverb.
Education will not; the world is full of educated derelicts.
Persistence and determination alone are omnipotent."
-- Calvin Coolidge

Grails XFire Plugin

Had a little trouble with the XFire Plugin for Grails. I found this thread of posts on
nabble which clears things up. I attached the thread to the appropriate bug. Other than that I noticed that java.util.Date Is turned into a string. To fix this I created DTO (Data Transport Object) with XMLGregorianCalendar instead. This works find for DTO but could cause a minor headache if I have to expose domain classes directly through a SOAP service. Other than that the XFire plugin handles everything I need it to so far.

XFire is apparently on the verge of getting replaced with CXF which is an Apache incubator project. I was able to work through an CXF service myself using the JSR-181 annotations (that's the Java Web Services meta data specification). Configuring CXF inside a Spring container was the usual Spring XML-er-ific mess that you run into when doing Spring work without a tool kit.

Integrating the CXF Spring config with Grails worked up until I hit a class incompatability between Groovy 1.1 and CXF somewhere down in the XML parsers. I caught just enough to see that it was a class version problem around the DATETIME type where Groovy had one version and CXF had another. That was enough for me to decide to stick with the XFire plugin. I don't want to be in the business of building my own versions of anything that I didn't write.

I figure if the XFire plugin is that simple to set up then it will probably be just that simple to "port" my services to CXF later. Grails does a pretty good job of letting you switch between DWR, Prototype, and YUI when you are working in Ajax... so why not have multiple SOAP plugins that swap out just as easily?