比较 Microsoft .NET 和 J2EE 的构成技术 选自蔡学镛's Blog
比较 Microsoft .NET 和 J2EE 的构成技术
即使你不在微软的平台上写程序，你可能也听过 Microsoft 推出的「.NET」平台，此技术是用来对付非微软阵营的兵器。如果你读过微软的新闻稿，或者你浏览过 MSDN 的内容，还是你出席了微软的专业程序员会议（也就是「.NET」平台现身的地方），你可能仍有两个疑问：
「.NET」平台到底是什么？
「.NET」架构和 J2EE 有哪些差异？
如果你想得更远一点，你还会有第三个问题：
我们能从「.NET」架构中学到一些哪些有助于推展企业软件开发的思维？
目前，「.NET」架构尚嫩，许多细节仍有待微软的「.NET」小组厘清。虽然如此，我们仍然能够从现有的信息中得到上述问题的解答。
「.NET」平台到底是什么？
现今大家对于「.NET」平台的看法有点类似寓言「瞎子摸象」，观点不同，自有不同的想法。有些人说「.NET」是微软的下一代 Visual Studio 开发环境；有些人说它是一个新的程序语言（C#）；还有些人说它是以 XML 和 SOAP 为基础的资料交换与传递讯息的机制。其实，上述三者都是「.NET」想扮演的角色，而且还不止于此。
让我们先得到一些较具体的观念。下面列出「.NET」平台内部的组成：
C# 是一个「新程序语言」，用来撰写类别和组件。C# 融合了 C/C++ 和 Java 的特色，还多了一些其它的特色，比方说 metadata tag。
一个「通用语言的执行时期系统（common language runtime）」，用来执行 IL 格式的程序代码。任何语言的原始程序只要被编译成 IL 格式之后，就可在「.NET」平台执行。
一组「基础组件」，提供多样的功能（例如：网络），以供执行时期系统使用。
「ASP+」，是新版的 ASP，能让 ASP 被编译成 IL 的格式。
「Win Form」和「Web Form」，是一组新的 UI 组件骨架，供 Visual Studio 使用。
「ADO+」，是新版的 ADO，使用 XML 和 SOAP 来进行资料存取和资料交换。
「.NET」和 J2EE 有哪些差异？
如你所见，「.NET」平台是一堆技术的组合。微软把这些技术当作现有技术（例如：J2EE 和 CORBA）的另一种选择，但实际上比较起来又是如何呢？下面是我们的一些分析比较：
Microsoft.NET
J2EE
主要差异
C# 程序语言
Java 程序语言
C# 和 Java 都源自 C/C++。两者有相当多共同的主要特色（包括：自动内存管理、阶层式名字空间）。C# 从J avaBeans 学来一些组件观念（propertie/attribute、event），还新增了一些特色（比方说 metadata tag），但是使用不同的语法。
Java 可以在任何有 Java 虚拟机器的平台上执行。C# 目前只能在 Windows 上执行。
C# 使用IL的执行时期系统。透过 just-in-time (JIT) 的编译方式或原生码编译方式来执行。Java 程序是透过 Java 虚拟机器来执行，但是也可以编译成原生码。
「.NET」通用组件
Java core API
高阶的「.NET」组件将支持透过 XML 和 SOAP 来存取。（请看下面 ADO+ 的介绍）
Active Server Pages+ (ASP+)
Java ServerPages (JSP)
ASP+ 将可以使用 Visual Basic、C#、和其它语言来撰写程序片断，然后被编译成IL的格式（不像以前的 ASP 每次都需要直译）。JSP 使用 Java 的程序代码，编译成 Java 的 bytecode（可以需要时才编译，也可以预先编译好）。
IL 执行时期系统
Java 虚拟机器、CORBA IDL、CORBA ORB
「.NET」允许不同的程序语言使用 Windows 上的同一套组件。
Java 允许 Java bytecode 在兼容的虚拟机器上都可以执行。
CORBA 允许不同语言和不同平台的对象互相沟通（必须有适合的 ORB）。J2EE 中可以使用CORBA，但两者的整合度不算是很紧密。
Win Form 和 Web Form
Java Swing
类似的 Web 组件在标准的 Java 平台中付之阙如，有些其它厂商在 Java IDE 中提供一些组件。
MS Visual Studio IDE 提供 Win Form 和 Web Form 的 RAD 工具，目前尚未有其它厂商宣称要支持 Win Form 和 Web Form。许多 Java IDE 工具都支持 Swing。
ADO+ 和 SOAP 的Web 服务
JDBC、EJB、JMS 和 Java XML 链接库（XML4J、JAXP）
ADO+ 允许透过 HTTP 进行 XML 资料交换（在远程资料对象和多层的程序之间），也就是SOAP。「.NET」的 Web 服务使用 SOAP 的讯息模型。EJB、JDBC 等则是把资料交换的通讯协议交由程序员自行决定，用 HTTP、RMI/JRMP 或 IIOP 都可以。
上面是各项技术的比较，下面是两者的整体比较：
特色：「.NET」和 J2EE 都提供许多相似的特色，虽然方法不见得完全一样。
可移植性：「.NET」只能在 Windows 上运作，但是理论上可以支持许多语言。而且，「.Net」支持 SOAP，使得不同平台的组件可以和「.NET」的组件交换讯息。虽然「.NET」中有些技术（比方说 SOAP 和其 discovery 与 lookup 机制）是公开的规格，核心的技术（比方说 IL 执行时期系统、ASP+、Win Form 与 Web Form）都还是由微软所把持，而且微软将会是「.NET」完整开发工具和平台的唯一提供厂商。
J2EE 则可以在任何有 JVM 的平台上执行，只要有兼容的服务（比方说：EJB 容器、JMS 等）即可。J2EE 的一切标准都是公开的，许多厂商都提供兼容的产品和开发工具。但是 J2EE 是一个单一语言的平台，如果要和其它语言平台沟通必须透过 CORBA（目前 J2EE 平台上不见得有支持 CORBA）。
整体来看
上面的各项分析指出「.NET」和 J2EE 的主要差异。微软正在「.NET」上做两件值得注意的事：开放「.NET」给其它程序语言的使用者，并开放「.NET」给非「.NET」组件的使用者（透过 XML 和 SOAP）。
因为「.NET」允许其它语言的组件整合进来，「.NET」赋予 Perl、Eiffel、Cobol 和其它语言的程序员在微软的平台上做事。各种语言的爱好者尤其喜欢这点，因为他们中多数人才不在乎微软和 Sun 以及开放阵营之间的战火。
大家的反应如何？
对微软的程序员来说：
如果你一直守着微软的架构，那么「.NET」的出现是一件好事。ASP+ 比 ASP 好；ADO+ 比 ADO 好；C# 比 C/C++ 好。「.NET」平台差不多要到 2001 才会现身，所以你还有时间准备。毫无疑问地，它将会变成微软预设的开发环境。如果你现在正在使用微软的开发工具，未来移转到「.NET」之后，你也会享受到这种种好处。
然而，「.NET」平台的一些目的太过崇高，不保证能达得到（至少短期内是如此）。比方说，IL 执行系统有一些很明显的难题待克服，想整合进此系统的每个语言必须清楚地定义如何对应到 IL，以及 IL 所需的 metadata。某语言要兼容于 IL 来必须提供编译器（x 语言转 IL，和 IL 转 x 语言）。
这有前例可寻。有许多编译器可将非 Java 语言转成 JVM 可执行的程序，这些语言包括了 JPython、PERCobol、the Tcl/Java project，有趣的是，连 Bertrand Meyer 和一些 Eiffel 语言的家伙也早在几年前就做出 Eiffel-to-JavaVM 的工具。其中只有 JPython 是成功的，其它的工具好象都没人在用，甚至连这些语言本身的族群都不用，虽然这些工具的出现使得他们能使用最爱的语言来写 Java 程序。为什么就是无法引起大家的热诚？我相信这是因为人们怀疑混合两种异质的语言环境会水土不服。如果他们想写在 JVM 上执行的程序，他们宁可花时间去学 Java 语言。我想，同样的情况也会出现在「.NET」平台上，人们宁可花时间去学 C# 来写「.NET」程序，而非使用其它语言。
还有一点要注意的：「.NET」使用的 SOAP 架构的性能值得观察。SOAP 使用 HTTP 来传递 XML。HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件剖析（parse），这又是计算上的负担。两者的结合会使得交易的速度大大低于其它方案。XML 是一个用途广、健全、又具涵义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，但是如果效率对你来说很重要，那么你应该多瞧瞧其它的方式，而不要用 SOAP。
对 Java 和 Open Source 族群来说：
「.NET」很容易被视为微软基于市场需求所推出的解决方案。其实，「.NET」是微软开始策略改变的征兆。以往微软在面对其它架构和平台有不错的战果，现在他们面对了来自 Java 和 open source 的压力，开始有了「开放」的迹象，也试着直接去满足程序员的需求，这可是和以往的老大作风大不相同。如果你是 Java 或 open source 的爱好者，请注意：这场战争的本质已经有所改变了。
而且，微软的 IL 执行时期系统有一点值得注意的目标：消弭程序语言和 API 之间的藩篱。Java 消弭了平台间的藩篱，但是如果你想使用 J2EE，你就必须搭配 Java 语言。「.NET」想让你使用你喜爱的语言来开发「.NET」程序，这点是很了不起的（但结果是否会成真仍是个大问号）。从这点来看，J2EE 就比不上「.NET」，但是这点应该不算太重要。
J2EE 如果想迎战「.NET」，有几个议题应该立刻被注意到。首先，J2EE 应该将 XML 好好地整合进来。我不是指制定 XML SAX/DOM 的 API，也不是指拿 XML 当作设定档格式，我说的是 XML 的讯息交换和处理应该被加进 J2EE。当然，目前你可以用 XML 格式当作 JMS 讯息内容，但整个 J2EE 却不会因此受益。XML 是一堆标准的集合，包括业界标准的 API 和 DTD，这应该都是资料交换时可以享受到的好处才是。
但是微软把赌注下在 SOAP 上，而且正积极地将 SOAP 的相关信息传送给程序员。J2EE 也应该如此，我想到的方法之一是在 JMS 上加一层 XML messaging provider，并整合进 Java Naming and Directory Interface（JNDI）和 LDAP、NIS、COS Naming 等技术。这样就等于是结合了 SOAP/BizTalk provider、ebXML provider 等技术。
即使你不在微软的平台上写程序，你可能也听过 Microsoft 推出的「.NET」平台，此技术是用来对付非微软阵营的兵器。如果你读过微软的新闻稿，或者你浏览过 MSDN 的内容，还是你出席了微软的专业程序员会议（也就是「.NET」平台现身的地方），你可能仍有两个疑问：
「.NET」平台到底是什么？
「.NET」架构和 J2EE 有哪些差异？
如果你想得更远一点，你还会有第三个问题：
我们能从「.NET」架构中学到一些哪些有助于推展企业软件开发的思维？
目前，「.NET」架构尚嫩，许多细节仍有待微软的「.NET」小组厘清。虽然如此，我们仍然能够从现有的信息中得到上述问题的解答。
「.NET」平台到底是什么？
现今大家对于「.NET」平台的看法有点类似寓言「瞎子摸象」，观点不同，自有不同的想法。有些人说「.NET」是微软的下一代 Visual Studio 开发环境；有些人说它是一个新的程序语言（C#）；还有些人说它是以 XML 和 SOAP 为基础的资料交换与传递讯息的机制。其实，上述三者都是「.NET」想扮演的角色，而且还不止于此。
让我们先得到一些较具体的观念。下面列出「.NET」平台内部的组成：
C# 是一个「新程序语言」，用来撰写类别和组件。C# 融合了 C/C++ 和 Java 的特色，还多了一些其它的特色，比方说 metadata tag。
一个「通用语言的执行时期系统（common language runtime）」，用来执行 IL 格式的程序代码。任何语言的原始程序只要被编译成 IL 格式之后，就可在「.NET」平台执行。
一组「基础组件」，提供多样的功能（例如：网络），以供执行时期系统使用。
「ASP+」，是新版的 ASP，能让 ASP 被编译成 IL 的格式。
「Win Form」和「Web Form」，是一组新的 UI 组件骨架，供 Visual Studio 使用。
「ADO+」，是新版的 ADO，使用 XML 和 SOAP 来进行资料存取和资料交换。
「.NET」和 J2EE 有哪些差异？
如你所见，「.NET」平台是一堆技术的组合。微软把这些技术当作现有技术（例如：J2EE 和 CORBA）的另一种选择，但实际上比较起来又是如何呢？下面是我们的一些分析比较：
Microsoft.NET
J2EE
主要差异
C# 程序语言
Java 程序语言
C# 和 Java 都源自 C/C++。两者有相当多共同的主要特色（包括：自动内存管理、阶层式名字空间）。C# 从J avaBeans 学来一些组件观念（propertie/attribute、event），还新增了一些特色（比方说 metadata tag），但是使用不同的语法。
Java 可以在任何有 Java 虚拟机器的平台上执行。C# 目前只能在 Windows 上执行。
C# 使用IL的执行时期系统。透过 just-in-time (JIT) 的编译方式或原生码编译方式来执行。Java 程序是透过 Java 虚拟机器来执行，但是也可以编译成原生码。
「.NET」通用组件
Java core API
高阶的「.NET」组件将支持透过 XML 和 SOAP 来存取。（请看下面 ADO+ 的介绍）
Active Server Pages+ (ASP+)
Java ServerPages (JSP)
ASP+ 将可以使用 Visual Basic、C#、和其它语言来撰写程序片断，然后被编译成IL的格式（不像以前的 ASP 每次都需要直译）。JSP 使用 Java 的程序代码，编译成 Java 的 bytecode（可以需要时才编译，也可以预先编译好）。
IL 执行时期系统
Java 虚拟机器、CORBA IDL、CORBA ORB
「.NET」允许不同的程序语言使用 Windows 上的同一套组件。
Java 允许 Java bytecode 在兼容的虚拟机器上都可以执行。
CORBA 允许不同语言和不同平台的对象互相沟通（必须有适合的 ORB）。J2EE 中可以使用CORBA，但两者的整合度不算是很紧密。
Win Form 和 Web Form
Java Swing
类似的 Web 组件在标准的 Java 平台中付之阙如，有些其它厂商在 Java IDE 中提供一些组件。
MS Visual Studio IDE 提供 Win Form 和 Web Form 的 RAD 工具，目前尚未有其它厂商宣称要支持 Win Form 和 Web Form。许多 Java IDE 工具都支持 Swing。
ADO+ 和 SOAP 的Web 服务
JDBC、EJB、JMS 和 Java XML 链接库（XML4J、JAXP）
ADO+ 允许透过 HTTP 进行 XML 资料交换（在远程资料对象和多层的程序之间），也就是SOAP。「.NET」的 Web 服务使用 SOAP 的讯息模型。EJB、JDBC 等则是把资料交换的通讯协议交由程序员自行决定，用 HTTP、RMI/JRMP 或 IIOP 都可以。
上面是各项技术的比较，下面是两者的整体比较：
特色：「.NET」和 J2EE 都提供许多相似的特色，虽然方法不见得完全一样。
可移植性：「.NET」只能在 Windows 上运作，但是理论上可以支持许多语言。而且，「.Net」支持 SOAP，使得不同平台的组件可以和「.NET」的组件交换讯息。虽然「.NET」中有些技术（比方说 SOAP 和其 discovery 与 lookup 机制）是公开的规格，核心的技术（比方说 IL 执行时期系统、ASP+、Win Form 与 Web Form）都还是由微软所把持，而且微软将会是「.NET」完整开发工具和平台的唯一提供厂商。
J2EE 则可以在任何有 JVM 的平台上执行，只要有兼容的服务（比方说：EJB 容器、JMS 等）即可。J2EE 的一切标准都是公开的，许多厂商都提供兼容的产品和开发工具。但是 J2EE 是一个单一语言的平台，如果要和其它语言平台沟通必须透过 CORBA（目前 J2EE 平台上不见得有支持 CORBA）。
整体来看
上面的各项分析指出「.NET」和 J2EE 的主要差异。微软正在「.NET」上做两件值得注意的事：开放「.NET」给其它程序语言的使用者，并开放「.NET」给非「.NET」组件的使用者（透过 XML 和 SOAP）。
因为「.NET」允许其它语言的组件整合进来，「.NET」赋予 Perl、Eiffel、Cobol 和其它语言的程序员在微软的平台上做事。各种语言的爱好者尤其喜欢这点，因为他们中多数人才不在乎微软和 Sun 以及开放阵营之间的战火。
大家的反应如何？
对微软的程序员来说：
如果你一直守着微软的架构，那么「.NET」的出现是一件好事。ASP+ 比 ASP 好；ADO+ 比 ADO 好；C# 比 C/C++ 好。「.NET」平台差不多要到 2001 才会现身，所以你还有时间准备。毫无疑问地，它将会变成微软预设的开发环境。如果你现在正在使用微软的开发工具，未来移转到「.NET」之后，你也会享受到这种种好处。
然而，「.NET」平台的一些目的太过崇高，不保证能达得到（至少短期内是如此）。比方说，IL 执行系统有一些很明显的难题待克服，想整合进此系统的每个语言必须清楚地定义如何对应到 IL，以及 IL 所需的 metadata。某语言要兼容于 IL 来必须提供编译器（x 语言转 IL，和 IL 转 x 语言）。
这有前例可寻。有许多编译器可将非 Java 语言转成 JVM 可执行的程序，这些语言包括了 JPython、PERCobol、the Tcl/Java project，有趣的是，连 Bertrand Meyer 和一些 Eiffel 语言的家伙也早在几年前就做出 Eiffel-to-JavaVM 的工具。其中只有 JPython 是成功的，其它的工具好象都没人在用，甚至连这些语言本身的族群都不用，虽然这些工具的出现使得他们能使用最爱的语言来写 Java 程序。为什么就是无法引起大家的热诚？我相信这是因为人们怀疑混合两种异质的语言环境会水土不服。如果他们想写在 JVM 上执行的程序，他们宁可花时间去学 Java 语言。我想，同样的情况也会出现在「.NET」平台上，人们宁可花时间去学 C# 来写「.NET」程序，而非使用其它语言。
还有一点要注意的：「.NET」使用的 SOAP 架构的性能值得观察。SOAP 使用 HTTP 来传递 XML。HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件剖析（parse），这又是计算上的负担。两者的结合会使得交易的速度大大低于其它方案。XML 是一个用途广、健全、又具涵义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，但是如果效率对你来说很重要，那么你应该多瞧瞧其它的方式，而不要用 SOAP。
对 Java 和 Open Source 族群来说：
「.NET」很容易被视为微软基于市场需求所推出的解决方案。其实，「.NET」是微软开始策略改变的征兆。以往微软在面对其它架构和平台有不错的战果，现在他们面对了来自 Java 和 open source 的压力，开始有了「开放」的迹象，也试着直接去满足程序员的需求，这可是和以往的老大作风大不相同。如果你是 Java 或 open source 的爱好者，请注意：这场战争的本质已经有所改变了。
而且，微软的 IL 执行时期系统有一点值得注意的目标：消弭程序语言和 API 之间的藩篱。Java 消弭了平台间的藩篱，但是如果你想使用 J2EE，你就必须搭配 Java 语言。「.NET」想让你使用你喜爱的语言来开发「.NET」程序，这点是很了不起的（但结果是否会成真仍是个大问号）。从这点来看，J2EE 就比不上「.NET」，但是这点应该不算太重要。
J2EE 如果想迎战「.NET」，有几个议题应该立刻被注意到。首先，J2EE 应该将 XML 好好地整合进来。我不是指制定 XML SAX/DOM 的 API，也不是指拿 XML 当作设定档格式，我说的是 XML 的讯息交换和处理应该被加进 J2EE。当然，目前你可以用 XML 格式当作 JMS 讯息内容，但整个 J2EE 却不会因此受益。XML 是一堆标准的集合，包括业界标准的 API 和 DTD，这应该都是资料交换时可以享受到的好处才是。
但是微软把赌注下在 SOAP 上，而且正积极地将 SOAP 的相关信息传送给程序员。J2EE 也应该如此，我想到的方法之一是在 JMS 上加一层 XML messaging provider，并整合进 Java Naming and Directory Interface（JNDI）和 LDAP、NIS、COS Naming 等技术。这样就等于是结合了 SOAP/BizTalk provider、ebXML provider 等技术。
