Wednesday, April 23, 2008

I'm a little surprised that it's taken until Java 7 to seriously consider how to address JMX in a Cluster. This seems like something that a lot of people would have to be dealing with regularly. I'm trying to discern what this means:

People don't use JMX much.

People who do a lot of clustering don't use JMX to manage their running applications.

Everyone who clusters and uses JMX invests a fair amount of time into deploying a solution like OpenDMK.

Tuesday, April 22, 2008

This is by far the best source for explaining the ideas and algorithms underlying java.util.concurrent -- the vast majority of them, plus some others, including a few that may someday appear. It also uses Java / java.util.concurrent to illustrate most concepts. I strongly recommended it.

It's not uncommon to want to be able to change the logging configuration of a running application without restarting the application. There are a few mechanisms for doing this. One, which I've used in the past, is to expose Log4J via JMX. It's a bit of work, but not terrifically hard.

Another mechanism is to have the logging framework watch its own configuration file and, if it changes, reconfigure itself. Log4J has a mechanism for this, which Spring exposes through the Log4JConfigurator (Log4jWebConfigurator, etc.)

Unfortunately, it seems as if, at least according to the Spring folks, and their documentation, Log4J's mechanism doesn't do a good job of shutting down its thread, and therefore should not be used in a production setting.

That means that either I'm going to have to back to using the JMX approach or, alternately, switch the project to LogBack, which has a JMX Configurator built-in, and can reload from configuration using JMX.

Tuesday, April 15, 2008

It'd be interesting if AppDrop moved its persistence layer to SimpleDB. You could then get a good comparative benchmark of a single instance of AppDrop EC2/SimpleDB vs. running on the Google App Engine infrastructure. From there, you could work on the scaling story, either with transparent scaling, like Google seems to offer, or with user-controlled scaling (since AWS services aren't free, the latter might be less dangerous).

Not that AppDrop is necessarily the future of AWS apps any more than GAE is the future of cloud computing, but a common model for platform-on-cloud development that could be deployed in more than one infrastructure is appealing.

Maven 2.0.9 locks down the versions of core plugins in the super POM. This should increase the stability and repeatability of your builds somewhat. You'll still want to lock down versions of third-party plugins in your build for the same reason.

A friend passed on a link to this Universal Data Models article, and I have to admit this is an issue about which I feel some conflict.

On the one hand, I respect the notion that, in the world of standardized relational databases and object-oriented programming, it'd be nice to be able to pick up standard models that represent clear and common items like people, companies, and the relationships between them.

On the other, I've wandered partially down this path before a few times and emerged with scars. While it's certainly true that many organizations have software that needs to track information about people, organizations, and the ways they're related, it's also true that there innumerable pieces of information one might want to record about people and organizations, and countless ways in which they can be related. In order to be truly universal, you'd have to capture all of those ways and distill it into a common data model.

Practically speaking, I find that universal data models fail in three important ways, and most models attempting to be universal suffer from at least one if not all three of these:

Too Generic: Because the model attempts to be flexible, to be useful in all kinds of scenarios, what you're left with is often too generic to be as useful as a data model tailored to your needs. For instance, if your company has one and only one account manager assigned to a particular client, the simplest way to represent that is something like a foreign key from a client to an account manager. In a universal model, this is might take the form of, say, a PERSON_ORGANIZATION relationship between an 'employee' person and a 'client' organization and where the PERSON_ORGANIZATION.ROLE is 'account manager', and you'll need application-level uniqueness checking to ensure there are no duplicates. You'll find yourself having to do extra work for the simplest things -- if a billing address is a requirement for any client, you can enforce that in your custom data model, but there's no way that your generic model can do that for you.

Too Much: The model has more information than you need. You don't have email addresses for your field employees, or you don't care about fax numbers, or perhaps your clients don't have departments and regions, or you don't care to track them.

Not Enough:

Often, each instance of those problems is pretty minor:

The universal model has a field you don't need? Ignore it, filter it with a view or don't map it to your domain objects.

The universal model doesn't have a field you need? They've kindly supplied a key-value table or custom_field_12 where you can put that sort of thing.

The model's too generic? You can simplify that by using a domain object that hides the complexity.

All those things are true, but they increase the pain and effort of using the model. Quickly, the cost of using a generic model exceeds its benefits, particularly if you're doing so for purely philosophical reasons like, "Wouldn't it be nice if we could all re-use a common idea of what a Company is?"

Worse still, these can introduce cognitive dissonance when you force-fit your own business needs into someone else's generic model - you can make it that much harder for your business members and development team to share a universal language about your domain and communicate effectively. When the business owner asks "Validate that when an account manager leaves the company, another account manager takes his place with that client", you have to do mental gymnastics to imagine what they mean, and those gymnastics can introduce errors, almost like transcription errors: "When a PERSON with PERSON.type='employee' and PERSON_ORGANIZATION.role='account manager' becomes PERSON.active=false, then add a new PERSON_ORGANIZATION record that associates another PERSON.type='employee' with PERSON_ORGANZATION.role='account manager' ... "

I'm curious how many people find themselves using universal models and are happy doing so.

Friday, April 11, 2008

Gartner says Windows is Collapsing. While I don't believe in industry analysis for the most part, and any headline like this is oversimplified, I'll agree insofar as this:

Microsoft has survived a poorly reviewed operating system before, but they're beseiged right now. If the next version of Windows doesn't get business accolades, we may well have witnessed the beginning of the end. Microsoft isn't going anywhere now, tomorrow, or even next year or the year after, but if they don't make some ground, they're going to be increasingly marginalized as a technology has-been.

Some people would argue they're there already, and have been there for a while, but as long as Windows and Office continued to bring in the Cash, it's hard to argue. If that destabilizes, Microsoft will begin to devolve for real.

Tuesday, April 8, 2008

I have to say, after preparing a long and exhaustive post on Google App Engine for InfoQ, one of my remaining takeaways is that in order to make good use of App Engine, you've got to be willing to trust Google.

To a certain extent, that's true of most software-as-a-service. If Google decides to terminate GMail, or goes out of business, that's going to do serious damage to my ability to communicate with the world, which is a little scary. At the same time, that's mostly relatively personal, relatively low-consequence items. I'm not saying I'd be happy if GMail went down, far from it, but I'd survive it.

On the other hand, if I built my startup in Google App Engine there are so many things out of my control that can happen, not the least of which is that Google could increase the cost of the service significantly, and notify me, and it wouldn't be incredibly easy to take my app and host it elsewhere.

That's not true of most web applications, which can be hosted at any compatible hosting provider, of which there are usually many. So you are, to a certain extent, locked in to the Google infrastructure, which provides you benefits, but comes at a cost.

That's not necessarily a deal-breaker, especially when compared to the cost of hosting an application yourself and managing it to scale, but it's something that any adopter has to seriously think about.

Many people are comparing Google's App Engine to Amazon S3. There's certainly some relation - both offer the ability to build an application and run it 'in the cloud' - in someone else's infrastructure, with seemingly limitless expansion room (well, Google's offer has a strict quota, but one assumes there'll be pay plans beyond that point in the future).

But Amazon's approach has been bottom-up - web services that allow you to control the bits and bobs of infrastructure you might use to create your own cloud-computing application (e.g. EC2 instances and S3 storage). This gives you a fair amount of flexibility while still being simpler and more cost-effective (in some cases, anyway) than building your own grid infrastructure. For instance, EC3 can allow you to scale to handle peak loads while still keeping your costs low when there's less traffic.

On the other hand, Google's top-down approach isn't really about giving you options, it's about creating a model for applications that run in the cloud and restricting you to that model, so that you can focus on building an application and trust that the limitations Google has placed on you will allow Google to scale it up and down as necessary to meet demand.

The former has a lot more control and sometimes that'll be very necessary for applications that are difficult to build in Google App Engine (for instance, there's only language support for Python at the moment). On the other hand, the latter offers a very simple model for creating applications at scale without needing to really know that much about how to scale an application.

It'll be interesting to see, with time, if development for the cloud is closer to Amazon's (full control, skill required) or Google's (restricted choice, with simplicity). I'd probably bet on the latter for most applications.

I'll have more to say on this later -- I'll be doing something more comprehensive for InfoQ.

Sunday, April 6, 2008

I guess I've never been a big fan of the idea of disposable razors. It seems like regular razors are pretty convenient, and I'm not sure there's much convenience to be added by throwing away the handle. I guess it never really seemed to make a lot of sense to me. Even if you want a razor just for travelling -- go buy a second razor, I guess.

It also seemed pretty wasteful. So I guess when the Yonge and Bloor stations in Toronto were papered over with "Mach 3 Disposable: Enough Said" ads, it really struck a nerve. Enough of a nerve to spend some time in Photoshop to translate their ads into the subtext, as read by me:I wasn't sure how much one could get away with without dealing with cease-and-desist letters, so I decided not to pull in the Gilette name or the Mach3 specialized writing, just to try and calm down the possiblity of legal storm. That said, either nobody ever really notices and neither will Gillette, or perhaps this'll attract enough attention to bring Gillette, at which point I hope this has reached a large enough audience, by then, that the value of issuing letters to have me remove this will be significantly reduced.

Wednesday, April 2, 2008

In order to prepare for some integration testing of a multi-WAR service layer, I included one WAR into the project dependencies of a Maven web project. If I had time to do this in 'the maven way', I'd probably pull this into an integration test subproject, but, sadly, I don't have time for that in this instance.

Unfortunately, this leads directly to Maven's principle of 'most surprise'. Turns out, if your web project depends on a WAR, the contents of that WAR will be overlaid over your web project, unless you explicitly tell it otherwise. Since I hadn't read about overlays this was actively damaging to my project, and very confusing. This cryptic build output helped me understand what was going on:

Tuesday, April 1, 2008

It's great to see JAX-RS picking up momentum. I've done work in Restlet, and I'd like to spend some time in Jersey, so it's great to see that I'll have more choices next time.

Next comes tool support, integration, and then ... the world. Although, to be honest, I'd be happier with web services and remoting if I felt that they were consistently being used appropriately. I still find that people consider remoting when they don't need it -- too busy looking for the long-term flexibility and not enough time actually building the immediately necessary functionality.