David Chappell


Get the Feed! Subscribe

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

8 comments :: Post a Comment



Hi David

Interesting to hear your views.

At Blue Prism we have bet our shirt on the .NET horse and expect it to romp home....one day.

First of all, I think David did a great job in moderating the SCA panel at JavaOne. Introducing SCA in 5 minutes, bringing forth most of the key questions in such a short time and keeping the audience engaged through out the session is not a simple challenge, I think.

Now, there are a few things in David’s blog that I think deserve further discussion, in particular - whether SCA defines a new Java programming model and how critical it is for the success of SCA.

In SCA, component implementations are highly configurable and rarely should you need changes to the actual code. SCA defines a lot of metadata for implementations to declare such as -- compositional aspects (provided services, dependent services, and configurable business properties), policies affecting execution and interactions, bindings to communication infrastructure, etc. Besides such metadata, SCA also defines a set of commonly useful features such as - asynchronous, bidirectional, conversational interactions!

For the above (declarative metadata and the small set of features), mappings to various programming languages are defined (not just for Java, but also for BPEL, C++, etc). So I guess, SCA does introduce some new programming model for the various languages. Now when I say "new", I am not implying that it is replacing anything existing or old, but simply that - SCA defines some new concepts and thereby introduces the corresponding new programming model. That's all. Your blog, however, seems to imply that SCA defines a new programming model in Java that competes and should win over Java EE (and EJB in particular). I don’t think this comparison is quite right. EJB is primarily an implementation technology which addresses a different set of problems. Java EE includes support for many aspects such as security, transactions and combines many critical Java technologies and frameworks together that are commonly used by application developers. So although there is possibly a thin overlap, I don't think of Java EE and SCA as competing technologies. OTOH, I think that they are highly complimentary technologies.

Also note that, for Java, it is envisioned that different vendors may want to support SCA on top of different Java component technologies such as Java EE or Spring. SCA makes this easier by defining - a> Java Common Annotations and API specification and b> bindings to individual technologies such as Java EE and Spring. So the idea is to allow enhancing different existing Java component technologies and not to re-invent a new one.

I have blogged on this topic a little more on SAP's SDN at - https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6567

-- Sanjay

I've blogged my take on this issue. Short version is that I think that the term "programming model" seems to be in dispute. However, rather than dealing with terminology, I just give a brief summary of what SCA is and note that some (but not all) JavaEE technologies aren't really needed when SCA is available. I'll let others decide if that qualifies it as a programming model.

Both Sanjay from SAP and Michael Rowley from BEA were on this panel, and it seems to me that their comments underscore my point: Different vendors see this differently. Sanjay's referenced blog entry says "Java EE 5 provides a great foundation" for SCA, while Mike's entry says "EJB session beans, MDBs, JAX-WS and even JMS aren't usually necessary in an SCA universe". It's worth noting that both of them are listed as authors on some of the main SCA specs. (Those must have been interesting meetings!)

And I'd argue strongly that SCA does define a new programming model for Java components. If it can be used in place of EJB, etc., surely this is enough to qualify as a new model.

It's hard to overstate the importance of this new approach. If the Java world doesn't adopt it, enterprise Java developers will be stuck in a world that's significantly more complicated and less modern than that provided by its biggest competitor, the .NET Framework.

I really think that this is missing the forest for the trees. What is happening in the Java world is simple: programmers are becoming more and more able to work with plain old Java objects for modeling their business logic and layering on "container" management as (mostly) orthogonal concern. The "model" for Java in SCA is almost identical to the "model" for Java in Spring. As I've pointed out elsewhere, it's possible to run "SCA Java code" in the Spring framework. EJB is moving in this direction as well, albeit somewhat more slowly. To be honest, it looks like the trend is convergence toward a single approach in the long run.

From a purely technical point of view, Greg, I agree with you: The various competing platform technologies are moving toward a similar approach. If your only concern is what the technology will look like in a few years, then your perspective is wholly valid.

But what about a vendor trying to choose which horse to back today? What about an end user trying to determine which platform will be safe to bet on? What about a developer trying to decide which skill set to invest time in acquiring? All of these are much more immediate concerns, and all of them require dealing with the various competing choices that exist in the aftermath of J2EE 1.4.

Long-run views are useful, but making decisions in the here and now can't be avoided. Unless the Java world wants to see .NET's market share continue to grow, it needs to choose what its primary business logic platform will be.

I realize that this is a somewhat old topic and your views have probably been updated thanks to new information by thought I would post my two cents anyway ...

in my opinion, the whole purpose of a IOC/injection programming model such as the one provided by SCA is that it frees our client from having to bet the farm when backing any "particular horse". Service logic code is completely decoupled from the underlying infrastructure of any particular SCA or non-SCA runtime. This should sufficiently isolate any early adopters of SCA in case they wish to switch to an alternate approach. As long as that alternate approach also supports simple declarative/annotated interactions then the migration will be quite painless. I don't think there's any confusion within the Java vendor community around the vision that injection is the ideal way to define the interaction between container and business logic code. The major conflict comes from what the nature of the annotation and declarations should be. The beautiful thing is that as a systems integrator I no longer care, as long as my POJO's are supported then I can drop them into whatever container I like.

Actually, Jeff, my view hasn't changed. The SCA Java component model is about a lot more than IOC. (In fact, in the big picture of SCA, IOC is almost a detail.) Developers will surely care whether they build business logic on the latest version of EJB, on Spring, on the SCA Java component model, or on something else. It's always possible to port code, of course, but it's also something you want to avoid whenever possible.

The conflict among the various potential successors to J2EE 1.4 is very real, and it's a significant threat to the enterprise Java community.

Post a Comment

<< Home