构建的可伸缩性和达到的性能:一个虚拟座谈会
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
- Architecture, Java, .NET, Ruby,
作者 Charles Humble译者 王锐 发布于 2008年1月20日 下午7时52分
尽管目前公布的细节仍然有点简略,Java EE 6的大致方向已经变得更明朗了,并且反映出Java EE 标准的角色正在转变。一些开源项目,例如Struts,Hibernate和Seam,最初被视为一个完整的企业计算栈,被越来越广泛的企业采用来弥补目前版本Java EE的不足。在某些情况下,这些开源项目轮流影响了下一版规范的修订。同样,对于提供一个完整的解决方案,Java EE的角色变得更轻了,而对于提供一个鲁棒的基础代码集合,使软件提供商和开源开发者能够依托其上构建自己的应用,Java EE的角色变得更重了。JSR 316——做为下一个Java EE版本修订的庞大(umbrella)JSR,通过使可拓展性成为专家组的一个核心目标,看起来把这个新的关系放到了一个更加正式的根基上。另外这个规范承认,Java EE已经变得庞大而且复杂,建议既要对规范中特定元素进行修剪,还要引入使用偏好(profile)以针对特定开发组织提供其关注的EE功能子集。它还要建立在先前的版本所做的简化工作的基础上,这些简化工作包括使用注解来进一步削减对外部配置文件的依赖。
修剪采用的方式与Java SE6采用的方式相同,有一个Blog对此做了描述。这是作为一个多阶段过程来进行的,一个待修剪候选可能在一个发布中被声明出来,但在下一个发布中就可能被降级为可选组件,而所有这一切完全取决于社区的反应。JSR建议了两个最初的修剪候选——一是JAX-RPC [JSR 101,基于XML的RPC的Java API],它已经被JAX-WS [JSR 224,基于XML的Web Services的Java API]有效的取代了,二是EJB CMP,目前已经被Java持久化API (JPA)[起初是作为JSR 220,Enterprise JavaBeans 3.0的一部分来定义的]替代了。在对Artima采访的过程中,EE6规范的领导者Roberto Chinnici和Bill Shannon暗示目前没有被广泛采用的JAXR API [JSR 93, 用于XML Registries 1.0的Java API],一个访问web service注册表的API,可能被添加到修剪的候选名单中。
尽管大部分修剪是无可置疑的,Sun对profile(使用偏好)的使用还是引发了一些争议。SpringSource的CEO Rod Johnson理所当然的喜欢它们:
“最终,用户将会有权力货比三家,决定什么才是他们真正想要的,而不是由一个规范委员会在用户开始构建应用两年之前去决定他们的意志。”Johnson说,“现在到了用一些健康的竞争取代一个苏联式的命令经济的时候了。”
但是OSGi的布道者Peter Kriens对此不以为然:
“要解决众口难调的问题,Sun提议多创建一些尺寸,叫做profile。肯定能适合所有的情况吗?好吧,profile在J2ME[Java 2 Micro Edition]中尝试过了,我认为它们失败了。”
EE6计划中的第一个profile是Web profile,关注于web应用开发人员。在引入这个新的profile的同时,这个规范还会定义一些规则,用来为其它的细分市场创建额外的profile,例如电信业或者金融业的应用。
可拓展性的技术细节不是那么清楚,即便JSR制定了一些野心勃勃的目标:“我们相信使更多这样的技术在Java EE应用服务器上清楚的分层或者接插到Java EE 应用服务器是令人向往的,”JSR 316这样提到。通过增加更多的可扩展点和更多的服务提供者接口,这些额外的技术可以清楚高效的接插到这个平台的实现中,并且用户使用起来就如同将它们构建到系统中一样便利。
这种方式的一个例子是JSR 196:Java 容器的认证服务提供者接口,J2EE 1.4最初计划中API的三重奏之一。它提供了一个标准服务提供者接口来使认证机制提供者能够被集成到容器中。使用这个接口的提供者会被用来建立容器访问决策的身份认证,包括那些在容器中调用其他容器组件时所使用的身份认证。2007年10月这个规范最终发布并且可以下载了。
如同1.4的最初计划那样,Java EE 6也应该最终看到以下两组API的正式发布:适合用于管理环境的定时器API;一个容器可管理的编程模型,提供给那些使用容器管理的线程池并发执行的工作。这两组API是由IBM和BEA联合开发的,并得到了BEA WebLogic和IBM WebSphere的支持,具体的描述在这里(PDF文档)。
EE 6中还计划包含两组新的API。其一是深受JBoss的Seam和Google的Guice影响的WebBeans,它的目标是通过统一web层与事务层的组件模型,简化基于web的应用程序的Java EE编程模型。另外,WebBeans规范提供了一个会话模型和持久化上下文,其提供了细粒度的状态管理,并允许一系列的web事务(一个会话)被当作一个工作单元来对待。 Jacob Orshalick详细描述了Seam会话模型与超时处理的细枝末节。通过一个声明和四部分(一, 二,三, 四)的详尽描述,Gavin King为WebBeans模型做了全面广泛的说明。
尽管WebBeans JSR得到了广泛积极的反响,IBM在JSR 316的表决中还是持有一些异议:
“我们对JSR 299似乎要选择的方向很关心,这个方向超越了其提到的集成JSF和EJB组件的许可。并且我们相信,如果它在这个方向上继续努力,最终会使它从Java EE 6中被去除。我们不相信我们的客户会觉得采用需要添加一个别的组件模型定义的Java EE 6是一件容易的事。”
第二组新的API是JSR 311,一组RESTful Web Services的Java API。它已经产生了一些毁誉参半的反响。一篇InfoQ早些时候的文章对社区反应做了一个不错的概述。Brian Leonard的blog和相关的链接提供了这个提议的更多细节,Bill Burke 提供了一些反馈。
在Java EE 6中会看到对很多核心API的修订。主要的更改计划有:
最后,还有更多的较小的修改:
很多API没有为Java EE 6作出最后的修剪。有两件事值得注意,其一是JSR 168,Java Portlet 规范,其被几个主要的门户运营者所拥护;另一个是JSR 208, Java业务集成(JBI),一个服务仲裁规范,目前已经被除BEA和IBM之外的所有厂商支持。
EE 6规范有一个相当有竞争力的时间表,最终的发布瞄准了2008年第四季度。
查看英文原文:JEE 6: Extensibility, Profiles and Pruning
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
本视频主要对OpenSocial进行了分析,并对实现的方式进行了介绍。其中包括:OpenSocial的开发经验、Container Provider的技术准备、平台的构成要素、具体的规范、以及对未来的展望。
Memcached在大型网站被应用得越来越广泛,但是Java客户端并不多,本文作者基于现有的开源客户端进行了封装优化,并翔实记录了这一过程。
在他们文章的第二部分,作者探讨了动态业务应用的架构并介绍了资源容器的概念。他们示范了如何在JEE之上构建这个架构,以及它如何影响实现生产力。
ClickOnce让WinForms应用程序的部署轻而易举。David Cooksey演示了如何在ASP.NET中编写一个HttpHandler来实现对ClickOnce部署的版本细分。
本文是Productive Java with Ruby系列文章的第二篇,通过上一篇的介绍,我想大家对如何利用Ruby进行单元测试有了一个基本的了解,从这里开始,我将和大家一起讨论一些利用Ruby进行单元测试时的高级话题。
《应用SOA》是由四位一流SOA专家合著关于SOA的新书,其主旨是帮助你成功地实施SOA。尤其是,这本书将帮助你把你的SOA项目与企业架构、IT治理、核心数据和BPM项目结合起来。
没有回复
回复