Will Microsoft support Service Component Architecture (SCA)? It seems
unlikely... First, it's important to understand that SCA is purely
about portability -- it has nothing to do with interoperability. To
connect applications across vendor boundaries, SCA relies on standard
Web services, adding nothing extra. This is an important point, but
it's often lost (or misunderstood) in SCA discussions. Because some
of SCA's supporters describe it as a standard for SOA, people assume
it somehow enhances interoperability between products from different
vendors. This just isn't true, and so Microsoft not supporting SCA
will in no way affect anyone's ability to connect applications running
on different vendor platforms. But what about portability? Just as
the various Java EE specs have allowed some portability of code and
developer skills, SCA promises the same thing. Wouldn't Microsoft
supporting SCA help here? The answer is yes, but only a little. To
explain why, it's useful to look separately at the two main things
SCA defines: programming models for creating components in various
languages and an XML-based language for defining composites from
groups of these components... While some SCA skills portability will
occur -- at least everybody will be describing components and
composites using the same terms -- I'm doubtful that SCA will do much
to help move applications from one vendor's SCA product to another.
Put another way, don't look to SCA to play a big role in reducing
vendor lock-in... More Information See also the OASIS SCA TCs: Click Here
No comments:
Post a Comment