SCA Applies SOA Principles to Apps Design

Without a new programming model, the exponential acceleration in software speed could come to a screeching halt. Sure, Moore's Law still applies, but it's increasingly manifested as a larger number of CPU cores--which helps with server consolidation, but doesn't make today's single-threaded application run any faster. To take full advantage of tomorrow's hardware, apps must be broken up into small, loosely coupled components that can run concurrently on different cores on the processor.

Distributed applications ought to face this problem already, but most don't--thanks to SOA (service-oriented architecture). Designed to aid with service reuse and interoperability, SOA's architectural style also helps prevent unnecessary dependencies among applications or services. With SCA (service component architecture), under development by the Web services standards body OASIS, most of the big SOA players are attempting to apply SOA principles to applications. Just as SOA is about realigning IT infrastructure to fit businesses processes, SCA intends to rebuild applications so they are better aligned with SOA.

SCA is on the road map of every major SOA vendor except Microsoft, and its promise goes beyond making service-oriented apps or making more efficient use of multicore processors. By standardizing metadata about the relationships between app components, it should speed development time, letting apps be built from a large set of reusable components that are language- and runtime-platform-independent. On track to be ratified by OASIS within the next year, the first draft of the spec is supported by IBM and Oracle, among others.But SCA still has several obstacles to overcome. The most important is support: Although platform-independent in theory, in practice it looks Java-centric. Microsoft isn't supporting SCA, having produced its own, .Net-based rival, WCF (Windows Communication Foundation, aka Indigo). Most real-world SCA implementations must interoperate with WCF and legacy Java-based services, so it doesn't eliminate the need for higher-level SOA intermediaries. The alternative is to rewrite apps to take advantage of SCA, which isn't always possible. So far, SCA supports Java, C++ and BPEL, though vendors promise support for other languages.

Continue Reading This Story...

Language Barriers

SCA had its start in December 2005 as an attempt by BEA Systems, IBM, Oracle and other Java Enterprise Edition vendors to create a metadata spec that would free them from dependence on the Java Community Process, the Java standards body dominated by Sun Microsystems. To write the spec, they formed the Open SOA Collaboration, which was soon joined by many other SOA vendors, including Sun. It now has 18 members, including ESB (enterprise service bus) and SOA management vendors Progress Software, SOA Software and TIBCO, as well as other big software players, such as Avaya, Red Hat and SAP.

Although Java is now open source, the group believes SCA is still necessary to create apps that are truly platform-independent. While the various Java implementations and Microsoft's .Net theoretically let developers write in any supported language, they still tie apps to one Java platform (or to .Net). This limits component reuse, interoperability and app portability. SOA really works only at the relatively coarse level of services between apps: While SOAP (Simple Object Access Protocol) and JMS (Java Message Service) can in principle be used for anything, the overhead of XML and middleware makes them impractical for intra-app use. SCA is an attempt to apply the same principles more efficiently, rearchitecting apps around SOA design principles.

With SCA, composite applications can mix components that use different Java platforms. And it isn't limited to Java, at least in theory. To make it as open as possible, the Open SOA Collaboration handed its draft specification 1.0 to OASIS in April, and standardization work is expected to be finished by early 2008.

As with most things Java-based and open-source, Microsoft isn't involved; its WCF fills that space for the company. Many SCA proponents accept that their architecture is not fundamentally better than WCF, as they're both based on service-oriented messaging. WCF has a head start, having shipped at the end of 2006 as part of the .Net Framework 3.0, which is built into Windows Vista and Longhorn Server and available as an update for Windows XP and Server 2003. SCA's chief advantage is that it isn't proprietary. Although parts of .Net have been standardized by Ecma International, WCF is not among them. The only non-Microsoft implementation of .Net is the Novell-backed Mono project, which lags behind Microsoft's and does not include WCF.

Composing The Applications

SCA provides two ways to link components. Most like a conventional app is a composite, built from one or more components (see diagram, below). In most cases, components in a composite are compiled and run as a single thread. However, each component within a composite also exposes service interfaces, which can be accessed by components within other composites. In this way, both tight binding and loose coupling are achieved.Components understand how to access one another through the SCDL (Service Component Description Language), an element of SCA that is conceptually similar to the W3C's WSDL (Web Services Description Language). Although XML elements from one don't directly translate to the other, Web services management vendors such as SOA Software plan to add the capability to convert between SCDL and WSDL so that non-SCA systems can access component services. Similarly, the services can be translated into SOAP or JMS.

Another means of accessing SCA apps is provided by SDO (Service Data Objects), a spec for metadata about variables. In line with the philosophy of keeping things loosely coupled, SDO is an optional subset of SCA that also can be used elsewhere. Rogue Wave Software offers a product that can store SDO metadata in a relational database or publish it as an XML document, letting data objects created in SCA be accessed by other systems. Similarly, SCA developers can choose to ignore SDO, using ordinary variables for convenience or while porting older apps.

>

Andy Dornan is an NWC Senior Technology Editor. Write to him at [email protected].