.NET vs J2EE——面对SOA的荒谬与误解

.NET vs J2EE——面对SOA的荒谬与误解2011-02-06 天极 emanruoy引子

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

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

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

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

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

涉及主题

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

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

背景

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

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

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

2003年Sun公司发布了J2EE 1.4版，除了增强更加稳固的企业级应用之外，还增加了Web Services支持。Sun把这个最为流行的版本称为Java EE。

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

一些数据

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

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

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

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