甲骨文高级副总裁哈桑里兹维（Hasan Rizvi）称：“很高兴苹果能够成为OpenJDK社区中的一员，Mac OS X版Java体现了我们对Java跨平台发展的承诺。Java程序员社区能够确保Java运行环境始终处于行业前沿，并继续为未来的Mac OS X提供Java的更新版本。”

    来自外国的计算机安全专家Dino Dai Zovi认为这样将使Mac OS更加安全。Dino Dai Zovi表示，大多数Mac用户一般都用不上Java，苹果将Mac平台上的Java交由甲骨文管理将使Mac用户更加安全，否则Java上的漏洞很容易 被利用来攻击Mac OS操作系统。

• 判断SOA是否是最好的选择，根据白皮书：

  虽然SOA能够带来重用、敏捷及松耦合等好处，然而这些好处却不一定总是软件架构师首选的考虑因素。

  例如，实时系统或者网络限制的分布式系统，SOA可能就不是合适的架构选型。
• 从解决业务及运维中的挑战来开展SOA活动，为了使企业能够完全收获SOA实施带来的在时间及成本上的节约，它关注的应该是解决业 务问题而非只关注技术。

  如果企业的SOA采用是由解决业务问题而驱动的，并与之对齐，那么企业将会看到共享的服务，业务敏捷，和简化的整合带来的好处。

  作者们给出了一组SOA实施的工业案例，在这些案例中，都对业务目标进行了很好的定义。
• 将服务用于支持关键的业务流程的步骤，SOA主要的价值主张之一就是通过提供服务并实现能被多个业务流程公用的关键能力来降低IT 冗余度。

  通过关注跨企业使用的业务流程步骤，服务的重用就自然变成架构的产出之一……将服务定位在合适的业务流程级别是非常必要的（如， 服务所 包含的能力范围），这样它们就能被轻易地映射到业务流程步骤中。

  作者们认为，服务的一个重要特征是松耦合，它能在对服务进行修改时带来灵活性。白皮书在最后还谈到了服务契约规范化以及服务可视化，这通常是通过服务注册 实现的。
• 检查你的数据， 这意味着SOA不会解决你的数据问题，却会把它们暴露出来。SOA带来灵活性的一种途径是实现业务和数据间的解耦。这通常会导致创建数据服务，由它们提供 跨企业的通过服务对数据的访问。但是，作者们提醒到，

  实施SOA本身不会解决数据问题。在SOA让数据更易于访问的同时，因为数据质量、可用性以及不同社区在词汇上的差异，它依然可能是不可用的…… 缺乏对数据的重视可能会损害SOA实施所带来的价值。

  作者们认为，在SOA实施中成功地融入数据需要：定义数据语义，用于保证在服务消费者和服务提供者之间数据交换的含义一致性；数据质量，用于消除冗 余，不一致性或失效的数据及数据可用性……提供能够支持异构的，或可能是不可预知服务消费者集合的的跨网络的分布式的数据服务。
• 开始于一小点，学习并发展，白皮书的作者们认为，SOA项目失败的主要原因之一是不合理的范围。

  ……架构师们往往希望把他们最初的SOA项目变成是整个企业范围的工作，即便从某个业务场景来看这并不合理……采纳SOA时，最 好从一小点开始，学习并发展。递增的方法允许我们在实施大范围的SOA项目之前收集经验和教训；它可以最小化业务风险并能递增地收获回报。然而，在界定 SOA 工作范围时，至关重要的几个方面是：解决有意义的业务问题、关注架构的检验、清晰地描述期望的产出以及对成功的评判尺度，还要吸取经验教训，以备在将来的 工作中使用。

  白皮书的作者们基于对行业的研究，建议从试验性SOA开始，解决具体的业务问题并定义清晰的业务和架构成功的准则。他们还建议要吸取经验和教训，并在开展 下一个SOA项目之前把学到的经验教训传授给企业的其他人员。
• 要有远见，即便从很小的SOA开始，追求长期的SOA远景也是非常重要的。

  今天构建的SOA的结果可能是面向某个特定服务消费者的耦合服务，可能是系统间两两互联的一些通道。此外，缺乏对将来或者不可知 的使用的计划，SOA可能无法满足将来的服务需求。因此，在SOA实施中，设计时应该考虑到将来可能的需求发展。SOA的架设应该能支持扩容和扩展，既要 包含 SOA部署的范围的扩展也要包含需求的扩展。

  作者们认为，确保远见的主要步骤包含：服务管理（通过监控），由它提供管理目标是否被很好地实现的信息，它还辅助定位问题及解决问题；确保服务实 现的延伸性……包含基础设施，使能服务交互，可扩展部署及测试活动；创建合适的安全基础设施等。
• SOA的关键组件之一是治理的保障.

  对企业范围内的SOA采用中所必需的变更的成功实施需要政策和流程的参与，这主要都是受业务需求驱动的。企业对治理的保障对 SOA项目的成功是至关重要的。

  白皮书中描述的治理的主要方面包括：架构——设立一个最低限度的约束集合来确保服务实施的一致性；基础设施——建立政策来确保基础设施平台（包 括消息传输，安全和其他工具服务）在所有项目中都是标准的；信息——定义数据所有权、建立依附于企业所选的数据标准的政策及方针、设立政策来保障 数据质量度量尺度的遵守等。服务编目——建立政策保证服务声明周期的一致性、策划业务及工具服务、确保开发服务时恰当地利用了现有的企业应用。
• 设定投资回报预期， 基于行业研究，作者们指出：

  ……尽管节约开支是采用SOA的主要动机之一……然而SOA采用的一个根本的挑战是，考虑到过高的学习曲线、技术技能和熟悉程度 的缺失、成熟行 业标准的缺失、以及用户企业管理能力的缺失（比如，治理）等情况，如何决定投资SOA来制定整体的SOA实施。一个企业要施行SOA方法，就应该对需要进 行多少投资以及投资回报有理性的预期。

  他们强调，与传统的基于应用实施相比，最初的SOA实施几乎总要更昂贵一些，而且成本的节约并不会在企业的每个部门发生。在他们看来，大部分成本节 约都是长期的，并且会反映在SOA提供的组织敏捷以及共享信息的能力上。此外，服务重用将带来维护成本的降低。

C#如何在打印文档中添加进一张已有的图片，并打印出来？

C#如何通过api显示窗体在任务栏上的图标

Linq中的not in 语句应该怎么写?

虽然白皮书相当高层，但是，它的确强调了大部分重要的SOA关注点。对于正在考虑进行SOA实施的人们，它可以的是一个很好的指引，对与SOA执行 者 的，它可以作为一个提醒——SOA不仅关心很酷的技术，还关心架构，业务和投资回报等。

• 投射（Projections）。让客户端可以通过投射功能，只获得实体对象中所需的属性；或者组合多个实体对象中的属性成为一个新的动态对象。有 了投射，在客户端使用Data Service和在服务器端使用实体框架就很接近了。
• 加强了的数据绑定。现在支持双向的数据绑定。
• 行数量统计。之前的版本一直缺少一个重要的也是被大家强烈期待的特性，就是获取数据行的数量。没有这个特性，要知道某个数据的总数，只有把数据全部 获取到客户端进行统计或者自己编写一个服务器端接口来单独计算。
• 自定义feed。通过这个特性，开发人员可以自定义feed中的数据结构。
• 服务端驱动的分页。从字面上理解，通过使用这个特性，客户端就可以直接获取到已经在服务器端分好页的数据。对性能的提高不言而喻。
• 加强了BLOB的支持。虽然对BLOB的支持在第一个版本中已经支持，但是现在支持任意大小的BLOB数据，可以把元数据和BLOB的内 容分离等。
• 请求管道。服务器端在获取到客户端请求的时候，利用请求管道可以控制对Data Service的访问，可以实现自定义的HTTP响应缓存等等。
• “Data Service Provider”接口。新添了一个数据服务提供程序的接口，让开发人员可以编写自己的提供程序。在之前的版本中，Data Service只能暴露实体框架（EF）和任意.NET类；不过现在有这个接口，理论上可以把任意数据源暴露为Data Service了。

当然这个版本也不是尽善尽美，比如还不支持诸如First()这样的很多扩展方法。

web.config中怎么配置Access连接?

Asp.net如何清空页面上的所有TextBox

Asp.net里的这两个符号有什么区别?

Ado.net中常用的对象有哪些?

同时，ADO.NET Data Service团队为这个更新提供了一个入门向导：

• 第一部分，主要讲述了如何安装这个更新，并用新版本创建一个项目，在这个项目中用OData协议把实体框架的数据暴露出来。
• 第二部分，创建一个WPF应用程序来使用第一部分中创建的Data Service。

这个更新不仅用于.NET 3.5 SP1，也提供给了Silverlight 3，不过暂时处于CTP阶段，正式版会和Silverlight 4一起发布。

值得一提的是，虽然ADO.NET Data Service现在已经更名为WCF Data Service，但由于这个更新是针对之前的老版本而发布的，所以名称依旧是“ADO.NET Data Service”。

正如John所述，在各种不同的浏览器中测试jQuery难度非常大：

我们力求在jQuery项目中支持所有主流浏览器的当前版本、最新发布版以及即将发布的每日构建版/beta版（我们根据用户升级浏览器的频率对这些支持标准进行了一些平衡——Safari与Opera用户的升级频率非常高）。

在本文发布时一共包含12个浏览器。

• Internet Explorer 6、7、8。（不包括8中的7模式）
• Firefox 2、3及每日构建版
• Safari 3.2、4
• Opera 9.6、10
• Chrome 1、2

当然了，这只是Windows平台上的，还不包括OS X及Linux。对于jQuery项目我们采取了明智的策略，通常只在一种平台上进行测试，但理想情况下还需要在所有平台上测试Firefox、 Safari及Opera（这三个是跨平台的浏览器）。最后的结果是在每一次提交前后我们都要在12个独立的浏览器上运行10个独立的测试套件。跨浏览器的JavaScript测试的可伸缩性还不行。

如果测试需要与用户进行交互，那么这对于jQuery乃至任何大量使用JavaScript的Web应用来说都是糟糕透顶的事情了。

一些测试套件（如Yahoo UI、jQuery UI及Selenium）可以对用户交互进行自动化（你可以编写类似于“点击按钮”这样的测试）。大多数情况下这能满足我们的要求，但所有这些仅仅是对实 际用户交互的一种模拟。没有什么东西可以与让人手工运行一些容易重现（并且可验证）的测试相提并论。

这是最大的可伸缩性问题。用自动化的测试套件乘以想要运行的测试个数，手工在12个浏览器中运行100个测试简直是天方夜谭。一定还有更好的办法，因为很明显：跨浏览器的JavaScript测试的可伸缩性还不行。

像Selenium Grid这样的解决方案有几个限制：

• 据我所知，Selenium Grid需要用Selenium来运行测试。目前还没有哪个主流的JavaScript程序库使用了Selenium（这么做的代价也不小）。
• 它无法测试非桌面机。每个服务器都必须运行一个后台程序来处理众多任务，这样移动设备就不行了。
• 它无法测试未知的浏览器。每个浏览器都需要特殊的回调代码以让Selenium加载浏览器，这样未知的浏览器（如IE 8、Opera 10、Firefox Nightly及Chrome）可能就没法运行了。
• 最重要的是：Selenium Grid要求你拥有大量机器来运行测试，这不太可行，尤其是在分布式的开源JavaScript开发下更是如此。因此我们需要更加行之有效的解决方案。

John提出的解决方案Test Swarm基于JavaScript客户端，该客户端会持续不断地向中央服务器发出连接请求以运行测试。服务器收集测试套件并将其发送到各自的客户端上：

以下是我设想的Test Swarm的工作方式：开源的JavaScript程序库将测试套件提交到中央服务器上，同时用户也会参与进来。程序库的用户需要在其日常的工作中额外开两个浏览器窗口来辅助我们的工作，这样他们会感觉到也在参与着项目（其实就是这样！）。

程序库还可以将手工测试发给用户。新的手工测试到来时会通知用户（通过声音提示？），这样他们就能迅速执行了。

用户提供的这些帮助也不是无偿的：我们可以统计参与最积极的用户，然后对前几名进行嘉奖（T恤、杯子、书等等）。

InfoQ联系到了John Resig以进一步了解相关的信息。

InfoQ：Test Swarm基于何种协议？

基于MIT协议（服务器端采用PHP和MySQL，客户端是一些简单的JavaScript）。

InfoQ：除了框架所有者以外，你认为它对于其他组织有何价值？

我认为这对于其他组织和厂商都大有裨益。下面是我设想的成长计划：

• 首先开放给主流的JavaScript程序库（他们已经建立好了测试套件和测试体制）。
• 接下来开放给其他开源的JavaScript项目。
• 然后开放给其他组织，只要这些组织允许匿名用户运行其测试就行。

当然通过这些步骤，任何组织都可以轻松下载服务器软件并运行自己的swarm实例——无需通过主要的Test Swarm服务器的测试。

在最初的声明中，John还提到了Test Swarm的“corporate”版：

Test Swarm的“corporate”版已经引起了很多人的兴趣。目前对此还没有什么计划（除了以开源的形式发布该软件），我倒是想留点空间以便将来的扩展 （或许用户会因手工测试而得到一些报酬——就像Mechanical Turk测试JavaScript那样——我不知道，但确定的是其成长空间很大）。

如果对Test Swarm感兴趣可以索取其alpha版。

还可以通过InfoQ上的JavaScript、jQuery、富Internet应用及持续集成频道了解更多信息。

SpringSource tcServer——SpringOne上的头条新闻就是新的tcServer的公诸于众：

...SpringSource tc Server包含了Apache Tomcat、增强的操作管理能力及高级服务器和应用诊断功能。该服务器在多种环境下都经受住了考验并且支持企业级的关键任务。SpringSource tc Server以独立的控制台视图提供了对组织的Tomcat server集中管理和监控能力：定义Tomcat server组、单独或者是跨越一个服务器组来部署/启动/停止/卸载应用，同时还能够启动和停止Tomcat server本身。它可以独立的控制台来控制Tomcat server的整个生命周期。其管理功能还可以监控并控制其他版本的Tomcat（例如，那些在实现tc Server之前已经部署了的Server）。SpringSource tc Server提供了高级的诊断功能，如死锁检测和更多的跟踪、可以更快的识别出问题并给出解决方案。在失败发生后的这些诊断功能可以从Server中捕获 跟踪、内存及线程信息以便进行快速诊断并对运行时的问题进行隔离和修复...

tcServer的发布并没有出乎人们的意料，因为早在今年初SpringSource就收购了Covalent。eWeek注意到过去两年内Tomcat项目中80%的提交来自于SpringSource员工。

Spring IDE 2.2.1——SpringOne还发布了新版本的Spring IDE。

SpringSource/VMWare——可能在很多领域都会结出硕果的一个声明就是SpringSource和VMWare之间结成的新的伙伴关系。

...与VMware（SpringSource认证的解决方案合作商）的合作包括SpringSource Tool Suite（一个基于Eclipse的开发环境，使用Spring Portfolio来构建企业级应用）和VMware Workstation的集成以能够在开发者桌面上动态创建虚拟机...该合作还包括联合开发两个开源的应用服务器虚拟映像（SpringSource tc Server和dm Server virtual images），这样就可以跨越桌面和数据中心虚拟化环境来移植企业级Java应用了。 SpringSource dm Server是一个完全模块化、基于OSGi的Java服务器，因其灵活性和可靠性，它可以运行企业级Java应用和基于Spring的应用。 SpringSource tc Server是Apache Tomcat（应用最广的Java应用服务器）的企业版，它可进行企业级应用并可以处理关键任务，同时还满足了系统管理员的要求。所有这些想法都将成为 VMware和SpringSource围绕着VMware的vCloud的一部分...SpringSource Tool Suite与VMware Workstation的集成可以使开发和QA专家为不同的开发和测试场景指定虚拟服务器配置。凭借这些虚拟设备，开发者可以在不同的操作系统和应用服务 器配置上选择多种构建目标而无需额外的硬件设备。虚拟设备配置、开发和调试已经集成到了SpringSource Tool Suite中了，因此他们可以使用为dm Server、tc Server和Apache Tomcat提供的那些虚拟映像了...明年1月将发布首个SpringSource/VMware的商业产品。

正如新闻中所述，IDE和虚拟机的集成看来是2009年的路线图了。官方的VMWare workstation博客也说到此次合作并提到了之前的Eclipse集成（只是一个原型）。

Spring/Adobe——在SpringOne上，Spring生态圈继续扩张着，有两个关键的与Flex相关的声明。Prana框架正式更名为Spring Actionscript。作为此次更名的一部分，该项目获得了官方的SpringFramework.org论坛、JIRA访问及Fisheye集成。SpringSource还宣布了与Adobe的合作以集成Spring与BlazeDS：

...一个新的开源项目Spring BlazeDS Integration将为Spring和BlazeDS、基于Adobe开源服务器的Java remoting和web messaging技术提供更为紧密的集成。该集成项目将成为Spring Web家族中的一个关键组件...针对Adobe Flex的SpringSource Adapter将以Adobe® LiveCycle® Data Services ES for Adobe Flex®提供集成，这将可以为实时和接近于实时的解决方案创建基于推模式的服务端应用。针对Flex的SpringSource Adapter将成为SpringSource企业应用客户订阅的一部分...

在社区将BlazeDS集成到了Spring和Spring Security之后，官方支持终于来了。

Spring Integration 1.0——InfoQ最近曾报道过，Spring Integration 1.0已经发布了。Spring Integration支持大多数常用的传输方式，如JMS、web services、文件、RMI等等，同时还有其他选择如FTP，这是由社区通过Spring Extensions贡献的。

Spring 3.0 M1——对于2009年来说，最具影响力的声明就是Spring 3.0 M1的公诸于众。以下内容来自于Juergen Hoeller的官方博客：

• 通过基于模块的源码修正了项目布局和构建系统
• 使用Java 5编码风格更新了全部代码基（泛型、可变参数）
• 更新到JUnit 4.5和JRuby 1.1
• 引入了Spring EL解析器（org.springframework.expression包）
• 在bean定义中引入了对#{…}表达式的支持
• 为嵌入式表达式引入了@Value注解
• 为MVC处理器中URI模板的处理引入了@PathVariable注解
• 为MVC处理器中的@RequestParam引入了默认值支持
• 为MVC处理器中的HTTP header访问引入了@RequestHeader注解
• 引入了AbstractAtomFeedView和AbstractRssFeedView基类
• 引入了JSP标签

Spring 3.0需要Java 5+。Willie Wheeler已经撰写了博文，对里程碑上的声明和会议进行了综述。第一部分，第二部分。

来自Blogsphere的一些想法——Blogsphere在SpringOne上也表现的非常积极。Solomon Duskis撰写了一些博文，很好的总结了会议的主题，如tcServer、Spring DM的成熟度、Spring和JCP的继续合作以及工业上重量级公司不断加入SpringSource的演变过程。其他主题列举如下：

所有
http://springinpractice.wordpress.com/2008/12/01/rod-johnsons-keynote-address-at-springone-americas-2008/
http://www.jroller.com/Solomon/entry/spring_one_random_thoughts_and

第一天
http://www.i-proving.ca:80/space/Alec+Ho/blog/2008-12-04_1
http://ptrthomas.wordpress.com/2008/12/02/springone-2008-day-1/
http://greybeardedgeek.net/?p=66

第二天
http://ptrthomas.wordpress.com/2008/12/03/springone-2008-day-2/
http://greybeardedgeek.net/?p=71

第三天
http://ptrthomas.wordpress.com/2008/12/04/springone-2008-day-3/
http://greybeardedgeek.net/?p=83
http://greybeardedgeek.net/?p=88

第四天
http://ptrthomas.wordpress.com/2008/12/05/springone-2008-day-4/
 

为了在接下来的几年中能够模块化JDK 7，同时也为了更好地宣传JSR 294的工作，Sun打算不久之后在OpenJDK社区中创建Jigsaw项目。

该努力必然会创建一个简单、低层次的模块系统，其设计将聚焦于模块化JDK这个目标。开发者可以在自己的代码中使用该模块系统，Sun也会全力支持该系统，但它并不会成为官方Java SE 7平台规范的一部分，也不一定会得到其他SE 7实现的支持。

如果未来的Java SE平台包含了特定的模块系统，那么Sun将提供一种方式来移植Jigsaw模块以使之符合相应的标准。同时，我们还会积极地寻求与其他模块系统交互的方式，尤其是OSGi。

模块化JDK这个目标应该是可以实现的，尤其是Apache Harmony已经证明了JDK是可以被模块化的（使用OSGi）。然而这个目标却因另一个原因而变得更加有趣：它将在JCP外实现。

由于缺少可视化的发展过程，再加上闭门造车的实现，对于大多数人来说很难参与进JSR 277，更别提对其献计献策了。通常这会导致标准的误入歧途，使得标准过于关注实现的细节而忽视了通用性。不仅如此，这还会导致标准成为事后诸葛亮——想解决问题时（例如奇数的版本号）却发现已经太迟了。根据声明所述，JSR277还处于“领导地位”，但它实际已死。

从JSR277中分离出的JSR294（以前可是个庞然大物，不过现在已经模块化了）是个很大的进步；它将引入一些语言上的变化，这会使得模块化的实现独立于任何特定的模块化进程。

从声明中看到的激动人心的事情还有OSGi已经成为模块化的事实上的标准了，这种合作是件好事。但这不一定意味着它将基于OSGi实现，事实上，它只是建议最好与OSGi而不是其他方式合作：

JSR 277的JAM模块系统并不适合作为模块化JDK的基础，那么OSGi框架如何呢？该模块系统非常成熟、稳定和健壮。其核心甚至已经在Java虚拟机中实 现出来了，也就是Apache Harmony。OSGi并没有与Java语言集成，相反，它构建在Java SE平台之上而不是其中。

这最后的问题也能解决。Sun现在计划直接与OSGi联盟合作以便OSGi框架的未来版本能充分利用JSR 294的特性进而能和语言集成的更加紧密。

我相信未来的OSGi标准会使用JSR 294的模块，尽管还有一些建议的改变。不管怎么样，下周在Devoxx 08举办的Modularity in Java讲座应该会对Java的未来做出一些有趣的预言。

其中一个主要的特性是11月后期提交的对Ruby 1.9解析器的支持。正如发布说明中提到的，JRuby目前支持了Ruby 1.9中的大部分库，而在2009年第一季度会提供全面的支持 。对Ruby 1.9的支持可以通过--1.9命令行开关来打开。JRuby嵌入器可以设置版本，比如说，使用一个org.jruby.RubyInstanceConfig实例，它能够被传入JavaEmbedUtils.initialize(List loadPaths, RubyInstanceConfig config)方法。

发布说明中还提到了对于org.jruby.javasupport.JavaEmbedUtils类的改进，这个类对那些将JRuby嵌入到普通Java代码中的开发者来说非常有用。与JRuby交互会需要使用JRuby的内部API，而这些API在不同的版本中很有可能发生变化。但现在可以通过BSF或者Java 6中引入的JSR 223 hosting API来解决这个问题。使用BSF需要有BSF库，而JSR 223会把代码限定在Java 6上。但JavaEmbedUtils类可以让开发者初始化JRuby实例，调用方法，将Ruby类型转变成Java类型等等，而无需依赖BSF或者JSR 223。

发布说明还包括：

- 一份修复故障IO引用bug的列表
- 更加快速的Array.sort
- 无需解压即可在jar中运行的gem
- 将gem库存在jar中，并通过classpath来加载
- 修复两个RC过程中可测的内存泄漏
- 自从1.1.5以来的74个bug修复

修复的bug示例有：

• JIRA-3189 "java.lang.Iterable should have an each method"
• JIRA-3230 fixes Hpricot which was broken in the 1.1.5 release
• JIRA-3233 fixes a problem with instantiating Java objects with Rails 2.2.2
• JIRA-3126 "Allow Rubygems to be loaded and used from within jar files"

最后，JRuby1.1.6RC1是最近一次Ruby大比拼中所使用的JRuby版本。

Terracotta是一项Java技术，它也可以完成类似的功能。Fabio Kung已经开始了一些尝试以将Terracotta应用到JRuby上。过去他也尝试过一些类似的项目。Gemstone还尝试了在其基于Java的产品上支持JRuby，之前他们也尝试过将Terracotta应用到JRuby上，尽管没有取得实质性的突破。

我们采访了Fabio Kung以了解该项目，他称这个项目为“JMaglev”，我们想知道要想让JRuby和Terracotta协同工作需要做哪些事情以及需要解决哪些问题。

首先，Fabio谈到了他的实现以及他是如何对JRuby进行了修改以让其正常工作：

我使用了Terracotta POJO集群以便JRuby内核可被集群中的所有节点所共享。事实上，每次运行都会有一些全局变量，像下面这样：

public class Ruby {















// ...















private GlobalVariables globalVariables = new GlobalVariables();















} 

及：

public class GlobalVariables {







// ...







private List values = new ArrayList();







}

Terracotta仅仅对这个全局变量列表进行集群。对该列表的任何改变都会被复制到集群中的所有JRuby运行时。这样做的好处在于你可以将任何 ruby对象增加到该列表中，甚至连复杂的对象如regexps、hashes和procs都可以。所有的全局变量都会自动被共享，同时由全局变量所引用 的任何对象都会被Terracotta加到集群中。

为了做到这一点，我需要对JRuby进行一些修补，使其可以被“集群”。事实上，JRuby中的每个ruby对象都会维护一个ruby运行时引用。由于共 享的对象会用在很多不同的运行时中，所以JRuby必须得支持运行时的增加及删除。我可以解决这个问题，但是每个JVM上只能有一个Ruby运行时。在这 个地方仍然有一些尚未解决和需要讨论的问题，如：

——全局对象标识符：在所有节点中object_id都应该相同么？——共享的元类（metaclass）：当不同节点中的对象类、父类或者是包含的模块发生变化时怎么办？——在单个JVM上对多个运行时的支持。

对于这些问题我采取了简单的解决方法，但每种方法都需要一整篇博文才能说明白:-)

Fabio解释了他知道的一些针对JRuby和Terracotta的用例：

通过使用Terracotta的High Availability模式，我认为“JMaglev”（或许需要起个更好的名字）绝对能成为一个很棒的memcached而无需侵入Ruby代码。然 而还有很多事情需要做。这就是我将其开放的原因所在，如果大家感兴趣，都可以尽一份力：http://github.com/fabiokung/clustered-jruby/

很多服务器都可以配置在Terracotta中，其中一个服务器叫“主”服务器（或者叫活动服务器），其他的处于备用模式。这很有意思，因为一旦活动服务 器崩溃，其他的就会自动顶替上去。在Terracotta的企业版中甚至还有一种可用的模式，该模式可以开启多个活动服务器，这与memcached所做 的事情差不多，但是memcached不会持久化对象。

Terracotta可作为一个分布式缓存，同时无需Java序列化：它仅仅复制改变的东西。你只需要将想从数据库中取出的对象共享给集群中所有的节点即 可。通过使用JMaglev，你只需将他们放到全局变量中即可——$shared = Person.find(:all)。

其他可能的用例是在Rails应用中的多个进程和机器上共享HttpSession。如果将rails应用部署到JRuby中，那么可以使用透明的集群对象来维护集群中所有节点所共享的HttpSession。

事实上，任何Terracotta用例都是JMaglev用例。坦诚地说，就是因为这是可行的，我才这么做。这与Avy Briant的Maglev例子非常像：他说可以使用SmallTalk VMs运行Ruby代码，然后Gemstone的那些家伙让他证明这是可行的:-)

我希望那些比我更富创造力的人们能为“JMaglev”想出更多创造性的用例。

分布式的对象内存仅仅是Gemstone/S（以及MagLev）诸多特性中的一个；另一个重要特性是持久化。正如Gemstone的Monty Williams在最近的一个关于Rails的播客中所说，Gemstone/S支持对象内存的持久化，这意味着我们无需ORM甚至是RDBMS来存储数据。

当被问到“JMaglev”是否支持类似的功能时，Fabio说到：

所有共享的ruby对象都位于Terracotta服务器中，而Terracotta服务器能自动地持久化这些对象，即使他们不 是序列化的也可以。客户端持有这些真正的、共享的对象的桩（stubs）。你只需将服务器配置成持久化模式即可。我还没有测过，但这需要在XML配置文件 中增加一行。

我认为Terracotta可作为一个面向对象的数据库以持久化JRuby对象，但我觉得这不是目前最主要的目标。Terracotta现在可以通过其 High Availability模式来持久化共享的对象，这存在于fail-safe-high-available部署中。http://www.terracotta.org/web/display/docs/Configuring+Terracotta+For+High+Availability。

Terracotta的站点上列出了很多Terracotta集成模块（Terracotta Integration Modules，即TIM），其中一些面向的是流行的ORM解决方案。当被问到这是否有助于持久化时，Fabio说到这些TIM的目的是不同的：

这些TIM并不涉及共享对象的自动持久化。他们仅有助于Terracotta与这些ORM框架的协作。例如，hibernate TIM与持久化没有任何关系。它仅仅是简化了Hibernate对集群的（分布式的）EhCache（以及其他）的使用而无需真正的分布式缓存，如 JBoss TreeCache和memcached。

Fabio展示了JRuby与Terracotta是如何协作的。要想尝试一下，请参考Fabio在Github上的clustered-jruby仓库，它提供了你所需要的所有内容。

Rubinius引入了自己的Foreign Function Interface（FFI），它与Ruby/DL非常像，尽管FFI的API看起来有些不同，对于类型签名来说，它使用了Ruby符号和排列方式而并没有采取C代码的方式，也没有使用Ruby/DL中所用的客户化类型格式。

早在今年初，构建于JNA之上的jruby-ffi就已经发布了（JRuby不支持Ruby/DL）。

虽然对Rubinius和JRuby提供了支持，但在使用MRI的Ruby世界中还是有很多地方依然在使用Ruby/DL或其它方式来使用共享库。为了解决这个问题，Wayne Meissner（已经创建了jruby-ffi）创建了ruby-ffi项目，它现在提供了相同的FFI接口，就像Rubinius之于JRuby、Ruby 1.8.x及Ruby 1.9.x.一样。通过ruby-ffi，我们可以跨越所有这些Ruby实现以相同的Ruby代码来访问共享库了。

Ruby FFI 0.2.0已经发布了，可以通过gem install ffi进行安装。你可以在其项目的wiki上查看相关的文档，这些示例是很好的入门材料。Charles Nutter对FFI的使用进行了更详尽的说明并给出了一些例子。

Spring 通用的方法拦截

带有附加功能或免除单元测试需要的第二代工具正在研发当中，包括.NET4的Code Contracts和自主研发的NStatic。

托管代码并不是唯一获得关注的领域。Ubitsoft公司正对T-SQL应用相同的技术。随着数据库增长，封装在T-SQL中的业务逻辑数量变化相当明显，有时候甚至在重要性方面胜过普通代码。要协助管理这一情况，Ubitsoft公司创建了SQL Enlight。我们就此和他们的开发主管Iliyan Stoyanov进行了沟通。

这是个相当新颖的产品，你可以给我们一些关于SQL Enlight如何诞生的背景吗？

我们设计SQL Enlight作为T-SQL管理和反射工具，但由于我们需要更多的时间来实现心中的所有想法，所以决定先发布T-SQL重格式化功能，稍后逐步来添加新功能。

你决定对Transact-SQL脚本分析提供支持是基于哪一点考虑呢？

从本项目开始，该分析功能就是我们其中一个目标，但我们决定推迟它的发布，直到我们完成T-SQL语法分析器扩展为止，它支持新的SQL Sever 2005 T-SQL语法。

你如何决定给分析添加哪些规则呢？

我们实现的分析规则基本上来自互联网找到的提示和实践，或者来自SQL Enlight用户提交给我们的分析规则请求。

你们的技术支持提到过你正研发一个新版本，它会对整个数据库进行分析。可以给我提供一些关于它的信息吗？

是的。我们正研发新的1.6版本，它将是我们SQL Enlight1.x版本的里程碑。该新版本会包含两项重要特性——创建自定义分析规则功能和支持在数据库上运行分析。我们也打算包含命令行工具和MsBuild任务。

SQL Enlight当前版本支持这些分析规则。

设计

• 包括NULL常量在内的相等和不等比较
• 非ANSI外部联接语法
• 非ANSI内部联接语法
• 过时的语法，字符串_别名=表达式
• 在执行数据操作语句（像INSERT/UPDATE/DELETE)之后，使用TRY..CATCH结构或者检查该@@ERROR变量
• 在存储过程、视图和表值函数中支持SELECT *
• 使用SCOPE_IDENTITY()替换@@IDENTITY
• 支持ORDER BY子句中使用常量已经过时
• TOP子句用在不带ORDER BY子句的查询
• 在INSERT语句中总是使用列的列表
• 反对不带WITH关键字的表提示用法
• （聚集或非聚集）索引类型未指定
• 避免使用GOTO语句来改善可读性
• 考虑使用括号来改善可读性和避免由于逻辑操作符的优先级导致的错误。

命名

• 在命名函数的时候避免使用“fn_”前缀
• 在命名存储过程的时候避免使用“sp_”前缀

性能

• 变量@variable已声明但从未使用
• 变量@variable已使用但之前未分配
• 变量@variable已分配但其值从未使用
• 在LIKE谓词中以“%”开始的模式
• 考虑使用表变量来代替临时表
• 在触发器中避免返回结果
• 使用非常小的变量长度类型（大小为1或者2）
• 在存储过程和触发器中使用“SET NOCOUNT ON”选项
• 在WHERE子句中避免使用不等操作符（<>,!=）
• 本地游标没有关闭
• 本地游标无明确释放
• 本地游标引用无明确释放
• 在WHERE子句的函数中避免封装过滤列
• 可以从WHERE子句中提取确定性函数调用，避免不必要的表扫描
• 输入参数从未使用
• 输出参数从未赋值
• 在WHERE子句中避免使用“NOT IN”谓词
• 不要使用不带聚合函数的“GROUP BY”子句

云计算不仅是这次大会的一个热点，也是2008年技术领域的热点，以Google为代表，微软、IBM以及国内的安全厂商如趋势、瑞星等都将自己的产品和“云”联系在一起。在谷歌中国工程研究院副院长和工程总监幺宝刚的“共同打造云计算时代的开发网络平台”演讲中，他特别提到Google云计算的网络平台全部是开源和免费的，而且从后台计算到前台展现以及开发云计算应用的语言和工具都提供了相应的产品：

要实施云计算，后台的计算能力必须得到提升，要使得提供给开发商的API得到迅速响应，Google的App Engine即是为了解决这一问题；另外在前端的展现上也要流畅，这样云端的强大功能才能体现出来，为了解决以前浏览器执行JavaScript脚本速度 慢的问题，Google提供了自己的Chrome浏览器，特别通过其V8渲染引擎优化JavaScript的解析速度；而为了达到用户能随时随地访问互联 网服务的目的，Google又推出面向手机和移动设备的操作系统Android；最后，Google还提供对脚本语言Python的支持，提供方便进行 Web应用开发的GWT，而且都以开源的形式提供。

相比于Google的开放特性，微软依然是在自己现有的产品上进行改良优化，提供基于云端的服务。微软中国平台与开发合作部平台策略首席顾问赵立威就提到，云计算的出现不是对原有开发模式的终结，而是给个人和企业应用提供一个新的选择，他特别强调了微软为适应云计算而推出的操作系统——Windows Azure：

（Windows Azure）是基于微软数据中心网络的操作系统，构成了将来微软云计算服务平台的最底层核心，它提供最基础的计算、存储和管理能力。基于这样一套操作系 统，不管你的应用、业务系统将来运行在哪里，只要在Azure上面，就能享受包括升级在内的不间断服务，帮助提供基于云端的强大的计算处理能力。在 Windows Azure底层架构上面，微软提供了SQL服务、Live服务、.NET服务、SharePoint和动态CRM等5个服务。

如果说Google和微软对云计算还停留在宣传阶段的话，Amazon则已经趟出了自己在云计算领域的商业模式，其EC2和S3已经为众多厂商提供数据存储服务，而且价格不菲。在Amazon Web服务推广部高级经理和云计算战略师Jeff Barr的演讲中，他简明点出未来云计算的方向：

未来云计算会怎么样？只要你上了线，全世界都是你的服务器。你可以将你的时间更多地放到自己的服务和创造性上，你的未来会越来越光明。

在云计算概念出来后，虽然SOA已经不如前几年那么火热，但是在企业应用领域，它依然是个绕不开的话题。对于目前SOA的发展，普元软件首席架构师焦烈焱认为SOA已经进入大规模实施阶段：

SOA已经进入实用阶段，不管是企业集成厂商还是企业软件客户，对于SOA概念已经逐渐接受，因此更多的企业忙于对SOA进行实施和实践，而无心再进一步进行市场推广。

Oracle公司全球研发中心副总裁Frank Xiong在其“互联网创新与企业级应用新模式”演讲中，也提到在未来一段时间内，SOA依然会继续影响企业级应用市场：

我基本上可以判断，将来一定会有一批专业的软件公司，会专注在开发各种小的服务的模块。而把这些模块商业化，再卖给其他要组成这 些软件的公司，比如说你的帐单可以是SOA，或者帐目管理也是SOA，顾客管理也是SOA，这些SOA的服务都有共同的特点、共同的开发的层面，所以说会 很快被商业化。

不论是Salesforce的SaaS，还是微软的S+S，软件即服务（Software as a Service）对整个软件产业的进程已经起到了变革的作用。通过SaaS方式，Salesforce本能的年度收入已经突破10亿美元。在国内，阿里巴 巴下属软件公司阿里软件也在朝这一方向努力，希望能够为国内中小企业开发商提供SaaS平台支持。阿里软件研发中心总监叶伟在其演讲中，提到了SaaS对终端用户、开发商的好处，以及目前SaaS面临的难题：

对用户来说，SaaS的价值第一是按需付费，用多少买多少；第二是免除了安装维护的费用；第三是先天性防毒；第四是随处可用。而 对软件开发商来说，SaaS的价值第一是没有盗版问题；第二是借助于互联网，产品推广的成本很低；第三是维护的成本很；第四，也是最重要的一点是客户是可 积累的，续签率非常高。对于多租户情况下的SaaS，其不足之处一是要满足高性能，二是要满足高个性化，三是目前的基础设施还不够完善。

注：本文引用部分均非演讲者原话，为记者根据CSDN网站所提供的视频整理所得！

Ruby on Rails（ROR）是一个基于Ruby的用于快速Web应用开发的开源框架。Rails和RIA社区目前都在积极地寻求两者的集成方案，而Flex框架Ruboss就是这样一个成果。InfoQ采访了Ruboss的联合创始人及CEO Peter Armstrong以更深入地了解该框架。

根据Armstrong所述，Ruboss框架是一种尝试以简化Flex应用和RESTful服务器端框架的集成。现在这些框架包括RoR和 Merb。Ruboss还提供了一个RESTful 接口以使其可以与Adobe AIR的嵌入式SQLite数据库进行通信。 Ruboss框架之于Rails和Merb的关系就好象Adobe LiveCycle Data Services ES之于J2EE应用的关系。

当被问到为何不利用现有的一些框架，如Cairngorm或PureMVC时，Armstrong解释到：

他们太简单了，无法满足我们的需要。Ruboss框架的架构与Cairngorm、Mate及PureMVC都不同。它是一个数 据集成框架，专注于Flex与RESTful框架的集成。把Ruboss看作是“Flex + Rails”是很不错，但更加贴切的描述应该是“Flex + 简单的RESTful CRUD”，其中Rails只是最流行且目前集成的最好的一个框架而已。

我们所需要的东西应能无缝地集成Flex和RoR并且会将Rails开发上的一些设计原则和生产力带到Flex中。我们觉得Rails是最具有生产力的服务器端框架之一，而Flex是最好的客户端RIA技术之一。因此，自然而然地我们想将这二者结合起来。

因此，我们真的没有与Cairngorm、PureMVC或Mate进行竞争。例如，虽然你所编写的Flex代码会以类似于Cairngorm的方式（它 通过命令模式对使用进行了简化）去使用Ruboss，但你还可以用比Cairngorm更简洁的方式去使用Ruboss。

Armstrong继续谈到Ruboss一些独特的特性：

首先，我们是唯一一个将RESTful CRUD作为通用接口的Flex框架，这一点与Rails、Merb及AIR中的SQLite是不同的。这种简化、优雅的设计使得大家可以对Ruboss 框架进行扩展以支持目前我们尚未提供的一些服务。例如，Ruboss的使用者可以将其连接到CouchDB上。因此，Ruboss就可以对服务进行扩展以 达到与Flex的完美集成。

其次，你使用Ruboss编写的代码不仅对传输方式来说是抽象的，而且还非常简单和优雅。第三，你可以快速上手并运行起来。通过使用Ruboss，你可以 在5分钟内创建一个完全的Flex+Rails应用。没有任何Flex框架能做到这一点，也没有任何Flex框架可以让你在这么短的时间内就完成从数据模 型的编写到应用运行的整个过程。想知道怎么做吗，看看Ruboss“pomodo”指南吧。

最后，我们认识到没有任何一个框架能满足所有的数据集成需求或是解决所有应用的架构问题。因此，我们所做的就是尽力解决那80%的常见问题。

Armstrong又谈到了Ruboss框架的路线图：

对于该框架来说，我们打算在本地和远程服务提供商之间增加数据同步支持，因为目前这是应用开发者必须要自己解决的问题。我们还打 算将对Merb+DataMapper的支持提升到Merb+Active Record上来。这之后，我们会考虑扩展Ruboss以支持更多的服务，如SimpleDB及Google AppEngine。

Peter Armstrong还是Flexible Rails一书的作者及Hello! Flex 4的主要编写者。

Envers是一个来自于JBoss的开源项目，致力于提供简化版的持久化JPA类。InfoQ曾经在2008年七月报道过其首个GA版1.0.0的发布。随后，Envers 1.1.0提供了若干新的功能。

1.1.0版的主要关注点在于增加了对持久集合的支持。Envers的创立者Adam Warski描述了这个新的功能：

现在你可以版本化任何关系、“简单”类型的集合以及映射等。现在支持所有JPA定义的集合映射，而且其中大多数的集合映射在Hibernate中也是支持的。

最新版本还包括了其他一些改进和错误修正，以及更新的demo。在Envers的持续改进中，又出现了别的新闻。2008年10月30日，Envers正式成为Hibernate的一个模块。Envers的网站、文档和论坛在今后一段时间内会保持原地址。Adam Warski在博客中列举了主要变化：

• 代码现在存于hibernate-core存储（envers模块）。不会再对旧的存储库提交代码。
• 问题跟踪迁移到Hibernate的JIRA上。所有公开的问题都已经移到了那里。
• Envers现在使用maven2构建，替代了过去的ant。

这对于Adam Warski和Envers的其他贡献者来说是一个激动人心的时刻，迁移到Hibernate家族将会继续Envers的模块开发，并成为开发者在持久化Java对象时必不可少的利器。

“在Sun内部，核心Swing正在作为一种UI的技术遗产而逐步退休，上周则是记录了一个伤心的（不过也可以预料的）里程碑——停止资助SwingX项目。”

“这明显失去了外部参与者的信任，他们再也不会回来了，甚至是Sun内部开发人员也退出了这个项目。”

Krill同时对JavaFX持严重怀疑态度：

我不知道JavaFX未来会怎么样。Sun在这上面压了太多赌注，没有人想把他们的活动时间永远留在互联网上。我所知道的 是，JavaFX已经明显的阻碍了所有核心Swing的开发。在过去18个月里，我们看到重大的架构提议（JSR 295和JSR 296）换了负责人并被冻结。Java 6 Update 10中的Java 2D、AWT和Swing方面的所有面向客户的改进都是为了满足JavaFX的需要。

与JavaFX关系密切的Sun高级工程师Josh Marinacci在随后的帖子中指出上面的这种担忧是不成熟的，SwingX和SwingLabs会继续前进，Swing开发人员会从Java SE 6 Update 10和Java 7中获益：

作为一个终身从事Java客户端的开发人员，我对Java的现状非常满意。Java客户端应用正在变得更快、更稳定、更易 于开发。这对Swing和 JavaFX应用都是如此。JavaFX 1.0版目前处在调整中，我相信当你看到我们的工作成果之后，你会很开心。这对于一个Java平台上的GUI应用开发人员是一个激动人心的时刻。

Sun依然公开支持JavaFX。在Adobe的MAX会议上，Sun重申JavaFX桌面1.0版将在12月初 发布（目前已经确定为12月4号），JavaFX移动和TV版会在2009年第一季度发布。此外，Sun在过去一年里积极招聘工程师从事JavaFX开发 工作，包括来自苹果公司和Adobe公司的人员。但事实上软件对Sun的贡献很少。Sun在2009财年第一季度的全部软件收入为12400万美元，而存 储收入为50700万美元，服务器和其他系统收入为124600万美元。Sun事先没有通知个人而宣布裁员大约6000名员工，这肯定会引起Java社区 包括 Sun内部人员的忧虑。对于那些致力于Java和Swing开发的人员来说，Sun对Java 7中Swing的计划缺乏透明度才是一个真正的问题。

　　谷歌新服务器农场最初将雇佣50-100名员工。

　　服务器农场中安装有大量高性能服务器，满足互联网用户对数据的需求。除了需要充足的电力外，服务器农场还需要充足的水源对计算机设备进行冷却。

　　查询数为总共发送的query个数，失败查询数为非正常返回的结果（可能被封禁了）。结果数是从抓取下来的页面中解析出来的结果个数（包括竞价 拍名结果），结果中广告是搜索引擎根据竞价排名，嵌到正常结果中间的结果。赞助商结果是指在正常结果上面的一些广告，而右侧广告是指在搜索结果页右侧的非 搜索结果。

百度、谷歌、有道三者所包含的竞价排名数量，其中，谷歌和有道包含数为0

　　敬请区分赞助商链接和竞价排名的区别，我们在批判的是竞价排名（混淆在搜索结果中的广告），而非赞助商链接。

（点击看大图）

　　点击这里可以下载这个小软件，不过我不太会用Python脚本，如果你会的话，可以自己用了试试看。