With SCA, reality bites J2EE again – but is that the whole story?
[Note to readers: this is a long entry. Please bear with it!]
With the
announcement last week by IBM, BEA, Oracle, SAP, Siebel, IONA and others that they are collaborating to develop a language neutral programming model tuned to the needs of SOA initiatives, it looks like a little more lustre has rubbed off J2EE. But it also looks a little like something deeper could be going on: the biggest vendors are shifting their attention to a wider market opportunity. Can they avoid the mistakes of J2EE?
J2EE was originally designed with serious input from IBM (based on its ComponentBroker middleware project), BEA and others – as well as Sun – to standardise a programming model for building web-based business applications. It arrived in the dot.com boom, when the world was awash with small innovative suppliers selling middleware which combined web servers with support for object-oriented programming, and transaction handling against remote databases; and outwardly at least, the idea was a good one – the argument from the authors was that without a clear standard in the market, the cost of developing skills and the risk of vendor lock-in would hold the market back.
But for some years now voices in the software development community briefing against the suitability of J2EE for various types of work have been getting louder.
"If it ain’t J2EE, it ain’t going to do the job"
I’m happy to admit that there’s long been a conspiracy theorist living in my brain, telling me that J2EE was an attempt by the established players (IBM, BEA and Oracle, aided by Sun) to lock small vendors out from the Java application server market opportunity. For most of the time the primary "evidence" to support my feverish imaginings was the fact that certifying products to J2EE has always been expensive – and it has become more expensive as the specification has become more complicated. Small vendors had real trouble getting the resources together to play that game. Now, though, I’m starting to think that the increasingly audible developer discontent with J2EE adds fuel to my fire.
It is entirely possible that J2EE was developed altruistically by the folks involved in the process. However good the original intention was, though, the large vendors’ sales and marketing teams have certainly been happy to associate complete J2EE compliance with the ability to deal with real-world requirements in customers’ minds (see
here for just one example).
Innovation always finds a way
The shine on J2EE started to dull when a core element of the Enterprise Java Beans (EJB) element of the J2EE programming model, Entity Beans, started to be seriously tested by developers – and many declared it to be too clumsy and inefficient to provide the facilities which were advertised (again, see
here for an example). Curiously, given its stated intent, as well as its shortcomings in helping developers manage persistent data, the J2EE model also never really offered design patterns to help people building web-based applications become productive. More recently, the specification has received brickbats for failing to really get to grips with the challenges of developing and deploying web services.
On top of this, J2EE is managed by the Sun-led Java Community Process (JCP), which has, in all core Java-related areas, eschewed the creation of royalty-free specifications. This is combined with the fact that as J2EE has moved through a handful of major revisions the specification has only become more difficult and expensive to certify against.
More and more Java development shops have been looking to (open-source, royalty-free) frameworks like
Hibernate,
Spring,
Tapestry and latterly
Struts – supported by "professional open source" vendor JBoss and vendors with "blended" approaches like BEA – to help them build the kinds of applications that the J2EE specification was originally designed to help with. The JCP has learned some lessons from these frameworks in the new Java Server Faces (JSF) and EJB 3.0 specifications, but the alternatives continue to thrive.
And at the same time as all these J2EE-related shenanigans have been going on, Microsoft has been steadily plugging away at its own .NET programming model – introducing features to
hide the muckiness of dealing with web services and various proprietary integration technologies; offering a variety of ways of
processing and managing persistent data; as well as making it relatively stress-free to develop client-server applications which can seamlessly work with or without network connectivity.
If you want to a winner, you can’t only champion Java
Moreover, IBM and BEA have done little to hide their antipathy regarding the JCP. Both abstained from voting on a recent specification proposal concerning the creation of a standard Java integration framework (JSR
208, for anyone interested ;-). IBM has taken to adding a statement (see
here for an example - scroll down in the comments box) to all its JCP submissions to the effect that it disagrees with the JCP’s licensing model. And IBM and BEA have been collaborating heavily, along with a number of other very significant vendors, on two new programming model specifications: Service Component Architecture (SCA) and related Service Data Objects (SDO).
The technical details of SCA and SDO (such as they are, at this early stage) clearly borrow from the innovations of the open-source Java frameworks – as well as from Microsoft’s own programming model innovations in .NET 2.0, the Windows Communication Framework, ADO.NET and LINQ. Most importantly, however, they are explicitly "multi-language". Support for Java is obviously important, but Java is just one language that the project will target: the other "first class citizens" are C++ and PHP.
For IBM and BEA watchers, this move is very significant. Both companies are betting a lot on SOA being a Big Thing – and the truth is that SOA is about integration first and foremost – irrespective of runtime environment or programming language. A SOA technology proposition based solely on Java is a three-legged dog in what will turn out to be a fiercely-contested race. Both IBM and BEA have some serious technical and marketing work to do in this regard, as they have spent many years and hundreds of millions of dollars convincing the world that they are synonymous with “enterprise Java”. BEA’s acquisition of the language-neutral Plumtree was a good step forward; and IBM is constantly being reminded of the need to something by its Global Services outfit, which makes a lot of money away from the Java world. IBM and BEA’s roles in the development of SCA and SDO are clearly there to support the companies’ moves away from Java-centricity.
For J2EE watchers, the introduction of SCA and SDO is also of paramount importance: it’s yet another sign that J2EE is increasingly seen by many of its big vendor champions as just one possible platform design which will work for customers looking to build and integrate modern business applications. In my opinion, it’s not before time.
SCA: the next J2EE?
The SCA/SDO programming model initiative has a lot of potential to help development shops in the software community, as well as in other industries, get to grips with the challenges that SOA brings. But there are some challenges that the promoting group will have to overcome if it is to really serve the needs of customers – and if it is to avoid the slide into disillusionment that software vendors and enterprises are now experiencing with J2EE.
The group says it’s committed to developing open and royalty-free specifications. But will it also work to keep specifications simple, so as to ensure that a wide range of participants can implement them?
When and how will the group transfer the specifications to an independent standards body? This question is crucial and also tricky. There are many who say that the JCP is too quick to adopt new specifications – leading to endorsements of specifications which aren’t fully road-tested in industry. Standardisation of a technology has to both take input from commercial experience from technology innovators and early adopters; as well as making the technology appealing to the larger population of mainstream adopters.
The philosophy is language-neutral. But will the group make explicit provisions for the addition of new language bindings to SCA and SDO by third parties that may come along later, and how easy will this be?
If SCA and SDO are set up to compete against Microsoft’s programming model initiatives, the sponsoring group needs to ensure that they make solid, compelling development tools available quickly. Unless progress is swift they will leave potential customers with a complex set of specifications which are difficult to implement.
