By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The vision for the Service Component Architecture (SCA) specification, a notion that originated with IBM and BEA Systems, was of a programming standard for service-oriented architecture (SOA), according to Michael Rowley, who has been involved with the spec almost since its inception. Rowley, CTO at Active Endpoints and former director of technology at BEA, is also co-author of the recently released book, Understanding SCA (Addison-Wesley, 2010).
"It's meant to be a standard for SOA," Rowley said. "The standards SOA is based on now are primarily around the protocol standards. This is a programming standard for SOA."
SCA as a vision has been around for about five years, said Steve Kinder, an Architectect for IBM WebSphere/SOA Foundation. "It's been a journey," said Kinder, who was at the initial IBM/BEA meeting. At that meeting representatives discussed how to take IBM's ideas around SCA and create an open specification.
Later Oracle, Tibco, SAP and others joined the effort, and the Open SOA (OSOA) Collaborative was launched to work on version 1.0 of the SCA specification. In March 2007, OSOA turned over the SCA work to the OASIS Open Composite Services Architecture (Open CSA) group, which promotes the development and adoption of both SCA and the Service Data Objects (SDO) specifications. Today, version 1.1 of SCA is in public review.
Kinder explained how the vision behind SCA addressed three specific areas. The first is connectivity between services. "There were too many different ways to connect services" said Kinder. "They all looked different, and there was no real way to see your application as set of services and visualize that application. I view [SCA] as trying to leverage a circuit board paradigm for building services, so you build 'chips' and wire them together and expose them as reusable chunks for the enterprise."
Kinder said the second focus of SCA is to remove middleware concerns from programmers. "Since the days of CICS we've been trying to get programmers out of doing middleware-type things. The nice thing about SCA is I can access services and I can expose my services without having to bother in my code about how that connectivity was made and the specific protocols."
The third benefit, Kinder said, "is around the notion of SOA and a SOA programming model, being able to visualize and see those services in your enterprise at a coarse-grained level."
Language-independance sought after for SCA, but difficult to achieve
SCA is intended to be multilingual. "If you create an application using SCA you should be able to take it to any SCA runtime and have it work," Rowley said. "That's the key value of standardizing." But Rowley acknowledges, however, that the primary focus thus far has been on Java and BPEL.
"SCA was intended to be language-independent, but in practice it's primarily Java-centric, with a little PHP and a little C++, but really it's a way for the big Java vendors to implement certain SOA principles in the context of a Java environment," said Jason Bloomberg, industry analyst and managing partner of ZapThink LLC. If you're focusing on the software part of the SOA story, and you have an Oracle or an IBM Java environment and you want to leverage services in this context, then SCA is a standards-based, practical approach for leveraging services in a Java environment."
Currently, SCA is not supported by Microsoft. "There isn't currently a model for C# or a variant of a .NET language," said Rowley. He added, though, that SCA is prepared to add Microsoft to the mix. "When we went to public review in SCA we got some very thoughtful comments from Microsoft. It was created so [Microsoft] could easily be brought into the fold of SCA. Nothing in it would prevent a .NET-based environment."
Kinder said Microsoft has been invited to participate. "We could build a C# implementation for SCA, but my understanding is that if we can't get Microsoft to add it to their development environment it will have low traction."
SCA compatibility with OSGi highlights open source strengths
Another component framework is OSGi. OSGi is a standard for components that specifies how components are installed and managed. Both Rowley and Kinder said it is complementary to SCA. "You can use OSGi as way of implementing a new service in SCA," Rowley said. "They line up well." OSGi is overseen by the OSGi Alliance, which includes IBM and Oracle.
Kinder pointed to the Apache Tuscany project, which is an open source infrastructure for SOA development and management that is based on SCA, as an example of where SCA and OSGi can overlap. Tuscany, he said, has built out support for using OSGI bundles.
The interplay of SCA and OSGi has caught the attention of IBM. "IBM is extremely interested in the intersection of SCA as composition model for OSGi applications, using SCA to wire to other JVMs," Kinder said. "The coarse-grained SOA enterprise services are wired with SCA, and you can use Java, OSGi, and EJBs as a program model to wire from SCA. I think it's very complementary. To SCA, OSGi just looks like another way to build an implementation of services."
Rowley said SCA can also be used with Spring, a layered Java/J2EE application platform that includes a lightweight container for centralized, automated configuration and wiring of application objects. "We have a spec for how to use Spring applications as services in a SCA runtime," Rowley said. "There are a dozen different specs in SCA, a few related around the things Spring cares about, like hooking up Java objects in a more sanguine way. The bigger aspect of SCA allows for multiple technologies for implementing services; so you can use the built-in way of handling Java or Spring's way of handling Java."
Bloomberg said there is some overlap with SCA and Spring, but that it is limited. "I see it as different tools for different jobs. SCA is a way of creating composite applications based on modular software components that incur SOA best practices; Spring is a more declarative application environment."
Open source availability leads to commercial support
Now with SCA in the open source community, Kinder said it is starting to catch on. He said IBM customers have been leveraging SCA, the precursor to the open standard, for a number of years, with thousands of customers in production. He said IBM's BPM stack is built on SCA, as well as the ESB, fabric and process server. And WebSphere Application Server V7 has a feature pack for SCA.
Oracle's SOA Suite 11g, which is part of the Fusion middleware stack, includes a native SCA-based platform and designer. Active Endpoint's development environment is also built around SCA, Rowley said.
Bloomberg said he does see SCA being adopted in the IBM/Oracle worlds. "If you have existing middleware from existing Java vendors then SCA plays a role. For other organizations taking a vendor independent approach without a middleware-centric [infrastructure], SCA will have less of a role."
In the end, Kinder said SCA is a way to make businesses more agile, with the ability to adapt to change more easily. "SCA is about trying to make changing the incidental things about an application much easier and more flexible," said Kinder. "People can beat us up on the execution [of SCA], but I think we did pretty well. The idea [behind SCA] can't be wrong—the need to change and visualize your application."