Foundations for Service-Oriented Applications: Comparing WCF and SCA

When Microsoft went public with Windows Communication Foundation (WCF) in 2003, I wondered what the Java world’s response would be. We now know the answer: it’s Service Component Architecture (SCA), defined in a recently-published group of specs created by IBM, BEA, Oracle, SAP, IONA, and others.

Originally code-named "Indigo", WCF was expressly designed to support the creation of service-oriented applications. SCA, according to its creators, focuses on "building applications and systems using a Service Oriented Architecture", which at least in this case amounts to pretty much the same thing. In the .NET world, WCF is certain to become the dominant foundation for building service-oriented applications. If the vendors behind SCA can breathe life into this still-incomplete specification, SCA has the potential to play the same role in the Java world and beyond.

 
WCF and SCA: Similarities

Given that WCF and SCA address many of the same problems, it’s not surprising that the two technologies look alike in a number of ways. The similarities include the following:

• Both provide a way to use ordinary objects to implement service-oriented applications. Rather than requiring a class to inherit from some standard parent, as in .NET’s Enterprise Services, or implement a standard interface, as in J2EE’s Enterprise JavaBeans (EJB), both WCF and SCA simplify developer’s lives by allowing any class to expose services. Both also let developers focus on writing business logic, providing a clear separation between communications plumbing and the logic itself.
   
• Both rely on extras (called attributes in .NET, annotations in Java) to let developers define service interfaces and more in programming language such as C# or Java. In WCF, for instance, a C# interface that implements a service is preceded by the [ServiceContract] attribute, while in SCA, the same thing is accomplished for a Java interface by preceding it with the @Service annotation. In both cases, a WSDL portType can be automatically created from the interface definition.
   
• Both use the notion of bindings to wrap together the various information required to communicate with a service, including how reliable the communication is, what security options are used, and other things. Both WCF and SCA also allow bindings to specify SOAP or other protocols–web services aren’t the only choice–and both let a single service expose itself through multiple bindings simultaneously. Each technology also defines an XML-based configuration file format for specifying these bindings and provides some pre-defined bindings that developers can customize as needed.
   
• Both rely on the WS-* specifications, including WS-Security and others, to provide secure, reliable, and transactional communication using SOAP. Both also expose a binding’s behavior using WS-Policy. This common approach gives us good reason to expect effective interoperability between WCF applications and SCA applications.
   
• Both allow traditional synchronous calls, in the usual RPC style, and both also support one-way invocation and two-way interactions (called duplex contracts in WCF, callback interfaces in SCA). Both technologies also support session-oriented communication, with state maintained throughout a series of calls. A C# developer using WCF indicates this with the attribute [ServiceContract(Session=true)], while an SCA Java developer specifies this behavior for a service with the annotation @Scope("session").

There are many more similarities. Both define a proprietary optimized wire protocol, for example, and both also have explicit support for a REST binding. These two technologies clearly target the same problem–creating service-oriented applications–and it’s also clear that to a great degree they address this problem in a similar way.

 
WCF and SCA: Differences

But SCA isn’t just a copy of WCF–it’s different in some interesting ways. Among the additions that SCA provides are the following:

• SCA defines more than just a way to build services and clients. It also defines how those components can be assembled into larger modules, including specifying dependencies between them. The notion of a connection between components, known as a wire, is a first-class concept in SCA. WCF focuses on creating services and clients, and so doesn’t on its own address this larger issue.
   
• SCA intends to let developers create service-oriented applications in a diverse group of languages. This set includes typical choices such as Java and C++, but it also includes more specialized languages such as BPEL and XSLT. WCF supports multiple languages, too, but all of them must be built on the .NET Framework’s Common Language Runtime.
   
• SCA is meant to be implementable on top of various existing technologies, including EJB, Spring, and others. WCF is a .NET-based technology.
   
• SCA strongly encourages (and sometimes requires) the use of System Data Objects (SDO) as a standard approach for passing data between components. WCF doesn’t dictate what approach should be used for data.

 
Challenges for SCA’s Creators

Designing SCA can’t have been an easy task. At least three major challenges are evident: managing the process used to create the technology, addressing the problem of supporting diverse platforms, and facing the need to control complexity.

The Process Challenge
Multi-vendor committees are an unwieldy way to create new technologies. Getting a group of fiercely competing vendors to agree on an important spec–which SCA clearly is–is always difficult. The Java Community Process (JCP) was set up to do exactly this, and it worked reasonably well for several years. Yet SCA wasn’t created via the more open but sometimes ponderous JCP. Instead, the vendors involved (a group that didn’t include Sun, who has the final word on all JCP specs) chose to work together behind closed doors. The first published versions of the SCA specs clearly aren’t meant to be final; they’re labeled "Version 0.9", and their authors are looking for feedback in a number of areas. Yet even though these creators would clearly like some input from the larger world, SCA was not created in the fashion mandated by the JCP.

If anything, the process used to create SCA is reminiscent of how the various WS-* specs were created. Those agreements were also hammered out behind closed doors, then presented to the world largely as a fait accompli. (Like the WS-* specs, IBM has even predicted that SCA will eventually be submitted to a standards body.) While it’s possible to criticize this approach, it’s much harder to argue with its success. Whatever the process lacks in openness is more than made up for in speed and efficacy. Unlike some of the more open processes, the private consortium approach can actually work well.

Yet it’s worth pondering what this means for the future of the JCP. If IBM, BEA, and other major Java vendors can go their own way, as the process used to create SCA suggests, then the JCP becomes irrelevant. The Burton Group’s Richard Monson-Haefel has called J2EE "a standard in jeopardy", and the publication of SCA suggests that he’s right on target. The process used to create SCA, together with the fact that SCA is not a Java-only technology, are harbingers of the storms ahead for J2EE as a standard and for the Sun-controlled JCP itself.

It’s worth comparing all of this with the way that WCF was created. Microsoft combined the groups responsible for a range of technologies, including Enterprise Services, .NET Remoting, ASP.NET’s web services (commonly called ASMX), and more, under a single leader, then made these people responsible for coming up with a coherent replacement for these diverse but related technologies. This process certainly had its share of politics, but they were all inside one company. Ultimately, there was always someone with the power to make a final decision on any issue.

The Platform Challenge
Given the group of vendors involved, the technical environment for which SCA is intended is unavoidably diverse. Whatever SCA defines must be implementable on different supporting platforms by different vendors, yet still be interoperable and portable. Vendors also presumably wish to protect at least some of the investments that they and their customers have already made. How is it possible to create a new container for applications that can effectively use EJB, Spring, and other diverse technologies, while at the same time supporting Java, C++, BPEL, and a diverse range of other languages? The challenge is clear.

The solution is less clear, however. The SCA specs published so far omit a number of important aspects of the technology. Among the things left unspecified in the published version 0.9 specifications are the following:

• Much of the planned multi-language support has yet to be spelled out. Unsurprisingly, Java is the dominant option in the initial specs, with some support for C++. How less mainstream choices such as BPEL might fit into the SCA model isn’t clearly defined. Similarly, details on how SCA fits with other existing technologies aren’t provided.
   
• How security, transactions, and reliable messaging should be handled is described quite generally in an appendix–no specifics are given. SCA’s creators explicitly request feedback in these areas, noting that they’re complex.
   
• How asynchronous and message-oriented communication should be done is also defined quite generally. Once again, the description is accompanied by a request for feedback.
   
• Only two bindings are defined: one for basic web services and another proprietary option for optimized SCA-to-SCA communication. Other bindings are promised, including support for WS-I profiles, the Java Message Service (JMS), and more.

If the experience of WCF’s designers is any guide, hashing out how to deal with challenges like security and asynchronous communication will take some time–they really are complex areas. A few aspects of SCA are implemented in (and apparently derived from) version 6 of IBM’s WebSphere Process Server, and the Apache-sponsored Tuscany project is getting underway to create an open source implementation of at least some parts of SCA. Still, all of the vendors backing this new spec clearly have a substantial amount of work left to do. Meeting the broad platform and language goals expressed in the initial SCA specifications won’t be simple.

Once again, the creators of WCF faced a significantly easier problem. Although web services and SOA are platform independent, the foundation that supports service-oriented applications need not be. As a result, WCF takes the straightforward path of supporting only one platform: the .NET environment on Windows. Even with this simpler goal, Microsoft spent more than five years designing and implementing WCF, a fact that might help SCA’s creators plan realistic delivery schedules.

The Complexity Challenge
SCA offers a new foundation for creating service-oriented applications. Rather than replacing existing technologies such as EJB, the stated goal is to work together with these technologies. Once SCA is available, a Java developer will need to choose when to use it rather than, say, EJB, JAX-RPC (now called JAX-WS), or something else. And since SCA can work in concert with these earlier technologies, developers must also decide when to combine it with EJB or other approaches. While SCA may one day provide a solid foundation for creating service-oriented applications, it will also add another choice to the already complex landscape that Java developers face.

With WCF, a primary goal was to make life simpler for developers. Rather than add another technology for building service-oriented applications, Microsoft took the fairly radical step of subsuming several existing technologies, including Enterprise Services, .NET Remoting, ASMX, and more, into the single approach provided by WCF. Once WCF ships, most new applications that would have been built on any of these will instead be built on WCF. By placing such a big bet on services, Microsoft gambled that service-oriented applications really would be the norm going forward. This bet was correct, and the payoff will be a simpler development platform.

 
Conclusions

The first public release of the SCA specifications was in November 2005. The second beta release of WCF (the code, not the specs) is expected in early 2006, with the final release planned for late that year. Given this disparity in delivery dates, it’s a safe bet that 2007 will see more WCF applications than SCA applications.

Still, the appearance of SCA should stifle any remaining doubts about the coming dominance of service-oriented applications. And while some parts of this new technology owe a clear debt to WCF (Microsoft even has a patent on the idea of attributes), borrowing across the Microsoft/Java divide has a long and bilateral history. Neither camp has a monopoly on good ideas, and this kind of cross-fertilization benefits both sides.

SCA has the potential to provide significant value in the Java world and beyond. If the vendors behind this new technology can complete the tasks they’ve set for themselves, we can look forward to a day when the two major foundations for creating service-oriented applications are SCA and WCF. As with .NET and J2EE today, healthy competition between two established camps is good for everybody.

• Foundations for Service-Oriented Applications: Comparing WCF and SCA
   

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps information technology professionals around the world understand, use, and make better decisions about enterprise software. David has been the keynote speaker for conferences in the U.S., Europe, Asia, and Latin America, and he’s also delivered keynotes at many in-house events. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries, and his books on enterprise software technologies have been published in ten languages. In his consulting practice, David has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales force, and write business plans.

© Copyright 2005 David Chappell and Associates
All rights Reserved.