What is that SCA does which WSDL couldn’t already do! ?
Well, on the face of it, it may look quite an answerable question but its implications go deeper on second thoughts and perhaps makes one think deeper about the future of SCA and perhaps make educated guesses about it. Here, I will try to answer this question and one need not know anything about SCA (except that it is a superseding component specification model which promises the heaven – no plumbing code only business logic, remember!). I will assume you have fair understanding of WSDL. SCA promises to be an interesting component specification on the horizon and backed by big names such as IBM, SAP, etc. so no harm spending some time understanding it. Seems like it is logical evolution from the J2EE component specification and some basic ADL concepts – component, interface and connectors…In fact most of the concepts are familiar in the Java world (references, annotations, etc.).
Let me start with WSDL which I will assume we know – it is an interface description language. It provides us a way to specify the interface of a service – messages, message exchange pattern and the protocol bindings to be used to access the service and concrete endpoints (IP address, port number, etc. in the HTTP world) for accessing the service. So what does WSDL achieve? It decouples portions of the service interface from one other – say, operations, messages, etc. from the protocol bindings. This provides flexibility. Hence you could imagine a service interface A being built out of message parts B, operation C, and binding D as well as the same interface A being built out of message parts B, operation C and binding E. In fact, we could using the import mechanism of XML create multiple such service interface descriptions by combining parts of the WSDL. So WSDL provides flexibility at interface level. We are completely silent about implementation here…
If we bring in the implementation, then we have many more challenges. Imagine a crazy situation for example sake to understand the problem (of course in SCA it does not remain so crazy a situation after all). Let me have a C++ implementation to which I provide a CORBA IDL interface and I want to configure the C++ implementation with different database connectivity protocols (at will) and make this configured implementation (a component in SCA) available to a Java implementation which wishes to refer to it using a Web services protocol or better even having a COBOL implementation wishing to refer to this C++ implementation. Now, my requirements are I have these implementations which I don’t want to touch, and I wish to configure and wire them together in a descriptive manner (configuration files). Hence, the contraption on which these components would play would need to introspect these implementations (C++, COBOL, Java ) find if the implementation expose the promised and published interfaces (CORBA IDL, WS) and if these implementations can actually be properly configured (database connectivity) and if the source and target components interfaces are compatible and finally if the protocol bindings the interfaces demand can be made available between these components. An SCA based runtime can do all that. Which means an SCA runtime should support IDL, RMI, WS, COBOL, Java, EJB, BPEL, C++, HTTPS, HTTP, TCP, etc. etc. etc. Too much of a promise!!!???
Well, yes and no.
SCA has a wonderful extension mechanism by which you could extend the platform with new interface types, implementation types and binding types. So you have it. The specifications get into details of some of these programming languages, bindings and interfaces at the moment and specify how these have to be handled given the above set of requirements. So expect a chain of SCA related specs or appendix specs!
In the final analysis, SCA enables description of component to component inter-dependency. It specifies the component architecture, which WSDL is not concerned with. Secondly, 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, interface to binding flexibility. So flexibility delivered in more areas than WSDL. And all this flexibility is provided through component and composite configuration files. Hence, the programmer can be relieved of writing a great deal of plumbing code (no RMI, no WS, no HTTP in his/her code) – only business logic! Sounds too good to be true? This is not entirely true however.
Suppose I am writing an implementation which is a POJO or an EJB. I still have to have put Java and EJB annotations for references, properties and services. The SCA specifications would also support Java and EJB annotations and then if I specify a Web services interface to it, the SCA runtime would introspect the code and verify if the published interface is compatible with the actual implementation using the annotations. I could now specify Web services or RMI binding for inter-component communication. However, I don’t need to write any Web services or RMI related code here. Only a few annotations in the code and a few configuration set up in the SCA composite files would suffice.
The concept of ComponentType is extremely powerful in SCA. In case the SCA cannot verify the implementation through introspection, it can use an accompanying componentType (which has been provided by the implementation supplier graciously) to discern for the “intentions” of the component – services, interfaces, dependencies, properties.
Some of these concepts are mature in the field of Java/J2EE and Web services and hence developers from this community may not find it shocking or eye opening at the first instance.
The promise and the future of SCA would depend upon how rich the vendor’s SCA runtime is, what performance and interoperability issue might crop up during implementation.
