SOA服务组件架构SCA的问题?

  Eric Newcomer，在他的博客中，就David Chappell的最近围绕SCA的言论发表了评论。在David的博客中，他说道： 
  服务组件架构（SCA）不是特别简单的技术。只是阅读规范，很难弄清楚它。
这促使他撰写了非常棒的SCA白皮书介绍。另一方面，正如David之前提到的，有时很难让所有的SCA作者就SCA中哪些是重要的达成一致。但是，在他看来：创建Java组件的新的编程模型是SCA中最重要的部分。因为，它提供了一个更简单和更加面向服务的构建业务逻辑的方法，开发者可以使用它代替EJB、JAX-WS，可能还包括Java EE 5中的其它部分。
  David认为，该Java编程模型没有得到它应得的重视，它在SCA中的重要性等同于.NET中WCF的重要性： 
  正如微软的Windows通信基础（WCF）对由.NET企业服务、.NET Remoting和ASPX解决的问题提供了统一方法，SCA编程模型涵盖了当前由EJB、Java RMI和JAX-WS解决的绝大多数有用场景。建构于SCA新的编程模型之上的业务逻辑仍能使用JSP、JPA和Java EE 5的其它方面——SCA不会全部替换企业Java API。
现在Eric，作为代表IONA的SCA作者之一（也是Eclipse SOA 工具平台成果的领导人），不同意David的观点。他认为服务装配模型才是关键，同时还认为与WCF进行比较未必合适：
  WCF宣布的时候，我就在2003年的Tech Ed会场。而且清楚地记得，听到一些与会开发者的反对之声，因为他们发现微软打算要求他们改变开发Web服务的方式。 

  在对Eric的帖子的回复中，David澄清了他的一些言论： 
  我认为，SCA的装配模型也很重要；我只是认为它的Java SCA组件模型更重要。……定义组件应该如何装配到应用中当然有用，并且SCA的这部分看来得到了广泛的支持。尽管如此，正如你提到的Windows开发者的抱怨，这恰恰可以用来理解为什么WCF是个好东西，Java企业开发者应该理解统一编程模型对面向服务应用的价值。

  但是正如Eric随后指出的： 
  微软世界和Java世界之间的一个区别是，早已存在若干种创建服务的方法——一些方法比另一些更复杂，这是事实——但是我一直在说的一件事是，SCA Java编程方法存在有将一个复杂性交换到另一的危险。我不确定SCA编程模型，与JAX-WS或Spring相比，会显著的降低复杂性。

  那么问题仍然存在：SCA最重要的方面是什么？答案可能仍是厂商特定的。但是如果是那种情况，为了全面认识SCA的复杂性要做些什么呢？