Following the specification
How important are the standards to you?
Back in the days when J2EE app servers were the best thing since sliced bread, I remember having lots of discussions with people about the J2EE specifications and I don't mind admitting that it was always my goal to build a truly spec compliant application. For example, file access from the EJB tier was explicitly forbidden in the specification; because of reasons around portability, lack of file system transactionality, etc. Fast forward a couple of years, and I started to realise that a lot of this stuff didn't really matter. File access via the EJB tier actually did work and it was much simpler than writing JCA connectors. In addition, and in the same way that I have almost never swapped out a database during a development project, it didn't really matter if my J2EE application was portable or not. We'd develop on WebLogic/WebSphere/etc and we'd deploy on the same platform.
Earlier in the week I was talking to a group of people who were defining the architecture for a Java EE system and they started asking how they were going to access the file system from within their EJB tier. I'm curious ... what's the general feeling about specification compliance these days? Do you care whether your applications follow all of the recommended guidelines, or do you take a pragmatic view that just asks whether it works? How important is this to you as an architect?
About the author
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.
You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.
Re: Following the specification
I used to be the same, trying to get the code as compliant as possible, finding ways to minimise vendor dependencies. I've kind of come to view that as a series of missed opportunities -- a blueprint for an average application. Much of these specifications is concerned with the intersection of providers' functionalities and if that's all you're interested in then it seems fair to assume you're using the cheapest product :P
You tune various parts of the system to get the most out of the products you're using so why not "tune" the code in the same way? The trick is to get the architectural bulkheads in place that prevent these idiosyncrasies leaking throughout the code.
Re: Following the specification
Re: Following the specification
For mine, portability is one of those non-functional requirements that needs to be traded off against many others.
Like any other requirement, there's a sliding scale of cost associated with meeting it.
If I'm an app vendor, portability is high on the list, so I can broaden the market. If I'm developing an internal enterprise app to a stable infrastructure, I would spend my time and resources on things like availability, performance, etc.
Re: Following the specification
As far as file system access is concerned, the primary issue in my view has always been the behavior when your application is clustered. You need a way to deal with that in a reliable fashion. This is the kind of problem that many of the ESB products that are around (such as Mule and JBoss ESB) deal with rather well.
Re: Following the specification
I agree that people become almost fanatical about portability. My favourite bug-bear is databases- avoid vendor specific extensions if you can, but be realistic about how likely you actually are to change databases.
I think the point about bulkheads is a good one- some property stuff in well defined places is probably ok if it meets a need, but don't let it pervade the code. Keep it contained.
Tom
Re: Following the specification
I very much like Mike's "NFR argument". It really links well with the architect's responsibility as Simon discussed in the SA2008 talk. Perhaps it's also a part of "technology selection", and "ownership of the big picture". All Architect responsibilities.
We're the ones with the big picture, we're the ones who know (for a given value of 'know') where the system will be going. We need to contain and control (bulkheads) where we've traded off some part of a technology spec against something else (like performance, cost, timescales, etc).
I think that in order to do this trade-off, you need all the responsibilities and information that an architect has. Therefore, only the architect is really in the right position to do it - to say stuff like "ack, just blast it into a properties file", or "yeah, use the Oracle/Weblogic/whatever specific function call". There are probably going to be problems if someone else starts making these decisions.
Re: Following the specification
I pretty much agree with the point of specification compatibility being a tradeoff like any other. And I am the kind of guy that will push against compatibility if that makes a significant different in making development easier, meeting deadlines and so on.
However, mind you that following portability has also important advantages like a explicit contract that every application server must mandatorely meet. That means that as long as you stick to the spec. hopefully you will be pretty much safe.
I remember a project months ago in which we broke the spec and started using some rogue threads because it was easier, quicker to develop and trivial to understand. At the end this proved as a wrong choice as this caused severe problems with the server-side transactions which ended up on losing quote a few messages in our messaging system. An error that indeed was quite difficult to track and made us lose quite a bit of time on it.
So, yes, make the tradeoff, but also it will be good if you are really sure of what is going to be your server behaviour if you break the rules.