# The Future of SCA

| by Stefan Tilkov 1 Followers on May 17, 2007. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

In a blog posting, David Chappell (the David Chappell from Chappell & Associates, not to be mistaken for the Sonic/Oracle David Chappell) has posted his impressions from a panel on the Service Component Architecture (SCA) he moderated at JavaOne. David highlights the fact that SCA is composed of two things, namely

[...] 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.

The relative value of SCA and JBI, the Java Business Integration, has been debated here on InfoQ before -- there is now an official statement as to their relation. In previous postings, Chappell has argued that SCA is a threat to Java EE. Both IBM and BEA, whose J2EE/Java EE investment is not being seriously questioned, are big SCA supporters -- but as David points out, this can mean different things:

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.

Google's Gregor Hohpe shared his impressions:

The programming model, much like Microsoft's WCF, provides a unified API for all kinds of distributed systems communication. In the Microsoft world this is a big deal, and rightly so. So it was a little surprising that the vendor support for SCA's programming model is at best luke warm. Even a lot of the "official" documents seem to downplay this aspect of the spec. Only IBM and BEA are really supporting both aspects while the others openly stated that the programming model is not their focus.

Hohpe also questions whether SCA really has something do with SOA:

When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor.

Indeed it seems that SCA addresses a topic different from the typical "high-level" SOA aspects. While that doesn't mean it's not a viable technology, it begs the question whether the common-place association with the standards around SOA is really applicable.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

OSGI?

How does SCA different from OSGI? Seems like very similar goals and it would be nice if the two groups would just join and produce a more stable spec/implementation. OSGI seems to have more implementations to date and they seem to be well implemented and tested.

Much to difficult for what it's worth...

I met a managing director for a Tanzanian bank that makes microfinance loans, often less than $100. The bank executive made a decision to buy a Java-based software package for$250,000 to handle server-side and client interfaces to the banking management functions. Unfortunately the bank spent another \$250,000 on a Java engineer to make the system output the reports they need and integrate with existing bank IT systems.

"Why does it cost so much to do integration?" the bank director asked me.

This is the cost of Sun, BEA, and IBM fighting among one-another over JBI and SCA. The fight keeps the costs high - and our salaries high - but does little to better the world. And that is a shame.

-Frank Cohen
www.pushtotest.com

A few quick of points

1. If you're interested in SCA and OSGi combination see:
2. There are a couple of SCA open source implementations out there. I've used Apache Tuscany and for the most found it a pleasant experience.
3. To Gregor's comment about SCA composites running in a single environment: I don't see this is as so much a limitation as it is a simplification. A more general "Composite" that spans environments essentially amounts creating a Service. Composites don't need to span environments so long as Services do. SCA maps to SOA in that it is a model for programming by contract across technology boundaries. The question arises as to whether it should define more than that.

Re: Much to difficult for what it's worth...

I think your criticism is misplaced. Any fight between JBI and SCA is a misrepresentation. They are solving different problems. Indeed both can bring high quality backend systems within the reach of SMEs like the bank in your example by encouraging commoditisation of Java containers and frameworks. A valid point would be that it still requires a high level of competency to perform the actual integration itself.

I suspect the cost came from hiring consultants who advised them on a monolithic system (he says guessing).

Kit

Re: Much to difficult for what it's worth...

Kit, do you know of a JBI binding component or service engine that works in more than one JBI container?

Re: Much to difficult for what it's worth...

Well, these people do advertise as having tested with OpenESB and ServiceMix: www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=COR... .
I know what you're getting at, but wouldn't you agree that having an evolving standard is better than having no standard at all?
But this misses my point, that "JBI vs SCA" is a travesty and is not the reason why integration is expensive, but that in fact both should make it cheaper (in the long run)
Regards
Kit
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Login to InfoQ to interact with what matters most to you.