软件开发技术的选择.docx

软件开发技术的选择.docx

《软件开发技术的选择.docx》由会员分享，可在线阅读，更多相关《软件开发技术的选择.docx（15页珍藏版）》请在冰豆网上搜索。

软件开发技术的选择

软件开发技术的选择

一、前言

作为的研发部，担负本公司产品所有软硬件核心技术的维护、创新与发展的重任，也是本公司的发展壮大的力量源泉。

软件研发技术的选择，与我们部门当前与未来的技术发展紧密相关，或者说，与我们的战略规划密不可分。

现阶段，我们部门的战略规划是建立有强大创新能力的高效团队，立足彩票行业，不断拓展新的业务领域。

–短期目标（未来一年）：

以公司市场为导向，配合市场活动，扩大市场份额；同时加强管理，进行相关的技术储备和技术研究，调整和优化自己的组织架构，为公司未来的发展方向打好基础。

–中期目标（未来1－3年）：

建立良好的管理制度和合理的组织架构后，并结合自己的技术储备开始全面拓展彩票业务，同时公司盈利结构开始发生调整，向软件、系统集成、增值业务开始倾斜，同时开始重点强调业务领先的思路。

–长期目标（未来3－5年）：

在形成了彩票行业全面的产品结构后，部门重心开始向行业顾问倾斜，服务和业务将成为核心竞争力

那么，我们研发部的软件技术研发方向是什么？

我个人认为我们的发展方向：

面向网络（或者说Internet）、面向对象。

二、当前的主流软件研发方向

1、为什么不是C++？

C++作为最主要的工业语言标准之一，特别是近几年来，C++语言出现了蓬勃的发展，各种新技术和新概念层出不穷，世界范围内的C++社群也是蒸蒸日上。

但是，勿庸讳言的是，C++的地位确实受到了来自Java/C#的有力挑战。

在应用领域、特别是在高端的应用领域中，Java正在逐渐取代C++成为主流。

导致这种情况的原因是多样的，但最主要的原因有两个。

一个是C++的标准推出太晚，直到1998年ISOC++标准才正式推出，在此之前，各种风格的C++版本把时间浪费在内耗上，将大片的市场拱手让给了Java。

另一个更重要的原因是，虽然ISOC++标准的制定统一了C++的语言，但是却没有统一C++的framework。

虽然C++标榜自己是平台无关的语言（它的确也是），但是对于同一个问题，在不同的平台下有各种不同的解决方案。

C++自己的标准库只是一个语言的framework，而不是一个应用的framework：

在I/O，多线程，Socket，GUI，数据对象模型等等常见的问题上，开发者们不得不要么自己封装特定平台的API，要么寻找难以保证质量的第三方类库。

没有统一framework的C++，就象没有VCL的Delphi，没有JFC的Java，没有.NETframework的C#。

因此，除了在某些底层的开发中C/C++仍然具有不可替代的地位，C++在应用领域无法与Java/C#抗衡，而逐渐退守到底层编程。

对于我们来说，如果确实有必要搞搞C++，可以考虑BorlandC++BuilderX。

因为Microsoft公司已经下定决心，将操作系统从Win32全面转向.NET，.NET将是Microsoft公司解决方案中的统一的编程模型。

BorlandC++BuilderX并没有向.NET靠拢，而是坚持走原生开发工具的道路，并且扩展到了多个平台、多个编译器。

BorlandC++BuilderX现在的framework，完全使用标准C++整个重新写成，而且支持跨平台和交叉编译（CrossCompilation，即在一个平台下编译生成另一个平台下的可执行代码），同时也对某些专业领域，例如嵌入式开发，提供了专门的支持。

另外，它还能够方便地挂接ACE、Loki、Boost等第三方的C++库。

2、DOTNET与J2EE的比较

1）群力所致的J2EE

Java于1996年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。

后来，人们发现Java的“一次开发，多次运行”、纯面向对象的特性、垃圾回收机制和内置的安全特别适合于开发企业应用系统。

于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。

但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。

鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1998年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。

这一规范和其定义的平台就构成了J2EE。

J2EE是一个基于组件-容器模型的系统平台，其核心概念是容器。

容器是指为特定组件提供服务的一个标准化的运行时环境，Java虚拟机就是一个典型的容器。

组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE底层的API，为组件提供事务处理、数据访问、安全性、持久性等服务。

在J2EE中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。

组件和容器间的关系通过“协议”来定义。

容器的底层是J2EE服务器，它为容器提供J2EE中定义的各种服务和API。

一个J2EE服务器（也叫J2EE应用服务器）可以支持一种或多种容器。

EJB是J2EE平台的核心，也是J2EE得到业界广泛关注和支持的主要原因。

我们知道，J2EE的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。

EJB正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。

EJB的核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心商业逻辑，而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。

服务是组件和容器之间，以及容器和J2EE服务器之间的接口，在实现层面上它就是一系列API和协议。

J2EE平台定义了一组标准的服务，其中有些服务是由J2SE提供的，有些则是J2EE对Java的扩展。

从应用的角度来看，J2EE为企业应用系统的开发提供了一种多层分布式企业应用模型。

在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。

2）.NET开发平台留住Windows开发者

.NET开发平台一推出，就开始了与J2EE平台的竞争。

它的绝大部分是微软WindowsDNA（DistributedNetworkArchitecture）的重写，DNA是微软以前开发企业应用程序的平台。

WindowsDNA中包括了许多已经被证实的技术，新的.NET框架取代了这些技术，并包含了Web服务层和改良的语言支持。

从战略角度看，.NET开发平台担负着整合.NET战略的重任，但它最直接的目标则是努力为微软保留住庞大的Windows用户基础。

微软的Windows开发用户群是微软通过Windows操作系统获得的最大财富。

对于为什么要推出.NET开发平台，微软表示，主要原因之一就是由于Java向开发者承诺的硬件和操作系统无关性，可能会导致这些用户转向其他平台。

虽然开发平台本身不会给微软带来很多收益，但Windows程序员是企业内部对微软产品的主要支持力量，商用软件的开发者形成了向客户销售微软产品的重要渠道。

如果微软可以让开发者在.NET开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。

（1）、.NET框架内核

NET框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的功能，为Web服务及普通应用程序提供了一个托管、安全、高效的执行环境。

所有在.NET平台上创建的应用程序运行都需要两个核心模块:

CommonLanguageRuntime（CLR，通用语言运行时）和.NETFramework类库。

CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。

.NETFramework类库则向程序员提供软件组件，来编写在CLR的控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对XML功能的网访问的每一样功能。

（2）、CLR——.NET的虚拟机

CLR为.NET应用程序提供了一个托管的代码执行环境。

托管意味着将原来由程序员或操作系统做的工作剥离出来交由CLR来完成，从而使程序运行获得更高的安全性和稳定性。

这些工作包括内存管理、即时编译、组件自描述、安全管理和代码验证，以及其他一些系统服务。

CLR提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET应用程序就可以独立于语言。

CLR还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性、接口等组件编程特性。

CLR中的自动垃圾收集器负责.NET应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。

即时编译器在运行时将中间语言以调用的对象方法为单位动态编译成本地二进制代码。

中间语言是在.NET平台下编译器输出PE文件（Windows可执行文件）的语言，它为.NET平台提供了多语言支持，允许开发者使用20多种不同的编程语言。

而元数据是一个内嵌于PE文件的表的集合，描述了代码中数据类型等在代码执行时CLR需要知道的信息。

元数据使得.NET应用程序代码具备自描述特性，提供了类型安全保障，而这在以前需要额外的类型库或接口定义语言（IDL）。

CLR根据托管组件的来源（如互联网、企业局域网、本地机器）等因素确定各组件的信任度，并根据信任度来限定它们执行诸如读取文件、修改注册表等敏感操作的权限。

此外，CLR借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在的类型不匹配问题。

通过代码访问安全机制，开发人员可以为应用程序指定完成工作所必需的权限。

CLR不仅规定了代码访问安全，还规定了基于角色的安全。

基于角色的认证为互联网上分布式组件的执行提供了安全保证。

值得指出的是，CLR通常寄宿在其他高性能服务器的应用程序中，比如互联网信息服务器（IIS）、SQLServer数据库服务器等。

这样，开发者可以充分利用CLR诸多安全、高效的优点来部署自己的商业逻辑。

（3）、类库——组件和服务的家园

.NETFramework类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。

它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，不管是传统的命令行程序还是Windows图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET或Web服务应用。

与在Windows和它的SDK中发送的代码库一样，.NET框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。

它将核心Win32API最常用的功能和外挂SDK的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。

ASP.NET应用服务体系架构为用ASP.NET建立Web服务提供了一个高级的可编程模板。

虽然建立Web服务并不限定使用特定的服务平台，但是ASP.NET的许多优点将简化其开发过程。

使用这个编程模型，开发人员甚至无需理解HTTP、SOAP或其他任何网络服务规范。

ASP.NET可以利用现存的体系架构和应用程序，为在互联网上绑定应用程序提供了一个简单的、灵活的、基于产业标准的模型。

3）异中有同同中有异

（1）、类似的平台基础构造

一个平台在语言编译、代码执行、编程支持等基础构造方面往往会对平台的可用性、生产性、移植性等产生重要的影响，也是我们评判一个平台是否适合特定应用的重要依据。

J2EE和.NET两个平台在底层的执行引擎都源于托管的虚拟机概念，但.NET的CLR沿着Java虚拟机（JVM）走得更远。

CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。

在.NET和J2EE平台上，程序的编译都经过两个类似的过程。

首先特定高级语言编译器将C#（及其他.NET语言）和Java源代码分别翻译成中间语言（IL）和字节代码（ByteCode）。

.NET在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。

J2EE的基石是Java语言，它最典型的特征是：

一次编写，多次运行。

跨平台是J2EE一直引以为豪的关键，这是通过JVM来实现的。

其次，在执行时，中间语言被即时编译器（JIT）编译成特定平台的二进制代码，字节代码则通过JVM解释执行，完成各自语言的指令功能。

鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于Java有明显的优势是不争的事实。

但在Unix/Linux平台上，由于.NET迟迟未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就无所谓。

在代码执行的同时，通用语言运行时和Java虚拟机也都提出了异常捕捉、类型安全、内存分配、垃圾收集等自动化内存管理工作，大大减轻了现代软件的内存泄漏问题和程序员繁重的负担。

面向对象程序设计在J2EE和.NET平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。

但在面向对象之外，.NET对现代组件编程提供了直接支持。

当然，当下的很多企业中间件都是基于J2EE平台的，只是.NET从设计、编码、配置到运行给予了组件编程更多、更直接的支持。

一个能够为编程提供广泛服务的、可复用的API类库对于现代软件平台非常重要。

从基础的集合、字符串操作到企业级的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在这方面有着非常坚实的结构。

微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单、ASP.NET等一系列的API。

在这些基础的和企业级的服务上两个平台很难一决高下，而且对功能集合的支持很多时候是一个时间问题，往往是一个平台推出了某一子功能集，另一个平台马上推出类似的功能集。

除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的一点。

CLR和Java虚拟机都支持本地方法的调用。

在异构平台方面，J2EE更钟情于IIOP（InternetInterORBProtocol），而.NET则使用SOAP。

（2）、相同的三层/多层体系

基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。

在客户端，表示层负责用户与系统的交互。

对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：

JavaApplication与Windows表单、JavaServlet/JSP与ASP.NET双双形成犄角之势。

但Windows表单依赖微软桌面系统的天然优势，不管在交互速度还是在界面的表现性能上都较JavaApplication稍胜一筹。

Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。

虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度，以及服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高下。

在缓存、状态优化等方面两者可谓旗鼓相当。

另一个和客户端应用相关的技术是ActiveX与Applet，但从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。

在中间层，分布式业务组件负责企业应用的商业逻辑部署。

由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。

J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。

EJB的核心是容器，容器是一个为组件提供服务的运行时环境，负责为组件提供诸如事务处理、持久性、安全性、组建状态自动化管理等服务，它分离了商业逻辑和系统底层逻辑，使开发人员的工作大为简化。

.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。

在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：

J2EE的JDBC和.NET的ADO.NET。

它们在支持传统SQL数据源的同时，也都支持新型的XML数据源。

这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。

值得指出的是，在打造三层/多层体系结构的同时，Web服务作为新一代企业计算模型也得到了J2EE和.NET平台相当的关注，在后面的文章会有这方面的详细评述。

（3）、不同的移植、性能和扩展

在移植性方面，微软通过.NET通用语言运行时来消除编程语言的差别，而J2EE则通过Java虚拟机来消除平台差别。

“选择.NET平台就意味着选择Windows”，这句话至少在可预见的一段时间里仍然是一个基本事实。

跨平台是J2EE的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持。

实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择。

J2EE更关注跨平台而不是跨语言。

但微软认为，如果企业的应用都能通过标准协议以Web服务的方式发布，那么平台都是中立的。

跨平台甚至是微软所不想的。

为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。

性能是J2EE和.NET喋喋不休的话题。

二者之间著名的论战是一个关于宠物店的范例应用。

宠物店是Sun一度以来作为J2EE典型应用的展示范例，但.NET“自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。

但Sun的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，而且指责微软通过后端数据库优化和缓存虚抬了.NET平台的效率。

这样的争吵当然不能作为我们判断的依据，目前也没有见到更客观的第三方评测报告。

在“Wintel平台”上我们也许没有理由怀疑.NET的性能，而至于非Windows平台，.NET和J2EE也不再具有可比性。

在平台的成熟度方面，两者也有一拼。

J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。

而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（DistributedNetworkArchitecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列、SQLServer数据库等。

而对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。

这也符合微软和Sun各自的产品利益。

J2EE另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是J2EE兼容的。

这使得J2EE从制订之初就得到了广泛的支持。

BEA、IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。

而.NET在设计之初就紧紧地把平台规范与产品胶合在一起，虽然.NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI和Web服务标准），但至少目前很难想像会有一个非微软的.NET实现。

4）Web服务谁主沉浮

（1）、.NET与J2EE对Web服务的支持

从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，在它的市场推广活动中，无时无刻不凸显其作为Web服务的开发和部署平台的特征。

可以说，.NET天生就是为Web服务准备的开发和部署平台。

相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级应用领域而制订的一个平台框架规范。

随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避业界的重大技术革命——Web服务。

随着Web服务技术的发展，J2EE也不断地引入了对Web服务的支持。

从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是.NET的开发工具更为方便一些，集成度更高一些。

.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前成功者的优点，.NET就大量地吸收了J2EE平台的优点。

其中，最重要的一点就是.NET不再完全沿袭微软先前的技术，从.NET开始，其应用不再以本地机器代码运行，而是编译成中间代码，由称为CLR的虚拟机来运行，这样，.NET也具备了跨平台的可能。

不过.NET的跨平台特性主要体现在支持多种开发语言上，VB.NET、C#、C++、JScript等都可以被编译成相同的中间代码，使用相同的运行库执行。

（2）、第三方厂商的支持

J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等在J2EE的实施上都有较大的投入。

目前市场上最好的J2EE应用服务器并不是Sun与Netscape合资的iPlanet，而是BEA的WebLogic和IBM的Webshpere。

一年一度的JavaONE就有成千上万的开发商参加。

由于J2EE是开放的规范框架，任意厂商只要有实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用，当然最关键的是这些参与J2EE的厂商都具有很强的实力。

除了微软以外，基本上所有的软件业巨擎都钟情于J2EE。

然而，J2EE虽然是开放的规范，但是它的使用却不是那么开放，每家使用J2EE技术的公司都不得不为此向Sun支付一笔不小的费用。

同时也正因为Sun对J2EE规范的独家控制，使得J2EE规范的开发进度缓慢，迄今为止，J2EE规范中并不包含对Web服务的支持，Sun推出的WSDP只是一种插件形式的扩展支持。

有消息表明，在今年年底前，Sun和Java领域的其他支持商，包括IBM、Bea、Silverstream等会就J2EE如何支持Web服务达成一致，然而这一切均存在变数，其中的根结就在于Sun对Java技术的独家控制。

同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发Java平台的Web服务支持，IBM在这个领域的步伐是飞快的，它的WSAD（WebshpereStudioApplicationDeveloper）集成了大量自行开发（部分来自于Apache.org，不过这个项目的前身是IBM发起，而后移交给Apache.org）的Web服务组件，业已成为Java领域开发Web服务的最佳开发工具，同时IBM的Websphere也慢慢向Web服务开发部署应用平台的角色转化。

而对于微软的.NET而言，虽然从一开始，微软就以独占、垄断、不开放的形象出现在平台市场上。

然而，它的.NET却表现出了前所未有的开放姿态。

.NET的主力开发语言C#已经提交给ECMA，开始标准化，ECMA是一个致力于推动行业范围内采用信息和通信技术的非特定供应商的国际标准组织。

C#的标准化使希望在任何平台上都可以实现C#编程工具的公司能够实现其愿望。

微软还向ECMA提交了微软.NET框架的一个子集，叫做CLR（公共语言架构，CommonLanguageInfrastructure）。

这将使其他供应商能够在各种平台上实现CLI，以