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.

6 thoughts on “First Impressions from Service Component Architecture

  1. I have also started working with SCA and have the same goals you have for TDD to test SCA components and interfaces outside the container. I was wondering, have you made any progress on this?

  2. Alexander:
    I’m using IBM WID 6.0.1.2. The IBM article referenced in http://www.osoa.org/display/Main/SCA+Resources demonstrates some good techniques to externalize input data and expected results using the com.ibm.websphere.bo.BOXMLSerializer.

    http://www-128.ibm.com/developerworks/websphere/techjournal//0608_artus/0608_artus.html
    http://www-128.ibm.com/developerworks/websphere/techjournal/0609_artus/0609_artus.html

    We’ve also prototyped copying POJOSDO using reflection. From there one could use Spring to inject test data.

    I’m currently looking at wiring mock objects in WID to simulate external services. I’ll keep you posted on my progress.

  3. PJ Murray:
    Yes, SCA and SDO are kind of bundled together, and with IBM products you cannot use SCA without SCO. Can’t say that I’m over ecstatic with it; SDO’s dynamic typing and “kinda XML but not exactly” API IMO leaves a lot to be desired.

  4. If i cannot use SCA without the aid of SCO, why would i go for IBM? Could it be for the brand? or reputation? or simply because IBM really rocks…

Comments are closed.