Opinari

Subscribe

What's Really Important About SCA  
# Tuesday, January 23, 2007
 
Service Component Architecture (SCA), the new technology under development by IBM, BEA, and others, provides two main things. One of them is a new programming model for building service-oriented business logic, a model that's mostly defined in a document called the Client and Implementation Model Specification for Java. The other is the ability to assemble business logic created using this new platform and/or existing platforms such as EJB and Spring into composites. How this is done is described mainly in SCA's Assembly Model Specification. Both are interesting reading, but so far, the latter spec has gotten much more attention. To the casual observer, in fact, assembling logic is what SCA is all about.

This is fundamentally wrong. True, the assembly aspects of SCA may well be broadly useful at some point. The idea of grouping diverse software into a single logical component allows creating graphical tools for defining and deploying this component, along with other interesting things. This approach has value, especially for the more service-oriented world we're heading into.

Yet does SCA's assembly capability address a major problem in the enterprise Java world today? I'd argue that the answer is no. The biggest challenge enterprise Java developers face is the complexity of their platform. There are too many APIs, each with too many options. Providing a simpler and more unified foundation for creating business logic would have real merit.

And this is exactly what SCA's new programming model does. Just as Microsoft's Windows Communication Foundation (WCF) provides a unified approach to the problems addressed by .NET's Enterprise Services, .NET Remoting, and ASPX, the SCA programming model covers the great majority of the useful scenarios currently addressed by EJB, Java RMI, and JAX-WS. Business logic built on SCA's new programming model can still use JSPs, JPA and other aspects of Java EE 5--SCA doesn't replace all of the enterprise Java APIs. Still, a common foundation for business logic certainly would simplify life for developers.

This aspect of SCA doesn't get the attention it deserves. The reason for this might be political, as promoting a replacement for key parts of Java EE 5 is bound to be contentious. It might also stem from people's natural enthusiasm for new technology, such as SCA's assembly mechanism, over a simplification of things that are already available. Yet Microsoft has successfully promoted WCF primarily as a better way to do things that are already possible with .NET. There's no shame in making significant improvements to what already exists.

It’s always fun to innovate, and SCA's assembly technology has potential. But given the very real complexity challenge that the enterprise Java world faces, embracing SCA's unified programming model makes a great deal of sense. At the very least, everyone should understand that there’s more to SCA than assembling services.

0 comments :: Post a Comment

 

<< Home