In this installment we are going to dig further into Idea #3 from Building the Enterprise Hammer:

The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.

Developers have already rejected “special hammers” (past versions of EJB), in favor of plain old hammers. This is a great step towards more flexible applications. However, they still typically mount their hammers in some kind of frame (e.g. Spring). What happens when this frame is not perfectly adapted for the task at hand, or when the task at hand changes?

Let’s say, for example, that we wanted to repurpose our Enterprise Hammer as an Enterprise Window Washer, by installing different attachments. We believe that this should work because:

• Windows are regularly spaced on the side of the building.
• Window spacing has a known relationship to the spacing of nails hammered by the Enterprise Hammer.

This is an example of refactoring to generality: finding similarities so that you can cheaply provide a new function (washing windows) through the same mechanism that provided the original function (driving nails).

Java makes this kind of generalization difficult. Java encourages up-front rigor about the type of an object. If you decide later than the “Hammer” type can be generalized to “Widget”, you may have to touch hundreds or thousands of lines of code to enact that change. Duck-typed languages, such as Ruby and Python, encourage less assumptions. And, the assumptions are easier to change later. This is one place where the 10x hype is real.. Duck-typed languages can be an order of magnitude more productive, in both developer time and lines of code, when designing for (or refactoring to) generality.

There’s another issue here, as well. Our Enterprise Window Washer may require changes to the frame itself, since windows are spaced differently than nails, and washing requires a different motion than hammering. But, we didn’t build the frame. What are our options? Many languages provide a simple solution through open classes. With open classes, our own application code can make spot modifications to the frame to suit our specific needs. Conversely, Java discourages this flexibility in two ways:

• deliberately, by closing classes
• inadvertently, through its complex deployment model

As a result, Java developers may learn to not even see opportunities for reuse. Elegant solutions are not only not chosen, they are not even considered.

But More Flexible Languages are Dangerous!

Yes. There are many good reasons that Java became dominant, instead of e.g. Smalltalk. Understand those reasons, and you’ll also know why it’s time for a change. Stay tuned for the next installment.

In this segment we are going to dig further into Idea #1 from Building the Enterprise Hammer:

The three things that distinguish real enterprise development are flexibility, adaptability, and maintainability—not scalability!

The Enterprise Hammer is not Flexible

In the first segment, we introduced the “Enterprise Hammer”, which attached a number of hammers onto a frame so that entire sides of buildings could be nailed together quickly. In practice, this Enterprise hammer has a lot of problems:

• Other building shapes will not work.
• Other building materials will not work.
• It is difficult to adjust the Enterprise Hammer to deal with local variations: terrain, zoning, architectural considerations, etc.

This starts to look like a straw man argument. Couldn’t we just make a more flexible, adjustable frame for the Enterprise Hammer, and solve these problems? Yes, we could, but…

The Enterprise Hammer is Deliberately Inflexible!

In the Java world, we have been obsessively focused on scalability. I.e., how big can we make the Enterprise Hammer? Flexibility gets less attention. In fact, the J2EE stack and the Java language itself are deliberately designed to limit flexibility. To continue the analogy: engineers are allowed only to build and attach hammers. They are not allowed to adjust the frame of the Enterprise Hammer, or attach other devices to the frame. What the consequences of this approach?

• If the frame is flexible enough to match your building, you will do well.
• If the frame does not match, you may be worse off than if you had no frame at all.
• If the frame is inflexible, you will see builders abandon the frame and build their own.

The success of Spring, Hibernate, etc. are pretty good evidence that more flexibility is needed.

Are You Saying that Flexibility and Scalability are Opposites?

Absolutely not! In fact, they go hand-in-hand.

Enterprises need flexible software systems that model their world in rich detail. While some processes are wholly standardized, there will always be important exceptions. Enterprises also need to deal with disparate internal systems, outside partners, mergers, and evolving laws and regulations. Size brings issues not only of magnitude, but also of variety.

One reason enterprises need flexibility is in order to scale! Consider a seemingly unrelated question: world hunger. Tragically, people go hungry every day, despite global food production capabilities that are sufficient. The problem is not production, but allocation. Similarly, software scalability problems tend to come not from insufficient processor power or disk space, but from difficulty in allocating that power to the right tasks at the right times. More flexible systems make it easier to reallocate resources and tasks, solving real scalability issues when and where they occur.

So How do I Get More Flexible?

Stay tuned for the third installment.

We do a bad job of building Enterprise software, primarily because we don’t even know what “Enterprise” means. Today we will lay out six facets of Enterprise development. In subsequent posts we will evaluate each facet in more detail, working toward a shared notion of “Enterprise” that just might make projects more successful.

The Enterprise Hammer, Today

Hammering a few nails is a personal project. Hammering thousands of nails on the side of a building is an Enterprise challenge. Here’s one solution, in six parts:

1. Up-front design: Carefully map the position of the nails that need to be hammered.
2. Enterprise Specification: Build a frame that matches the design
3. Components: Attach special hammer adapters to the frame, at each point that a nail needs to be hammered.
4. Engine: Attach the frame to an engine that can drive all the special hammers at once.
5. Scalability: The engine handles a big task (hammering all the nails on one side of large building) very quickly.
6. Build to Standards:You can improve quality of service by attaching a different engine. Or, you can build a different kind of building by using a different frame.

The Trouble with Components

The Enterprise Hammer I just described is J2EE:

• Hammer = Java code
• Special Hammer Adapters = EJB
• Engine = J2EE Container
• Frame = J2EE Specification

By now, the Java community has realized that this is a poor way to build software. They have focused their ire on item 3 (component models, especially EJB). I will reiterate the primary arguments against EJB very briefly here:

• The special hammer adapters are more expensive to build and maintain than plain old hammers, and offer no compensating benefit.
• The special hammer adapters are difficult to test, undermining reliability. Entire (sometimes interesting) technologies have sprung up to deal with this. I guess that’s a form of peace dividend.
• Terrible performance is easily achieved.

Rather than put up with this nonsense, developers who want to get work done have built their owncontainers around Plain Old Java Objects (POJOs).

But All the Other Facets are Broken, Too!

Java developers have rejected EJB in favor of more pragmatic approaches such as Spring and Hibernate. But it is time to take the next step, and realize that the other five facets above are equally problematic, and need to be reconsidered. POJOs are not a sufficient solution to the component problem, either. So let’s start over, and replace all six facets of the Enterprise Hammer with the following ideas for Enterprise development:

• The three things that distinguish real enterprise development are flexibility, adaptability, and maintainability—not scalability!
• Standards should evolve from working code. The role of standards bodies is to filter the best and simplest.
• The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.
• Engines should be testable and open source.
• Specifications should be flexible, and encourage developers to focus on key concerns.
• The goal of up-front design should be maximum flexibility, not complete solution of the problem.

Subsequent posts will take up each of these ideas in turn.

I was giving my talk on Java Concurrency this morning to a great audience in Denver. Several people knew quite a bit about pre-1.5 Java concurrency, so I was getting interesting questions. As I was demoing ExecutorService and friends, someone asked “But how do I efficiently wait for several Futures?”

Doh! I stop in my tracks. I know there is a simple trick for this, but cannot remember the helper class. Fortunately Brian Goetz is wandering the halls somewhere. Brian is way better than Javadoc, so at the next break he sets me straight (and teases me for not remembering every word of his excellent new book). Here is a little sample showing how you do it:

public class Stump implements Callable {
  public final int serialNo;

  public Stump(int serialNo) {
    this.serialNo = serialNo;
  }

  public static void main(String[] args) throws Exception {
    ExecutorService es = Executors.newCachedThreadPool();
    ExecutorCompletionService<Stump> service = new ExecutorCompletionService<Stump>(es);
    for (int n=0; n<10; n++)
      service.submit(new Stump(n));
    for (int n=0; n<10; n++) {
      Future<Stump> fs = service.take();
      System.out.println("Finished " + fs.get().serialNo);
    }
  }

  public Object call() throws Exception {
    Thread.sleep(new Random().nextInt(1000));
    return this;
  }

}

In my copious free time this week I read the newest Prag Beta Book, Enterprise Integration in Ruby by Maik Schmidt. As I have come to expect from the Prag series, the book is clearly written, from someone who clearly is both a coder and a writer.

It continues to amaze me how easy it is to get things done in Ruby—and how much is already done for you. In demonstrating ActiveRecord in an integration scenario, Maik surprised me with a feature I hadn’t used before: push_with_attributes. If you haven’t used this method before, try it out. Then try to do the same thing with, e.g., Hibernate.

Another thing that stands out is how easy it is to apply existing Java knowledge to Ruby libraries. You’ll find that log4r is log4j, but easier to use. And REXML is ElectricXML, but waay easier to use.

I also like that this book addresses Ruby’s undisputed strengths. The success of Rails for web applications has fueled a lot of disagreement on when and how dynamic languages are suitable for application development. With enterprise integration there is more consensus: scripting languages are great for glue code. If you haven’t done so already, check out Ruby on its home court.

Want to predict the future of software development? Look for features that are currently used only by developers during development/debugging, and project them into a production world.

Consider AspectJ, for example. For years, developers have been pointcutting their own code in the debugger. In fact, gdb’s scripting and breakpointing could definitely be used to implement a primitve Aspect environment

Or, take a more forward-looking example. Today developers are writing unit tests. Jim Weirich has blogged about the new RSpec project, which looks almost like unit tests, but recast as executable specifications:

  class EmptyMovieList < Spec::Context
    def setup
      @list = MovieList.new
    end
    def should_have_size_of_0
      @list.size.should_equal 0
    end
  end

Of course it won’t end there. RSpec (or something like it) will morph into a DSL for specifications. Once in this form, it will be reasonable to, for example, turn precondition checking on or off for specific portions of your code in production. What we now thing of as “development time” unit tests will be fully integrated into production software.

Is this just semantics? Yes, and I agree with Jim. Leave out the “just”.

Congratulations to Scott Davis and Tom Marrs for shipping JBoss at Work. Scott gave me a copy at the Reston NFJS show last weekend, which was fortunate timing since my flight home was delayed and I was stuck in Dulles’s delightful Terminal G.

I am not currently using the full JBoss stack on a project, but I was curious about JBoss’s JAAS support, and was pleased with the proportion of the book devoted to the topic. The tutorial in the appendix reminded me of something I need to add to my JAAS talk: coverage of the command line JAAS debugging flags.

Addendum: Since reading the book I have poked around in the JBoss codebase a bit. If you’re doing JAAS work; it is a nice source for inspiration.