[转贴].NET和J2EE架构之战 正在升级

xujh

当运营商为下一代Web服务设计CRM、ERP、计费和OSS架构时，他们总是希望所有的软件都可以互相兼容。他们现有的软件和第一代计费系统都是特建的，所以并不是开发的。但对于Web服务，运营商需要一个开放的环境，以他们的架构中不同的组件能够平滑地“共事”。

　　.NET的优点在于它使用XML语言和Web的性能，但它的成熟性和其他解决方案的集成能力还是一个问题。反观之，J2EE提供了多平台支持技术，但用起来却不如 .NET方便。

　　市场调查公司Forrester的分析师Ted Schadler认为：“必须先把问题搞清楚，然后才能根据事实做出结论”。他说，软件开发商不必再坚持使用J2EE，而.NET操作系统中以前存在的安全问题也应该得到重视和解决。

　　为了解决这个问题，Forrester最近发表了一份报告，提出一项战略构想：根据运营商不同的主页来确定哪些适合用J2EE，哪些适合用 .NET。

　　“大多数大型运营商都有六到八个主页”，Schadler认为这些主页可以分为Web网站、安全设施、ERP系统，以及为工作人员提供应用的内部网，他说：“这些主页一般都已经运行一段时间，所以能提供历史记录和前景，作为系统决策的依据。”

　　Gartner的分析师Mark Driver在一份名为《充分利用Web服务和中间件：为企业建立和配置集成的应用平台》的报告中预测，在未来五年内，.NET和J2EE在市场份额上将平分秋色，因为两者在Web界面、Web服务和XML互相竞争。Driver相信，.NET和J2EE将占到新的电子商务应用开发的80%。

　　大多数业内专家认为，伴随着使用Windows服务器平台的客户平台和后台办公数据中心的整合向 .NET的转移，中小厂商将逐渐转向使用 .NET。

　　Portal软件公司宣布，该公司的产品Billing Agility将以 .NET作为开发平台，这源于它和微软签订的一个共同进行市场营销和技术开发的协议。Portal这么做的事实依据是：Web网服务的计费需要很多硬件支持，而Siebel和SAP公司的大部分销售都来自微软的平台。Portal负责战略方案的副总裁Steve Zielenski说：“微软正在数据市场上取得更多的份额。我们预期微软由于总拥有成本的原因将得到很大的市场份额。”

　　Portal并不是唯一发誓要将运营商的现有系统转移到 .NET平台的计费厂商。富士通公司是一家提供电信计费的咨询服务的公司。该公司副总裁Don Tiedeman说：“作为Unix技术的专家和Solaris系统的代销商，我们似乎应该采用J2EE平台，但我们发现带宽的问题，使用J2EE很难实现系统的转移。”尽管他认为，.NET和J2EE的应用程序接口都设计得很好，具有良好的兼容性，但他更喜欢商业化的组件和不断更新的技术。实际上，富士通刚刚完成了一个主机系统转换的项目，旧系统每年的设备和软件使用费高达72万美元。而该公司负责改造系统转换的副总裁Dave Flawn认为：“现在用价格为2万美元一台的英特尔电脑照样也能行。”

　　像Flawn这样的.NET的拥护者认为，由于C-Sharp语言在几年内将逐渐淘汰VB和C++，因此 .NET将不再使用这两种旧的语言。

　　Info Directions公司的董事长兼CEO Don Culeton说：“我们正在WAP产品开发中尝试C-Sharp语言。”该公司目前正致力于开发基于Web的前台组件，用于帮助代理商接入和集中管理业务，以实现更好地手机和配件发送，以及从因特网的任意站点接入计费、CRM和其他系统。

　　对Info Directions来说，.NET的通用语言执行环境所具备的功能使C-Sharp软件能够在因特网上畅通无阻。微软的通用语言执行环境允许企业最多使用27种语言进行编辑（包括Assembler），这些语言同时也可以在MS执行环境下使用。18个月前，该公司将全部产品转移到 .NET平台上，从而成为首个基于 .NET技术的计费厂商。公司负责市场和销售的副总裁Derrick VanGrol认为：“由于你必须与所有的技术打交道，包括AFP、COM、javascript，以及浏览器本身，所以企业不可能将整个企业应用建立在浏览器上。”

　　Culeton 则补充说：“J2EE环境下的变数太多，可扩展性、可靠性和易开发性就成为了问题。”他认同有些批评者认为Sun过分注重基础构架，从而导致产生了不同风格和延伸的J2EE。比如，IBM风格的J2EE要和BEA公司的J2EE相集成的话，可能就颇费周折。

　　VanGrol说：“我们只使用C-Sharp，这样我们就可以在因特网的两端，把客户通过因特网传输和组合的业务目标系列化，从而大大简化了开发过程。”

　　除了现有的支持.NET的计费厂商外，同时还有同样多拥护J2EE的厂商。微软在支持旧系统方面好像做得不如J2EE，咨询公司RedMonk的分析师Stephen O，Grady说：“用一种语言编完程序后，再到其他执行环境下进行编辑，微软对旧应用软件的支持是做不到这种程度的。”

　　J2EE为旧的环境提供了开放的源代码工具包（例如Eclipse，它可以管理COBOL 和Assembler代码）。这些工具包拥有许多支持者，其中包括惠普、Borland和甲骨文。许多公司都喜欢使用Eclipse，他们可以用COBOL或Assembler语言编程，然后利用Eclipse做成插件，应用到整个研发过程当中，尽管这么做有时候也并非易事。

　　IBM软件WebSphere Marketing项目的主管Stefan Van Overtveldt说：“.NET环境通常被认为是‘连接到’其他环境中去；而‘连接’意味着利用Web服务技术建立新的基于Windows的平台，比如Unix平台。”他认为要做到这一点，软件开发商必须在现有的基础上提高他们在硬件、软件和所有操作程序上的投入。“因为我们的任务是提供一个平台服务器、接入口和通用的系列产品，以支持使用各种不同软件的所有设备，同时要提供一整套完整的开发工具以及与此相对应的合作伙伴生态系统。WebSphere就是基于J2EE建立的。”他还认为，这样就允许任意设备都能连接到Web服务软件上，移动电话、Kiosk（便捷上网站）、PDA、车载电脑等都可以。

　　由于Windows要求软件开发商从零开始编程，这对那些依赖大型机的可用性和支持功能的运营商来就几乎就是“不可能的任务”。Van Overtveldt 的观点是，“对这些公司来说，将旧的计费系统或大型机直接转换为Web服务更节省时间”。

　　J2EE将对大多数大企业客户更有吸引力，因为这些公司的数据中心一般是由大型机和AS/400服务器，以及Unix 和Win32系统组成。J2EE对各种不同环境的支持和目前.NET还不擅长的可扩展性方面都有一定的优势。Java在手机和无线设备上的应用同样也将促进J2EE兼容性能的发展。Van Overtveldt 说：“使用Unix的人将转而使用Linux，而且很可能利用J2EE来开发软件，因为J2EE能强化Linux平台，特别是因为能在远程环境下方便管理而受到了欢迎。”

　　但在手机的销售中比较.NET和J2EE到底哪个更占上风是很困难的。O,Grady认为：“J2EE领域的竞争者要比 .NET的多。比如IBM、Borland、Sun和甲骨文的工具软件全是J2EE的。”

　　尽管微软在企业市场的手持终端设备领域推出了许多新的技术，但消费者移动电话市场却是Java的天下。在O,Grady看来，“其实正因为有了拥护Java的厂商和客户群，Sun才迅速推出了Java并在开发和设计上保持领先地位”。

　　2003年7月召开JavaOne会议的时候，Sun就曾努力打造Java作为开发手机软件的实用技术品牌形象。这一点很重要，因为沃达丰和其他运营商正不断地通过移动网络，从喜欢历险游戏和足球等游戏的手持终端设备用户那里赚取大量利润。“手持设备将为人们提供更多有趣的东西，这使得移动行业获得了无限的成长空间；不论是对IBM还是微软，寻找新软件开发商都将成为他们感兴趣的市场。”

　　虽然大多数人都认为微软的Visual Studio为移动应用的企业开发设立了高的门槛，但丰富、多功能的应用在手机上是很难阅读的。Java则占有使用者众多的优势，因为所有的操作系统和大多数设备都支持Java。

　　这一点对那些正致力于使移动网络更智能化的电信运营商来说将是非常重要的。“有些人认为，如果将远程系统的人事成本作为一个要素考虑，Linux将会打败Windows”，Van Overtveldt说。

　　毫无疑问，如果不把移动应用软件考虑在内，围绕Win32/COM平台进行的软件开发将促成向 .NET构架的转移。甚至Sun的主席、董事长兼CEO Scott McNeely都曾说过，谁先占领市场并不重要，重要的是谁在市场上有很大的量。

　　J2EE和 .NET之间的本质区别在于以下几个方面：成本、工具、性能、可扩展性、集成和安全。

　　成本

　　虽然微软声称，由于 .NET是在Intel环境下运行的，软件的授权使用费很低，程序员的数量较多，所以.NET较便宜。但Java拥有更多的企业工具厂商和应用厂商，同时也得到了更多的风险投资的支持。

　　话说回来，J2EE和 .NET还是有差异的。从服务提供商的角度来说，J2EE是一个全新的架构，它和Java的相似之处有时的确容易让人搞混。其实，Java语言和J2EE架构有着主要的区别。

　　.NET 拥护者称他们只需花一半的成本就能实现Unix所具备的全部性能。Portal公司的Zielinski说：“.NET 能帮助企业降低他们在数据库、底层操作系统、接入以及支持软件上投入的硬件和基础构架成本。” 他还举了个拥有1500万用户的欧洲某GSM运营商为例，该运营商正在测试 .NET系统。他指出，测试的结果表明：.NET和J2EE在性能上相差无几；但在将Web自助服务与内部桌面系统的集成方面，.NET能够节约50－90%的成本。不过，这只是围绕Portal的CRM合作伙伴Siebel的平台所得出的数据。

　　J2EE的拥护者则警告说，在节约成本方面得出的结论并不重要，因为还要考虑性能和可扩展性问题。Sun的J2EE产品经理Glen Martin说：“微软曾将最新在通用执行环境下的 .NET评测数据和旧的Java虚拟机的性能数据进行比较。”他认为，公司应该将在Linux和Solaris平台的J2EE 1.4.2提供的最新性能数据进行比较，而不是用六年前的历史数据。

　　“对某些公司来说，他们不需要软件有多大的规模，而只需要简单实用的软件，因此节约成本是非常重要的。但他们最好记住一点：Windows系统一般只能扩展到不超过8个处理器，而Sun的系统却可以扩展到100个甚至更多处理器。” Sun的Java技术市场经理Ralph Galantine说道。

　　由于大型机和Unix系统往往要花费几十万甚至几百万美元，J2EE能够承担大规模工作量的特性对eBay和Charles Schwab（美国互联网股票交易商）这样的在线交易网站自然就产生了不可抗拒的诱惑。由于每天可以处理数百万个交易，因此对于支持大容量的交易和用户、月计费帐单或移动电话Web服务的运营商也相当具有诱惑力。

　　但是，微软也有许多采用 .NET工具包和执行环境的大企业客户，其中包括惠普（该公司正与南非电信合作推出Wi-Fi服务）、BroadWing、Qwest和T-Mobile。他指出，Verizon采用 .NET平台连接其后端基础构架只用了不到9个月的时间。
不成熟？

　　要与这些大型运营商合作，微软将不得不解决 .NET所面临的一些问题，包括在新的执行环境下的“不成熟”，软件开发和安全方面的问题，以缺乏与微软的Office及其他已有系列产品的集成等问题。

　　关于成熟问题，微软通信和移动解决方案全球市场的战略分析师Andy Chu认为，.NET已经开发出来好几年了，它的战略目标范围已逐渐超越了J2EE。他说：“这个范围包括软件开发商、基础构架建设者和最终用户。”他认为，由于微软的桌面系统被广泛地使用，因此微软注定要扮演沟通服务提供商和最终用户的桥梁的角色，“这是一个将最终用户和OSS/BSS基础结构连接起来的端到端的图画。”

　　但是，这种端到端的图画是建立在这样的事实基础上的，那就是整个 .NET环境是和Windows联系在一起的。虽然微软自有的技术（如VB、COM和Microsoft Transaction Server）拥有众多使用者，但出于安全和集成方面考虑，许多战略分析师在制定Web服务战略时都想尽量避免采用微软自有的解决方案。

　　安全

　　尽管微软最新公布了一个“可信赖的计算”，但仍有人认为由于安全是 .NET引起的附带问题，所以它仍然存在着“致命的错误”。也就是说，就算用升级包来特别加强安全，Windows漏洞仍然会对 .NET产生影响。

　　而J2EE的安全性从程序的第一行开始就得到了保证，简直是天生的完美，此外更有合作厂商Tivoli、Entrust和Netegrity的共同努力。因此安全性仍是微软在销售时不愿触及的一个敏感的痛处。

　　不可否认，这种情况可能将改变，因为大部分专家都一致认为Windows Server 2003是一个安全的操作系统。实际上，有报道说Windows Server 2003的安全认证比Linux还要高。RedMonk的O'Grady说：“传统上，Unix销售商比他们的windows同行更熟悉安全要求。”不过他也承认，就商务操作系统来说，微软正迎头赶上，“他们在证明他们商务操作系统的实力。但Windows要想在安全问题上得到认可，还必须要拿出实际行动来证明自己”，他补充道。确实，Windows仍然备受安全问题的困扰，因为其桌面系统存在太多缺陷，最近的冲击波蠕虫病毒更严重地暴露了这个问题。

　　.NET为软件开发商和使用者提供了在“安全模式”或“非安全模式”下工作的选择，由此产生的问题是，只要开放任意一个采用非安全模式（C++）编写的程序接口，就等于把整个网络主体暴露在病毒的威胁之下。大约98%的病毒都是利用“缓存溢出错误”。缓存溢出会使程序无法正常运行，并且不停地自动复制程序代码。J2EE和基于C++ 的语言不同，它不允许产生缓存溢出这样的错误，因为软件设计者根本就没有设计任何缓存，从源头上消灭了所有这种类型的编程错误和毁灭性病毒存在的根源。用Galantine的话来说，就是“只要一段不安全的代码就能影响整个系统的安全性”。

　　开发商是否能盈利，就要看他们如何掌握易使用性和安全产品的市场化速度之间的平衡。微软的Andy Chu认为，出现安全问题的部分原因是由于基于Windows的系统通常都没有受到像大型机和旧系统那样的重视。他警告说：“我们应该给基于Windows的技术以同等的待遇。J2EE、Linux和Unix其实也存在着同样的问题；这是一个有关完整操作的问题。我们不必在大型机上插入网络接口卡，而是在适当的地方集中控制安全问题。”

　　微软已经建立了安全反应中心，帮助用户迅速地诊断和修复安全问题；同时它还指导用户在开发软件的过程中，怎样更谨慎地使用安全协议。

　　.NET还引进了一些新的特性，软件开发商应该认真思考因此而付出的代价。Driver说：“它们将带来许多新的中断，软件开发者将不得不重复学习。”他发现，大多数软件开发者可能都需要3至9个月的时间才能熟练掌握软件的特性，有些人可能会花更长的时间，就算是12到15个月也不稀奇（比如COBOL的开发者）。不过，如果不考虑这些因素的话，我们恐怕就很难知道学习软件需要的时间，因为培训时间可能受到各种因素的影响，其中包括构架、执行环境、语言和基础设备。

　　集成的容易性

　　电信是一个具有许多操作系统的十分复杂的环境，这已被人们所承认。有鉴于此，开放性和集成就成了至关重要的因素。当多个OSS和BSS系统受到基本的数据交换连接直到全部的业务流程集成的影响时，一个集成的业务组合是十分必要的。如果没有集成，那么就连诸如修改地址这样简单的调用都会变得很复杂。IT部门必须能够利用用户图形界面（GUI）来应对流程的变化。例如，利用自动升级和安装程序来完成地址的修改过程要求软件开发者调整系统的安装差异。某个计费系统很可能将名作为第一条记录，而将姓作为第二条记录；但在另一个系统完全可能是相反的。软件开发商必须能够识别这些差异，并在集成战略中体现出来。

　　软件开发商希望在无需调整软件的前提下来应对设备之间的差异，而他们最终还是会根据用户的设备来开发软件。一个移动电话的GUI所代表的数据显然和个人电脑或kiosk终端的不一样。

　　微软最大的卖点之一是微软所说的集成比较容易，因此可以使新服务进入市场的时间更快。然而，所谓的 .NET实际上与windows是紧密集成的，因为这是一个大的源代码库的说法并不一定代表这是一件好事。

　　微软已经开始对关于它不开放共享源代码的批评做出积极的回应。

　　虽然有人对此表示赞许，但仍有不少人对它表示不满。微软已经向欧洲计算机制造协会（ECMA，该标准组织同时也控制着环球网文本语言javascript）提交了 .NET约40%的应用程序接口和规格说明书，但许多人都抱怨微软提交的只是低级应用程序接口。Gartner的Driver在他的报告中写到，“微软仍保留着对平台上高端元素的控制权。”

　　Martin说：“他们的战略更像一种‘主要厂商’形式，他们安装了一些东西后，他们的合作伙伴再据此建立连接；这是那种不保证厂商之间互操作性的流程。”他还说，Java的流程包括参考实施和兼容性测试，“要是没有实施范本和兼容性测试，你很难把它弄懂。”

　　这样做的结果是人们普遍抱怨 .NET很难与使用其他操作系统的系统相集成，不管是Unix、Linux或是大型机。

　　微软的Andy Chu说：“我们理解人们不可能简单地废除现有基础构架；我们的平台也要成为基础构架的一部分。”

　　由于不同的公司对灵活性、集成、安全、性能和可扩展性的意义的理解不同，因此我们不可能笼统地说 .NET或是J2EE哪一方比另一方更“好”。两者都有各自的优点和缺点，取决于Web服务战略的重点。在评价这两种技术时，将会被考虑在内的两点要素是：在运营商基础构架的不同界面之间表现的开放性和集成；以及在OSS系统和BSS系统之间的集成。

　　Verizon：管理能力将决定

　　J2EE 和 .NET的成败

　　正当围绕J2EE 和 .NET的争论愈演愈烈时，出现了除人们关注的安全性、可扩展性和易集成以外的一个声音：管理能力，这是实现所有其他性能的前提。

　　我们有幸采访到了Shadman Zafar先生，他是Verizon公司负责IT架构和E服务的高级副总裁，他对我们谈了一些在管理成长中的Web服务开发平台时容易被人忽略但却是前所未有的问题的重要性。目前，Verizon正对有关如何通过Web服务实现应用和现有服务的集成，以及使项目开发更简单等议题进行评估。

　　记者：在讨论J2EE和 .NET这样的平台时，最主要的评价标准是什么？

　　Shadman：首先，当人们想要构筑平台时，他们并没有考虑到可能会因此搞乱他们的数据中心这样的后果。他们不去考虑冷却系统，以及无数附加的电源插座；他们能想到的仅仅只是一个性价比。但是，随着Web服务的发展，有关管理平台的战略将成为你成功与否的重要标志。管理能力将决定J2EE和 .NET的成败。

　　撇开最初节约的成本不谈，管理能力将成为最核心的问题。你可以用100台机器支持100万用户或仅用半台机器就够了——这取决于该平台所提供的工具。有时候，维护100台机器比维护半台更便宜。

　　记者：为什么管理能力会成为企业实施Web服务时的决定因素？

　　Shadman：企业用户使用Web服务的目的起初是为了降低重复开发的成本，后来则是为了减少软件的漏洞。当你想要提供服务、账户管理服务，或是借助个人电脑和手持设备在线察看计费项目时，你希望能够在开发简便、在严密的安全条件下将服务推向市场，便于管理，以及使最终用户使用简便这几个目标之间取得平衡。

　　最初是一些软件开发队伍建立了一项服务之后，其他人就开始使用服务。到目前为止，他们积累了许多非常有益的经验。但人们对能给他们带来好处的东西总是会要求索取更多的好处。在商业用户领域，这意味着开发几百个甚至几千个服务项目，供企业内部和外部的开发项目使用。

　　因此，Web服务的服务水平协议管理（包括性能、可靠性和容量规划）就显得至关重要。例如，帐单支付服务在10秒内做出反应，客户不会感到任何的不适。但是，呼叫中心服务代表的反应时间是受到质量监督部门严格限制的，如果他也要10秒钟才做出反应，这项服务就没有任何价值了。同样，某个移动客户察看订单的状态时，在可靠性方面的要求并不高；但当911紧急呼救查询系统要查验某个地址的变化时，则要求100%的可靠性。

　　记者：有什么措施可以保证管理能力吗？

　　Shadman：在Verizon内部，我们已经开发出一种Web服务管理模式，它在 .NET和J2EE架构下都适用。目前采用我们方法的都是一些与Web服务的管理和配置有关系的行业佼佼者，像BEA、微软和IBM等。虽然 .NET和J2EE都积极地向企业级Web服务管理模式靠拢，但还没有哪个阵营取得最后的胜利。

　　我个人在管理这方面的经验是，J2EE在数据中心的管理上可能发展更快一些。不过，.NET的软件开发工具更出色一些，开发周期也更短些。因此，.NET在软件开发领域非常吃香；但在操作系统领域，J2EE则因其管理工具而大受欢迎。

　　记者：一些对 .NET的抱怨似乎仍然是围绕着安全性、集成和可扩展性问题的，而J2EE在前端用户图形界面上则远远地落后于 .NET，到底哪一种技术完善得更快些？

　　Shadman：最近我们公司正好有两支开发队伍同时利用这两种平台开发了相似的应用软件。.NET开发队伍有300多个非定制级的小插件可以利用；而J2EE开发队伍在前端开发上只有两个插件可用，而且这两个插件都很差，于是他们只好花时间和精力想别的办法。可是，虽然.NET队伍进展很快，但在我们随后的结构和安全性检查中，我发现J2EE队伍开发的软件比较完美，而 .NET却耗费了我大量的时间。

　　至于哪一种技术进步得更快，我发现 .NET在安全问题上取得的进展要比J2EE在前端件上取得的进展要快得多。我认为这两种技术都可以获得成功，说到底，Web服务的宗旨也就是让不同的平台只花费极少的集成成本就可以和平共处。但是，我却发现由于大部分独立软件开发商都在为 .NET平台开发前端件，因此前端应用软件仍然总是使用 .NET技术；反过来，.NET在服务器和数据中心、尤其是安全领域仍是举步唯艰。

　　总的来说，你会发现大多数人对采用J2EE技术的后端数据库服务器感觉良好，而 .NET正在从网络服务器通向应用软件服务器以及数据服务器的道路上艰难前进。

　　记者：如何看待关于J2EE“占据”了移动计算发展空间的说法？

　　Shadman：对于有些不需要高分辨率或高保真度，或是完美的使用体验的设备来说，比如移动电话，那么J2EE或者说是J2ME还是不错的。但如果你想得到160或240以上的分辨率的话，那就只能靠 .NET来实现了。在这里，我们碰到一个尖锐的矛盾，你必须权衡高度的安全性和画面以及可用性。如果你想中途换技术，担心别把事情搞砸；从一种结构转移到另一种结构的工程浩大而繁琐。

　　很显然，这两种技术的性能各有千秋，并没有哪一个能做另一个做不到的事；只不过一个需要在安全性和可管理性上多下些工夫，而另一个则要在前端开发上多投入一些。

　　微软软件库里的软件基本上都和前端有关，所以他们拥有几千个独立软件开发商在他们的平台上开发软件，这些开发商也全部是以前端为优先考虑的。相反地，Sun和J2EE的拥护者如IBM考虑的是后端和服务器，因此他们关心的是数据中心的安全和可管理性，他们的独立软件开发商当然也一样。

　　这其中不但包含着行业的因素，同时也包含了企业内部的因素。软件开发队伍随着软件技术的发展而成长；有时候成功会冲昏你的头脑，因为往往是内部因素决定了你要使用哪种技术。