Supporting SCA’s Java Component Model: Which Vendors Will Do It?
Friday, May 11, 2007
This year's JavaOne conference included a panel on Service Component Architecture (SCA)
, for which I was the moderator. Representatives from BEA, IBM, Oracle, SAP, Sun, and Tibco spent an hour answering questions posed by the audience and me. It quickly became apparent that even though all of these vendors supported SCA, they had quite different ideas about what this meant.
To understand the main division, recall that SCA 1.0 defines two main things: a new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites
. Composites can contain components built using SCA’s new programming models, but they can also contain components built using other technologies, such as Spring and BPEL. SCA doesn’t define a new programming model for these other technologies, however; it just describes how components built using them can be made part of a composite.
I’ve argued before
that the new programming model for creating Java components is a fundamentally important part of SCA. Because it provides a simpler and more service-oriented approach to building business logic, developers can use it instead of EJB, JAX-WS, and perhaps other parts of Java EE 5. As the JavaOne panel discussion made clear, not everyone agrees.
While IBM and BEA strongly support the new SCA Java component model, Oracle, Sun, and SAP appear to have a different perspective. All were big fans of SCA’s assembly aspects, but none of these vendors seemed happy about the prospect of another component model competing for the hearts and minds of Java developers. SAP's panelist asked the audience for a show of hands: Who wants to see a new programming model for Java components? In a crowd of several hundred people, not one hand went up.
Yet asking this question of a .NET developer audience before the announcement of Windows Communication Foundation (WCF)
, the .NET analog to the SCA Java component model, would have elicited the same response. Most developers want to get their jobs done, not devote scarce working hours to learning yet another way to do them. Nevertheless, it’s incumbent upon platform vendors to improve the technologies those developers use. Moving from COBOL and CICS to the Java platform annoyed a lot of people, as did Microsoft’s move to the .NET Framework. But in both cases, the resulting boost in productivity and functionality made the pain worth the effort.
Although it’s nowhere near as big a change as these earlier shifts, SCA’s Java component model has the potential to offer another boost. Yet judging from the vendor responses on this JavaOne panel, there’s no guarantee that this will happen. Strong support by BEA and IBM improves the odds of success, since these two vendors dominate the market for commercial Java platforms. Still, if their competitors fail to support this new approach, SCA could miss a chance to modernize and simplify the Java environment.
One more point to take away from this is that when a vendor says they support SCA, you can’t know what they mean until you ask them. When Oracle says it, they seem to mean the technology’s assembly aspects. When BEA says it, they seem to mean the assembly aspects and the Java component model, but not necessarily the C++ component model. When IBM says it, they seem to mean pretty much everything in the current 1.0 specs. When Sun says it--well, I’m afraid I can’t tell what they really mean.
The unity that let J2EE compete so successfully against Microsoft is breaking down
, and the result isn’t pretty. If the vendors in this camp can’t agree that supporting SCA’s Java component model is worth doing, I can’t help worrying about the future of the Java platform