Service Component Architecture (SCA) so far has largely gone unnoticed by developers of enterprise applications, even though there are already several SCA implementations on the market. Additionally, open-source SCA implementation from Apache called Tuscany is gaining momentum.
I suspect that most developers think of SCA as yet another “enterprisey” SOA-related standard along the lines of the mostly obscure WS-* specifications. The fact that SCA is being developed by a vendor consortium as opposed to a grass-root open source effort does not add to its popularity either.
However, SOA and Web services are not the main focus of SCA. SCA is a generic component/application framework that is totally separate from Web services. SCA allows defining component interfaces and implementations in Java (although WSDL interfaces are supported as well). I would actually speculate that Java interfaces are going to be used in the majority of cases (at least, for Java applications) and WSDL will be left to special circumstances.
SCA also supports remoting by allowing to expose component interfaces using Web services or other technologies, such as JMS (using so-called “bindings”). But this capability is secondary to the SCA assembly model that explains how components are defined and composed.
The bottom line is that it is perfectly valid to use SCA without ever creating a single Web service.
Moreover, SCA directly competes with Spring and other application and IOC frameworks. SCA’s component is very similar to Spring’s bean. SCA components can have properties and references. References can be “wired” to other components. Similarly to Spring, references and properties translate into setters or constructors that are populated via injection mechanism. SCA 1.0 even supports component auto-wiring that matches auto-wiring Spring feature.
SCA does support Spring via Spring Component Implementation specification, which allows to define SCA components using beans defined in a Spring’s context file. However, for brand new SCA applications, there is really no need to use any other IOC container in addition to SCA itself (in fact, I would argue that using multiple component/IOC frameworks in the same application may make the application architecture really confusing). Of course, Spring does much more than just providing IOC functions (e.g., AOP, integration with persistence frameworks, MVC support) and so these other Spring capabilities could provide sufficient rationale for deciding to use Spring in conjunction with SCA. But given that SCA will be integrated with many commercial products (IBM has already started down that path with adding SCA to the WebSphere application server) including development tools support, I can see how SCA could become a very substantial alternative to Spring.
SCA also directly competes with Java EE. This can be illustrated by the following diagram which is part of the documentation provided with WebSphere SOA Feature Pack:
Indeed, SCA bindings insulate developers from specific communication protocols and mechanism so they don’t have to deal directly with Web services and JMS. On the Web services side, it is not entirely clear to me at this point how SCA is going to be able to support all the capabilities currently provided by JAX-WS, such as “bare” and “wrapped” styles, JAXB serialization and others but I guess it could be possible in theory.
SCA policy framework allows to declaratively specify various policies for SCA components. Currently the policies mostly focus on reliable messaging and security. In theory, they could also include defining transaction boundaries similar to EJB’s transaction attributes.
Another common misconception about SCA is that it must to be used together with Service Data Objects (SDO). This is not the case. While SCA recommends using SDOs, regular Java classes and simple types are supported as well.
SCA also has a number of unique benefits, the most prominent one being its support for different languages. There are SCA implementations for C++ and PHP; Apache Tuscany supports Ruby, Groovy and JSR 223 component implementations (what’s interesting, component interfaces still have to be defined in Java or WSDL).
Binging flexibility is another interesting SCA feature. Today we have to use completely different APIs and libraries for different ways of inter-system communication, e.g., JAX-WS has very little in common with XML over JMS. SCA supports a uniformed declarative binding abstraction so that developers don’t have to be concerned with the intricacies of the specific communication type. New protocols and data formats can be added. For example Tuscany is going to support JSON as one of the bindings. One can imagine that REST or even COBOL Copybook format can be added in the future.
I’m somewhat concerned that SCA binding is actually a combination of a data format and a transport protocol. So, for example, JMS binding translates into XML transported using JMS text message with certain headers. So it is not clear to me if JMS binding can support other data formats (e.g., positional string) over JMS. Perhaps this is something that can be clarified in the future versions of the spec.
So is SCA going to win over hearts and minds of developers and become the de-facto standard for enterprise applications (and not just the ones with heavy Web services aspect)? That remains to be seen. I’ll be watching closely how it evolves, especially the Tuscany project which at this point is still in the incubation stage.
Alexander,
Nice article – as one of the perpetrators of SCA, I’m glad that you’ve recognized its potential!
There are a few comments I’d like to follow up on.
“SOA and Web services are not the main focus of SCA” – well, it was certainly the intention that SOA is the main focus of SCA – it’s designed as a way of building solutions using an SOA. I agree that Web services is not such a focus – SCA is designed to “sit above” Web services and mask much of their complexity. However, you are right in pointing out that it is perfectly possible to build an SCA solution without ever using Web services – using for example messaging via JMS, as you correctly identify in your article. Many companies have already built solutions of that kind already.
“SCA directly competes with Spring..” – well, in a word, – no. SCA is designed to fit with IOC frameworks like Spring – they match each other very nicely. Indeed, you can envisage building a very neat SCA Java implementation using the Spring IOC container as its core, with SCA metadata being used to describe and handle remote services and remote connections. Certainly, Spring can be a great implementation type for SCA in a heterogeneous solution, say using BPEL as you describe. I’m giving a talk about just this at JavaOne this week. SCA and Spring share a common philosophy of keeping complex details out of the business code in Java implementations.
SCA has its own simple Java POJO implementation type for cases where other frameworks are not available (an example might be a small device, where space and function are limited). I agree with you that I would not envisage using both an SCA POJO container and a Spring container in one solution – but Spring has useful capabilities that assist in building a service implementation (eg Persistence integration).
“Spring also directly completes with Java EE” – well, not really. Java EE can again be one component type in a larger SCA application. EJB 3.0 beans support the SCA philosophy of keeping middleware APIs out of business code, so they are a good match – but SCA can integrate with EJB 2.1 session beans too.
“On the Web services side it is not entirely clear how SCA is going to be able to support all the capabilities provided by JAX-WS”. This is definitely a case of “yes” and “no”. “Yes”, SCA will be able to support all the varieties of underlying SOAP messaging like bare and wrapped, through configuration parameters on the Web services SCA bindings. “No” in that JAX-WS makes detailed and complex information available through its API, like headers and other stuff that SCA regards as “plumbing” that is best kept out of application code (SCA would deal with such stuff more through binding extensions….)
You hit the nail on the head when you say that SCA is not tied to Service Data Objects (SDO). SDOs are a great way of handling data, but if you want to use other data handling frameworks like JAX-B, you can help yourself. Of course, SDO has some advantages, such as treating XML data and relational data in a uniform way, or providing a disconnected data model allowing for retrieval and subsequent update…. (but I wont bore you with all that !).
“Component Interfaces still have to be defined in Java or WSDL” – this is really not true at all. SCA can in principle support any interface definition language that you choose. The current SCA C++ specification makes this clear – you you a form of C++ header files to define an interface in C++. What SCA DOES say is that any “remotable” interface (ie one that might be accessed over a network and may be accessed by a component written in a language technology different from the provider), that must be TRANSLATABLE into WSDL – ie WSDL forms a “meeting point” for different languages and runtimes. So in the case of C++, for example, there is a WSDLC++ mapping defined, just as there is for WSDL Java. Whether folks will define interfaces for PHP, Ruby, etc, remains to be seen, but the principle of being able to map to WSDL is important….
You question if SCA bindings are capable of handling different data formats when transmitting data over specific transports – and the answer is “yes”. This is called a “data binding” and it basically says how the parameters of the service operation get mapped by bytes on the wire. As you rightly identify, there are many possibilities when using JMS over some messaging platform (SOAP over JMS being just one example…..). The data bindings are a piece of work that the Bindings group are still working on, but Tuscany already has some implementations of these…
Thanks for your interest and yes, Tuscany is well worth watching, along with OASIS, where the SCA specifications have now moved for formal standardization.
Yours, Mike Edwards
Chair of SCA Assembly working group, Open SOA collaboration.
http://www.osoa.org
Mike,
Thank you for your detailed comments and also for clarifications. I can certainly see how SCA can complement Spring and EJB3 solutions as opposed to being an alternative to these technologies. However, taking by its face value, SCA is a component framework/programming model and so are Spring and EJB3. If I understand you correctly, you’re saying that Spring and EJB3 could be used as the underlying mechanism for implementing the SCA spec or at least some of its aspects. But as long as we only use SCA for defining our components, as opposed to Spring context files or EJB3 annotations, this underlying mechanism really becomes irrelevant. If as a developer I can implement my entire application using SCA component descriptors/annotations and appropriate policies, why would I need to go to a lower level and deal with the intricacies of EJB3 (assuming that all EJB annotations/attributes can be expressed as SCA policies)? Additionally, adopting a single component model can be extremely advantageous at the enterprise level as not all components could be/should be expressed as services and so there’s still going to be a need to share components by physically consuming their code in different applications.
So I still think that in developers minds SCA will be seen more as an alternative to other component models/application frameworks as opposed to a nice complementary abstraction layer.
Best regards,
Alexander
When we consider the portability and agility, develop components based on IOC framework like Spring, which does not rely on “container” and provide a wrapper layer for a specific “container”. For example, I develop a component based on Spring, if I need to make it run on SCA, I add a wrapper class or may simply take advantage of Spring binding of SCA. If I need to make it run on JBI, I do the same. If I use SCA with Spring, The SCA is used for for easier web service setup. (I’m not so sure how much it make easier, though).
Thanks for your personal marvelous posting! I truly enjoyed reading it, you happen to be a great author.I will always bookmark your blog and will often come back from now on. I want to encourage you to continue your great job, have a nice afternoon!