Apache Tuscany is a project which combines various technologies including an implementation of the OASIS OpenCSA "Service Component Architecture (SCA)" standard to simplify the development, deployment and management of distributed applications built as compositions of service components. Apache Tuscany has been incubating for over two years at Apache. Graduating to a top level Apache project is a significant milestone and further endorsement of the already successful project. After a bit of a slow start SCA now looks like it has a bright future. There is growing recognition of the utility of SCA and most vendors in the SOA space are planning to introduce support for it in their products. Sun remains one of the few unconvinced but even there there is now a burgeoning user driven effort trying to change that. Can you afford not to know about SCA? Apache Tuscany is now the premier open source implementation, come check it out!

SCA sounds like OSGI. What's the difference?

Try looking at Newton, it combines SCA, OSGi and Jini. My combining the three, perhaps it will become clearer where each serves its purpose... :))

SCA sounds like OSGI. What's the difference?

They each address different areas. SCA is about assembling applications out of components with the component interaction QOS policies and communication protocols defined declaratively. OSGi is about running services and managing their versions and dependencies. So they are complementary, with SCA being at a higher level. You can use OSGi within SCA, and OSGi could be used to build an SCA environment. OSOA has a whitepaper, Power Combination: SCA, OSGi and Spring, which describes this in more depth.

OSOA has a whitepaper, Power Combination: SCA, OSGi and Spring, which describes this in more depth.

Thanks. I hope I will not be forced to go into these "simple", "leightweight" technologies.

Thanks. I hope I will not be forced to go into these "simple", "leightweight" technologies.

Right. If a technology claims "lightweight" as its most important trait, be dubious. Very dubious. You can't walk around complexity by imagining it doesn't exist.

Lightweight is often an euphemism for 'unfinished', isn't it?

Thanks. I hope I will not be forced to go into these "simple", "leightweight" technologies.

Right. If a technology claims "lightweight" as its most important trait, be dubious. Very dubious.

You can't walk around complexity by imagining it doesn't exist.

There was no reference to "lightweight" in this post about Tuscany so whats with all these comments? Of all the qualities and attributes of Tuscany and SCA the weightiness is not one of the major features.

Thanks. I hope I will not be forced to go into these "simple", "leightweight" technologies.

There was no reference to "lightweight" in this post about Tuscany so whats with all these comments? Of all the qualities and attributes of Tuscany and SCA the weightiness is not one of the major features.

I think it started when somebody mentioned the whitepaper about SCA/OSGI/Spring. Spring is often described by its fans as "lightweight", though some of us might disagree.

Well, maybe it came from the website which describes Tuscany as being a, "lightweight runtime...designed to be embedded in, or provisioned to, a number of different host environments without much effort" (http://incubator.apache.org/tuscany/sca-java.html)? I took the trouble to download Tuscany and discovered it was over 60MB with 150+ third-party dependencies. Based on this, the criticisms seem fair. Tuscany is hardly lightweight. Another thing is the post sounds as if it came out of some jargon-mill: "...simplify the development, deployment and management of distributed applications built as compositions of service components." You guys would be better served describing what Tuscany does in plain terms.

What's more, SCA even has a Dependency Injection mechanism of its own! Like having all those other DI systems was not enough! To count a few of them: spring, seam, webbeans, jsf managed beans, OSGI service lookup stuff, ..., and now SCA's DI stuff. Soon we'll see apps with potentially 3 or 4 different but similar ways of DI in them! Nice! Ara.

Fair points about the descriptions of SCA/Tuscany being more than a bit vague. It slices, it dices, it makes your teeth whiter, it makes your lawn grow in thicker and women love a man who's got Tuscany. Probably the best way to think of it is as a service composition tool. It goes beyond orchestration/workflow (though it addresses that too). Imagine you've got six different components you want to stitch together to build a composite application -- stuff like a price calculator, inventory, payment processor, customer history, etc. Somebody previously had to code those components and tackle the complexity. Maybe someone has to go in an build another component or two for the new composite app to get up and running. What Tuscany does is give you a framework to put all of that together and let each component run wherever it runs. Provided you've built components with the right granularity (in this case large), it should be easy enough to swap out components or change the app on the fly. Here's the summary I wrote on the JavaOne Tuscany presentation. What complexity it eliminates is mostly on the integration side. A little Atompub and A is talking to B in a jiffy. It aims to simplify the middle. Technically a non-developer could take care of the Tuscany composition, leaving your developers to tackle complexity within the individual components. Ideally it will mean less busywork for developers. I make no representations that it will all work as advertised. Almost nothing does. I imagine some effort will be required in making sure a component is Tuscany-consumable.

There seems to be a lot of confusion about the "Service Component Architecture. Rather than point to the somewhat cryptic specifications, here's some useful commentary: "SCA and the Future of Development." Bill Roth Blog " SCA: Service Component Architecture." Jim Marino Blog "Development Model for Services." Eric Newcomer Blog "SAP Joins Group To Push for SOA Standards." By Robert Westervelt "Building SOA solutions with the Service Component Architecture." By Roland Barcia and Jeff Brent

I agree. In terms of reading, I would also add the following: - Meeraj Kunnumpurath's blog entry at: http://weblogs.java.net/blog/meeraj/archive/2008/01/introducing_ser.html - The best intro on SCA I've read is David Chappell, "Introducing SCA" (http://www.davidchappell.com/articles/Introducing_SCA.pdf). Note David is not the David Chappell of JMS/ESB fame. The thing I like about David is he is an independent voice and has the ability to cut through to the core concepts. Jim