Extensibility Mechanism of SCA
The extensibility mechanism in SCA is extremely powerful and allows custom support for new interface types, implementation types, and binding types. However, until they’re standardized it would remain proprietary, limiting true interoperability. In any case, one can imagine that within the boundaries of the same enterprise and even among a limited set of business partners, these extensions could be standardized. For example, in the case of Apache Tuscany, a popular SCA platform, the steps for adding an implementation type would involve implementing a few interfaces having lifecycle methods for the Tuscany SCA runtime to invoke and activate these extension modules as well as the standard SCA. Moreover, SCA does not require thecreation of new rules for implementation and binding platforms. It leverages already existing standardization efforts in these diverse platforms. For example, it builds on the Java Annotations concept prevalent in the Java EE platform to specify SCA-specific annotations. A Java developer conversant with the Java annotations concept and style of development would find it easy to adopt SCA annotations for the Java platform.

SCDL Compared to WSDL
WSDL, like SCDL, is a service interface description language for Web services, hence there’s a chance for confusing it with SCDL. While WSDL provides an interface for Web services, WSDL isn’t at all concerned with the details of service implementations other than providing the concrete endpoint where the service is actually accessible. SCDL addresses the broader requirement of configuring and wiring heterogeneous implementations together (with different kinds of interfaces and wiring mechanisms), Web services being just one of the interface types.

For example, you could have a C++ implementation with a CORBA IDL interface description. It may be desirable to configure the C++ implementation with different database connectivity protocols and make this configured implementation (a component in SCA) available to a Java implementation. The Java service component could talk to the C++ component using a Web services protocol. The C++ could even be referred to by a COBOL implementation. The requirement here then is to configure and wire together these diverse implementations without opening the implementations up. The runtime on which these components would execute would have to address multiple challenges – it would have to introspect these implementations (C++, COBOL, Java), find out if the implementation exposed the promised and published interfaces (CORBA IDL, Web service interface), if these implementations can actually be properly configured (database connectivity), if the source and target components interfaces are compatible, and finally if the protocol binding the interfaces demand can be made available between these components. An SCA runtime would address these challenges exactly.

SCA enables the description of component-to-component interdependency. It specifies the component architecture, which WSDL isn’t concerned with. Second, SCA promises to provide tremendous flexibility in being able to specify, configure, and wire components together – implementation-to-implementation flexibility (varying with properties), implementation-to-interface flexibility, and interface-to-binding flexibility.

Business Use Case
Let’s consider a sales analytics application (see Figure 1) that supplies analytical data on sales history to other enterprise applications that consume this information to generate regular reports for managerial decision making, implement BAM, and provide field sales personnel with the latest sales reports. This requires data input with different degrees of recency and latency. The regular reports require weekly inputs in batch mode and hence the sales analytics application could supply the data asynchronously over JMS. The BAM application requires real-time updates and hence would require data to be provided over a synchronous RMI binding. The field sales personnel would have to be provided with daily updates on their devices. Hence, the data has to be formatted from the sales analytic application for mobile device form factors and would have to be provided over the Internet with enhanced security levels. The enterprise decides to use Web Services over a secured HTTP protocol to do this. In addition, to enable mobile form factors the existing sales analytics application would have to be front-ended with another component from a deployed mobile-enabling framework. The architecture of this setup is depicted in Figure 1. The sales analytics component exposing the service functionality is written in Java.

The same Java component SalesAnalyticsDetailsImpl (see Listings 1 and 2) has been configured to use different data sources (having different data recency – SalesAnalyticsDS1, SalesAnalyticsDS2) and then is exposed as service components SaleAnalyticsSeviceComponent using different binding protocols – RMI, JMS, Web Services. There could be an intervening mobile-enabling framework service component SalesAnalyticsDSVersatile between SalesAnalyticsServiceComponent and SalesAnalyticsDS1 (or SalesAnalyticsDS2) that could supply mobile-formatted data from the data sources. The SCDL file providing this entire composite configuration on open source Apache Tuscany is shown in Listing 1.

The Java interface and implementation contain no references to individual binding details or security details. These are taken care of by the SCA runtime through the SCDL configuration. The Java interface and implementation files are shown in Listings 2 and 3.

Conclusion
Composite applications are the emerging face of SOA for developing IT applications. SCA is a good starting point for standardizing the necessary infrastructure for realizing true flexibility in composite application development. The true power of SCA lies in providing flexibility at multiple levels: implementation, interface, and binding. Further, as more and more implementation types and binding types get supported by SCA, the true power of composite applications will be unleashed with mainstream penetration.

References

• Service component architecture specifications
  
• Apache Tuscany
• Tuscany: Adding a New Implementation Type
• An overview of Service Component Architecture