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.