My thoughts on Java

We’re working right now on implementing on the IBM Websphere Extended Deployment platform. Yes, that much aligned of JEE App Servers. Certainly IBM deserves the common criticism that their system is overly complex. Still, if you implement what enterprise requirements ask for (clustering, high availability, scaling, failover, persistence, automation, etc.) I think you’re hard pressed to come up with a simple solution.

Nonetheless, that’s not the main point of my post. IBM provides a flavor of Websphere Application Server, or WAS, called ND (Network Deployment). This model centralizes and automates deployment and configuration management. Extended Deployment or XD comes in 3 flavors. Two of them focus on long running batch transactions and distributed object models for high volume enterprise applications. I’m not using either so I won’t go into detail on them.

The third section is Operations Optimization now referred to as Virtual Enterprise (because, it’s always so much fun to start with a new name and acronym and have to retrain everyone on it!). This component focuses on post-deployment monitoring and management. The system has improved reporting capabilities built in (which appear to be a flavor of ITCAM, IBM Tivoli Consolidated Application Management baked in), as well as autonomic capabilities within the WAS environment. These functions allow for the system to dynamically take ‘dead’ JVMs (which consume too much memory or CPU) offline or in maintenance modes for investigation, as well as scale the cluster to meet demand. Today most enterprise environments run the system at maximum capacity all the time. The notion IBM has here is that multiple applications could share the environment, allowing XD (guess I need to start referring to it as VE now!) to shift capacity between them on demand. One shortcoming we’ve discovered in thinking how this would be applied to the enterprise beyond our group is that many applications share peak load time. The ideal savings here are pairing critical applications with non-critical, or daytime peak systems with others that only run large loads at night (batch jobs perhaps).

The idea seems nice. So far the system works as described. There’s been some bugs along the way, but I have to give IBM’s support department credit for quick turnarounds on patches. The built in debugging in WAS is very structured and capable and typically allows for them to spot problems quickly. The other nice feature of XD/VE is the capability to manage a repository of stored versions of an application which you can then switch between, even running a second version concurrently for validation purposes.

The core of the XDOO system is the On Demand Router (ODR). This JVM is built upon IBM’s proxy server technology and handles the dynamic work load management (DWLM) and other autonomic functions of the environment. Being the most complex and crucial part of the system, it is also the most error prone.  Again though, it has superior logging modeling itself both on a JEE application as well as a traditional web server.

There are a number of other approaches to this type of dynamic or ‘cloud’ computing as it’s being referred to in the hype machine. Amazon’s EC2 is another example more in the Software as a Service (SaaS) model. While these may serve certain purposes for non-critical systems running on non-private data, in the long run I think many enterprises are going to want more control over their systems and will want a blend of a more traditional data center and hardware with an application platform that can deliver some of the benefits of cloud computing in terms of dynamic resources. While IBM is by no means perfect and XD OO isn’t the only solution out there, it does seem to be a solid step in the right direction.

In the JEE world, Sun breaks down the process of delivering an application into various roles: developer, assembler, deployer, etc. This is all well and good, but I have yet to work somewhere where we had each of these roles filled by unique individuals with clearly defined responsibilities. One particular area where I see a lot of confusion and lack of direction on (even from the likes of new visionaries like the Spring folk), is in where to place environment-specific configuration values. By this I mean properties that change from the development, to test, to production environments. Often this consists of host names that change, ports, email addresses, etc.

To the best of my knowledge, if you read the Sun abstract ivory tower specifications, the code should be compiled once (and run anywhere, right? ). However, it is then assembled into a deployable archive - an enterprise or web archive (ear or war) for each environment. The appropriate values are stored in resource bundles (*.properties files). A bundle is selected for each environment’s ear. So in the end you have:

• MyAppDev.ear
• MyAppTest.ear
• MyAppProd.ear

Sounds good. But in reality, the ear/war assembly step is far more complex. It combines compiled code, configuration files, jar libraries, tlds for tag libs, JSP pages, and much more. The risk in deploying such a complex assembly directly to production without testing that very same ear in another environment is simply too high in most enterprise environments.

So I see a variety of solutions:

• put values into JNDI space via whatever mechanism you use to configure your application server (often done via a scripting language/interface such as wsadmin & jython for Websphere)
• Load all values but have an external flag indicate which to use
• Place the property file outside the ear on the target system in a separate deployment process (these environment specific values tend to be unique from release specific values, but are not always distinct)

Each has its own advantages and disadvantages. Personally I prefer a holistic deployment unit that can be deployed in a fully automated process, and runs the least risk of using test values in production. Thus, I lean towards a variant of the first option above.  In essence we have a tar file with an ear, properties files for all environments, and the necessary automation scripts for our server.

Since any and all of these approaches are not standard, you cannot simply pick up these deployable units and run them on any application server unless you revert to the environment specific ear. Sun, Spring and others need to come together to address this concern and have a meta-specification for environment configuration that boils it down to the simplest possible solution such that there is little to no concern or risk over the complexity in the assembly step of what still amounts to an environment specific assembly step. For example, a tar file with the ear or war in one location, and one or more properties files in another, with the deployment keying off a passed in argument to know which property file to load. Simple, but effective in its very simplicity.

So Spring recently announced they will enter the application server space. However, rather than being just another player (who would have expected that from Spring?) they are going to have a server that only implements part of the JEE specification: a web container only, no EJB container. They’ll also be OSGi compliant. Which to be completely honest, I’m still not entirely sure what that will mean. It looks to be a new generic standard for interoperability and module deployment/configuration. Could be a good thing as that is an area JEE is sorely lacking in, IMHO (I intend to blog on this topic soon).

Generally I’m very positive about the work Spring has done in the JEE space. Their frameworks are simple, reliable, and clever. I’m concerned what this announcement will do to the community. Don’t get me wrong. I’m glad there’s a container out there that doesn’t implement the ugly, complex EJB spec that often weighs down a JEE server (like Tomcat, which is what the Spring server is wrapped around). In my current project we are using IBM Websphere, for better or worse. While WAS delivers deployment and monitoring management capabilities, I would be just as happy to run an environment with those abilities with a server which just had a web container. It’s been nearly 8 years since I wrote an EJB and I plan to keep it that way. And I think Spring is trying to work cooperatively with others and come to the table. The JEE 6 spec to my knowledge will have the notion of profiles: different containers can be certified to run certain profiles (whole spec, just web container, or some other variant I’m not clear on right now). Spring intends to be certified on the web container only profile.

Still, this could be the beginning of a major shift in the Java camp. We’re on the verge of significant change anyways with the proliferation of dynamic, functional languages on the Java platform like Scala and Groovy. Change is good, and healthy. Still, change like this can also bifurcate and weaken an ecosystem like the Java community. By finally throwing down the gauntlet against the major app server vendors which they’ve played nice with to this point, an IT holy war could be on the verge of occurring in the Java community. Not trying to be overly dramatic, but it’s possible. I’m curious to see where this all ends up.

This weekend I attended for the first time one of the No Fluff Just Stuff conferences, one of the big conferences for the Java crowd. Other than a Gartner conference, I haven’t attended any type of IT conference before. I’ve never had the opportunity to make it out to Java One which I have heard has gone downhill since its inception.

I was very impressed. For starters, the conference was very reasonably priced. I’m always floored with the prices charged for IT training and conferences. The speakers were all of an excellent quality. Not only were they knowledgeable, but they were good presenters. With introvertedness being very common in IT circles, it’s always refreshing to find people who are outgoing and communicative.

The material is specific, and directly applicable to enterprise IT. I found Gartner to be very fluffy and buzzword-laden. While NFJS was a bit excited about some new technologies like Groovy, all in all I thought it was very level headed.

Topics ranged from next generation languages like Groovy & Scala, to best practices around measuring quality and open source tools you can use for metrics. I’m excited to get back to the office and try to plug some of these tools like PanOptiCode in.

People like Craig Walls (of Spring in Action fame) and Scott Davis were on hand to teach some of the sessions, so there was no dearth of big names. If you’re in the enterprise Java space, I strongly encourage you to seek out a No Fluff Just Stuff conference and attend soon.

I’ve grown tired of writing on my personal blog, but the writer in me always needs an outlet. As I’ve matured as a software developer and architect I’ve been wanting a place to share my thoughts on good practices around software development. I don’t think I have all the answers but I do feel like I’ve learned a lot and have a few good ideas.

I debated what name to have for this blog. Software development isn’t as much a science as we’d like to think. It’s a skill you learn over time from others. It reminded me of the guilds of olden times, when an apprentice would work with an artisan and slowly learn the craft. So, Code Guild is born.