TAG:
|
作者：Ed Roman著 宁凯 译 本文选自：赛迪网 2002年04月24日 近来，出现了很多关于企业级JavaBeans(EJB)和微软的COM+技术的讨论。一些人认为EJB是项新技术，因此它并不适合当前的多数应用。而另外一些人则对Windows 2000的稳定性和可靠性存在怀疑，于是他们对在一些关键任务的处理中使用视窗2000而感到不安。那么，当我们的一个开发需要在这两个开发环境之间进行选择的时候，又应该怎么来选择呢？ 在这篇文章中，我要提出一些问题，你在为自己的业务和应用选择技术时，也需要问自己同样的问题，因为它们会有助于做出正确的选择。虽然这文章不会回答你所提出的全部问题,但是它将会引导你走上正确的方向。 ISV 还是 IT Shop? 首先，你需要问自己一个很重要的问题：你是要把软件卖给其它公司还是要自己使用软件。 对绝大多数卖软件给商业客户的公司来说，选择EJB 通常来说变得非常关键。为什么这样说呢？这是因为EJB主要支持异构环境下的开发。除非你能够保证你的所有客户都会接受Windows的解决方案，不然的话，你就会因此限制了公司职员的业务范围，他们将失去那些使用UNIX 解决方案或者使用基于大型主机解决方案的大客户，这对大多ISV来说是不能接受的。如果你并不知道客户正在使用的具体方案，那么你应该告诉公司的部门主管和特约顾问，请他们帮你查明你的客户所使用的具体方案。千万不要为此而感到羞涩，因为你得到的数据越多越好。 如果你是自己使用软件的话，你就应该能够支配和管理所使用的开发环境。这就意味着你既可以选择COM+又可以选择EJB，两者是同等的。 现有开发人员的技能 （Existing developer skill-sets ） 现在你的开发人员知道做什么了吗？他们是精通Java还是 C++呢? 他们有没有使用MTS/COM+和EJB进行开发的实际经验呢?所有这一切肯定会影响你的最终选择。毕竟，招聘新人员和留住已有职员将会是你要面对的头号问题，而这些和你所处的行业是没有任何关系的。选择一项和现有开发人员技能相吻合的技术，肯定会给你带来一笔数目巨大的收益。 选择Java 编程语言的选择对于中间件的选择来说绝对是至关重要的。为什么呢？因为EJB 组件必须使用Java语言来编写,这就意味着需要对Java 语言投入很大的精力，因为只有这样才可能精通Java语言。如果你并不愿意对Java 语言投入很大的精力，那么，COM+就是一种更有吸引力的选择了。同样，如果你愿意使用Java来进行一次赌注的话, EJB通常就是最好的选择了。你要是回想一下的话，最近的法院裁定已经开始逐步削弱Microsoft对 Java平台的支配权。正是这个原因， Microsoft正在积极开发新的编程语言，比如COOL。 虽然微软或许以官方的形式说支持Java, 不过还是又很明显的暗示：在支持模是方面，微软会支持Java 和 Visual J++。如果你完全相信你的提供方将会大力支持Java编程语言的话 ， EJB (和CORBA) 将会是风险最小的选择。 中间件的特点 对EJB 和 COM+所作的比较绝大多数都聚焦于这两个平台的特点对特点的比较。这些都是很重要的区别，当你进行选择的时候，你应该仔细权衡一下这些特点以便使它们能够适用于你的业务需要。 需要注意的是,现实的电子商务系统既有使用 EJB开发的也有使用COM+进行开发的.尽管每个平台可能不支持某些特点，但是现在的开发团队已经学会了如何处理它们所选择的平台的局限性。COM+中不支持持久组件，而EJB不支持队列组件。仅仅基于平台的特点就做出选择在实际中是很少见的，因为这两个平台时非常非常相似的。相反，具有决定性的商业力量则是更大的因素。 系统的成本 微软的技术普遍有一个很明显的特点：这些技术看起来总是通过廉价来赢得竞争的主动权。Windows 2000也不例外。Windows 2000的每笔交易都有一个很明显的低价。这是由Microsoft使用的价格政策造成的。而且， COM+ 子系统也安装了Windows 2000, 而基于EJB的应用服务器则是单独销售的，它和有关平台是分离的。当你把低价位的Intel硬件和 Microsoft的中间件方案组合起来的话， 每笔交易的费用明显变低了。 然而，读者应该注意，一项工程的所有权的全部费用将会大大缩减中间件，操作系统，和硬件的成本。当你在考虑招聘，培训和维持开发者所需费用的时候，开发和维护相关解决方案的成本，由于错误的决定而导致失去潜在客户带来的成本消耗，以及所作决定在未来几年中的持续效应和软件硬件的成本都是微乎其微的。 购买的组件和完全从头开发的组件 EJB 和 COM+的一个价值就在于他们能够帮助ISVs来把应用设置为组件。在不久的将来，EJB 和 COM+也将会让电子商务应用能够一种分离的形式进行组合，这其中既有专门的组件也会有垂直的市场分布。和白手起家，完全从头开发的组件相比，上述的范例将会更富有吸引力，同时它也会比购买一个并非个性化的通用商业社区更有价值。如果需要新的组件，客户能够精确制作出他们自己的定做组件。 现在，并没有很多现成的服务器方组件拿来使用。然而，如果你在自己所的领域中确实找到了一个提供组件的销售者，那么这就会成为一个很有说服力的理由来让你做出决定选择它们所支持的中间件。你可以查找所需组件的几个web站点如下：  http://www.flashline.com/ http://www.componentsource.com/ 总结 简言之, 在EJB和 COM+之间进行选择是件棘手的事情，而且这篇文章仅仅打算使你能够更好的处理手边的事情。表 1 总结了两个平台的不同之处。 特点 EJB COM+ 组件支持的语言 仅支持Java 所有 (Java: 未来不明朗) 平台 所有 Windows 2000 中间件销售商 30+ Microsoft Legacy Integration RMI/JNI, CORBA, Connectors COM TI, MSMQ, OLE DB 协议 任何(将来: IIOP) DCOM 无状态组件（Stateless components） 支持 支持 有状态组件（Stateful components） 支持 不支持 持久组件（Persistent components） 支持 不支持 Method-granularity transactions 支持 不支持 Middle-tier load balancing 大多数销售商 很快就会支持 Middle-tier data caching 一些销售商 没有 Queued components 不支持 支持 Single-vendor solution 不支持 支持 Low cost per transaction 不支持 支持 Middleware comes with OS 不支持 支持 Per-machine processors 256+ 16 (32 via OEMs) Cluster-wide processors 理论上是没有限制的 理论上是没有限制的 Development tools 多种选择 Microsoft Dev Studio 如果需要获得更多关于这些技术比较的信息，可以看看最近我和Roger Sessions（一个COM+的支持者）在 http://www.middleware-company.com/debate.html这个站点所进行的相关讨论；. 对技术人员而言，如果你需要获得在技术层次上这些中间件比较的信息，可以看看我发表在TheServerSide.com resources section的一篇对比文章。 但是，最后你需要记住： EJB和COM+都将会获得成功。因为这不是零和游戏并且也不会由明确的获胜者。这两者将会占有他们各自的市场，业界的领军企业也会大力支持这两种技术。对于那些象你一样需要在EJB和 COM+之间进行选择而同时又希望降低项目风险的人来说,我建议作出主观判断，然后指定一个一流的解决方案来对你所选择的平台进行有效性测试。只有这样，你才能够知道你所选择的中间件是否真正满足具体商业应用的需要。 关于作者 Ed Roman , CEO of The Middleware Company (iwgh) |