.NETvsJ2EE——面对SOA的荒谬与误解[1]

　　引子

　　·.Net与J2EE在金融行业愈来愈呈势均力敌之势，二者均宣称提供了不同于对方的、听起来很迷人的个性化应用服务。

　　·理性的IT执行官们已经深刻的认识到这样的一个事实：无论是.Net还是J2EE，将来必将在SOA理念的应用中占有各自的一席之地。

　　·Microsoft的.Net技术在今天的金融市场面前，显得商机无限。

　　·从前，荒诞与误解依然在.Net与J2EE平台之间萦绕着：似乎没有一个IT决策者能够看透了这层迷雾，继而在两个平台之间做出理性的决择。

　　·今天，技术执行官们已经能够很好的把握需求动机，进而在这两种平台架构上做出正确的选择。

　　涉及主题

　　SOA(Service-OrientedArchitecture，面向服务的架构)已经在全球业界日益成为核心的技术议题，那么实现SOA的技术标准问题则成为了严格关注的核心问题。在这个领域中，所有的IT经理们将不得不面对一个古老的问题：J2EE和.Net，我们选择谁?

　　我并不愿意试图去回答“YesorNo”，在特定企业的特定应用环境下的选择，也不在讨论范围之内;但是本文的确广泛搜集了当今金融领域内IT专家们的普遍性思维以及他们选择技术架构的方法论。IT经理和软件提供商将能从本文关于技术架构的讨论中发现一些令人诧异的结论，并且了解金融IT专家们在这场关于J2EE和.Net技术架构争议中的思维方法。因此，自从J2EE和.Net诞生以来，那些弥漫在你脑海中关于这两个平台的“荒谬论点和神话故事”很可能从此销声匿迹。

　　背景

　　上个世纪90年代，面向对象的编程(OOP)引发了诸多的软件开发标准。首当其冲的是Microsoft的组件对象模型(COM)，这是一个模块(组件)化的技术开发架构，它源自于微软早期的对象链接与嵌入技术(OLE)。稍微资深一点的技术人员应该知道，今天互联网应用中最常见的ActiveX技术就是构建在COM框架之上。

　　2002年微软全面的用.Net从逻辑层上置换了COM，作为新的软件开发框架(COM仍然被支持)。.Net技术的全面推进，统一了微软的不同技术理念和平台。作为一个战略品牌，.Net为WebService提供了原生的解决方案，并且成为提升不同应用和系统之间互操作性的标准。

　　在1993年微软引入COM之后，Sun公司于1995年推出了Java平台。Java平台由一套应用开发语言(Java)、API和Java虚拟机(JVM)构成，JVM允许用Java编写的程序运行在不同的操作系统上。事实上，Sun引入Java的初衷是使得程序员能够开发可移植的应用程序，而不关心硬件和操作系统。在1999年末，Sun提出了Java平台企业版(J2EE---JavatoEnterpriseEdition)，该规范被应用在主要的IT提供商以构建稳健的应用系统框架，如IBM、Oracle和BEA，等等。

　　2003年Sun公司发布了J2EE1.4版，除了增强更加稳固的企业级应用之外，还增加了WebServices支持。Sun把这个最为流行的版本称为JavaEE。

　　由于.Net和J2EE各自的初衷，使得二者之间的竞争常常掺杂着一些莫名其妙的荒诞。但是最近IT专家及IT决策者们关于这个问题的争论却更加注重于从业务实践的客观角度考察二者技术上的优劣，因为这将有助于他们的正确选择。

　　一些数据

　　几乎每一个IT技术经理都听说过“.Net应用的延展性匮乏或者J2EE架构不易开发”的故事，的确，对这两个平台认知上的误解在业界普遍存在。

　　就在最近的两年以前，许多的IT经理们常常带着个人偏见对其中某个平台情有独钟，而刻意的排斥另一平台。他们仅仅因为一个毫无依据的个人预想而拒绝部署某个平台，或者其依据甚至是来源于杂志上的某篇技术文章。这种情况非常的普遍，因此围绕着.Net和J2EE谁优谁劣的讨论相当多。

　　我们承认.Net平台的延展性会因为其特殊的基于Intel的硬件平台而受到约束，但是我们也不应该忽视.Net平台诞生的那一天起，就有着比J2EE平台更强的互操作性，并且允许开发者利用现有的.Net组件构建更加复杂的解决方案，而不用花费太多的成本。

　　J2EE得到了大部分供应商的支持，包括Sun，IBM等，所以J2EE的最大灵活性和可移植性不用置疑。另一方面，.Net平台被微软独家全面支持，因此有着更为一致性的行为方式和可预见性。

　　令人遗憾的是，两种技术平台的第一手测试资料的匮乏总是使得人们的主观臆想常常凌驾于技术本身的发展之上。对.Net和J2EE认识的模糊也导致了IT执行官们在关键时刻的优柔寡断，甚至又回到了本世纪最初几年的状态，那个时候的平台分布如下所示。

　　Net22
　　J2EE26
　　不确定15
　　都没有30
　　都有7

　　全球.NETandJ2EE技术的跨行业调查(2002)

　　资料来源：MerrillLynch&Co.

　　图1为2002年MerrillLynch对全球100个CIO关于WebService在两种平台的应用分布数据。对100个CIO的问卷调查显示出他们的公司缺乏清晰的WebService应用战略。

　　图2显示了2002年.Net和J2EE平台在美国最大的100家银行的应用分布。

　　Net15
　　J2EE36
　　不确定24
　　都没有5
　　都有20

　　图2美国最大的100家银行2002年的平台分布

　　资料来源：全球金融咨询及顾问公司TowerGroup的评估报告

　　几年之后的今天，IT经理们的决策渐渐变得更加理性，他们开始更多的基于业务需求和技术因素做出选择。我们终于发现，在同一家银行常常同时存在着.Net和J2EE两种技术架构，更为重要的是，Webservices已经成为这两种平台整合的共同桥梁。

　　回到本来

　　哪个平台更加适合新的应用?或者我们应该升级到那个平台?必须做出决定。在过去的6年中，.Net和J2EE平台在全球范围里都未能保持着对对方的绝对优势，他们各自有着自己的特色。

　　2006年，全球著名的金融顾问咨询公司TowerGroup在与金融行业CIO和IT架构师们的一次研讨中，发现他们对于这两个平台的选择有着更为清晰的目标和期望值，这的确是一个消除误解的好机会。

　　这次讨论中至少有两点值得我们注意：企业似乎并没有固有的倾向性;也没有明确的迹象表明那一个平台更加具有延展性和可靠性。

　　(1)对于.Net和J2EE并没有特别的偏好

　　经过广泛的调查，TowerGroup公司发现，企业从前对某一个技术平台的偏好完全是基于个人的爱好和浮躁的“一窝蜂”心态。这种态势目前渐渐变得理性，当然不排除仍然有某些IT经理存在着个人的嗜好。

　　但是企业对于WebService和SOA的强烈关注，则意味着对于某种平台的个人嗜好不再成为平台选型的可接受的依据。

　　(2)没有证据表明那一个平台更具延展性和可靠性

　　虽然有许多关于.Net和J2EE平台性能的研究报告，但是这些报告大部分要么来自于Microsoft，要么来自于J2EE的厂商，使得他们的公平性令人怀疑。也许他们的研究结果是真实的，但是这种供应商自身的性能测试本身就冲淡了研究结果的价值。另外，设计好的TestCase具有很大的复杂性，至多只能有一到两个比较全面的测试用例，其他的用例则显得十分的苍白与简单，极大地限制了测试范围的适应性，从而与实际应用场景距离甚远。

　　差异的必然性

　　虽然对于.Net和J2EE平台的个人偏好显得毫无理由，但是IT经理们承认这样的一个事实：两个平台的差异性常常成为他们在开发、选型和维护升级时的重要参考依据。

　　(1)在硬件和操作系统之间的可移植性

　　.Net和J2EE之间最大的差异性成为金融企业做技术选型的重要依据：在数据中心的数百台服务器之间移植应用的能力。由于J2EE原本就是一套跨平台应用的规范，所以对于那些需要部署到不同服务器上的应用，J2EE似乎是更好的选择。

　　但是，J2EE的上述优势却遭到两个因素的严重挑战。

　　首先，没有两个厂家的J2EE规范是完全一致的。这种在部署、存储和安全性规范上的微妙差别意味着在两个平台之间的应用移植需要因为这种差异性的存在而付出代价。因为对于很多应用而言，应用的可移植性远比可维护性还要重要。

　　其次，银行从前为了克服应用能力的瓶颈，总是存在着升级到具备高端处理能力服务器的需求。但是随着基于Windows-Intel的机器处理能力越来越强大，这种需求被最小化。Unisys公司在6年前就推出了基于windows的主机(Mainframe)，IBM也推出了64位的windows兼容的系统，而CPU层叠技术也允许基于SMP(对称多处理)的Windows服务器系统拥有四个CPU。进一步，.Net操作系统(Vista和Longhorn)将进入高端处理市场，尤其是网络计算机的出现，使得大量的单机分布式处理能力足以胜任目前大型机的工作负荷。