Category Archives: SCA

SCA and JBI Mean Nothing for SOA?

There is an interesting and somewhat controversial interview with ZapThink’s Jason Bloomberg where he claims that SCA and JBI are just going to “muddy the waters” as opposed to provide real help to SOA architects.

I certainly agree with his assessment that SCA (can’t really speak about JBI) is more of a generic component-centric programming model than a SOA implementation framework. I blogged about it before. However, I do think that SCA is going to provide a lot of value in the area of application architecture and just general component reuse. A technology or a framework does not have to be about SOA to be useful.

Is SCA New Java EE?

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.

First Impressions from Service Component Architecture

I’m currently playing with

Service Component Architecture (SCA)
,
currently supported in IBM products,
such as WebSphere Process Server and WebSphere Integration Developer (WID).

IBM implementation “wraps” all SCA standard
classes and namespaces using IBM proprietary classes and namespaces.
As a result, XML tags and class names don’t match
what’s in the spec. I suspect that the
reason for that was that the products were developed when the specification was
still in flux so hopefully it will change in future versions.

Looking at SCA, one immediately gets a deja vu feeling since SCA
resembles a lot an approach used in Spring and other IOC containers.
Similar to Spring, an SCA component definition file can contain references to other
components and configuration properties. However, SCA lacks some sophistication
of Spring, for example, there is no “auto-wiring” of references and so each reference has
to be wired explicitly in the component definition file. On the other hand, SCA is supposed to
be a cross-language framework (with even some talks of PHP being supported in the future).

On the bright side, SCA is simple and easy to understand.
Editing component definition files by hands is a snap and these file formats are pretty
intuitive (which is quite an achievement for an SOA-related spec).
This is certainly an advantage over similar-in-purpose JBI which comes across as a
much heavier framework with
lifecycle methods and prescribed container interactions a la EJB 2.0.
In SCA you only deal
with components and modules and so the small number of key concepts certainly
makes it easy to grasp.

Even though SCA is related to service integration and SOA, it does not force WSDL
down developers throats; regular Java interfaces are also supported.
Unfortunately, Java interfaces look like second-class citizens in WID
since the the IDE generates WSDL by default (although I was able
to create Java interfaces manually). Also, Java inteface-based components
can’t be referenced firectly from BPEL-based components (I guess,
because references have to match partner links in BPEL and those partner
links are WSDL-based). My personal preference would be to use Java intefaces
whenever possible since they are easier to deal with and easy to enforce
using regular language constructs.

SCA components could be implemented using POJOs.
There are no magic methods and a component implementation class does not need to inherit
from anything or implement any interface (except
for its own Java interface, if it has one).
As per the spec, annotations are also supported, although
it does not look like this support is in
IBM products at this point (they are still on JDK 1.4).

I was hoping that reliance on POJOs will provide for a nice test-driven development
experience. However, at this point, I’m still trying to figure out
a way for binding and invoking
a component from a Junit test outside of a container.
I can test a component’s implementation
directly (I construct SDO objects in my test classes and
pass them to implementation classes)
but I would like to be able to use proper SCA APIs and look up the
component dynamically so I can test against its interface.
Testing framework (which generates Junit test classes) that comes with WID for some reason
was giving me some problems and, in any case, I prefer to write my test classes by hand.

So to sum up, other than implementation-related glitches,
SCA looks like a nice generic component framework.