The Service Component Architecture (SCA) is a specification that was announced on November 30, 2005, with the support of IBM, BEA, Oracle, SAP, Iona, Sybase, and other software vendors. SCA is often described in conjunction with the specification for Service Data Objects (SDO). For example, the Oracle press release states:
The SOA Programming Model specifications include the Service Component Architecture (SCA) to simplify the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats.
Tuscany is an implementation of the SCA specification, currently in the Apache Software Foundation incubator. In fact, there are currently two Tuscany implementations - one based on Tomcat for assembly of Java applications, and one based on C++. Others are expected to follow. The idea is to use a common application assembly model (SCA) in all implementations.
The purpose of the SCA spec and the Tuscany implementation is to address a key problem of application development in a world of service-oriented architectures and composite applications. As Bill Roth of BEA states in his blog:
The goal of SCA is the same as BEA's goal: Make things (building apps, in this case) easier. SCA allows the development of application assemblies without regard to specific middleware APIs or language.
Similarly, he concludes:
SCA matters, because this is the first technology that promises a compositional model that will enable the Service Network and allow the building of the next generation of service-oriented applications.... To put it simply, SCA is the future of building THE large scale enterprise composite application.
Looking closely at Tuscany and SCA, we see that they provide an alternative to EJB-based programming models, which can constrain the development of composite applications in a service-oriented world. So the spec and implementation give us a good POJO-based programming model for developing composite applications. Increasingly with Spring and SCA (and to some extent with EJB 3 as well) there is a move to hide middleware and to use simple POJOs for business logic. SCA follows this by introducing a small API and a collection of annotations for adding various things to POJOs such as:
- lifecycle annotations (@Init, @Destroy)
- dependency injection annotations (@Property, @Reference, @ComponentName)
- messaging annotations (@AllowsPassByReference, @OneWay, @EndSession, @Scope, @Remote etc)
- SCA specific injections (@ComponentMetaData, @SessionID, @ComponentContext)
Nevertheless, despite their usefulness, SCA and Tuscany focus on the developer's view of the world.
With any new specification, it's natural to imagine that it is designed to compete against, or improve upon a current standard, so it is not surprising that some people ask whether SCA makes the Java Business Integration (JBI) specification unnecessary, since both SCA and JBI are designed to simplify SOA. However, while SCA makes life easier for the composite application developer, JBI is designed with middleware developers and integration component authors in mind.
While SCA and Tuscany simplify the assembly of components of composite applications, JBI and ServiceMix (our favorite JBI implementation) provide an API for integration components to work together in a standard way. You can think of JBI a little like JMS for integration components, which specifies how all the standard message exchange patterns from WSDL can be nicely handled, along with any kind of messaging technology (JMS, HTTP, FTP, files, RMI, Jabber, CORBA etc).
In short, SCA and Tuscany address an important, but different problem from JBI and ServiceMix. The two models not only serve different purposes, but we believe that they are actually compatible, and that an SOA may require both in the near future. In other words, we must provide both application assemblers and integration architects with the best tools for their respective needs, and we must do so within the same ecosystem. The two can work hand in hand. The nice thing about SCA is it supports pluggable middleware, so JBI is an ideal back end for SCA.
A discussion of how we intend to do this within ServiceMix is coming soon.