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的复杂性要做些什么呢?