SCA Java EE Integration Spec brings the Java world closer to SCA
The SCA Java EE Integration Specification has been released. It is quite an interesting read. The vision of SCA is to build composites and composite applications out of configurable, reusable service components or assets as I had tried to explain earlier. It does not intend to replace existing open standards but to build over those standards to enable a technology agnostic service component integration platform. So it has support for multiple communication protocols (or binding types), component implementation languages (implementation types) and component interface languages (interface types). The list of these types is growing. Also I had mentioned (SCDL vs WSDL) the promise to support so many technologies in a standard manner is indeed a big one! This often gives rise to skepticism in some quarters and comparison with similar looking standards such as the JBI.
However, it is important to remember that in the world of SCA, the concept of service component (or simply services and not necessarily web services) is fundamental. An important aim or design goal of the set of SCA specifications is to enable exposure of existing software assets as service components having well defined, carefully designed and publicly visible interface definitions. This is also one of the important goals of service-orientation and SOA. The latest Java EE SCA Integration Specification re-instates that. It specifies how a given JAR/WAR/EAR (Java application / component archive) which has already been built (without having any SCA stuff in mind), could be converted into a first class service component (technically called an SCA contribution). So I can re-use my existing set of Java EE components (sorry only Java EE and not J2EE L) and convert them into service components to be used by others. Imagine a BPEL component talking to an EAR module directly! The specification also enables Java EE web modules to be exposed as SCA contributions and enables presentation components such as JSPs to directly consume SCA enhanced service components, bringing my dream of Portal Composites a step closer to reality.
To the discerning it may appear that there is a good amount of overlap (re-use) between this specification and the Java EE specifications and indeed I had to go back and forth on this specification to really understand its potential. But I find this overlap proper as the SCA is not trying to re-invent the wheel but map the critical features of existing platforms into the SCA, and at the same time ensuring that the final product is a simple uniform looking service component to be consumable by other platforms, enabling interoperability to a large extent.
Comments
Sudeep
Given your observations about portal composites leveraging SCA becoming easier now, Would like to see the role of standards like WSRP. Will they phase out giving way to more mainstream penetration of the conflicting but inevitable platform level battles between J2EE standards..and likewise a .NET way of creating portal applications (e.g. - webparts). Guess this ties back to SCA - WCF debate..
Posted by: Dr. Srinivas Padmanabhuni | June 11, 2008 07:08 PM
At the moment the Integration specification does not cover WSRP, but yes its coverage would help in future. I dont forsee the core J2EE standards getting phased out, if that is what you mean and neither does SCA intend to do that in all probability. .NET is a good topic :-). We dont have the concept of SCA domain for .NET yet and I am not sure if there would be any in future. So the now traditonal J2EE-.NET integration modes would carry on such as use of web services. But it would be interesting to understand the similarity and differences in the component / service model of the SCA and WCF environments.
Posted by: Sudeep Mallick | June 12, 2008 08:22 AM
Two approaches mentioned here:
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02108.html
Posted by: Sudeep Mallick | June 26, 2008 10:23 AM