本文为了适应时代精神而进行了一次不太典型的尝试，我建议稍稍背离一下我们已经熟悉的事务管理器来看一看框架。同样，我希望您能够猜出我将要分析什么样的特殊框架。
因为几乎只要有微处理器存在的地方，就有框架的存在。J2EE应用服务器可以说是框架，同样，消息传递系统或者甚至是操作系统都可以被称作框架。同时，可以轻松地得出这样的论证：框架是软件中成功实现重用这一神圣目标的惟一组件。虽然真正可重用的商业逻辑实例仍然很难确定，但框架却有很多（尤其是当您接受我对框架的定义，即框架包括应用服务器以及诸如可看作比构成广泛采用的商业产品（比如BEA WebLogic Server）的代码更具可重用性的一些东西）。
框架是存在于各层中的实体，每个框架负责一些存在于其架构层中的一般问题，从而对位于高层的客户提供更高的抽象层。例如，应用服务器负责诸如线程及套接字管理等低层的技术问题，从而使得使用组件的程序员能够将其精力更多地集中在他或她所尝试实现的业务功能上。
尽管应用服务器如此高效地提供了更高的抽象性，然而就我所知，每台应用服务器都有相当多的客户并不仅仅是运行项目；这就导致从底层创建的EJB及servlet需要实现一些业务功能。在几乎所有的情况中，应用服务器客户已经自己编写了一个框架，然后他们的应用程序开发人员编写存于那个预定好的框架中的代码。通常，这些框架执行诸如从集中的企业存储库中读取数据等任务，来完成对静态引用数据及业务规则的配置。在多数情况下，框架同样限制了向应用程序开发人员提供的自由度——J2EE向其用户提供了可作出许多架构决定的能力。我的逻辑是在servlet中还是在EJB中？EJB是一个会话bean还是一个实体bean？会话bean是有状态的还是无状态的……诸如此类的选择还有很多。这些选择为解决广泛存在于服务器端的、逻辑型问题提供了功能强大的工具集，然而百分之八十的情况下应用服务器客户试图解决的问题并非广泛存在。许多应用程序采用非常普通的标准使用模式。这些模式驱动J2EE使用模式的常用集，或者至少它们应该如此。通过向应用程序开发人员提供功能强大的工具，您已经迫使他们能够正确作出诸如怎样最佳地利用其工具集等决定。
富有经验的J2EE架构师团队的商业价值是什么？为什么您需要配备能对这些难于决断的问题作出决定的人员？而且，您将如何留住他们？如果他们花费大量时间来解决从技术角度来说非常相似的问题，他们将有可能寻找另一份的工作——（“拥有极具智慧的头脑，我却在这里泊车”）或者将花费大量时间来作白日梦并且编写出对您而言也许并不需要的或不能从中获利的新框架。即使您所处的状态是拥有专家团队并且他们非常遵守纪律，并且没有进行架构方面的冒险活动，但是您所拥有许多极具才华的个体，他们做他们自己的事情、追求他们自己的目标，将不可避免地导致代码风格的多样性以及实践中的变化性；这在下一代程序员试图维持生产中J2EE业务应用程序的价值并且顺利运行业务时将会导致维护成本的上升。在生产中，规则性和一致性是您的朋友！
所以，需要框架（并不仅仅是使大师高兴！）向开发人员提供一致性以使“普通人员”也能够实现高生产效率而不仅仅是超级英雄才是如此。然而，大多数应用服务器客户在他们预定的框架中将会发现潜在的危险。当他们招募新的团队成员时，这些个体并不能立即就有产出——他们被聘用的开始几周将被用来解决他们将要在其中工作的预定框架的问题。不可避免地，由于缺乏或没有现存的文档，所以无论多么富有J2EE经验的新雇员都将需要花费许多时间在角落里向老师讨教，他们应当如何进行。这不仅仅会浪费他们许多时间，在角落中的大师也花费了他或她一半的时间来回答基础的问题，而不是向学生们传授凝聚他们心血的高水平代码。这个问题在您把部分开发工作转包给其他公司时变得更糟。另一个机构中的，或者甚至是另一块大陆的开发人员将没有在角落中向大师讨教从而获得生产效率方面明显收益的机会——因为大师（他或她）并不在角落中。框架为我们带来了一致性和拥有多技巧水平的团队，其代价是技巧可转移性的收益，那正是我们一开始就采用J2EE的原因。
所以，总而言之，当我们需要框架来提高生产效率时，我们已经定义了任何真正有用的框架都需具备的需求集，即：
- 它必须被广泛采用并且具有充分的文档说明来使开发人员可转移性最大化。
- 它必须易于使用以便最大程度地减小开发人员了解服务器端计算低层细节的需要。这意味着它必须是可工具化的。
进入蜂巢框架
下一代的运行时框架使得当今的BEA WebLogic平台应用程序功能更加强大，并且由三个基本组件所组成：页面流、控件以及JSR 181 Web services。
三个组件都使用代码注释来驱动从运行时观点部署的代码——运行时行为声明集将大多数代码级的开发人员交互限制在直接追求业务需要的实现上。控制器上的代码注释使得页面流子系统能够处理支撑的细节部分；类及方法级的注释使得与业务目标相关的事情能够作为Web services轻松处理；同时，注释使得开发人员能够对在控件中传递的可重用功能块进行声明。最好的新闻是：虽然注释和与之相关的代码收集在一起，而且还可以通过可信任的编辑器对其进行操作，通过知晓蜂巢的IDE（首先是WebLogic Workshop，但是还有其他工具供应商（更不必说Apache Pollinate 项目）也在其中，来确保它并不是惟一的），使其本身适于智能操作；这就使得开发人员能够轻松实现与蜂巢开发模型及自定义方式的自定义控件进行交互操作——例如，看一下当今的数据库控件——在IDE中创建一个控件，您需要从运行的服务器中找到数据源，而且甚至需要查看在模式中有哪些表。这种智能的、环境敏感的提示将会为开发者带来快速学习曲线，不像基于向导的代码生成器方法，初学者决不会面对成百上千的代码行及其他制品，这些代码或制品不是他或她自己写的、难于理解的但是现在却必须要维护（还有人记得4GL COBOL生成器工具吗？！）。
当然，现今这种开发方法使BEA已有的客户从中受益，正如在Gartner以及Crossvale或其他人的研究中的说明一样；但是指挥官Paranoia正在他们头上低声说着令人恐惧的“私有”一词，并且还埋怨着锁定的供应商。所以对这些人而言，蜂巢代表着从BEA的革新中受益却不受BEA基础结构生命周期限制的可能性（虽然那就是为什么会吓着任何在我前面的人的原因！）。
对于其他人而言，蜂巢不仅提供了被世界大型主要供应商所支持的开放、已证明的、可工具化的开发框架，而且为服务器端的Java带来了开发上的方便；所有的一切都以与当前面向服务的架构和谐统一的方式完成。
可能会受到的对可工具化框架解决方案的最后抵触通常来自J2EE开发人员本身。他们将他们对于晦涩难解的JNDI的理解运用能力看作是实现其自身价值的需要——“如果工具和抽象使得事情变得如此简单，我们就将失业了！”我认为存在这样的误解有以下两方面的原因。首先，所有执行查表等类似任务的代码总是从示例上或者“我先前准备好的示例”上剪切并粘贴上去的。在我作为一名Tuxedo顾问工程师的日子里，我丢失了一些生产系统的计数，这些生产系统在其注释中声明他们将字符串放入上层用例（甚至连注释都是从“simpapp”示例应用程序中剪切下来再贴上去的）。在J2EE的世界中情况也是如此——任何认为他的剪切粘贴代码行的能力高超到足以保证其工作安全的J2EE开发人员也处于被误导之列。而且，框架并不意味着项目可以在没有J2EE开发人员的情况下开展——对于任何开发而言，一至两个架构师总是需要的。有了框架之后，J2EE架构师和业务开发人员之间就有了明显区别。框架决不会使专家贬值，相反，框架通常会为开发人员提供某些类型的就业机会——这正突出了经验的真正价值。最后，如果Java（以及相关技巧的市场价值）想要在企业中长久地生存下去，专家将其目标定位于宽广的专业经验至关重要，然后大众才能集中于高效率的生产。
所以，跨出这一步就拥有了全部……清醒过来闻闻蜜糖的香味吧！蜂巢已经来到啦！
|
