Industry analyst Mike Gilpin (along with Randy Heffner, John R. Rymer) has published an interesting report on the competition between SCA/SDO and JBI.
The key conclusion is that SCA/SDO will emerge as the de facto industry standards if the supporters bring products to market based on the specifications. Even Microsoft will eventually be forced to provide cross compatibility.
Java Business Integration (JBI)
JBI is part of the Java Community Process and defined in JSR 208. JBI is a standard for composing service containers into composite applications. It's very much a Java-centric approach that is very focused (or limited, depending on if you think your cup is half-full or half-empty). Sun Microsystems and TIBCO Software are considered the primary backers of JBI (although Sun is generally considered a key player in most JSRs).
Service Component Architecture and Service Data Objects
SCA and SDO is a very ambitious and broad solution to the composition problem that works for multiple languages and multiple platforms. It's designed to be the universal solution. SCA was introduced in November 2005 by some of the leading industry vendors and is now gaining market support. SCA and SDO are backed by IBM, BEA, Oracle, IONA, SAP, Siebel Systems, and Sybase. All of the backers have Web pages dedicated to the new specifications. It's clear that some of the vendors - particularly IBM, BEA, and SAP are strong supporters.
There's some key points that indicated that SCA/SDO will emerge as the de facto standard:
-IBM and BEA did not support JBI in the JCP. Any Java specification not supported by the two Java industry leaders does not have a chance regardless of technical merits (think JDO)
-SDO is fairly unique in the industry as the only data persistence API for SOA data services. So SDO could in fact drive industry adoption of SCA (Gartner predicts faster SDO market uptake)
-Forrester (rightly) predicts that if the vendors that support SCA/SDO bring out products then it will become the de facto industry standard, regardless of which standards body manages the specifications
The most likely outcome is that that JBI will evolve into a complementary and compatible Java-only version of a subset of the SCA specification.
A bigger question for CodeFutures is what happens to EJB 3.0/JPA with the emergence of SDO?
PJ Murray
CodeFutures Software
David Chappel has written an interesting article on why SCA is important.
The conclusion is:
SCA certainly faces hurdles to success, some of which I described in my SCA/WCF comparison. Still, for organizations moving to SOA—that is, for pretty much everybody—SCA is a big deal. Unless you’re an all-Microsoft shop, in which case your future will rely on WCF, your primary vendors have told you that they’re about to change the platform on which you build service-oriented applications. Since this style of development is becoming the default, the platform you use for it matters enormously. If you care about application development, pay attention to SCA. It really is big news.
CodeFutures is watching the progress of SCA closely, because Service Data Objects is a key part of the SCA architecture.
PJ Murray
CodeFutures Software
There's some speculation that the use (market share) of J2EE (or JEE if you prefer the new branding) Application Servers has already peaked and will now start to decline. This is certainly true - the rise of the POJO, the popularity of frameworks, and the uptake of SOA all mean that there are now alternatives.
There are fundamental problems with J2EE Application Servers that mean that they are no longer the 'platform' on which most business logic is developed and the market share will continue to decline.
Too complex for most problems
We can expect that the J2EE Application Servers will become even more powerful and sophisticated. But also increasingly difficult to use (try mastering 1000+ pages of specifications). J2EE is a sophisticated solution for complex problems. It's overkill for many business applications. To put this in context, CodeFutures often uses Tomcat for its internal applications. Andy Grove, CodeFutures' CTO, was the CTO of the first J2EE licensee in the UK. So to say he used to be a big fan of J2EE is an understatement. But no matter how technically good J2EE is, it's just not appropriate for many projects. That's probably the main reason why the simple, open source frameworks are eating into J2EE market share.
Scalability and performance problems
J2EE has benefitted from the increase in raw CPU processing power. But that free ride is now over as CPU clock speeds are no longer increasing. It is certainly possible to achieve scalability using the traditional server farm approach (which also sells lots of software licenses, which is why software vendors like them), but it's very costly because it's not linear. If you've got a big application running on 100 CPUs, then adding another 100 CPUs might only increase the performance by 30% or 40%. This problem is well documented. The monolithic platform approach needs to be replaced by lightweight (and if appropriate, distributed) architectures.
Commoditization
The evolution of Java is very much one of creative destruction, with commoditization of the J2EE by JBoss. This means that the big J2EE vendors, and their systems integrator partners, can no longer make a lot of money from selling application servers, so they won't be pushing them customer projects. That will reduce market share. At the top end of the market, the major vendors are now pushing SOA. At the bottom end, Java developers are using open source frameworks if allowed, and in the middle, JBoss is giving away a very good product (turning a multi billion dollar market into a hundred million dollar market with a disruptive busienss model). Sun is going to going to be doing a lot of renegotiation of J2EE/JEE licensee contracts!
The rise of SOA
SOA is lightweight, highly distributed, and loosely coupled (it's not, but it should be, unless it's just retrofitting SOAP onto legacy products). That's almost the opposite of a J2EE platform. Application server vendors might position their legacy products for SOA support, but the monolithic architecture is just fundamentally wrong. EIther way, the major vendors clearly think there's money in SOA and that's what they are all pushing their customers to use. If they are pushing SOA, then they are not pushing J2EE, so again, less market share. That's market share pressure on J2EE from the top down (to complement the bottom up pressure from the open source frameworks).
Relax, change is constant
So J2EE/JEE market share is declining due to various market forces. So what? It's still hugely important and still the 'top dog'. It's just not going to dominate like 3- 6 years ago.
Java in general is getting even stronger, so there's nothing to worry about. The Java ecosystem is THE center of innovation in application development, partly due to open source projects like Spring and partly due to the backing of all the industry leaders (except Microsoft, of course).
So relax and enjoy the ride!
PJ Murray
CodeFutures Software
