前言

在上期中，笔者针对J2EE与.NET的基础架构支持技术，做了全面性的介绍，同时也将这二大架构的技术做了简要的比较。在本期中，我们将再深入探讨其中重要的运作架构模型，以期能够达到深会探究的目的，也希望读者可以藉由本文的比较，找出您心目中所谓的“赢家”，以利各位在未来软件研发或决策上，能有更正确的决定。

本文中，将先以组件架构以及客户端架构部份的讨论为开端，接着讨论二大架构下最重要的两大议题：数据／目录存取，以及对XML的支持，由检讨二者开发的架构性，让读者能够更了解二者所采取的市场策略。接下来，我们就开始这系列的探讨旅程。

回顾组件架构

由于J2EE是由升阳公司所提出的运作架构，因此在这运作架构中的主角自然是所谓的JavaBeans 以及EJB（Enterprise JavaBeans）组件模型。JavaBeans是所有Java组件的基础精华，其文件中定义了对象属性（attribute）、事件处理程序（event-handling）、对象永续性质（persistence）、对象自省功能（introspection），伴随着Java执行所提供的各项特色，如内存管理、安全管理，以及JavaBeans架构，所定义出来的分布式计算版本，其中包含远程访问与运作组件，分散或安全管理，分散或事务处理支持，更强大的对象永续性管理，对象运作周期管理（life-cycle management），以及资源运作管理（resource pooling）等等。

反观微软的.NET架构，是由微软最初的对象运作模型所演变而来，包括COM（Component Object Model）以及COM+所组成，这两种组件运作模型，将随着.NET架构的出现，而逐一被新的组件架构所取代。在新的.NET架构下，共享语言执行环境（Common Language Runtime, CLR）肩负起提供基础服务的重责大任，包括安全管理以及内存管理等等，而这些有如Java虚拟机的功能，是以前COM或COM+模型中所未见到的。同时.NET也延伸了既有的微软组件架构，包括扩充多重接口继承（multiple interface inheritance）、具有弹性的对象诠释数据（meta-data），以及新的连接模型（delegate model）。总而言之，CLR扩充了COM以及COM+的组件架构，加入了新且丰富的特色，彻底地区隔出与传统COM架构的不同。

微软在组件架构开发的历史由来已久，部分原因乃是因为微软对平台开发者提供了主要的整合性开发环境（包括Visual Studio及其前身），而微软的组件架构，随着微软操作系统的演进，也进行了多次的进化与改版。反观Java的组件架构，虽未经多次改版的洗礼（也就是说，不具有传统常见的兼容性负担），但以其与Java语言本身的密切关系，很可能会对架构本身的演进，带来一定程度的阻碍。

对各类型客户端的支持比较

笔者在此粗略地将客户端分为两大类型：一为应用程序类，也就是所谓的“胖”客户端（fat clients）；另一则为动态产生的网页类，也就是所谓的“瘦”客户端（thin client，或称精简型客户端）。

升阳阵营

可视化对fat client来说，J2EE提供了Java的Swing接口，也就是一组由标准的JavaBean组件所形成的集合，透过可视化开发环境适当的组合（如WebGain的Visual Cafe，Borland的JBuilder，IBM的VisualAge for Java等等），构成与用户互动的可视化接口。

而对thin client的开发而言，J2EE则提供了Servlet以及JSP（Java ServerPages）技术来建立以HTML、WML，或XML为基础的动态网页客户端。目前支持Java Servlet以及JSP技术的应用服务器甚多，其中包括商业性质的（如BEA的WebLogic , iPlanet ,IBM WebSphere以及SilverStream等等）以及非商业性质的（如Apache的Jarkata开发计划，Enhydra，以及Resin等等）。

微软阵营

反观微软阵营，针对fat client部分，传统上都是透过提供微软的基础对象MFC（Microsoft Foundation Classes）来进行建构工作。但是从新的.NET架构开始，微软转为提供新一类的基础建构组件集，称之为Windows Forms。基本上，Windows Forms的功能与角色，和原先的MFC相同，但是微软为了新的.NET架构执行环境，不得不将MFC以Windows Forms来取代。

而针对thin client部分，微软则发展出新版本的ASP（Active Server Pages）来因应，称为ASP.NET。基本上，ASP.NET的功能与ASP并无不同，但是为了因应新的.NET架构执行环境，也就是要在新的共同语言执行环境（CLR）下运作，因此才对ASP做了一定幅度的进化。同时以ASP.NET所撰写的程序片断不再是利用解译（Interpret）的形式来执行，而是转为由编译（Compile）成CLR下的执行IL位码来取代。

对数据存取与目录服务的比较

J2EE与.NET平台在数据存取以及目录服务方面，均提供了不同形式但类似功能的程序开发接口。

升阳阵营

在J2EE环境中，存取数据源的方式，主要是透过JDBC接口来完成。JDBC是一个可以涵盖不同关系数据库的共通接口，将各种不同关系数据库的访问方法，改为统一的存取方式。由于JDBC是一种较为低阶的程序开发接口，由几种最基本的存取单位来进行运作（Connections, Statements, ResultSets）。因此在新的JDBC 2.0之后，便开始延伸这些基本功能，包括连接资源管理（Connection Pooling）、支持分布式的交易模型（Open XA）。

这些延伸都是由新的Java 2平台来提供，而J2EE使用了这样的平台后，自然令涵盖这些功能，而更高阶的数据存取途径，则是由J2EE中的entity bean以及数据永续化服务来共同完成。在此类商业性的产品上，有许多第三方提供商品与服务，如升阳的Java Blend，WebGain的TopLink，但是这些都没有涵盖在J2EE所定义的范围之中。

接着提到的是目录服务，在Java环境中，目录服务是由JNDI（Java Naming and Directory Interface）来完成。JNDI是一种接口定义，其下可以涵括许多不同的数据对应形式。包括名称、本文内容，以及属性值等等。JNDI所能涵盖的目录服务实作目前约有LDAP、Novell NDS、NIS、DNS，以及DSML（Directory Service Markup Language）来源等。

微软阵营

反观微软的数据源存取形式，是源自于微软自行发展的OLE以及ODBC接口，后来演化形成的DAO（Data Access Object），以及最后所形成的ADO（ActiveX Data Object）接口。ADO目前的角色，就如同Java世界中的JDBC以及JNDI的混合体，也就是说，所有的数据与目录的存取动作，都被定义成为几个基本的存取动作（Connections, Commands, 以及RecordSets），共同对数据源与目录服务进行运作。ADO有着某些比JDBC 2.0更为强大的功能，包括数据记录的浏览以及脱机的数据存取。可是ADO也有其缺点，在于ADO是会仰赖以COM模型为基础的OLE DB以及ODBC接口，间接地严重影响其扩充性以及互动性。

由于ADO有以上的缺点，微软便在.NET架构中重新定义ADO.NET，用来取代既有的ADO接口。ADO.NET舍弃了原有的COM-based基础，而改以开放性的XML数据传输为其核心能力。因此，ADO.NET在开放性方面大幅的改变了以往ADO接口的不足。由于XML在存取以及可移植性方面表现优越，因此在.NET架构的观点中，数据源以及目录服务是可以变成虚拟的，开启了更多可能性。但是XML的缺失，也是其优点，便是较高的可读性，也就是较为庞杂的数据描述，而这间接影响了数据处理的效率。

对一般性XML数据处理的支持

就XML数据处理而言，J2EE与.NET平台都提供了最基本的支持，其中包括了最重要的文件对象模型（Document Object Model, DOM）呼叫接口API的定义，可以用来产生DOM的解释与结构。

升阳阵营

Java在XML数据处理方面，主要是提供了JAXP（Java API for XML Processing），来支持DOM以及SAX（Simple API for XML）模式的处理，同时也提供了一个运作架构，可以让不同的解译模块（parsing engine）嵌入执行。在此笔者必须强调，目前在J2EE架构中，并没有强调XML API的存在，因为对XML的处理支持，是在Java2基本工具中就已经存在。但是从J2EE 1.3开始，将会陆续加入对XML处理更进阶的支持，这不但具有象征性的意义，同时也表示出J2EE走向开放标准的努力。

在Java环境中对XML数据处理的支持并非不足，相反地，Java对XML的支持是广泛且多样的：我们可以发现，与XML相关的新标准，大都是用Java先实作出来的。而升阳公司近来更发表了在讯息传递方面的标准JAXM（Java API for XML Messaging），其中使用了ebXML来提供讯息服务。此外也发表了数据系结方面的标准JAXB（Java API for XML Data Binding），其中使用XML Schema以及XML Binding来定义XML数据与Java物之间的建构与解构关系。目前这些标准正在讨论加入J2EE的相关议题，相信会在未来的J2EE版本中见到这些对XML处理丰富的技术支持。

微软阵营

反观微软阵营，对XML数据处理的支持，也是不遗余力的。在最基础层次的技术方面，微软提供了MSXML程序接口来支持DOM以及SAX模式的处理。更重要的是，XML在.NET架构中，是担任多处的基本数据格式，就如上一节中，我们已经讨论到ADO.NET是使用XML来当做底层的数据传输协议与格式。一般来说，.NET组件在各种不同形态的数据呈现上，都是以XML为其默认的选择。更有趣的是，在.NET架构下的各项Web服务（.NET Web Service）可以很轻易地输出XML接口，而以SOAP协议在网络上流通。关于SOAP协议的介绍与各方面的优劣，笔者将在未来几期中予以介绍。

而由于是使用SOAP协议，.NET架构下的Web服务开启了许多有趣且实用的应用可能：因为是使用XML当做数据传输格式，因此只要是使用SOAP协议的客户端，无论是Web浏览器，甚或是行动式的设备，都可以轻易地使用这些Web服务。

主要的开发架构差异

笔者在前几节中，已经重点式的就两大架构功能性的异同，为读者做分析。但是.NET架构与J2EE架构之间的比较，是个涵盖许多不同层次的问题。笔者在七月号中曾经就特色上的差异做了介绍与比较，而在八月号中则是针对架构中的各项支持技术做比较。而在本期中，主要是针对一些不同层次的比较进行探讨。而在本节中，笔者要讨论的是一个根本上的差异，也就是开发模式上的不同，在上期中，我们已经对这方面的讨论埋下了伏笔，请参考(表一)与(图一)，在本节中，我们就是要针对这样的层面，为各位做较为详细的探讨。

《表一 两大架构实作哲学的差异》

《图一 两大架构开发流程的比较》

无论是微软的.NET架构，抑或是升阳的J2EE架构，都是以最主要的三项基础做为比较标准：程序开发语言、对象模型、以及虚拟机平台，而这三项基础的构成的最主要差异，就是在于执行平台环境的设计目标，以及其上所支持的开发与布署模式，观察家与评论家是最容易给出的结论就是：

“J2EE是一种特定语言但不限定平台的架构，而.NET则是一种不限定语言，但是却有特定平台限制的架构。”

这样的结论并没有真正的谬误，但是似乎过于简化，原因如下：

但无论如何，J2EE在规格上仍是跨平台的，而.NET仍是以Windows平台为其主要基础。

J2EE是一个由核心Java环境中所演化产生的产品，其基础是放在Java程序语言、Java虚拟机（JVM）、以及Java核心程序接口（core API）三者上。Java的程序开发模型，是先以Java语言撰写对象类别，然后被编译成跨平台的程序位码（byte-code）。而这样的位码，必须要符合JVM的规格标准。这些编译好的位码，可以在各式平台上的JVM环境中被解译与执行，如Solaris、Windows、Linux、AIX等等。在JVM规格中，定义了具有内存管理以及安全管理特色的执行期环境。

此外，Java程序代码以及编译过后的位码，更可以再进一步的被编译成特定平台的机器码以供执行，或是实时地透过JIT（Just-In-Time）编译程序来进行机器码的转换产生。因此，以J2EE来开发，就意味着程序一旦以Java撰写完成，便可以在跨平台的环境中运作；而对于使用其他程序语言的开发的对象或组件，则可以透过JNI（Java Native Interface）或是CORBA接口来进行处理。整个J2EE的开发模型，可以由(图二)来表示。

《图二 J2EE的开发模型数据源 SD Magazine》

微软的.NET架构主要是以共同语言执行环境（CLR）为基础。所谓的CLR环境，主要是由一个与程序语言无关的中介语言程序代码（Intermediate Language code, IL code），以及一个提供内存管理与安全管理等等特色的执行期环境所组成。这样的架构，看上去似乎可以和Java的运作环境形成模拟，但两者之中最主要的差异，是在.NET平台可以用多种支持CLR组件模型的程序语言来进行开发，也就是说，针对这些程序语言，必须开发出相对应编译程序，来将该种程序语言编译成IL程序代码。这样的模式，将可以让各种不同程序语言所开发的组件都转换到CLR环境中共同合作。请注意，所有IL程序代码都是透过JIT方式转成Windows平台的机器码，或是原始的组件程序也可以直接编译成Windows的DLL或EXE模块，如(图三)所示。

《图三 微软.NET的开发模型 数据源 SD Magazine》

这两大架构之间的异同比较，其实会呈现出相当有趣的现象：当我们针对较为基础性的设计概念比较时，会发现其中每一种比较，都触及了各自架构中重要的发展概念与策略。举例来说，Java在设计上是偏向于单一程序设计模型，但是强调与平台无关的特性。升阳在Java策略上所要强调的，是一旦系统是以Java开发完成，用户将会有极大的弹性与自由来决定多样性的支持工具与组件，更可以任意选择标的运作平台环境。

而反观.NET架构，微软所欲强调的，是一个单一的运作平台环境（Windows），这样的平台环境不但具有与程序语言无关的特性，同时也大量使用XML来支持各式的数据处理特性。微软强调，一旦系统是在Windows的CLR环境中运作，用户将会有极大的弹性与自由来决定多样性的程序开发语言，更可以链接多种组件与Web服务来进行合作，而在合作模式方面则有对象层级的CLR组件链接以及较具弹性的SOAP与XML链接。总而言之，在系统规划上的各种决策，都会因为整合在同一个Windows环境中而明显地得到简化。

策略上的选择与规划

在做完上述的讨论之后，对决策者规划企业系统上，又具有什么样的意义呢？就概念层次来看，我们都将会得到更好的架构与技术，因为微软正努力地修正其Web应用环境，以期能与J2EE相抗衡。由此看来，我们将会会有两种优良的架构平台可供开发选择；更重要的是，有了这两个架构的竞争，微软与升阳将会更加速致力于改善各自平台中较为不足的地方。例如微软会努力改善CLR环境在各种不同平台上的运作可能，而升阳则会加速致力于改善J2EE中XML支持不足的情形。这样竞争下的成长，对两大阵营在企业伺服架构的设计哲学上，都将形成正面的影响。

讨论至此，您仍须面对架构选择的决策问题。如果我们将这些技术性的探讨做一归结，我们将会发现决策的路是相当单纯的。为什么单纯呢？原因就在于架构设计哲学所造成的影响。如果您所拥有的状态，是丰富的Windows平台相关性的话（如内部开发，以及客户的使用上），您将会认为微软的解决方案是较为合适的作法。反过来看，如果您拥有的是许许多多Web上的应用与组件的话，或许在系统上，一个单一程序语言的开发与整合会较为有利。简单地说，如果您需要支持许多Unix或非Windows平台的话，J2EE架构将会是项首选；而如果您偏向于使用多种程序语言共同开发系统的话，.NET架构将会是您的最爱。

后记

笔者探讨至此，已经涵盖到这两大架构的各项议题，同时也就设计哲学与选择决策上，为读者做了说明与分析。至于用户该如何做选择，则可以依据系统以及环境的特性来进行评估。但笔者要再度强调的是，在技术市场变化快速的前提下，要如何慎选开发弹性与支持广度，终究会是最重要的考虑；而朝向开放式的标准与架构，则应当是决策者在做决策时，必须时时牢记在心的原则与重点。