Portability, Interoperability, and SCA
Given the competitive realities, Microsoft supporting SCA today is about as likely as an embrace of EJB would have been a decade ago. Yet even if the company wanted to, there’s not much there for Microsoft to embrace. Given SCA’s complete focus on portability rather than interoperability, the set of programming languages it supports, and the minimalist nature of SCDL, Microsoft’s support of this emerging technology would provide almost no benefit to customers.
Be sure to read the full piece; I believe David knows quite a bit about SCA, and has been an SCA proponent for quite some time — still, I can’t imagine anyone not wondering whether the whole thing is worth the effort after considering his arguments.
Interoperability clearly tops portability. Portability (and for what it’s worth, programming language-level integration) is such a 20th century idea …
Stefan:
it looks to me that Dave does not mention “the” argument that explains why Microsoft will never support SCA. Even though SCA was solely designed as a SOA technology, it has quite a CLRish feel. Java is no longer the center of the universe and new programming languages such as BPEL are welcomed. At the end of the day SCA undermines Microsoft’s strategy across the board: the programming model (WCF), interop (not just Web Services), and multi-lingual solutions (CLR).
Unfortunately it is impossible to resist SCA because it has just too many advantages .
The reason why Microsoft should join the SCA effort is because there is no center to it. You don’t see any clear vendor advantage. An SCA implementation is distributed (in other words nobody is surrending control to IBM’s runtime or anybody else) and composable. Sure there is a small logically centralized management component to it, but that’s not where the money is.
The money is in enabling customers to compose reusable IT assets regardless of the technology they were built in. There are no money to be made in the “centralized” pieces of SCA.
WCF missed the boat of asset composition since it only supported binary composition. To its defense it was designed early (2003) when there was little or no requirement for that and it was already very innovative. Microsoft will need to offer a composition model soon, the “interop” question will come back since customers will ask “I want to compose components” from different technologies (say Java). If Microsoft is developing its own component model, it might have some success, but innevitably, someone will develop an SCA layer on top of WCF and who would want to buy something else than SCA then?
It is important to realize that SCA is more than web services and composing “web services” into an SCA like model is not enough. WSDL 1.1. and 2.0 are flawed in the sense that they do not allow out of the box a peer-to-peer composition model. They only support a client/server model. SCA fixes that bug and solutions will increasing need this capability.
Hi JJ, I believe we just have to agree to disagree. To me, a portable, cross-platform assembly model and programming model has no chance to succeed — there’s just too much agreement requirement for our industry. Regarding your point,
it seems there was no clear vendor advantage to CORBA, either … which somehow did not make MSFT ever join it, either.
yes, but there is a fundamental difference that happened since CORBA. Back then “distributed” objects were a great idea in search of a seemingly great problem.
Today, there is demand for composition. Mashups at the presentation layers are showing the way. Soon people will realize that you can Mashup at the process and information layers too.
I am not sure REST will remain adequate for sophisticated mashups. I may be wrong, but I ready to be $1 on a successful technology neutral composition model. The value you get is just too high, not to mention that a “service” scales a lot more than a “distributed” object.
JJ-