Quite a number of bloggers have been wondering about the Service
Component Architecture (SCA) standardization effort. SCA's pick-and-chose
specification style makes it is easy to get lost in the SCA universe.
Because there is little experience with using SCA in the community,
many areas that deserve detailed specification are still under
investigation or have not even been touched yet. At first, readers
might easily be misled into believing that SCA is (yet another)
revolution in Java land. This is wrong on two counts. Firstly, although
Java oriented work attract most of the attention, SCA is not only about
Java land: there are specifications for C++, COBOL, PHP, and BPEL. What
we want to focus on though is that SCA is not primarily about replacing
existing environments (such as Java EE and OSGI) but about creating an
infrastructure in which applications can cross the boundaries between
different programming model in these environments. The details of how
SCA will integrate with existing technologies are the missing pieces
in the catalogue of published SCA specifications. There is simply still
a lot of work ahead to figure out the tedious details of integration at
all layers with these environments. Technology integration is hard. No
single interesting technology should be limited in its use. And yet,
SCA is all about cross-technology integration... SCA defines an assembly
language that may be integrated into such frameworks in order to realize
a number of benefits. We will discuss various benefits in detail. Here
are the claims we will make: (1) SCA can be supported in conjunction
with existing technologies. That will likely be its primary use-case.
(2) SCA's fundamental value lies in providing the foundation to
cross-technology programming model integration, distributed deployments
and assembly. (3) SCA will allow implementers to provide proprietary
technologies in a consistent and recognizable way -- which is good for
both developers and vendors.
No comments:
Post a Comment