David Chappell

Opinari

Get the Feed! Subscribe

Why Service Component Architecture Is Big News  
# Sunday, April 02, 2006
 
In an industry where new technologies are usually over-hyped, there’s one that’s not getting nearly enough attention. Service Component Architecture (SCA), currently described in a group of preliminary specs created by IBM, BEA, Oracle, SAP, IONA, and Sybase, generated a few news articles and blog posts when it was announced late last year. Since then, it’s largely slipped from view.

Yet I’d argue that the magnitude of what’s happening with SCA is analogous to Microsoft’s announcement of the .NET Framework back in 2000. If the vendors behind this effort can make good on their promises—and there are good reasons to think they can—a major part of the development world will be shifting to a new platform. This is big news.

SCA attempts to do several things. First, it replaces large parts of J2EE. SCA still relies on some J2EE technologies, such as JavaServer Pages, but its creators seem intent on moving away from EJB and other parts of this complex technology environment. The SCA specs make soothing noises about working with these older technologies, but SCA largely subsumes their functionality.

SCA also aims to eliminate Sun’s control over the primary non-Microsoft application platform. Given that both Sun’s stock price and its J2EE app server market share are in single digits, it makes no sense for it to retain control of this fundamentally important technology. By creating SCA outside of the Sun-controlled Java Community Process, the vendors behind this effort have made their intentions clear.

It’s also fair to view SCA as an attempt to provide a platform that’s technically competitive with Microsoft’s Windows Communication Foundation (WCF). I wrote a comparison of SCA and WCF shortly after SCA’s announcement, and the two have many similarities. WCF is significantly simpler than the .NET technologies it replaces, and it’s simpler still than the analogous J2EE technologies. Without a streamlined replacement for these J2EE technologies, which SCA tries to be, Microsoft’s competitors would be at a serious disadvantage.

SCA certainly faces hurdles to success, some of which I described in my SCA/WCF comparison. Still, for organizations moving to SOA—that is, for pretty much everybody—SCA is a big deal. Unless you’re an all-Microsoft shop, in which case your future will rely on WCF, your primary vendors have told you that they’re about to change the platform on which you build service-oriented applications. Since this style of development is becoming the default, the platform you use for it matters enormously. If you care about application development, pay attention to SCA. It really is big news.


15 comments :: Post a Comment

 


Comments:

Dave,

care to comment on how SCA compares to the (Sun-led) JBI SOA framework?

Are they competing, complementary, could they co-exist as Microsoft alternatives?

Thanks
 

I'd argue that the most important aspect of JBI is its lack of support by IBM and BEA. They're going their own way with SCA, which makes JBI much less important.

The big reason to care about JBI is its promised support by JBoss. JBoss seems firmly locked into the J2EE path, which suggests that an interesting split is coming: the traditional J2EE world lined up behind JBoss, with the major commerical vendors moving to SCA. It's unclear how current J2EE app server customers will respond to this, but the prospect of a divided competition must make Microsoft quite happy.
 

Dave,

Is SCA getting away from EJB really a good news ? The downside is that SCA relies on SDO, which IHMO is neither as simple or attractive than EJB3/JPA.

Rgds.
 

There's no objective answer to whether SCA/SDO is better than EJB3/JPA. It's also too early to know whether SCA getting away from EJB is good news for customers. It might be, since the J2EE world has gotten so complex, but it might make this complexity even worse by offering yet another choice. We do know, however, that if the major vendors choose to promote SCA over the J2EE technologies it subsumes, they can strongly push their customers in this direction. From the vendors' point of view, this is a good thing, as it gives them control of their technology destiny rather than leaving them at Sun's mercry.
 

A big advantage of SCA is that it also includes SDO, which is multi-language, multi-data format, and service-oriented (both loosely and tightly coupled, disconnected datagraph, etc). It is the only SOA data persistence specification. If you want standardized data services, SDO is the way to go (for IBM, BEA, Oracle, SAP, Sieble, etc).

The EJB 3.0/JPA data persistence API is Java-only and far too much based on ORM technologies, and focussed on just relational data. In fact, the EJB 3.0 specification group pretty much ignored the lesson learned by JDO (the Hibernate guys seems to dominate). EJB 3.0/JPA is doomed to be yet another failed EJB CMP specification (epecially in the context of SOA).

It's also interesting to see that other vendors that did not contribute to the SDO/SCA specifications, such as Rogue Wave (SCA) and CodeFutures (SDO), are now supporting them.

You're well ahead of the pack in spotting the importance of SCA/SDO. It will become more obvious once the major vendors start shipping products.
 

There has been a lot of consolidation with BPM vendors and there is bound to be some in the ESB space. How do you think these developments (SCA/SDO) will affect the current standing of ESBs and SOA vendor technologies?
 

There's no clear answer for ESBs, since there's no clear definition of what an ESB is. I think of ESBs as being primarily focused on moving messages between disparate systems, so given this view, SDO could make things somewhat simpler.

The impact on current vendor SOA technologies will be big, though. Half of the enterprise world builds apps on J2EE today, but SCA's creators have designed a new platform for supporting service-oriented applications that's not part of J2EE. Once SCA-based products are available, customers will choose between it and the parts of J2EE it replaces. With the exception of JBoss, the J2EE vendors with large market share are all backing SCA. The most likely outcome? Things are going to get messy.
 

Thanks Dave for two really good analyses of SCA. To clarify a few points made in posted comments:

- While SCA is intended to work well with SDO as a way to represent data, it does not require it (one could use another technology).

- SCA is also intended to integrate well with JPA.

- My colleague and fellow SCA spec author Mike Rowley has written a comparison between JBI and SCA at http://dev2dev.bea.com/blog/mrowley/archive/2005/08/jbi_doesnt_host.html. Ron Ten-Hove, the JBI spec lead also commented on it.

I'm interested in hearing more about your thoughts on SCA.

Jim Marino
BEA Systems
 

Thanks for the clarifications, Jim. I was never able to make myself care much about JBI, since when IBM and BEA aren't behind something in the Java world, it's unlikely to matter. Given that it's challenging just to explain what JBI is, I'm even more skeptical about its likely importance.

SCA is backed by the big vendors in the non-Microsoft world, and the core of what it does is easy to understand (at least to people who are familiar with Microsoft's WCF). As long as its creators don't make big mistakes here in the spec's end game, it certainly looks like we're seeing the birth of an important new technology.
 

Dave,

I am a little confused about the differences between BPEL and SCA, I know that BPEL can be on e of the implementaion of SCA component, but what I can not understand is how do they differ in "Composing Services", which means if I want to build a composite service, is there any difference when using BPEL or SCA?

Can you mean a clear explanation and provide me some examples?

Many Thanks!
 

I'm also very interested in the details of how BPEL and SCA relate. So far, the published SCA specs don't address these very well, so I'm not at all sure of the answer to your question.

If anybody else has a good sense of this or can point to a credible description, please do so.
 

The SCA spec group will address the relationship between BPEL and SCA soon. One of our objectives has been to deliver a "BPEL Client and Implementation Model" similar to other language bindings such as Java, C++ and PHP. This will cover how to use a BPEL process as an SCA component, including using it in an assembly and wiring to it. We've just had a lot of ground to cover so some things have been taking longer than others.

Jim Marino
BEA Systems
 

SCA's attempts to support multiple languages (interface types in SCA parlance) put it the sort of interoperability space that CORBA occupies. Of course, we all know why CORBA failed to conquer the world: Microsoft didn't support it. Do you think the same fate awaits SCA?
 

CORBA didn't fail because Microsoft didn't support it. CORBA failed because it wasn't really a standard: neither interoperability nor portability were easy to do. Customers mostly needed to install the same vendor's CORBA product on all of their systems, which is why one vendor--Iona--came to rule the CORBA world.

With J2EE, the vendors behind SCA have shown that they can make technologies they back very successful even without Microsoft's support. Unless its creators make some significant mistake, such as repeating CORBA's error of not being truly standard, I'd expect the same future for SCA.
 

Dave,

Regardng BPEL vs. SCA and their assemblies, at least one significant difference is that the SCA container does not maintain its own "hardened" internal state between wired services, such that the overall assembly behaves in an idempotent way (i.e. the BPEL container can remember where it left off in a given instance of a process after failure of the BPEL container, even driving a compensating action if so desired.) The SCA container does not "remember" completed or failed services it has visited in the assembly automatically across failures. BPEL is used for orchestrating long running processes, where SCA is about service composition, flexible loosely-coupled wiring, among other things of that ilk.

Regarding the buzz around SCA/SDO/DAS, I do believe it will pick up in the not too distant future as vendors are starting to deliver technology to the marketplace.

As was mentioned previously in this thread, there are already commerical Java and non-Java SDO implementations out there... and you can actually find them through Google. :-)

You'll also begin seeing things start to open up on the SCA front as well -- for instance, IBM has announced the availability of an
open alpha program
demonstrating the Tuscany open source implementation of SCA/SDO2/DAS running in WebSphere V6.1.

Steve Kinder
IBM
 

Post a Comment


<< Home