BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Problem With SCA?

The Problem With SCA?

In his blog, Eric Newcomer comments on David Chappell's recent entry around SCA. In David's blog, he says:
Service Component Architecture (SCA) isn't an especially simple technology. It's also hard to figure out just by reading the specs.
Which is why he has written a nice Introduction to SCA whitepaper. However, as David has mentioned before it is sometimes difficult to get all of the SCA authors to agree on what is important in SCA. But in his view:
... 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.
David believes that the Java programming model does not get the attention it deserves, equating it's importance in SCA to what WCF did for .NET:
Just as Microsoft's Windows Communication Foundation (WCF) provides a unified approach to the problems addressed by .NET's Enterprise Services, .NET Remoting, and ASPX, the SCA programming model covers the great majority of the useful scenarios currently addressed by EJB, Java RMI, and JAX-WS. Business logic built on SCA's new programming model can still use JSPs, JPA and other aspects of Java EE 5--SCA doesn't replace all of the enterprise Java APIs.
Now Eric, as a representative of IONA one of the SCA authors (and leaders of the Eclipse SOA Tools Platform effort), disagrees. He believes that it is the service assembly model that is key and also thinks the WCF comparison is not necessarily a good one:
I was at Tech Ed '03 when WCF was announced, and I remember clearly hearing the objections to some of the developers in attendance when they discovered that Microsoft was asking them to change how they developed their Web services.
In comments to Eric's piece, David does clarify some of his statements:
... my view is that SCA's assembly model is important, too; I just think its Java SCA component model is more important. ... Defining how components should be assembled into applications is certainly a useful thing, and this part of SCA seems likely to get broad support. Still, just as the complaining Windows developers you mention came to understand why WCF was a good thing, enterprise Java developers should understand the value of a unified programming model for service-oriented applications.
But as Eric then points out:
One difference between the Microsoft world and the Java world is that there are already ways to create services - some more complex than others, granted - but one of the things I've always said about the SCA Java programming approach was the danger of exchanging one complexity for another. I am not sure the SCA programming model significantly reduces complexity compared to things like JAX-WS or Spring..
So the question remains: what is the most important aspect of SCA? Maybe this will remain a vendor-specific answer. But if that is the case, what will this do for the perceived over complexity around SCA?

Rate this Article

Adoption
Style

BT