前言

在上期中，笔者针对J2EE与.NET的运作架构，做了概略性的探讨，同时也针对运作架构中的各项组成分子，做了简要的比较（如程序语言、执行环境、基础组件集、以及数据存取技术等），请参考(表一)。在本期中，笔者将针对J2EE以及.NET的基础架构支持技术，做一个全面性的介绍。

《表一 .NET以及J2EE的特点比较》

借着这些支持技术的对应与比较，可以让用户更清楚两大门派的技术源流，同时也可以借着一对一的比较，让用户更清楚对应技术之间的优劣以及使用场合与时机。

接下来在本文中，笔者将先简介目前相关业界中使用升阳与微软技术状态概要，以利读者对业界状况有最基础的了解。接着我们便会深入J2EE与.NET的各项基础架构支持技术，为读者做一番解释。而在本文的后半部，我们照例会来一次“捉对厮杀”，将这群技术做对应与比较，并探讨各项技术的使用场合与优缺点。接下来，就让笔者引领各位开始本次的探讨之旅。

相关业界所采用的开发技术概况

在了解了业界的探用的开发技术之后，我们便可以开始针对这两大阵营的基础架构支持技术，做一个全面性的介绍。除了让读者了解的采用技术内涵之外，同时也可以提供开发者在未来采用各项技术的参考。而由于微软的. NET 架构目前仍处于推展初期，因此尚无法取得市场方面的相关统计。因此本节将就Java应用伺服市场，也就是所谓J2EE应用伺服软件市场的各项统计数据为开端，进行广泛的介绍。

根据美国 IDC 公司的统计，北美的套装应用软件市场在公元2004年时将会成长为具有1600亿美元的规模，这样的规模是公元1999年的两倍有余。同时 IDC 也指出，对于产业的需求来说， ERM（ Enterprise Resource Management ）以及 CRM （ Customer Relationship Management ）的应用将会日益重要，其次则分别为办公室文件生产以及企业协同运作（ Collaboration ）等两项应用。就这样的发展看来，企业应用伺服市场的成长将会逐步扩大（这是由于有 ERM/CRM以及Collaboration 的关系）。因此，企业应用伺服市场实为软件大厂的兵家必争之地。

而就企业应用伺服软件市场层面来看，根据 Giga Information Group的调查指出，企业应用伺服软件的市场，将于公元2003年到达90亿美元的规模（公元1999年时仅为5亿8千万美元，公元2000年为16亿4千万美元），请参见(图一)。由（图一）中我们可以知道，如此剧烈成长的市场，将会引来众多软件大厂的觊觎。在公元1999年时，应用伺服软件市场的第一大品牌为BEA Systems，占有率达32%，其次为IBM的16%以及Sybase的15%，参见(表二)。

《表二 公元1999年应用伺服软件市场占有率分布》

《图一 应用伺服软件市场成长概况 单位：百万美元》

而到公元2000年时，由于这个市场引来众多竞争者的竞食，并且在占有率方面出现了洗牌效应，互有消长。其中BEA Systems的占有率滑落至24%，而IBM则成长至24%，呈现出两强鼎立的情形。其后则有ATG（10%）、iPlanet（9%）、Allaire（8%）、SilverStream（5%-7%）以及Sybase（5%-7%），请参考(表三)。

《表三 公元2000年应用伺服软件市场占有率分布》

到目前为止，伺服软件市场的占有率竞赛尚未停止，甚至有许多软件界的大老正在努力追赶之中（如Oracle等）。因此，在这样的市场中，竞争热络自然可以预见，而技术方面的快速变化与成长，也将会是预料中事。接下来笔者就开始针对J2EE以及.NET的基础架构支持技术，为各位做广泛的介绍。

J2EE的基础架构支持技术

J2EE（ Java2 Enterprise Edition ）是由升阳公司定义出来的开放性运作架构，这项发明其实部分是源自于某些未经预期的风云际会：首先，升阳公司本来想要开发出一个开放式、解译的、具可移植性的程序语言－Java，而在Java以开放性的姿态推广散布之后，引来了许多具有高度兴趣的开发者参与。伴随着90年代软件界对于伺服端运作的组件架构标准化需求渐殷，升阳公司便决定为这样的需求，定义出一套以Java为基础的标准架构，而这样的生产规划结果便是我们所熟知的J2EE。

J2EE是由几项重要支持技术所组成，这些技术涵盖了数种层面，其中包括Web处理技术、基本组件架构、分布式对象通讯、企业组件架构、事务处理、讯息传递、名称与目录服务、以及数据库存取等等，如(图二)所示。

《图二 Java组件模型所包含的各项支持技术 数据源：Middleware》

至于这几项技术层面各涵盖了哪些实质的技术呢？以下我们就来探讨这个重要的议题。

1.Web处理技术

以往的Web处理技术，都会透过所谓的 CGI （Common Gateway Interface）接口来进行处理，以达到网页动态产生的目的。这样的技术，为Web上的数据互动开启了宽敞的大门，同时也开启了Web商业运算的无限可能。但随着软件技术的进步，以及企业界对于开发速度需求的增加，这样的支持技术必须不断的发展成长，才能在应付未来的发展需要。升阳公司有鉴于此，便以Java平台为基础，推出了所谓的 JSP ( Java SeverPages )标准，藉由网页与商业逻辑分离的概念与技术，创造Java世界中的伺服端网页运算标准。在JSP的运作架构下，所有相关于网页呈现的处理，都是用Server Page来完成，而后端需要数据存取以及其他商业运算的部分，则是交由 JavaBeans 组件来负责。这样的分离概念，正符合了所谓 MVC （Model-View-Controller）的运作概念。

2.基本组件架构

在Java的世界中，组件基本上所指的就是所谓的 JavaBeans 。 JavaBeans是一种软件的组件，用以在软件开发中扮演“积木”的角色，藉由堆积木的开发方式，可以达到软件快速成形的目标（fast prototyping）。JavaBeans不但可以加速开发，同时也提供了组件架构的黑盒子特性，让开发者可以在不需要了解组件细部运作内容的情形下，达到建构大型且复杂软件的目的。

3.分布式对象通讯

升阳公司有鉴于对象之间的分布式通讯需求，定义出了所谓的远程对象方法呼叫（RMI , Remote Method Invocation），提供了分布式对象透过网络进行数据通讯的途径。后来更根据OMG（Object Management Group）所定义出来的使用对象需求代理架构（CORBA，Common Object Request Broker Architecture）架构，延伸既有的RMI标准，成为所谓的RMI-IIOP（Internet Inter-Orb Protocol），将RMI推向世界标准。

4.企业组件架构

在Java的世界中，所谓的企业组件架构是以企业JavaBeans（Enterprise JavaBeans，EJB）来对应。EJB是一种伺服端的运作架构，其特色包含了网络、对象，以及分布式计算，这样的技术可以支持企业应用程序的商业逻辑组件开发，同时也支持这些组件在这种伺服架构上的布设。而对象通讯的特性，则是建立在以RMI与CORBA的架构之上。EJB提供了企业组件执行的基础架构，使这些组件都能在受到制约的安全环境下运作。

5.事务处理

所谓的交易，就是试图将应用程序的处理程序，切割成许多细小且连续的工作单元，这样的工作单元，不会受到外界的其他干扰，且执行结果只有完成（committed）或未执行（roll back）两种。在Java的世界中，事务处理部份是由JTA/JTS来予以定义。一个JTA（Java Transaction API）交易，就是一个可以透过J2EE平台管理与协调的处理单位。这样的处理单位，将有能力存取系统中多个组件与数据源。而所谓的JTS（Java Transaction Service），就是提供JTA服务的交易管理者，它主要就是以OMG的OTS（Object Transaction Service）实作为主要目的，且在其下的交易传递部分（transaction propagation）是由IIOP所完成。概括来说，J2EE在事务处理的部分，是定义了一种运作方式，可以大幅简化在分布式多人使用的企业应用程序里的开发负担。

5.讯息传递

所谓的讯息传递技术，目的是在提供一个异步的讯息收发机制。在Java的世界中，这样的工作是JMS（Java Message Service）来完成。在JMS中，一个特定的商业活动讯息，可以得到完整的描述与定义，而透过讯息的交换，应用程序将可以追纵企业运作的过程。JMS的支持的讯息位递方式，主要有点对点（point-to-point style）以及公布/订阅（publish-subscribe style）两种方式。

6.名称与目录服务

J2EE中对名称与目录支持主要是透过定义JNDI（Java Naming and Directory Interface）接口来完成。一个实作JNDI接口的软件，将有能力提供企业应用程序标准的目录运作，如对象属性的关联、以及透过对象属性的搜寻等等。使用JNDI之后，企业的应用程序将可以存取任何型态Java所命名的对象，同时JNDI也可以用来整合各种知名的目录服务（如LDAP、NDS、DNS、NIS...等），达到与传统应用程序或系统共存的目的。

7.数据库存取

在 Java 的世界中，所谓的数据库存取是透过所谓的 JDBC （Java DataBase Connectivity）接口来完成。JDBC提供了与数据库无关的链接方式，让应用程序可以使用各种不同类型的数据源，同时透过J2EE的整合，新的JDBC可以与JNDI通力合作，同时也可以与事务处理密切配合，更可以透过J2EE内部的资源管理（connection pooling）来提升数据存取方面的效能。

在了解了J2EE各项基础架构支持技术之后，接下来我们就来检视一下，在.NET架构中，会有哪些相对应或是类似的支持技术。

.NET的基础架构支持术

.NET 是由微软公司定义出来的分布式运作架构。由于.NET架构的出现，让大家对微软与升阳的竞争关系上，又增加了一分联想。有许多观察家与评论家认为，如果当初微软的分布式网络架构（DNA, Distributed interNet Application architecture）技术够成熟稳定的话，今天就应该不会有.NET架构的出现。但是可以理解的是，.NET绝对不会只是那些DNA组件的重新包装而已，相反地，微软对.NET的期许，应该是一个全新的开始。但无论如何，在.NET平台架构下，也有许多Windows DNA的影子，如(图三)所示。(图三)所说明的是Windows DNA的对象架构。

《图三 Windows DNA组件模型所包含的各项支持技术 数据源：Middleware》

至于.NET中的几项技术层面，是由以下几项实体技术所共享建构而成。以下我们就来探讨这些基础技术：

1.ASP+

这是新一代的ASP技术，主要的用途是增强原ASP既有的功能。ASP+让软件开发者有能力在伺服端去撰写叙述式的程序，并具有编译成为位程序代码的特性。而其后端是使用微软的ISAPI接口来与服务器沟通，进而产生动态的网页输出。

2.ActiveX

所谓的ActiveX组件，就如同JavaBeans一般，是可以在客户端环境运作的组件单位。基本上来说，一个ActiveX控制组件，就是由COM组件所延伸进化而来的。

3.DCOM

这就是微软所定义出来的分布式对象架构。在这样的架构下，软件组件将有能力可以在不同的实体平台上移动。同时借着定义远程对象沟通的协议，软件系统将可以以类似Java中远程对象方法呼叫（RMI）的形式，来启动远程对象的程序。在DCOM技术的引导下，对象的接口与实作部分将会以分离的形式存在，并且具有与程序语言无关的特性。

4.MTS/COM+

微软的 MTS 技术（Microsoft Transaction Server）主要是要合并两项重要的功能：一是事务处理监看机制，另一则是对象需求代理机制，这两大部分都是为了处理伺服端的软件组件而设计。而COM+则是DCOM与MTS的下一步进化，允许更快速且方便地建立具高度可重复利用属性的伺服端软件组件。

5.DTC

这是微软开发出来用在分布式交易环境下的协调服务器。就如何Java的交易服务定义一般，DTC（Distributed Transaction Coordinator）可以用来支持应用服务所需的交易特性，针对这些需求而形成一个提供交易服务的基础构。这样的功能，正好与OMG的OTS以及升阳的JTS形成强烈的对应。

6.MSMQ

这是微软用来解决讯息处理需求的方案。MSMQ（MicroSoft Message Queue）实作了组件之间的异步讯息传送机制，并以队列（queue）的方式来安排处理顺序。这部分的功能，正好模拟于CORBA架构中的动态程序启动接口（DII , Dynamic Invocation Interface）。

7.ADSI

微软的 ADSI （Active Directory Services Interface）是一种目录与名称服务的接口定义，可以用来针对网络上的特定信息进行存取，如用户、计算机，以及其他相关的资源。在这样的接口定义下，应用程序将可以运用一个统一化的运作接口来操作如企业中多项的名称与目录数据。在CORBA架构下，这样的服务则是以COS Naming （CORBA Object Services Naming）服务来完成。

ADO+

这是微软在.NET平台下用来关系数据库进行存取的部分。这部分的功能，主要是源自于早期的ODBC（Open DataBase Connectivity）接口，进而演化为OLE/DB（Object Linking and Embedding for DataBase），最后才形成ADO（Active Data Object）接口。

在了解了.NET中各项基础架构支持技术之后，各位读者所感兴趣的比较即将开始。笔者将会针对以上所提的各项技术，做一个适当的对应，以期用户可以清楚了解技术之间的对应关系。

支持技术大比较：J2EE vs. .NET

在开始以下的比较探讨之前，让我们再回顾一下会形成这些比较的大环境。由这样的背景环境中，我们就可以知道，竞争为何而来，以及技术演进的动力。

微软以及其Windows产品一直是桌面软件产品市场上的常胜军。在Java出现之际，有许多观察家认为升阳将有能力撼动微软的大片江山。但是在微软的竞争策略上，认为与其浪费资源在建立Windows的仿真环境，以期能与Java的跨平台特性相较，不如针对Windows平台做重要的进步与演化，可能要来得更具影响力与号召力，同时也可以减少建立不兼容性的可能。但是就升阳的Java阵营来看，以Java具有优良的分布式特性来说，配合上跨平台特色，将可以在伺服端软件市场受到强烈的欢迎。因此，在市场的区隔上，微软的确比较长于桌面软件，而升阳也的确比较长于伺服端软件。

但是这一阵子以来，情况逐渐有了变化，微软在伺服端软件市场上逐渐开始着力，由原先发表但未见看好的DNA架构，逐渐演化成为即将大展身手的.NET架构。对于伺服端技术的整合，微软用尽心思，以期能在伺服市场中占有一席之地。在这山雨欲来之际，正好给了我们一个机会，好好地检视这两大阵营的伺服软件架构。同时也藉由这个比较，体会一下两大软件巨人的用心。升阳将其整合过后的JPE（Java Platform for the Enterprise）正式更名为J2EE，而微软也将其整合并提升过后的DNA（Distributed interNet Application architecture）正式更名为.NET架构，以下就是各项支持技术的比较。

后记

.NET与J2EE 在技术架构的相似度上似乎蛮符合观察家与评论家的预期，是具有同构型、市场重迭性的伺服产品。在实作的哲学上，尽管两大阵营的看法不同，请见(表四)与(表五)。但在对服务器市场的雄心上，却是没有二致的。因此，就让看倌们继续保持注意，看市场大饼旁落谁家吧。

《表四 .NET架构与J2EE架构支持技术比较表》

《表五 两大阵营的实作哲学》