The Problem with SCA

David Chappell recently published his Introducing SCA whitepaper, and it is a very good introduction to SCA. I recommend it to anyone interesting in getting a handle on SCA.

In his summary of the effort in his blog he notes the major difficulty he encountered: SCA participants seem to have different opinions about what’s important about SCA.

David has blogged about this before, based on his experience charing an SCA panel at Java One. He has also argued (and continues to take this view) that the new Java programming model is what’s important.

My view is that the service assembly model is the most important thing, and I guess it’s fair to say that IONA as an SCA vendor will emphasize that view as we incorporate SCA into our SOA infrastructure product line.

I don’t think the world needs another Java programming model, and although I understand the comparison David makes with WCF, I don’t think it makes as much sense for the Java world. In fact the Java world appears fragmented enough already.

I was at Tech Ed ’03 when WCF was announced, and I remember clearly hearing the objections to some of the developers in attendance when they discovered that Microsoft was asking them to change how they developed their Web services. And I also agree WCF is a nice piece of work, and has a great architecture (very similar to IONA’s architecture BTW).

Our view, and we did express this during the SCA meetings (and we were not alone), was that the metadata should be incorporated into the assembly spec as much as possible, and the metadata remaining in the Java annotations should be minimized.

I suppose it is not surprising that the committee work ended up placing more or less equal emphasis on both the assembly model and on the Java programming model, since the participants in the meetings also represented the division of opinion David encountered at his Java One panel. But this division of opinion continues to be a problem for SCA.

Advertisements

10 responses to “The Problem with SCA

  1. David Chappell

    Thanks for the kind words about the paper, Eric. Just to be clear, however, my view is that SCA’s assembly model is important, too; I just think its Java SCA component model is more important. As I’ve argued before, the unification of diverse APIs in this new component model addresses the biggest problem in enterprise Java today: complexity.
    Defining how components should be assembled into applications is certainly a useful thing, and this part of SCA seems likely to get broad support. Still, just as the complaining Windows developers you mention came to understand why WCF was a good thing, enterprise Java developers should understand the value of a unified programming model for service-oriented applications.

  2. Well, I should also clarify my position a bit, too.
    As the leaders of the SOA Tools Platform project at Eclipse, we will be supporting the SCA Java programming model as one of the options for creating services.
    But we tend to view the assembly spec as more important to the project. In fact the reason we joined SCA in the first place was because of our interest in using the SCA assembly metadata to bridge between an SOA design and an SOA deployment.
    The Java programming model is related to another big discussion in the industry: whether the top-down or bottom-up approach is better for developing services.
    We tend to think of SOA as an abstraction capable of tying together heterogeneous technologies into a common design, and in that context creating the SOA design seems like the highest priority, and mapping the design to technology a next step. In that context Java is one of potentially many technologies involved in an implementation of an SOA design, and the programming model for creating services somewhat less important in the overall scheme of things.
    One difference between the Microsoft world and the Java world is that there are already ways to create services – some more complex than others, granted – but one of the things I’ve always said about the SCA Java programming approach was the danger of exchanging one complexity for another. I am not sure the SCA programming model significantly reduces complexity compared to things like JAX-WS or Spring..

  3. The problem with SCA is the “C”. Components aren’t services and can’t be transformed into them with a protocol swaddling cloth. We don’t need Yet Another Way to think about exposing COM interfaces as web services. It is the wrong question–even though the answer has some very clever facets.
    What people need to do with legacy components is re-analyze them into resource-oriented service semantics. The protocol adaptation work is conceptually trivial by comparison.

  4. This is a very strange comment, as it references COM (which has nothing to do with SCA) and the poster’s name links to a music site – a commercial one I’d say.
    I get a lot of blog spam that tries to convince me to approve the comments, but the content is usually far off the mark. Stuff like “great site!’ or “Thanks for the info!” One recently said “Great insight, and I’ve posted a similar entry xxx” which turned out not to be the case.
    Here Frank at least references how components are not services (although they can expose a service, like any other software artifact) and recommends instead what sounds like a REST based approach, but without naming it.

  5. IMO, there is only the top-down approach (contract first) to build SOA based applications. The WSDL is designed from a business point of view and is not driven by a service consumer or an existing application. The “WSDL to Java” tool generates java code according to JAX-RPC or JAX-WS. These classes can then adapt the existing business logic.
    The bottom up approach does generate web services which design is driven from an application point of view (developer driven) and will not address the need for other consumers.
    JAX-WS is based on annotations which allow to add transport and binding information to your java classes. I don’t like this approach at all because it supports the bottom-up approach and couples programming and configuration. .NET does support this approach based on attributes as well for years (.NET framework 1.0). At that time, IT wanted to web service enable existing business logic very fast. The quality and reusability of the web services were not the main goal. Today, the quality of a SOA relies on the quality of the web service definitions. You don’t get this quality if you follow the bottom-up approach and JAX-WS does support the bottom-up approach additionally. Therefore, I’m not confident that JAX-WS goes into the right direction.
    I’m very confident in SCA because metadata are part of the assembly and not the annotations in the java class.

  6. Agreed, “the service assembly model is the most important thing(about SCA)”, and the more I read about SCA, the more I tend to agree with this view and see the pattern holding true.
    There is not so much talk of SCA as Java’s component model, as there is to SCA playing out a role in the service assembly approach. In this area, I have seen one particular open source project named Newton which aims at using SCA’s model for the assembly of composites, while leveraging OSGi for local wiring and Jini for distributed interaction. Also on the subject a whitepaper on combining SCA, Spring and OSGi [PDF] .
    Granted, both examples tie SCA in some degree to OSGi — which actually brings another interesting relation to SCA and Java — since most Java vendors are integrating OSGi into their Java server-side stack. So I would say its more Java following the service assembly model thanks to OSGi and bringing SCA along with it.

  7. Eric,
    I’ve not looked at SCA since a fairly early version of their documents, which were written in such atrocious English that I have not been back to see what has become of it since.
    I found those documents at http://www.ibm.com/developerworks/library/specification/ws-sca/
    It was very clear that their primary rationale was to service-enable legacy COM components.
    In order to achieve that goal in a fashionably abstract manner, they invented a new kind of abstraction (from invocation convention) that is at least intriguing in principle but, as I said, I doubt its usefulness in practice because making *real* services out of legacy components would typically involve refactoring far above any technological level.
    BTW my personal web site is not commercial.
    Thanks,
    FW
    .

  8. Frank,
    Thanks very much for the clarification. I get so much blog spam sometimes it’s hard to be sure. Glad yours was not! Happy to have your post.
    Eric

  9. Daniel,
    Yes, I am actually very familiar with Newton and the SCA whitepaper about OSGi, Spring, and OSGi. All good stuff, and all sources of input to the OSGi EEG (which I’ve posted about a few times already).
    But I would not say that OSGi had directly influenced SCA. In my experience working in both communities I’d say that the origins appear distinct, and the original goals divergent. SCA was all about service creation in the “large” sense – i.e. for distributed enterprise IT environments. OSGi was all about service creation in the “small” sense, i.e. nondistributed (singly JVM) embedded applications.
    It is very interesting that the two are converging, and we do have current activity within the OSGi and SCA groups to develop SCA mappings to OSGi. The interesting part now will be identifying the respective roles for SCA and the native OSGi programming model within the same enterprise IT environment, aka OSGi deployment environment (since the various emterprise Java technologies seem to be converging on OSGi, at least for deployment/management aspects).
    Eric

  10. Oliver,
    I debated this point several times with other SCA collaborators. Many of them believe that Java developers needed a new approach for developing services, other than creating an EJB and generating a WSDL from it.
    I did suggest that SCA could be improved by focusing more on the top-down approach (ie. giving this priority over the bottom up approach) but this did not gain agreement.
    Personally, I think that the Java IDE vendors are caught, as Microsoft is, in a product requirements cycle based on the evolution of their current products. Developers using these IDE products are asking (I believe anyway) for help creating services, and for them that means within the context of their existing tools. So the attribute based approach to including metadata in objects probably comes from these vendors trying to meet those requirements. Just my opinion, but it seems to make sense in terms of how products evolve.
    But I completely agree this is a strange model – having to change objects to update metadata definitely seems backward.
    Eric

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s