GIS开发平台的未来 — .NET还是J2EE?
在GIS开发领域，从底层开发到应用系统，从数据采集到空间分析，从单机应用到网络发布，我们是否真的需要.NET或J2EE?尽管四周一片鼓噪之声，尽管已经有了转换平台的成功先例，我们依然需要冷静的考虑，慎重地抉择。因为GIS作为一类跨数据库和图形显示两大计算机科学研究领域的专业软件，应用领域太广，我们开发者需要考虑的东西太多。
我们可以把GIS的开发分成几个层次：数据、基础软件平台、应用业务逻辑和数据表现。为了便于快速构建GIS应用系统，GIS平台开发商提供了种类繁多的二次开发语言，如ESRI的AML,Avenue，Intergraph 则有 MicroStation Development Language (MDL)，还有MapInfo的MapBasic。这些开发语言有自己的语法和结构，只能在固定开发商的软件环境下运行，尽管它们曾经拥有辉煌，尽管它们的确代表了一个时代，它们也不可避免的走向没落。GIS是一个开放协作的系统，数据和应用要分离，软件的功能要分离，而当我们需要的时候，他们又应该能够互相配合成为一个整体。这难道不就是组件化的思想了吗？于是对象和组件开始充斥着我们的左右，没有什么不是对象，没有什么开发不要组件，我们进入了组件的时代。当网络变得无处不在，所有的应用都要能够适用于 Web，适用于嵌入式的设备，适用于移动设备；我们仍然要求更强的互操作能力，我们希望即使是专注于某项业务逻辑开发的系统也能够方便的得到复用。毫无疑问，.NET和J2EE为我们达到这个目的铺平了道路，GIS的开发步入Web Service的世界是不可逆转的潮流。在Web Service 的世界里，数据和应用彻底分离，而构建应用则是通过XML 或SOAP来传递消息，我们不用买数据，不用维护数据库，只要提供Web Service和使用Web Service，世界变得井然有序。
.NETßàJ2EE
那么到底是.NET还是J2EE?我们仍然无法回避这个问题。也许做一个比较是回答问题的好办法，尽管这个比较是那么困难。
.NET代表了自1993年以来，微软软件开发环境最重要的一次变革。微软的目标是在保留和扩展已有的VB、ASP技术的同时，增加那些Web应用所必需的新技术。在.NET之前，程序员们需要在一个环境中开发桌面应用程序，而在另一个环境中开发服务器程序，开发Web应用则又是一个环境。如果我们需要开发移动平台上的应用，我们就得再搞一个环境。. NET的到来，从某种意义上讲，实现了这些不同开发环境的透明，为不同平台，不同环境下的软件开发构筑了一条笔直大道。
.NET和J2EE有着太多的相似之处：都是面向对象的开发思想，其上都可以创建桌面或跨Web的应用。这些相似之处其实集中于一点：那就是他们的设计初衷都是希望构建一个能够连接桌面和Web应用的开发环境。其实，一个应用系统的开发完全可以既用.NET又适用J2EE。人们在开发大量的工具软件以提高.NET和J2EE之间的互操作性。比如一些工具能够把.NET的代码转成纯Java。当然，也有能把Java代码转成C#的工具,JUMP( Microsoft's Java User Migration Path software.)( http://www.microsoft.com/presspass/press/2001/jan01/01-25javaupgradepr.asp)。 2003年末，微软发布了一份专业刊物：Application Interoperability ,Microsoft .NET and J2EE,这个300多页的文档能够在微软网站的下载中心找到，这也许对我们理解.NET和J2EE有所帮助。
值得注意的是，微软的.NET战略和.NET集成开发环境虽说是不同层面上的东西，但是在实际中它们却紧密捆绑，尤其是和微软各类服务器的捆绑。可以这么讲，接受了.NET，就意味着对微软“Back Office”解决方案的全面接受。而J2EE则是一个相对松散的结构，一般说来，J2EE开发的应用系统都能够和不同的数据库、工具联系起来。
四个层次
.NET和J2EE都可以分成4个层次。
首先是基础平台和操作系统。J2EE的应用程序可以运行在Windows,Solaris,Linux。而.NET目前还是只能运行在Windows上。不过有一个多平台的开源版本叫做Mono（http://www.go-mono.com）的，正在开发中。
其次是应用程序运行环境。J2EE的应用程序要运行在JVM下；同理，.NET是使用CLR。JVM在多平台上都可以运行，CLR必须在Windows下运行。
第三则是所谓的Framework，这是指那些为了方便应用系统的开发所制作的一些大型类库或开发包。J2EE中是如Swing、EJB、JSP、 JDBC这些东西。而在.NET中则包括ASP.NET,ADO.NET等。
第四就是应用系统本身了。
另外有一点非常值得一提，那就是Visual Studio .NET。VS.NET是一个集多种开发语言和不同应用层次一体的高效集成开发环境。而对于J2EE来说，使用Java来开发应用程序就显得缺乏像 VS.NET这样的利器。虽说也有Borland JBuilder, iPlants NetBeans和BEA的WebLogic等工具。但VS.NET的威力和魅力却总是令人难以抵挡。
Web Service之间如何通信是个问题。HTML对于Web Service通信来说是个小儿科的东西，为了满足更复杂的需要，XML就应运而生了。SOAP则是一个使用XML结构的消息传递协议。SOAP能够使 Web组件间进行复杂的数据通信，还可以帮助开发者们方便地把数据层和应用层分离开来。不过XML的结构中有很多内容都是为了便于互操作而定义的，这些内容其实和真正要传递的信息无关。有时候这会让我们觉得传输这些“不实质”的东西有些浪费，不过为了提高互操作性，浪费点也不算什么。
到底应该怎么如何选择呢
既然Web Service的体系结构是大势所趋，那么不管是.NET还是J2EE，在地理信息的世界里，他们应该扮演什么角色呢？其实，底牌就是数据和应用的分离。GIS最重要的是数据，地理数据量大不说，维护起来也非常困难。如果GIS中能够做到数据——应用分离，应用的开发就会变得简单而高效，那该有多么好呀。多层的结构，松散的体系，更灵活的系统，更强的可用性，Web Service难道不正是我们所想要的吗？
很多GIS软件公司已经开始了.NET或Java的GIS产品开发工作。比如微软的MapPoint Web Services(http://www.microsoft.com/mappoint/webservice/default.mspx), ESRI的 Arc Objects Assemblies和MapObjects Java Edition（http://www.esri.com/software/mojava/index.html ）。还有MapInfo的MapXtreme。J2EE平台上也有不少成功的案例，比如Laser-Scan Gothic JADE(http://www.laser-scan.com/technologies/gothic/goth_jade.htm)。
说到这里，我们还是没有对.NET和J2EE做出一个结论。.NET开发又快又方便，和Windows上的各种服务紧密相连，有人说.NET跑的还要更快些。J2EE呢，就更灵活，伸缩性也强，和其他组件组合的能力也强，当然用起来就比较复杂，管理起来也难。其实他们之间并无优劣之分，关键是因地制宜，看谁更合适些。
我们可以把GIS的开发分成几个层次：数据、基础软件平台、应用业务逻辑和数据表现。为了便于快速构建GIS应用系统，GIS平台开发商提供了种类繁多的二次开发语言，如ESRI的AML,Avenue，Intergraph 则有 MicroStation Development Language (MDL)，还有MapInfo的MapBasic。这些开发语言有自己的语法和结构，只能在固定开发商的软件环境下运行，尽管它们曾经拥有辉煌，尽管它们的确代表了一个时代，它们也不可避免的走向没落。GIS是一个开放协作的系统，数据和应用要分离，软件的功能要分离，而当我们需要的时候，他们又应该能够互相配合成为一个整体。这难道不就是组件化的思想了吗？于是对象和组件开始充斥着我们的左右，没有什么不是对象，没有什么开发不要组件，我们进入了组件的时代。当网络变得无处不在，所有的应用都要能够适用于 Web，适用于嵌入式的设备，适用于移动设备；我们仍然要求更强的互操作能力，我们希望即使是专注于某项业务逻辑开发的系统也能够方便的得到复用。毫无疑问，.NET和J2EE为我们达到这个目的铺平了道路，GIS的开发步入Web Service的世界是不可逆转的潮流。在Web Service 的世界里，数据和应用彻底分离，而构建应用则是通过XML 或SOAP来传递消息，我们不用买数据，不用维护数据库，只要提供Web Service和使用Web Service，世界变得井然有序。
.NETßàJ2EE
那么到底是.NET还是J2EE?我们仍然无法回避这个问题。也许做一个比较是回答问题的好办法，尽管这个比较是那么困难。
.NET代表了自1993年以来，微软软件开发环境最重要的一次变革。微软的目标是在保留和扩展已有的VB、ASP技术的同时，增加那些Web应用所必需的新技术。在.NET之前，程序员们需要在一个环境中开发桌面应用程序，而在另一个环境中开发服务器程序，开发Web应用则又是一个环境。如果我们需要开发移动平台上的应用，我们就得再搞一个环境。. NET的到来，从某种意义上讲，实现了这些不同开发环境的透明，为不同平台，不同环境下的软件开发构筑了一条笔直大道。
.NET和J2EE有着太多的相似之处：都是面向对象的开发思想，其上都可以创建桌面或跨Web的应用。这些相似之处其实集中于一点：那就是他们的设计初衷都是希望构建一个能够连接桌面和Web应用的开发环境。其实，一个应用系统的开发完全可以既用.NET又适用J2EE。人们在开发大量的工具软件以提高.NET和J2EE之间的互操作性。比如一些工具能够把.NET的代码转成纯Java。当然，也有能把Java代码转成C#的工具,JUMP( Microsoft's Java User Migration Path software.)( http://www.microsoft.com/presspass/press/2001/jan01/01-25javaupgradepr.asp)。 2003年末，微软发布了一份专业刊物：Application Interoperability ,Microsoft .NET and J2EE,这个300多页的文档能够在微软网站的下载中心找到，这也许对我们理解.NET和J2EE有所帮助。
值得注意的是，微软的.NET战略和.NET集成开发环境虽说是不同层面上的东西，但是在实际中它们却紧密捆绑，尤其是和微软各类服务器的捆绑。可以这么讲，接受了.NET，就意味着对微软“Back Office”解决方案的全面接受。而J2EE则是一个相对松散的结构，一般说来，J2EE开发的应用系统都能够和不同的数据库、工具联系起来。
四个层次
.NET和J2EE都可以分成4个层次。
首先是基础平台和操作系统。J2EE的应用程序可以运行在Windows,Solaris,Linux。而.NET目前还是只能运行在Windows上。不过有一个多平台的开源版本叫做Mono（http://www.go-mono.com）的，正在开发中。
其次是应用程序运行环境。J2EE的应用程序要运行在JVM下；同理，.NET是使用CLR。JVM在多平台上都可以运行，CLR必须在Windows下运行。
第三则是所谓的Framework，这是指那些为了方便应用系统的开发所制作的一些大型类库或开发包。J2EE中是如Swing、EJB、JSP、 JDBC这些东西。而在.NET中则包括ASP.NET,ADO.NET等。
第四就是应用系统本身了。
另外有一点非常值得一提，那就是Visual Studio .NET。VS.NET是一个集多种开发语言和不同应用层次一体的高效集成开发环境。而对于J2EE来说，使用Java来开发应用程序就显得缺乏像 VS.NET这样的利器。虽说也有Borland JBuilder, iPlants NetBeans和BEA的WebLogic等工具。但VS.NET的威力和魅力却总是令人难以抵挡。
Web Service之间如何通信是个问题。HTML对于Web Service通信来说是个小儿科的东西，为了满足更复杂的需要，XML就应运而生了。SOAP则是一个使用XML结构的消息传递协议。SOAP能够使 Web组件间进行复杂的数据通信，还可以帮助开发者们方便地把数据层和应用层分离开来。不过XML的结构中有很多内容都是为了便于互操作而定义的，这些内容其实和真正要传递的信息无关。有时候这会让我们觉得传输这些“不实质”的东西有些浪费，不过为了提高互操作性，浪费点也不算什么。
到底应该怎么如何选择呢
既然Web Service的体系结构是大势所趋，那么不管是.NET还是J2EE，在地理信息的世界里，他们应该扮演什么角色呢？其实，底牌就是数据和应用的分离。GIS最重要的是数据，地理数据量大不说，维护起来也非常困难。如果GIS中能够做到数据——应用分离，应用的开发就会变得简单而高效，那该有多么好呀。多层的结构，松散的体系，更灵活的系统，更强的可用性，Web Service难道不正是我们所想要的吗？
很多GIS软件公司已经开始了.NET或Java的GIS产品开发工作。比如微软的MapPoint Web Services(http://www.microsoft.com/mappoint/webservice/default.mspx), ESRI的 Arc Objects Assemblies和MapObjects Java Edition（http://www.esri.com/software/mojava/index.html ）。还有MapInfo的MapXtreme。J2EE平台上也有不少成功的案例，比如Laser-Scan Gothic JADE(http://www.laser-scan.com/technologies/gothic/goth_jade.htm)。
说到这里，我们还是没有对.NET和J2EE做出一个结论。.NET开发又快又方便，和Windows上的各种服务紧密相连，有人说.NET跑的还要更快些。J2EE呢，就更灵活，伸缩性也强，和其他组件组合的能力也强，当然用起来就比较复杂，管理起来也难。其实他们之间并无优劣之分，关键是因地制宜，看谁更合适些。
