Tuesday 3 November 2009

Using Service Component Architecture (SCA) and SoaML

Service Component Architecture (SCA) brings the formality of SOA contracts and end point separation into the implementation layer. For the many organizations undertaking modernization efforts the standardization of componentization and SOA enablement is an important issue. Whilst its usage may not be widespread, it is likely that growing demand for rationalization of the implementation layer will lead to increased adoption.

In a new report I look at SCA and consider how it relates and maps to SoaML and provide guidance for integration into the broader SAE/SoaML picture.

My conclusion is that in some respects the SCA and SoaML initiatives represent something of a missed opportunity. Though the respective groups will claim they address different requirements or audience, the reality is that it is hard to see why they couldn’t have been based on common concepts where they overlap. One could have extended the other instead of re-inventing. Then the inevitable additional effort and loss of integrity through the mapping and transformations from one to the other discussed in this report could have been avoided. More so given that some organizations participated in both initiatives.

On the positive side, SoaML to SCA transformation tools do exist, and the mapping provided between SCA, SoaML, and CBDI-SAE in the report is at least at a high level relatively straightforward.

SCA is an elegant solution, but somewhat limited by lifecycle scope, and dependence on the SCA runtime, in comparison SoaML. However, it does offer portability across SCA compliant platforms and that is of significant benefit.

SCA does seem to have reached a bit of an impasse. It is there, it works, but it isn’t clear whether adoption is growing, either by end-users or support by more vendors. If you are using or planning on using SCA, please let us know in our CBDI LinkedIn where we have created a discussion topic

No comments:

Post a Comment