Opinari

Subscribe

SCA vs. SOA?  
# Tuesday, May 22, 2007
 
Service Component Architecture (SCA) is commonly described as being a technology for SOA. The group that created it christened themselves the Open SOA Collaboration, a name that clearly indicates their stance. In fact, the first sentence of this group’s SCA web page says that it describes “a model for building applications and systems using a Service-Oriented Architecture”.

I understand the need to link new technologies to SOA today—it’s a great way to get attention. The problem is that talking about SCA and SOA in the same breath is at best confusing. At worst, it’s downright misleading.

To see why, understand that SCA defines an abstract component model, then specifies how those components can be assembled into larger groups called composites. The components that make up a single composite might all run in the same process, they might be spread across different processes on the same machine, or they might run on different machines. In all of these cases, SCA’s assembly model defines how components in a composite relate to one another, specifying things like how those components should be wired together. In effect, it allows treating a group of possibly distributed components as a single unified application.

The applicability to SOA is obvious, isn’t it? As the notion of “application” increasingly refers to a group of services provided by software on various machines, having some way to define the relationships among this software is appealing. And because an SCA composite also defines a deployment unit, it can help make managing this new kind of application easier.

But there’s one problem: While the SCA specs don’t strictly mandate this, in practice all of the components in a composite must run within a single vendor’s SCA environment. This limitation isn’t obvious from reading the specs, so just to make sure, I asked this question of the participants on the SCA panel I moderated at this year’s JavaOne conference. All of them publicly agreed. While things could change in the future, at least for now, an SCA composite is a single-vendor construct.

A primary reason for this is that the SCA 1.0 specs focus on portability, not interoperability, and so they don’t fully define the interactions between components necessary to create composites that cross vendor boundaries. This means that I’m free to create a distributed application that’s wrapped into an SCA composite, and even to allow the services that application provides to be accessed from other vendor platforms, as long as all of its components run on a single vendor’s SCA container.

What does this have to do with SOA? The answer is simple: not much. Multi-vendor services are the sine qua non of SOA . If an SCA composite can't be assembled from them, it’s not an SOA technology.

So does SCA improve the SOA picture in any way? I think the answer is yes, for a couple of reasons. First, even though its internals remain a vendor-specific black box, how a composite interacts with the outside world can be specified in a service-oriented way. And along with its assembly model, SCA also defines a new programming model for creating Java components. This component model allows building business logic in a modern, service-oriented style, similar to Microsoft’s Windows Communication Foundation (WCF). Just as WCF makes it easier to create service-oriented applications on the .NET Framework, SCA’s Java component model can make it easier to create service-oriented applications in the Java world. Although it might not be fully supported by all of SCA’s creators, this approach nonetheless counts as a step forward.

SCA has the potential to be an important technology. By defining a modern, explicitly service-oriented approach to creating business logic, its Java component model can help Java developers build better applications for an SOA world. But as long as composites can contain only components running in a single-vendor environment, SCA’s value as a technology for SOA is limited.

14 comments :: Post a Comment

 

Supporting SCA’s Java Component Model: Which Vendors Will Do It?  
# Friday, May 11, 2007
 
This year's JavaOne conference included a panel on Service Component Architecture (SCA), for which I was the moderator. Representatives from BEA, IBM, Oracle, SAP, Sun, and Tibco spent an hour answering questions posed by the audience and me. It quickly became apparent that even though all of these vendors supported SCA, they had quite different ideas about what this meant.

To understand the main division, recall that SCA 1.0 defines two main things: a new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites. Composites can contain components built using SCA’s new programming models, but they can also contain components built using other technologies, such as Spring and BPEL. SCA doesn’t define a new programming model for these other technologies, however; it just describes how components built using them can be made part of a composite.

I’ve argued before that the new programming model for creating Java components is a fundamentally important part of SCA. Because it provides a simpler and more service-oriented approach to building business logic, developers can use it instead of EJB, JAX-WS, and perhaps other parts of Java EE 5. As the JavaOne panel discussion made clear, not everyone agrees.

While IBM and BEA strongly support the new SCA Java component model, Oracle, Sun, and SAP appear to have a different perspective. All were big fans of SCA’s assembly aspects, but none of these vendors seemed happy about the prospect of another component model competing for the hearts and minds of Java developers. SAP's panelist asked the audience for a show of hands: Who wants to see a new programming model for Java components? In a crowd of several hundred people, not one hand went up.

Yet asking this question of a .NET developer audience before the announcement of Windows Communication Foundation (WCF) , the .NET analog to the SCA Java component model, would have elicited the same response. Most developers want to get their jobs done, not devote scarce working hours to learning yet another way to do them. Nevertheless, it’s incumbent upon platform vendors to improve the technologies those developers use. Moving from COBOL and CICS to the Java platform annoyed a lot of people, as did Microsoft’s move to the .NET Framework. But in both cases, the resulting boost in productivity and functionality made the pain worth the effort.

Although it’s nowhere near as big a change as these earlier shifts, SCA’s Java component model has the potential to offer another boost. Yet judging from the vendor responses on this JavaOne panel, there’s no guarantee that this will happen. Strong support by BEA and IBM improves the odds of success, since these two vendors dominate the market for commercial Java platforms. Still, if their competitors fail to support this new approach, SCA could miss a chance to modernize and simplify the Java environment.

One more point to take away from this is that when a vendor says they support SCA, you can’t know what they mean until you ask them. When Oracle says it, they seem to mean the technology’s assembly aspects. When BEA says it, they seem to mean the assembly aspects and the Java component model, but not necessarily the C++ component model. When IBM says it, they seem to mean pretty much everything in the current 1.0 specs. When Sun says it--well, I’m afraid I can’t tell what they really mean.

The unity that let J2EE compete so successfully against Microsoft is breaking down, and the result isn’t pretty. If the vendors in this camp can’t agree that supporting SCA’s Java component model is worth doing, I can’t help worrying about the future of the Java platform

8 comments :: Post a Comment