As we've discussed over the past few issues, JTA-style transactions provide a way for multiple data updates to be tied together so application logic can operate safely in the assumption that it will succeed or fail consistently, even in the face of technical failures along the road.

I have often mused, in this column and outside, on how bizarre it seems that I have filled over two years worth of space in WLDJ talking about JTA, a tiny corner of the tiny universe that is J2EE, itself a tiny part of what a development shop needs in order to deliver something of value to its lords and paymasters as fast as possible. Let's face it, when was the last time you saw a requirements document that said "we need 25 entity beans, 7 message-driven beans, and an XML interface, all of which must be transactional, because that will save us 10% per year over 20 years on our operational costs"?

What you are more likely to hear is something like "we need to automate the on-boarding process; every time we hire a new employee, it takes a full half day, say, of an HR person and a senior manager's time to complete the necessary procedures. We need to cut the overhead of recruitment down to no more than one hour: go and do it in six months with a budget of $150k."

It would be easy to leap from that reality to the view that these articles are of no value, that J2EE is of no value, and that the world should be filled with "solution providers" who do not sell or deliver technology, but solutions to business problems. The sspirin for every business headache, just add water!

The Aspirin for Every Business Headache
However, unlike headaches, business problems don't exist in isolation. A single pain point is just that - a point. Lose sight of the bigger picture in your solution (however seductive that solution might seem on paper) and you will build nothing more than a piece of tomorrow's migraine from today's palliative.

These realities have led the industry to a broader perspective as to what an application server should be, and what an infrastructure vendor (BEA still being the only independent one) should be providing. Gartner talks about the application platform suite (APS) as being the next-generation application server, having formulated that an APS can save an organization up to 22% in time to market across the application life cycle and 40% in post-deployment maintenance (a recurring cost), and give 50% better utilization of expensive developers and architects. Not surprising then that they predict that the APS will become the major unit of purchase within the first 10 years of this century.

So what is an APS? Well, if you think about a normal project's requirements - you typically need a front-end interface, some integration to existing business systems incorporating some automation of process flow between them, and somewhere to put custom logic. The "Do It Yourself" brigade might see that as an invitation to buy an app server, a portal UI framework, and an EAI bus and get coding. However, the savings Gartner identified from the APS approach to the solution flows from the fact that in a true APS Portal, integration and development infrastructures are unified with a single programming model and infrastructure, whereas in the DIY case effort must be spent understanding the infrastructural moving parts in isolation, and all that before the development effort of tying them together (with custom code that you need to maintain and understand) can start. Oh, and after all that the three sub-teams that understand the three component technolologies can start building their pieces of the overall solution that was required before the fooling around started.

You can see from this that the most effective way to provide a solution for a given business problem is to have a team of business-level analysts and developers specify and implement an end-to-end solution using APS technology. I am clearly somewhat partisan in this view (unlike Gartner, and the other analysts, who see it too), but I am proud to work for BEA because we are widely acknowledged in the industry as having a two-year technology lead in this important and growing approach to application development, being the only company that has a production-quality APS product shipping today (and that's said before you start thinking about SOA, SODA, ISE, ESB, and the other technologies that are coming along apace, promising new levels of flexibility to the tired, stovepiped world).

It is against that backdrop that I am currently reading lots of noise about who has the biggest market share in the "J2EE application server wars" - the market share figures are notoriously subjective at the best of times because many vendors don't release audited sales figures at the granularity of individual products. Some analysts say BEA is still in the lead, some say it has dropped to number two, and either way, a good puff of invective on the subject is a great consumer of column inches - there's nothing like a shock headline, whatever the reality. When you add the whole industry's march to the APS approach to the opaque nature of the figures being compared in this debate, what you are left with is the feeling that a change may or may not have taken place in a marketplace, which is rapidly being redefined anyway. Hold the front page! I think it's too early for victory celebration, or obituaries anywhere just yet.

So back to application servers, J2EE, and transactions, not to mention these articles: are they too small to be important? Well, no. The most comprehensive technical solution to any business problem must be built on a solid foundation, so the base-level underpinnings are still important, although hopefully the APS approach will mean fewer people on each project team will have to be intimately familiar with the ins and outs of J2EE. And besides, as chaos theory lovers will know, the wing beats of a butterfly in the rainforest today can cause a storm in the city tomorrow.

But as for the J2EE app server market being the barometer of infrastructure industry success, I don't know anybody who goes about trying to change the weather by talking to butterflies.

Reference