关于Beehive的讨论 Apache Beehive开放源代码项目

5月19日，BEA宣布计划创建一个称为Beehive（蜂巢）的开放源代码项目，该项目基于WebLogic Workshop应用框架并且“计划成为业界第一个易于使用的，用于构建面向服务的架构（SOA）和企业Java应用程序的开放源代码基础。”5月25日，BEA接着与Apache软件基金会共同宣布，Beehive成为Apache社区的一部分。为了让更多WebLogic开发人员了解Beehive的意义，Cliff Schmidt——BEA的WebLogic Workshop标准策略的产品经理，接受了记者的采访。
问：首先，“标准策略的产品经理”的确切含义是什么，它如何与Beehive开放源代码项目相联系？
Schmidt：BEA有一些人员紧密围绕公司的标准策略工作，这包括在诸如OASIS、万维网联盟（W3C）以及Java Community Process（JCP）这样的组织中开发的标准。这个团队的大多数成员在CTO办公室工作，但我是从事一个特定产品组WebLogic Workshop的成员之一。标准策略主要关注的是确定技术协作的最佳点，这种协作是在一组行业供应商、客户、竞争对手和合作伙伴之间以一种鼓励创新的方式进行的，同时提供跨厂商的兼容性。我们的工作主要包括确定WebLogic Workshop应该参与的已有标准，而且更为重要的是确定当作为新的工业标准的基础使用时，哪些Workshop创新应该更好地适应我们的客户。可以有多种方式开发工业标准——通过正规的标准组织，通过竞争对手之间的协作，以及通过开放源代码社区。通过开放源代码社区通常比一个标准组织更快地达成一致。为了在目前的WebLogic Workshop应用框架的创新方面取得业界的一致，我们启动了Apache Beehive项目，因为我们相信这样做将会更好地服务我们的客户，实际上是整个企业级Java社区。

问：Apache Beehive是什么，它是如何与WebLogic Workshop相关联的？
Schmidt：Beehive是一个开放源代码的软件项目，它为基于J2EE和SOA的应用程序提供第一个跨容器的、易于使用的编程模型和应用框架。它基于Workshop应用框架；并不包括集成开发环境（IDE）。Beehive具有三种主要的组件：控件、NetUI（以前称为Java页面流），以及Java Web服务。每一组件都在相应的侧栏中有详细解释。

问：对于WebLogic Workshop用户来说，Beehive意味着什么呢？
Schmidt：下一个版本的WebLogic Workshop运行时将基于Beehive框架。这将允许基于WebLogic的实现和任何其他支持Beehive框架的实现（如Tomcat）之间的可移植性。但是Beehive还向当前版本的WebLogic Workshop 8.1用户提供一个可移植性选项。正如今天利用Workshop 8.1编写代码的用户将能够移植它们的代码到WebLogic平台的下一个主要版本中一样，用户可以将今天的代码移植到Beehive平台。这意味着，即使今天，BEA的客户可以从开放源代码的、跨平台的Beehive框架所提供的投资保护中受益。
问：最近我们见到很多情况下使用“投资保护”一词，当您提到投资保护时确切地含义是什么呢？
Schmidt：当客户花费开发时间创建依赖于某些其他技术的应用程序时，我会提到客户所做出的投资。如果客户并没有被锁定到单一厂商从而继续使用他们的投资的话，那么他们在开发应用程序和相关技术培训上的投资是受到保护的。这个思想就是我们希望客户继续购买WebLogic平台，因为它是解决他们问题的最好解决方案，而不是因为他们已经被欺骗到该平台上。
问：在Beehive框架组件和其他技术之间已经有一些比较，例如NetUI对于Struts，Java Web服务对于JSR-181，以及控件对于EJB 3.0。您能够对于这些比较做出评论吗？
Schmidt：NetUI实际上是构建于Struts之上的。并不是重新发明一个新的模型－视图－控制（MVC）框架，NetUI使用Struts框架，但是将Struts的配置文件增强为一个单一的“页面流”文件，然后增加额外的功能，例如状态管理和异常处理。Beehive的Java Web服务组件实际上是JSR-181规范的一个实现。实际上，我们正在期望它能够与Tomcat是Java servlet和Java服务器页面（JSP）规范的参考实现（RI）一样，将成为规范的参考实现。同样和Tomcat一样，它并不限制沿着该路线进一步发展；但是对于现在来说，其目标是构建一个Java规范请求（JSR）的实现。最后，EJB 3.0通过使用基于JSR-175的注解更容易地向EJB的作者提供能力，而Beehive框架同样也使用了基于JSR-175的注解。但是，控件设计用于提供一个简单的和一致的客户访问模型，该模型跨越任意数目的异构的后端资源，并且结合一个轻量级的组件模型，以便处理诸如事件通知、生命周期管理以及配置等事情。控件可以帮助您调用EJB，但是控件肯定不是EJB。
问：NetUI是与Java Server Faces（JSF）竞争吗？
Schmidt：根本不是！JSF只是可以在NetUI MVC体系结构中使用的另一种内置视图技术。例如，JSF页面可以通过集成到JSF NavigationHandler层中，从而触发页面流活动。而且，我很自豪地宣布，Craig McClanahan，作为JSF规范的领导者和Struts项目的创始人，他已经很大方地自愿成为Apache的发起人和Beehive项目的指导者。他暗示着，我们正在认真地补充Struts和JSF。
问：在Beehive中，哪些控件正在开放源代码？今天，在Workshop中没有多种类型的控件吗？
Schmidt：最初，正在开放的是完整的控件框架源代码。这允许开发人员创建一个特定领域的控件，以支持它们所选择的资源。我们正在计划帮助创建几个特别常用的控件，例如数据库控件。然而，其目标是让社区构建更多的控件，而不是让框架提供正规的集合。
问：这与在eWorld期间BEA关于Workshop Control Pack的声明相关吗？
Schmidt：没有。Control Pack是一个已包装的、免费使用的和开放源代码的控件集合，其目标是使得访问诸如Amazon、eBay、Federal Express、Google、PayPal和UPS等公司所提供的服务更为容易。这些控件最初都是针对已有的控件框架，该框架是Workshop 8.1一部分。然而，我认为只要Beehive发布一个相对稳定的构造，或者可能更早，在Control Pack中的许多控件就会被移植到Beehive中。

问：您在前面提到JSR-175，它是如何与Beehive相关联的，可否告诉我们更多的信息？
Schmidt：作为Java源代码中关于元数据注解的JSR，JSR-175提供一个方法以允许标准化的声明性编程语言，正如在Beehive中所使用的。该JSR在2002上半年首次被提出，正好在BEA启动JSR-181之前，而JSR-181需要一个在Web服务领域中使用的标准化的元数据格式。元数据注解用于简化企业Java编程的潜力通过Workshop在2002年的初次发布中得到证明，并且引起诸如xdoclet等工具的兴趣。JSR-175所启用的标准化声明性编程模型思想对于所有Beehive组件来说，是一个通用的关键性主题。尽管这个新标准接近可以使用，但是BEA对于元数据驱动的编程模型，已经具有三年的工作经验。Beehive是将该经验与更广泛的社区共享的一个尝试。
问：为什么将Beehive框架指定在Tomcat上呢？它能运行于任何其他平台上吗？
Schmidt：Beehive被指定在Tomcat上运行，主要因为它是Java servlet引擎的参考实现，并且是可以使用的最为流行的servlet容器实现。这意味着任何J2EE应用服务器也都将能够在其兼容的servlet容器中运行Beehive框架。BEA WebLogic服务器还可能在EJB层内支持运行Beehive应用程序，并且我期望开放源代码的开发过程将导致其他EJB容器也做同样的事情。
问：Tomcat开发人员可以使用Workshop IDE构建Beehive应用程序吗？
Schmidt：是的。下一个版本的WebLogic Workshop将会是开发Beehive框架代码的优秀工具，不管它是被部署到WebLogic Server、Tomcat，还是任何其他兼容的servlet容器中。
问：Beehive对于Eclipse是一个竞争性举动吗？
Schmidt：绝对不是。Eclipse基金会、Instan-tiations和BEA联合发布与Apache Beehive计划向集成的Eclipse项目——Eclipse Pollinate。Eclipse提供开发环境，Apache Beehive提供基础应用框架和运行时服务，以帮助有经验的开发人员更省事地设计出更完善的应用，同时帮助那些刚刚开始使用Java的开发人员更快地提高生产力。另外两家公司Soaring Eagle和Genuitec，也宣布计入Eclipse Pollinate计划并提供编码基础。
问：Beehive项目是否显示BEA已经改变它对于JCP的看法？
Schmidt：BEA仍然致力于参与JCP。然而，我们意识到与开源社区的合作是另一个标准化的途径。它允许我们参与到一个高水平的用户群中，以验证我们已经具有解决问题的最佳方法并且在可以得到增强的领域中与社区共同工作。从社区获得对于运行代码的思想、贡献和反馈，对于改进我们的平台以满足客户需要带来的影响是无法估价的。在某些情况下，开放源代码项目在已经取得超过一个JSR通常所具有的更大程度的业界认同时，可能最终领导一个JSR。JSR-166，J2SE的对应工具，本质上是一个开放源代码库的收集，该项目是由Doug Lea和其他人所构建的。JSR-241，Groovy动态编程语言，是另一个通过实现进行思想领导从而导致一个下游规范的例子。当然，在某些情况下，一个开放源代码项目可能成为一个事实上的标准，而不会成为一个JSR——Struts可能是这种情况的最好实例。关键是BEA认为开放源代码是另一条取得业界认同、开发人员采用并且最终保护我们客户投资的途径。BEA将继续参与JCP和各种开源社区以帮助推动我们的创新成为业界标准。
问：为什么BEA将Beehive提交给Apache？
Schmidt：在改进Workshop运行时从而运行在一个标准servlet容器上的过程中，我们自己发现使用Apache产品的数目逐渐增多，例如Tomcat、Struts、Axis、Velocity、Ant，以及XMLBeans。尽管为Beehive配置相关产品的机会是因素之一，但是对于我们来说，更为重要的是Apache社区的状态。Apache Software Foundation（ASF）已经吸引一大批有卓越才能的和专业的人员。我们不仅期望Apache社区的成员帮助我们贡献一些重要的思想，甚至期望他们为该项目编写代码。我们还知道ASF和BEA在鼓励一个自我发展的社区，与其他组织协作，并且创建一个适当的合法框架，以支持可靠的开放源代码开发各方面所具有许多的相同利益。在去年大多数时间与Apache社区在XMLBeans项目上共同工作时，我们已经观察了所有上述提及的方方面面。
问：在从事Apache XMLBeans项目时您清楚地了解到什么呢？
Schmidt：由于XMLBeans是BEA在Apache的第一个开放源代码项目，我们学到了很多。当然，我们学到了在开源社区开发我们的部分产品时相关的许多善后问题，但是我们还学到了在围绕一个项目构建用户和开发者社区时需要做的许多工作。它确实需要很多关注。您不能只是具有正确的态度和一个开放的头脑，就会期望理想的协作情景将会奇迹般的发生。您确实必须付出额外的努力，使得它对于不熟悉项目的开发人员来说，更容易地理解体系结构并发现他们如何能够参与并且做出有用的贡献。对于XMLBeans项目，我们后来在这方面做了更多工作，而对于Beehive，我们将从一开始就关注这个方面。
问：Beehive与XMLBeans的关系是怎样的？
Schmidt：与Workshop利用控件、Java Web服务以及页面流无缝集成XMLBeans的方式相同，Beehive将提供类似的集成。然而，XMLBeans可能继续驻留在Apache的XML项目联盟中，而不会包含在Beehive中。
问：对于BEA来说，具有一个Apache开放源代码项目意味着什么呢？
Schmidt：BEA永远不会声称“具有”或者“拥有”一个Apache开放源代码项目。BEA所做的是授予ASF初始Beehive代码库的一个许可证；但是更为重要的是，BEA已经承诺大约十多名工程师与Apache合作开发Beehive项目库，并且围绕它构建一个自我发展的用户和开发者社区。设计和开发Workshop框架的工程师们正在全心致力于Apache Beehive取得成功。作为项目的提交者，他们是团队的一部分，负责开发、测试和文档化Beehive项目。BEA也积极参与Beehive项目管理委员会负责给出总的方向、优先级和发布计划。这个完整的过程是在Apache孵化器中开始的。
问：Apache孵化器是什么？
Schmidt：Apache孵化器为所有新的Apache项目，例如Beehive，提供一个入口路径。孵化器是一个支撑性的环境，新的项目在该环境中提升它们的工作并且成为一个Apache项目，同时它们设置相关的Apache基础设施，并且确保在初始代码库中没有法律性的问题，例如与Apache许可证的不兼容性。然而，孵化器的另一个同样重要的目的是鼓励新的项目构建它们自己的社区，同时还与其他Apache项目共同工作（以及向其他项目学习）。这确实是ASF在去年工作的一个领域，它帮助启动新的项目，以及保护ASF的法律的和社会的完整性。
问：参与Beehive项目的方式是什么？
Schmidt：有多种方式，从简单地使用产品并且提供反馈、错误报告和回答其他用户的问题开始。作为另一个步骤，您可以提供修复错误的补丁或者提供额外的功能；并且如果您对于编写代码不感兴趣的话，这里总是存在对于文档、实例代码和指南的巨大需求。利用控件框架，您可以开发一个定制的控件，然后将它提供给社区中的其他人使用。最后，在一系列对于项目的贡献之后，您可以被提名成为项目的提交者之一。
问：到目前为止，对于Beehive的反应是什么呢？
Schmidt：比我想像的要积极得多——当然我是一个非常乐观的人。尽管我很高兴地看到非常赞许的新闻和分析家评论，但是我真正感到兴奋的是来自BEA客户和Apache社区的反应。这两个团体已经令人难以置信地积极响应。在我们最近的eWorld会议上，我们无法告诉您有多少次客户对我说，Beehive产生一个巨大的差异，使得他们非常容易地向老板证明在Workshop上构建应用程序。许多人告诉我，他们已经认真考虑使用Workshop，但是如果它基于一个私有的运行时环境，他们将不会投入。现在Beehive是开放的并且可以用于多种平台，对于锁定的担忧就完全消失了。从Apache社区，我也得到了相同的积极反应。
问：开放源代码的Beehive对于WebLogic客户的优点是什么呢？
Schmidt：我将谈及它诸多优点中的一些。首先，最明显的优点是WebLogic客户不再必须为生产力而牺牲产品的可移植性。WebLogic Workshop 8.1已经赢得无数的业界大奖，包括PC Magazine的市场最佳开发工具大奖。现在，客户继续从Workshop提供给他们的生产力中获益，而不用考虑某一天他们可能需要痛苦地移植到其他环境中，并且代价昂贵。其次，使用Beehive/Workshop运行时的社区成员正在显著地增加；这对于该框架的用户来说是一件好事，因为这意味着与更多的人共享问题、技巧、经验和最佳实践。最后，WebLogic客户将获得这两个世界中的最好的东西。Beehive框架将根据BEA和Apache已经提供的最好的思想而演化，而且，整个WebLogic产品线将提供利用Beehive框架的最佳途径（因为BEA建立在该框架上已经有三年时间了）。
问：BEA将为Beehive提供支持和保障吗？
Schmidt：BEA为我们所有的产品都提供客户支持；包括开放源代码的组件也不例外。这种情况的一个实例是BEA为Workshop的NetUI/Java页面流的商业最终用户提供支持的方式，即使它是位于Struts之上的。我们支持完整的产品，包括产品所依靠的基础。BEA还会为侵犯第三方版权声明而赔偿客户的损失，这是许多公司认为对于它们的商业所依赖的任何软件来说是至关重要的。然而，我不是一个律师，并且如果您对于BEA所提供的细节感兴趣的话，可以查看我们的许可证条款。
问：最后一个问题：为什么取名为Beehive？
Schmidt：我并不是提出这个名字的人，但是我相信灵感是来自于一个大的社区所构建的健壮的框架，它们在一致的结构上协同工作。
问：对于我们的读者还想说些什么呢？
Schmidt：不管您只是希望窥视一下，还是尝试一下我们正在从事的工作，还是积极参与该项目，请您访问Apache Beehive Web网站http://wiki.apache.org/incubator/BeehiveProposal。在这里，您可以获得最新的项目信息，订阅开发或用户邮件列表，甚至是同步最新的源代码。