平台的选择.doc

J2ee 。net平台选择1、平台的选择随着三层/多层企业信息系统结构的深度发展和下一代分布式计算模型Web 服务的出现，企业应用中关于平台、框架、语言的竞争也愈演愈烈。J2EE平台在过去几年里一直引领着企业应用的潮流，但最近微软强力推出的.NET平台也开始吸引着众多IT企业和开发人员的注意力，向J2EE平台提出了强有力的挑战。企业应用领域的技术对抗也因此拉开了架势。需要强调的是，.NET是战略产品，而J2EE是描述产品的标准，现在有很多符合J2EE标准的产品。在可以预见的未来，它们都将是构建企业信息系统应用的基础性平台，尤其是开发和部署Web服务的重要平台。尽管可以同时使用几种系统平台和语言，但对于企业来说，还需要选择一个战略性的平台来实现数据的无缝集成，加速企业应用的部署。而要做出正确的选择，首先需要充分了解两个平台的特点和优势。1.1 J2EE企业应用系统的开发一直面临着重大挑战：一方面，企业应用系统面对的是一个异构的分布式环境，它必须支持与已有系统的集成性和与其他系统的互操作性；另一方面，作为为客户、合作伙伴和企业内部提供信息服务的平台，企业系统还必须具有高可用性、安全性、可靠性和可伸缩性。这些要求再加上复杂多变的用户需求和不断伸缩的交付时间，使得企业系统的开发越来越困难。开发商和广大程序员一直在努力推动和殷切期待一个成熟、标准的企业平台来简化和规范企业系统的开发和部署。Java技术的出现，尤其是J2EE（Java 2 Platform Enterprise Edition）平台的推出正是这种努力的结果，也使得企业系统的开发由此变得更加快速和方便。需要指出的是，J2EE本身是一个标准，它为不同厂商创建平台产品提供了标准，使不同J2EE平台产品之间的交互成为可能。J2EE旅程 Java于1996年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置的安全性特别适合于开发企业应用系统。于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1998年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了J2EE。目前J2EE的最新版本是J2EE 1.3。需要注意的是，J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成： l J2EE规范。该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。它是J2EE应用服务器开发商的大纲。 l J2EE兼容性测试站点。Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。 l J2EE参考实现。即J2EE SDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。 l J2EE实施指南。即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。 组件-容器 搭建体系架构 J2EE规范定义了一个基于组件的多层企业应用系统开发平台，其逻辑结构如图1所示。图中的椭圆形表示组件，大矩形表示容器，包含向下文字的小矩形表示API，箭头表示访问，箭头线上的文字表示相应的协议。 J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。组件和容器间的关系通过“协议”来定义。容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。一个J2EE服务器（也叫J2EE应用服务器）可以支持一种或多种容器。在图1中，你可能已经注意到每个容器的服务包括两部分：J2SE（Java 2 Platform Standard Edition）和一组扩展的服务。这是因为J2EE是以Java标准版为基础的，各容器在J2SE之上再根据需要提供一些扩展的服务，如目录服务、事务管理、数据访问、消息机制、安全性等。 J2ee的核心EJB J2EE定义了四种组件：Applet组件、Application客户组件、Web组件及EJB（Enterprise JavaBeans）组件。其中Applet和Application客户组件在客户端运行，J2EE通过Java插件为Applet提供运行环境，Application客户的容器就是本地Java虚拟机。Web及EJB组件在服务器端运行。J2EE中包含两种Web组件：JSP和Servlet。它们是Web服务器的功能扩展，都能生成动态Web页面。不同的是JSP是将Java代码嵌入到HTML中，服务器负责解释执行，生成结果返回用户（与ASP技术相似）。而Servlet是单独的Java类，它动态生成HTML文件返回给客户。Web组件的容器比较典型的就是基于Java的Web服务器。 EJB是J2EE平台的核心，也是J2EE得到业界广泛关注和支持的主要原因。我们知道，J2EE的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。EJB正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。EJB的核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心商业逻辑，而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。 一个可部署的EJB组件包含3个部分： l Remote 接口 Remote接口定义EJB组件中提供的可供用户调用的方法，也就是通常所说的实现商业逻辑的函数或过程（如计算商品价格的函数），以供远程客户端调用。在EJB组件部署到容器的时候，容器会自动生成Remote接口相应的实例，即EJB对象，它负责代理用户的调用请求。 l Home接口 Home接口定义一组方法来创建新的EJB对象，查找、定位和清除已有的EJB对象。在EJB组件部署时容器也会自动生成相应的Home对象，该对象负责查找和创建EJB对象，返回EJB对象的引用给客户；用户利用该引用调用EJB组件的方法，得到结果；最后Home对象清除EJB对象。我们可以形象地称Home接口为EJB对象的工厂。 l Enterprise Beans类 Enterprise Beans类是商业逻辑的具体实现类。其可供用户调用的方法在Remote接口中定义。根据功能不同，EJB 2.0规范中定义了三种Enterprise Beans:会话Beans（Session Beans）、实体Beans（Entity Beans）和消息驱动Beans（Message-driven Beans）。 会话Beans分无状态和有状态两种。一般无状态的会话Beans模拟商业逻辑，比如计算价格等。有状态的会话Beans通常模拟一个客户会话，它会临时保存客户信息，根据客户要求调用其他Beans来存取数据。两种会话Beans都不保存状态信息或数据，当客户断开连接或服务器关闭时，会话Beans也随之消失。一个会话Beans的典型例子是网站上的购物车。 实体Beans模拟商业数据，它表示一个数据存储，可以是状态信息或数据库中的一条纪录。实体Beans在客户断开连接或服务器关闭后，仍有服务保证其数据得以保存。一个实体Beans的典型例子就是客户账号信息。 消息驱动Beans在行为上很像会话Beans。不同的是仅在需要向这些Beans发送消息时才调用消息驱动Beans,比如在需要的时候发送用户确认信息等。 另外，在提交和部署EJB组件时，还需要两个文件：部署描述文件，容器根据该文件来部署Enterprise Beans，提供所要求的服务；EJB jar文件，它是提交给EJB容器的一个部署单元，容器（应用服务器）在部署时解开它，装入Enterprise Beans。 EJB容器非常复杂，一般由专业的J2EE应用服务器开发商提供，比较流行的EJB容器由IBM的WebShpere、BEA公司的WebLogic Server、Sun公司的iPlant等应用服务器提供。EJB容器除了为EJB提供事务处理、目录服务、持久性管理和安全性服务外，还负责EJB的部署、发布和生命周期管理。 平台标准服务 服务是组件和容器之间，以及容器和J2EE服务器之间的接口，在实现层面上它就是一系列API和协议。J2EE平台定义了一组标准的服务，其中有些服务是由J2SE提供的，有些则是J2EE对Java的扩展。 l 目录服务JNDI（Java Name and Directory） API为应用程序提供了一个统一的接口来完成标准的目录操作，由于JNDI是独立于目录协议的，应用程序可以用它访问各种目录服务，如LDAP、NDS、DNS等。 l 数据访问 JDBC（Java Database Connectivity) API为访问不同类型的数据库提供了统一的途径，屏蔽了不同数据库的细节，具有平台无关性。J2EE平台除了要求核心的JDBC API（包含在J2SE中）外，还要求扩展的JDBC API 2.0，它支持行集、连接池和分布式的事务处理。 l 事务处理 JTA（Java Transaction Architecture）定义了一组标准的接口，为应用系统提供可靠的事务处理支持。JTS（Java Transaction Service）是CORBA OTS事务监控的Java实现。JTS规定了事务管理器的实现方式，该事务管理器在高层支持JTA标准，在底层实现了OMG OTS规范的Java映射。 l 消息服务JMS（Java Message Service）是一组用于和面向消息的中间件相互通信的API。它既支持点对点的消息通信，也支持发布/订阅式的消息通信。 l 电子邮件 JavaMail API允许在应用程序中以独立于平台、独立于协议的方式收发电子邮件。JAF（JavaBeans Activation Framework）负责处理MIME编码，JavaMail利用JAF来处理MIME编码的邮件附件。 l CORBA兼容接口RMI（远程方法调用）是在分布式对象间通信的Java本地方法，它使应用程序调用远程方法像调用本地方法一样，不需要考虑所调用对象的位置。RMI-IIOP是RMI的扩展，是符合CORBA标准的对象通信协议，也是J2EE默认的组件通信协议。Java IDL允许J2EE应用组件通过IIOP协议访问外部的CORBA对象。 l 安全服务JAAS（Java Authentication and Authorization Service）用两个步骤实现安全性：认证，即由用户提供认证信息（如用户名和密码）来获得系统认证，这一过程又称之为登录；授权，在被确认为合法用户后，系统根据用户的角色授予其相应的权限。J2EE的授权是基于安全角色的概念，一个安全角色是一个拥有相同权限的逻辑组。J2EE的安全角色由应用组件提供商来定义。 l Web服务支持 目前J2EE还不提供对Web服务的支持。Sun提供了一套API及其实现WSDP作为对J2EE的扩展，但目前还不是J2EE规范的内容。在WSDP中，JAXP用来解析XML文档;JAXR向UDDI服务器注册Web Services；JTX/RPC用基于XML的协议（如SOAP）来发送和接收XML文档；JWSDL处理WSDL文档。虽然J2EE不是为Web服务而生，但它现在正在努力追赶Web服务的脚步。 多层应用模型 从应用的角度来看，J2EE为企业应用系统的开发提供了一种多层分布式企业应用模型。在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。 如图2所示，J2EE定义了一个典型的四层结构，分别是客户层、Web层、商业逻辑层和企业信息系统层。 在应用开发时，J2EE定义的四层模型可根据实际情况灵活运用。由于除了Applet外其他的组件都可以访问数据库、EJB组件和企业信息系统，所以通过不同层的取舍及组合，可以衍生出许多应用软件开发模型，如基于Web的四层模型、基于桌面应用的三层模型（不包括Web层）、B2B模型（不包括客户层）等。如果应用系统比较简单，一般不用EJB作为逻辑层，而直接用Web组件来实现商业逻辑和数据访问，毕竟EJB的开发和部署费用还相当高。 1.2 .NET.NET开发平台一推出，就开始了与J2EE平台的竞争。它的绝大部分是微软Windows DNA(Distributed Network Architecture)的重写，DNA是微软以前开发企业应用程序的平台。Windows DNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。从战略角度看，.NET开发平台担负着整合.NET战略的重任，但它最直接的目标则是努力为微软保留住庞大的Windows用户基础。 微软的Windows开发用户群是微软通过Windows操作系统获得的最大财富。对于为什么要推出.NET开发平台，微软表示，主要原因之一就是由于Java向开发者承诺的硬件和操作系统无关性，可能会导致这些用户转向其他平台。虽然开发平台本身不会给微软带来很多收益，但Windows程序员是企业内部对微软产品的主要支持力量，商用软件的开发者形成了向客户销售微软产品的重要渠道。如果微软可以让开发者在.NET开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。 认识.NET 认识.NET最好的方法是看它做什么。.NET战略将互联网本身作为构建新一代操作系统的基础，并对互联网和操作系统的设计思想进行合理延伸，使开发人员能够创建出与设备无关的应用程序，以便轻松实现互联网连接。.NET包括一个相当广泛的产品家族，它们构建于XML和互联网产业标准之上，为用户提供Web服务的开发、管理、应用和体验。图1是对.NET战略的总体描述。组成.NET战略的五个方面包括： .NET开发平台 这是一组用于建立Web服务应用程序和Windows桌面应用程序的软件组件，包括 .NET Framework（框架）、.NET开发者工具和ASP.NET。于今年3月发布的Visual Studio .NET将是RAD开发工具中一个重要的产品。 .NET服务器 能够提供广泛聚合和集成Web服务的服务器是搭建.NET平台的后端基础。 .NET基础服务 密码认证、日历、文件存储、用户信息等基础服务是必不可少的。微软正在着力建设的.NET My Services等基础性服务平台是这方面可以借鉴的例子。 .NET终端设备 广泛的连接互联网并体验Web服务的终端设备是实现.NET的前端基础。PC、PDA以及各种嵌入式设备将在这个广阔的天地里发挥作用。 .NET用户体验 能够满足人们各种各样需求的用户体验是.NET的最终目标，也是.NET的价值实现。 在这五个组成部分当中，.NET开发平台中的 .net框架是.NET软件构造中最具挑战性的部分，其他四个部分则紧紧围绕.NET框架来进行组织整合。 .NET 框架内核 .NET框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全、高效的执行环境。所有在.NET平台上创建的应用程序运行都需要两个核心模块:Common Language Runtime（CLR，通用语言运行时）和.NET Framework类库。CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。.NET Framework类库则向程序员提供软件组件，来编写在CLR的控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网络访问的每一样功能。该类库为开发提供了三种基本编程模板：基于ASP.NET的Web表单应用、基于ASP.NET的Web服务应用和基于传统GUI交互的Windows应用。图2描述了 .NET开发平台的组成。 CLR.NET的虚拟机 CLR为.NET应用程序提供了一个托管的代码执行环境。托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。这些工作包括内存管理、即时编译、组件自描述、安全管理和代码验证，以及其他一些系统服务。CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET应用程序就可以独立于语言。CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性、接口等组件编程特性。 CLR中的自动垃圾收集器负责.NET应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。 即时编译器在运行时将中间语言以调用的对象方法为单位动态编译成本地二进制代码。中间语言是在.NET平台下编译器输出PE文件（Windows可执行文件）的语言，它为.NET平台提供了多语言支持，允许开发者使用20多种不同的编程语言。而元数据是一个内嵌于PE文件的表的集合，描述了代码中数据类型等在代码执行时CLR需要知道的信息。元数据使得.NET应用程序代码具备自描述特性，提供了类型安全保障，而这在以前需要额外的类型库或接口定义语言（IDL）。 CLR根据托管组件的来源（如互联网、企业局域网、本地机器）等因素确定各组件的信任度，并根据信任度来限定它们执行诸如读取文件、修改注册表等敏感操作的权限。此外，CLR借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在的类型不匹配问题。通过代码访问安全机制，开发人员可以为应用程序指定完成工作所必需的权限。CLR不仅规定了代码访问安全，还规定了基于角色的安全。基于角色的认证为互联网上分布式组件的执行提供了安全保证。 值得指出的是，CLR通常寄宿在其他高性能服务器的应用程序中，比如互联网信息服务器（IIS）、SQL Server数据库服务器等。这样，开发者可以充分利用CLR诸多安全、高效的优点来部署自己的商业逻辑。 类库组件和服务的家园 .NET Framework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，不管是传统的命令行程序还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET或Web服务应用。与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。它将核心Win32 API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。下面是它所提供的一些核心服务： 系统框架服务 服务框架包括一套开发人员希望在标准语言库中存在的基类库，如集合、输入/输出、字符串、数据等基类。基类库还提供访问操作系统服务的类，如图画、网络、线程、加密等类型。此外，服务框架也包括数据访问类库以及开发工具。 ADO.NET组件 ADO.NET为基于网络的、可扩展的应用程序和服务提供数据访问服务。它不仅支持传统的基于链接指针风格的数据访问，而且对于更适合于把数据返回到客户端应用程序的无链接数据模板，它也提供高性能的访问支持。 XML数据组件 通过它开发人员可以对任何数据进行XML转换、传输和确认，所有数据都可以被看做是XML格式的。同时，系统也支持ADO.NET数据与XML数据之间的通用转换。 Windows表单组件 Windows表单组件为开发人员提供了强大的Windows应用程序模型和丰富的Windows用户接口，包括传统的ActiveX控件和Windows XP的新界面，如透明的、分层的浮动窗口。对CLR的强大支持也是Windows表单组件令人兴奋的地方之一。 ASP.NET应用服务 ASP.NET的核心是其用于处理基于低级结构HTTP请求的高性能的运行语言，其编译运行的方式大大提高了它的性能。ASP.NET使用基于构件的.NET框架配制模板，因此它获得了诸如XCOPY配制、构件并行配制、基于XML配制之类的优点。它还支持应用程序的实时更新，同时提供高速缓冲服务，以改善性能。 ASP.NET Web表单 ASP.NET Web表单把VB表单高效率的优点带到了Web应用程序的开发中。ASP.NET Web表单支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的、更加结构化的方法。它提供一套映射传统HTML用户接口部件（包括列表框、文本框和按钮）的ASP.NET Web表单控件和一套更加复杂的Web应用控件（如日历和广告转板）。 对Web服务的支持 ASP.NET应用服务体系架构为用ASP.NET建立Web服务提供了一个高级的可编程模板。虽然建立Web服务并不限定使用特定的服务平台，但是ASP.NET的许多优点将简化其开发过程。使用这个编程模型，开发人员甚至无需理解HTTP、SOAP或其他任何网络服务规范。ASP.NET可以利用现存的体系架构和应用程序，为在互联网上绑定应用程序提供了一个简单的、灵活的、基于产业标准的模型。 1.3 J2EE vs .NET市场从技术的发展来看，大型的用户、或是有着成功实施经验的用户，并不会因为新技术的推出，而盲目地否定旧技术，他们总是在保护投资的前提下，在不推翻现有架构的前提下，有选择地挑选适合他们的技术。J2EE已经是一个成熟的、成功的企业级应用解决方案，拥有大量的客户，已经实施了J2EE的企业不太可能在Web服务的时代中全面否定J2EE而去接收.NET。而.NET是一个全新的架构，虽然它的开发语言中，依然包含了诸如VB、C+等传统开发语言，刚刚接触.NET的开发人员会以为能将以前使用VB开发的代码平滑地转移到.NET平台下来。其实不然，VB.NET的语法与VB 6.0已经有了根本性的差别，与其说VB.NET是VB 6.0的升级，不如说VB.NET是C#的Basic版。由于采用了CLI的结构，VB.NET将很难兼容以前的VB 6.0的代码，大量的VB的代码无法顺利升级的.NET下来，我们期待着Microsoft能够提供转换程序以实现代码的升级。虽然在原代码级别上的升级变得不是那么容易，然而开发人员仍然可以在.NET平台下，将原有的COM组件进行重新包装，形成.NET平台下的Web服务组件。虽然在继承旧有技术上，.NET做得不是非常优秀。不过它的整个平台、开发工具的高集成性和友好的开发环境将给开发人员留下深刻的印象。在Java领域中，无论是Borland的JBuilder 6、还是SUN的Forte for Java，又或是IBM的WebShpere Application Developer以及Visualage for Java都无法达到VS.NET的生产效率。开发工具是.NET的一大优势，同时.NET平台对Web服务规范的支持力度也仅有IBM的Java平台能够与之比拟。因此，我们认为在企业级应用场合，如果已经采用了J2EE架构的，应该会在Web服务的时代继续使用J2EE架构。而原先就是采用Microsoft架构的，由于技术的延续性考虑，大多数仍然会选用Microsoft的.NET。而那些采用其他技术的企业级应用则会视对开发效率，安全性、可靠性、维护代价都不同指标对两种架构进行考察，应该说机会是均等的，J2EE强在有大量的应用实例，而.NET强在整合集成的优秀开发部署环境。在中小级别的应用领域，J2EE的占有率优势不再那么明显，一方面，一贯以来Microsoft特长于这个领域，另一方面，Java解决方案已经是如此地深入人心，即使是中小企业也会考虑J2EE架构，在这个领域，两者平分秋色。而在桌面应用(Web Service客户端)领域，除了一些管理客户端会采用Java开发以外，绝大多数的应用应当毫无疑问的会使用Microsoft的技术在Microsoft的平台上开发和部署。强强对抗从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，它的市场推广活动中，无时无刻不凸现其作为Web服务的开发和部署平台的特征。可以说，.NET天生就是为Web服务准备的开发平台和部署平台，.NET就是Web服务平台。相对.NET而言，J2EE是一个比较老的东西，最初它是为了将Java平台拓展到企业级解决方案的应用领域而制定的一个平台框架规范，随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，是无法回避业界的重大技术革命-Web服务的，随着Web服务技术的发展，J2EE不断地将Web服务的支持引入进来。有多家公司已经构建了基于J2EE的集成开发环境(IDE)和应用服务器。他们中的多数已经开始在产品中支持Web服务的创建、部署和运行，对Web服务标准的支持和复杂的程度则随厂商的不同产品而异。多个独立的公司，包括IBM、BEA、Oracle、HP、SUN等，在他们的基于J2EE的开发工具和应用服务器的中正在提供对Web服务的支持。当在这个技术领域中有多个竞争产品，这时就意味着没有单个公司的垄断。在过去的四年中，J2EE已经被证明是一个稳定的、可扩展的、成熟的平台。新增的对Web服务的支持是这个平台的又一个特征。Microsoft进行Web服务开发的基础开发工具(集成开发环境IDE)是Visual Studio.NET，使用Visual Studio能够确保了产品的强壮性和易用性。Microsoft同时提供了支持Web服务的服务器软件，包括BizTalk 2000以及SQL Server 2000等。然而，这所有的工具、服务器和技术都是由一家公司控制：Microsoft。尽管Microsoft 公司对Web服务技术的做出的承诺和稳定性没有任何问题，但是没有竞争，技术的提供和推动也许不是最好的。不过Microsoft刚刚在它的网站上提供了.NET的核心CLI for FreeBSD的原码下载。这也许是一个好的开端。尽管.NET从Windows DNA体系框架中继承了大量的特征，但是它仍然相对较新，需要被证明能够提供企业范围的应用框架。Web服务支持整体上看，J2EE是通过一组API包(JAXM,JAXP,JAXR,JAX-RPC)对Web服务提供支持。J2EE的Web服务实现一般是通过EJB来实现的。当然也可以把提供Web服务实现的Java应用独立出来，这完全依赖于设计和构建应用程序的业务处理和数据逻辑层。而在.NET中，Web服务直接构建在平台中，.NET框架提供完整的服务标准如SOAP、WSDL和UDDI。.NET框架中Web服务的实现一般通过.NET Managed Component(包括Managed Class以及COM/COM+组件)来实现。从使用者的角度来看，两者都是Web服务的开发和部署平台，在这里，我们将首先来比较一下两者对Web服务的支持力度，比较将从以下四个方面来进行：1. 服务实现 (Service Implenmentation) 2. 服务调用和执行 (Service Invocation and Execution) 3. 服务描述 (Service Description) 4. 服务发布、发现与绑定 (Service Publishing, Discovery and Binding)服务实现目前来看，实现一个Web服务，实际上是意味着，首先要将服务调用所需要指定的操作以及操作所涉及的数据结构化，并且将其组织成符合SOAP规范的XML消息文档，然后该Web实现需要能解释和处理这个XML文档。当一个Web服务被实现之后，这个Web服务的客户端就能够向其发送一个SOAP消息，该SOAP消息中包含了具体需要调用的操作以及涉及的数据，这个Web服务接收该SOAP消息并完成处理后，向客户端相应一个SOAP消息，该消息包含了操作的执行结果(返回值)。在J2EE中，通过使用WSDP中的Java API for XML-based RPC(JAX-RPC)，已有的Java类或Java应用都能够被重新包装，并以Web服务的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使用EJB的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web服务的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言，SOAP/WSDL变得透明，这有利于加速Web服务的开发周期。当然如果开发人员认为这样的透明带来了不灵活性，那么也可以直接使用JAXP来手工地处理XML消息。.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前的成功者的优点，.NET大量地吸收了Java平台，甚至是J2EE平台的优点，其中，最重要的一点就是.NET不再完全沿袭Microsoft先前的技术，从.NET开始，.NET应用不再以本地机器代码运行，而是编译成中间代码(Microsoft Intermediate Language)，由称为CLR(Common Language Runtime)的虚拟机来运行，这样，.NET也具备了强大的跨平台的可能。.NET不但在底层跨平台，在开发语言上，则能以较小的代价支持更多的开发语言，它支持的所有开发语言，包括VB.NET、C#、C+、JScript等都被编译成相同的中间代码，使用相同的运行库执行。因此，从平台特性而言，.NET平台是迄今为止最通用的应用开发和部署平台。在.NET平台上，开发人员可以自由地使用各种语言来开发Web服务，.NET平台同样提供了优秀的快速开发工具，将SOAP/WSDL等繁复的技术点对开发人员透明，当然，同样开发人员也可以使用MSXML来直接处理XML消息。服务调用和执行SOAP(Simple Object Access Protocol)为在一个松散的、分布的环境中使用XML对等地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。SOAP规范主要由四部分组成： SOAP信封用于包装数据 可选的编码风格用于表示应用相关的数据类型以及数据 请求/响应的消息交换模式 可选的SOAP/HTTP绑定SOAP是Web服务的主要通信协议。一个Web服务一般而言是以一个SOAP Listener的形式存在，当它收到SOAP消息，会将消息解码，并将其中的数据传给相应的商业处理模块进行处理，处理结果回送给SOAP服务器，SOAP服务器再将处理结果包装成响应消息返回调用者。J2EE使用WSDP中的Java API for XML-based RPC (JAX-RPC)来完成使用SOAP方法来调用远端服务的功能。JAX-RPC使得Java开发人员能够利用符合SOAP/1.1规范的基于XML的RPC方法来完成Web服务之间的交互。当一个JAX-RPC服务被设计并实现之后，它就需要被部署到服务器端的JAX-RPC运行系统中。部署的步骤会视具体实现时使用的组件的不同而有所不同，例如，一个基于EJB的服务就需要被部署到EJB Container中。在JAX-RPC服务的部署过程中，可以使用部署配置工具来为这个JAX-RPC服务配置一个或多个协议绑定。绑定的实质就是将抽象的服务定义与指定的基于XML的传输协议相结合，一个绑定的例子就是在HTTP之上的SOAP 1.1。而对于这个Web服务的客户端而言，它应当根据描述该Web服务的WSDL文档中所描述的绑定信息与这个Web服务进行远程调用。对于.NET而言，实现Web服务的方法与J2EE中描述的方法是类似的，同时具有更好的集成性。.NET的开发人员目前实现Web服务有三种典型的方式： 使用内置的.NET SOAP消息类 手动地构建一个SOAP Listener，使用诸如MSXML、ASP或者ISAPI等技术 使用Microsoft SOAP Toolkit v2来构建一个Web服务，这个Web服务链接了一个商业构件，一般来说，这个商业构件是使用COM技术的，这个有一些类似与J2EE里面的Java类或EJB的SOAP包装。同样，.NET也是通过Microsoft SOAP Toolkit这样的工具来使得客户端能够根据描述Web服务的WSDL文档与Web服务进行远程交互。服务描述为了使Web服务的应用能够不断增长，非常重要的一点是，我们需要有一种结构化可理解的方法来描述Web服务，使得Web服务的描述信息能够被程序自动处理，这是Web服务即时装配的基本保证。而WSDL(Web Services Description Language)正是这样的一种工具，它是一种类似IDL技术的服务描述语言。WSDL 定义了一套基于 XML的 语法，将Web服务描述为能够进行消息交换的服务访问点的集合，从而满足了这种需求。WSDL 文档将Web服务定义为服务访问点或端口的集合。在 WSDL 中，由于服务访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行重用。J2EE通过Java Web Services Developer Pack(在文章的后面部分，将简称为WSDP)中的Java API for XML-based RPC(JAX-RPC)提供了Web服务的RPC调用的支持，其中Web服务的RPC调用界面使用的规范正是WSDL。使用J2EE开发和部署的Web服务，能够使用WSDL来发布它的调用界面，Web服务之间的所有的XML交互消息及其交互模式都应当遵循对应的WSDL文档的描述，同时Web服务的消费者也可以在各种Web服务的注册中心中查询并获取Web服务的WSDL描述。与J2EE Web服务相同，.NET Web服务同样支持WSDL 1.1规范，同时采用WSDL作为Web服务界面的描述工具。此时，我们常常将一个XML命名空间与这个WSDL文档相关联，以使用这个XML命名空间来唯一标识这个WSDL文档所描述的Web服务。.NET提供了一个Client端的组件以使应用程序能够调用由WSDL文档描述的Web服务的RPC入口，而同时也在Server端提供了一个组件以实现从WSDL文档到COM组件的映射。服务发布、发现与绑定当Web服务被实现之后，它应该被以某种形式被发布到某个可提供查询的在线服务站点中，以使得潜在的Web服务的使用者能够发现这个Web服务。关于如何访问这个Web服务的技术信息应当同时被发布，以使得发现这个Web服务的客户端能够通过这些技术信息与Web服务进行交互，具体地来说，这些信息称为绑定(Binding)信息。注册服务是目前用于发布、发现和绑定Web服务的主要方法。注册服务中包含了用于描述Web服务以及Web服务提供者的数据结构和分类信息。注册服务即可以由企业自己来提供，也可以使用第三方的中立服务。在J2EE的WSDP中，Java API for XML Registries (JAXR)提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范向兼容的Web服务，这里的Web服务即为注册服务，一般来说，注册服务总是以Web服务的形式运行的。JAXR支持三种注册服务类型： JAXR Pluggable Provider： 实现了JAXR规范的特性，而又独立于任一种指定的注册服务。 Registry-specific JAXR Provider：实现了JAXR规范的特性，同时以指定的某一种注册服务的方式工作。 JAXR Bridge Provider：并不指定一个特定的注册服务，而是作为与其他类型的注册服务交互的桥梁而存在。其他类型的注册服务可能包括UDDI注册服务或是ebXML注册服务。而对于Microsoft的.NET，最初，Microsoft使用一种称为DISCO的文件来发现Web服务，而随着以Microsoft、IBM、Ariba作为创始企业的UDDI.org发布UDDI规范之后，.NET将UDDI注册服务作为其内置的Web服务的发布、发现机制。在VS.NET中，内置了一个私有的UDDI Registry供开发使用，同时提供了一个基于UDDI注册服务的非常友好的Web服务发现的GUI。就目前来看，UDDI提供了最佳的保证Web服务互操作性的注册服务。而Microsoft也是UDDI实现的领先者。在它的Office XP中，也提供了使用UDDI集成Web服务的功能。全年年底，IBM和Microsoft又一起发布了WS-Inspection规范(也称为WSIL规范，Web Services Inspection Language)，WS-Inspecation将作为UDDI的补充，在兼容UDDI的基础上，为未注册入UDDI注册服务的Web服务提供发现机制。第三方厂商的支持在前面的内容中，我们已经看到，在对Web服务的支持上，J2EE和.NET基本上是不相上下的，唯一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。在这里来考察一下第三方厂商对两种架构的支持。J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等都洒下了大笔的投资在J2EE的实施上。目前市场上最好的J2EE Application Server并不是SUN与Netscape合资的iPlanet，而是Bea的WebLogic和IBM的Webshpere。一年一度的JavaONE都有成千的开发商参加。由于J2EE是开放的规范框架，任意厂商只要有实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的是这些参与J2EE的厂商都具有很强的实力，基本上可以这么认为，除了Microsoft以外，基本上所有的计算机软件业巨擎都对J2EE情有独钟。然而，J2EE虽然是开放的规范，但是它的使用却不是那么的开放，每家使用J2EE技术的公司都不得不为此向SUN支付一笔不小的费用。同时也正因为SUN对J2EE规范的独家控制，使得J2EE规范的开发进度有些缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，WSDP只是一种插件形式的扩展支持。有消息表明，在今年年底前，SUN和Java领域的其他支持商，包括IBM、Bea、Silverstream等会就J2EE如何支持Web服务达成一致，然而这一切均存在变数，其中的根结就在于Sun对Java技术的独家控制。同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发Java平台的Web服务支持，IBM在这个领域的步伐是飞快的，它的WSAD(Webshpere Studio Application Developer)集成了大量的自行开发(部分来自于A，不过这项项目的前身大多是IBM发起的，而后移交给A的)Web服务组件，业已称为Java领域的开发Web服务的最佳开发工具，同时IBM的Websphere也慢慢向Web Service开发部署应用平台的角色转化。而对于Microsoft的.NET而言，虽然从一开始，Microsoft就给人以独占、垄断、不开放的形象出现在平台市场上。然而，它的.NET却表现出了前所未有的开放姿态。.NET的主力开发语言C# 已经提交给 ECMA 进行标准化，ECMA是一个致力于推动行业范围内采用信息和通信技术的非特定供应商的国际标准组织。C# 的标准化使希望在任何平台上都可以实现 C# 编程工具的公司能够实现他们的愿望。Microsoft 还向 ECMA 提交了 Microsoft .NET 框架的一个子集，叫做公共语言架构(Common Language Infrastructure，CLI)。这将使其他供应商能够在各种平台上实现 CLI，以便用 .NET 框架提供的基本体系结构模型所写的软件可以在各种平台上用各种工具来创建。大家应该能够发现，CLI是类似于Java VM的机制，是.NET跨平台的基本保障。同时具体的实施也已经开展：著名的Linux桌面环境GNOME的开发商，美国Ximian公司在2001年7月开始启动一个名叫Mono Project的开放源码版.NET的开发项目，旨在使开发者能够编写同时在Windows和Linux上运行的.NET程序，Mono计划主要包括一个C#编译器、与Microsoft 公司的Common Language Infrastructure(CLI)兼容的类库、Linux版Common Language Runtime(CLR)编译器。最近，Microsoft又在它自己的网站上提供了CLI for FreeBSD/Windows的原码下载，为推广CLI踏除了探索性的一大步。虽然这些只是起步，然后谁也不能说，它就不会象当初的Java那样，从Sun的小玩具，变成了今天如此重要的开发平台。2、WebSphere和WebLogic随着IBM公司WebSphere 4.0 的高级版和BEA Systems Inc.的WebLogic Server Premium Edition 6.1的发行，我们很容易觉察到应用服务器市场在一步步地走向成熟。 WebSphere 4.0早