软件开发技术的选择.docx

1、软件开发技术的选择软件开发技术的选择、前言作为的研发部， 担负本公司产品所有软硬件核心技术的维护、创新与发展的重任， 也是本公司的发展壮大的力量源泉。 软件研发技术的选择， 与我们部门当前与未来的技术发展紧密相关，或者说，与我们的战略规划密不可分。现阶段，我们部门的战略规划是 建立有强大创新能力的高效团队，立足彩票行业，不断拓展新的业务领域。短期目标（未来一年） ：以公司市场为导向，配合市场活动，扩大市场份额；同时加强管理，进行相关的技术储备和技术研究，调整和优化自己的组织架构，为公司未来的发展方向打好基础。中期目标（未来 13 年）：建立良好的管理制度和合理的组织架构后，并结合自己的技术储备

2、开始全面拓展彩票业务，同时公司盈利结构开始发生调整，向软件、系统集成、增值业务开始倾斜，同时开始重点强调业务领先的思路。长期目标（未来 35 年）：在形成了彩票行业全面的产品结构后，部门重心开始向行业顾问倾斜，服务和业务将成为核心竞争力那么，我们研发部的软件技术研发方向是什么？我个人认为我们的发展方向：面向网络或者说 Internet ）、面向对象 。、当前的主流软件研发方向1、为什么不是 C+ ？C+作为最主要的工业语言标准之一，特别是近几年来，C+语言出现了蓬勃的发展,各种新技术和新概念层出不穷， 世界范围内的C+社群也是蒸蒸日上。但是，勿庸讳言的是,C+的地位确实受到了来自 Java/C

3、#的有力挑战。在应用领域、特别是在高端的应用领域中,Java正在逐渐取代C+成为主流。导致这种情况的原因是多样的，但最主要的原因有两个。Java。一个是C+的标准推出太晚，直到 1998年ISO C+标准才正式推出，在此之前，各种风格的 C+ 版本把时间浪费在内耗上，将大片的市场拱手让给了另一个更重要的原因是， 虽然ISO C+标准的制定统一了 C+的语言，但是却没有统一C+的framework。虽然C+标榜自己是平台无关的语言 （它的确也是），但是对于同一个问 题，在不同的平台下有各种不同的解决方案。C+自己的标准库只是一个语言的 framework，而不是一个应用的 framework :

4、在I/O, 多线程， Socket，GUI ，数据对象模型等等常见的问题上，开发者们不得不要么自己封装特定平台的API，要么寻找难以保证质量的第三方类库。没有统一 framework的C+，就象没守到底层编程 。原生开发工具的道路，并且扩展到了多个平台、多个编译器。Borland C+BuilderX 现在的framework，完全使用标准 C+整个重新写成，而且支持跨平台和交叉编译（ Cross Compilation ，即在一个平台下编译生成另一个平台下的可执行代 码），同时也对某些专业领域，例如嵌入式开发，提供了专门的支持。另外，它还能够方便 地挂接 ACE、Loki、Boost等第三方

5、的 C+库。2、 DOTNET 与 J2EE 的比较1）群力所致的 J2EEApplet 。Java 于 1996 年由 Sun 公司推出，当时它的主要用途是制作产生动态网页的Java 标准版的基础上后来，人们发现 Java 的 “一次开发，多次运行 ”、 纯面向对象的特性、垃圾回收机制和内置 的安全 特别适合于开发企业应用系统。于是，企业应用开发商纷纷在 各自扩展出许多企业应用 API ，其结果导致基于 Java 的企业应用呈爆炸式增长。但是各企 业系统 API 之间又不能相互兼容， 破坏了 Java 的平台独立性。 鉴于此， Sun 公司联合 IBM 、Oracle 、 BEA 等大型企业

6、应用系统开发商于 1998 年共同制订了一个基于 Java 组件技术的企业应用系统开发规范， 该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了J2EE 。J2EE 是一个基于组件 -容器模型的系统平台， 其核心概念是容器 。容器 是指为特定组件提供服务的一个标准化的运行时环境， Java 虚拟机就是一个典型的容器。 组件 是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了J2EE 底层的 API ，为组件提供事务处理、数据访问、安全性、持久性等服务。在J2EE 中组件和组件之间并不直接访问，而是通过容器提供的协议和方

7、法来相互调用。组件和容器间的关系通过协议 ”来定义。容器的底层是 J2EE 服务器，它为容器提供 J2EE 中定义的各种服务和 API 。一个 J2EE 服务器也叫 J2EE 应用服务器)可以支持一种或多种容器。EJB 是 J2EE 平台的核心 ，也是 J2EE 得到业界广泛关注和支持的主要原因。 我们知道，J2EE 的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。 EJB 正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。EJB 的核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心

8、商业逻辑，而由EJB 容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。服务是组件和容器之间， 以及容器和 J2EE 服务器之间的接口， 在实现层面上它就是系列 API 和协议 。 J2EE 平台定义了一组标准的服务，其中有些服务是由J2SE 提供的，有些则是 J2EE 对 Java 的扩展。从应用的角度来看， J2EE 为企业应用系统的开发提供了一种多层分布式企业应用模型。在 J2EE 中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。2) .NET 开发平台留住 Windows 开发者.NET 开发平台一推出

9、，就开始了与 J2EE 平台的竞争。它的绝大部分是微软 WindowsDNA(Distributed Network Architecture) 的重写， DNA 是微软以前开发企业应用程序的平台。Windows DNA 中包括了许多已经被证实的技术，新的 .NET 框架取代了这些技术，并包含了 Web 服务层和改良的语言支持。从战略角度看，重任，但它最直接的目标则是努力为微软保留住庞大的微软的 Windows 开发用户群是微软通过 Windows 操作系统获得的最大财富。对于为什么要推出 .NET 开发平台，微软表示，主要原因之一就是由于 Java 向开发者承诺的硬件和操作系统无关性， 可能

10、会导致这些用户转向其他平台。 虽然开发平台本身不会给微软带来很多收益，但 Windows 程序员是企业内部对微软产品的主要支持力量，商用软件的开发者用程序，那么就会有更多的公司购买微软的其他产品。(1)、 .NET 框架内核NET 框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的平台上创建的应用程序运行都需要两个核心模块 :Common Language Runtime ( CLR ，通用语言运行时)和 .NET Framework 类库。CLR 是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。.NET

11、Framework 类库则向程序员提供软件组件， 来编写在 CLR 的控制下运行的代码，网访问的每一样功能。CLR 为 .NET 应用程序提供了一个托管的代码执行环境。 托管意味着将原来由程序员或 操作系统做的工作剥离出来交由 CLR 来完成，从而使程序运行获得更高的安全性和稳定性。这些工作包括内存管理、 即时编译、 组件自描述、 安全管理和代码验证，以及其他一些系统 服务。 CLR 提供一个技术规范，无论程序使用什么语言编写，只要能编译成中间语言，就 可以在它的支持下运行， 这样 .NET 应用程序就可以独立于语言。 CLR 还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属

12、性、事件、对象、继承性、多态性、 接口等组件编程特性。大大增强了应用程序的健CLR 中的自动垃圾收集器负责 .NET 应用程序运行时的内存分配、对象布局、 内存释放 等内存管理问题， 彻底解决了多年来困扰程序员的内存泄漏问题， 壮性。即时编译器在运行时将中间语言以调用的对象方法为单位动态编译成本地二进制代码。中间语言是在 .NET 平台下编译器输出 PE 文件（ Windows 可执行文件）的语言，它CLR 需要知道的信为.NET平台提供了多语言支持，允许开发者使用 20多种不同的编程语言。而元数据是个内嵌于 PE 文件的表的集合，描述了代码中数据类型等在代码执行时息。元数据使得 .NET 应

13、用程序代码具备自描述特性，提供了类型安全保障，而这在以前需CLR 根据托管组件的来源（如互联网、企业局域网、本地机器）等因素确定各组件的 信任度， 并根据信任度来限定它们执行诸如读取文件、 修改注册表等敏感操作的权限。 此外，CLR 借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在 的类型不匹配问题。 通过代码访问安全机制， 开发人员可以为应用程序指定完成工作所必需 的权限。 CLR 不仅规定了代码访问安全，还规定了基于角色的安全。基于角色的认证为互 联网上分布式组件的执行提供了安全保证。CLR 诸多安全、值得指出的是， CLR 通常寄宿在其他高性能服务器的应用程序中

14、，比如互联网信息服 务器（ IIS）、 SQL Server 数据库服务器等。这样，开发者可以充分利用 高效的优点来部署自己的商业逻辑。（3）、类库组件和服务的家园.NET Framework 类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务，不管是传统的命令行程序还是 Windows 图形界面程序， 亦或是面向下一代互联网分布式计算平台的 ASP.NET或 Web 服务应用。与在 Windows 和它的 SDK 中发送的代码库一样， .NE

15、T 框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。它将核心Win32 API 最常用的功能和外挂 SDK 的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。ASP.NET 应用服务体系架构为用 ASP.NET 建立 Web 服务提供了一个高级的可编程模板。虽然建立 Web 服务并不限定使用特定的服务平台，但是ASP.NET 的许多优点将简化其开发过程。使用这个编程模型，开发人员甚至无需理解HTTP 、SOAP 或其他任何网络服务规范。 ASP.NET 可以利用现存的体系架构和应用程序，为在

16、互联网上绑定应用程序提供了一个简单的、灵活的、基于产业标准的模型。3)异中有同同中有异(1)、类似的平台基础构造一个平台在语言编译、 代码执行、 编程支持等基础构造方面往往会对平台的可用性、产性、移植性等产生重要的影响，也是我们评判一个平台是否适合特定应用的重要依据。J2EE 和 .NET 两个平台在底层的执行引擎都源于托管的虚拟机概念，但.NET 的 CLR 沿着Java 虚拟机 (JVM) 走得更远。 CLR 在借鉴了 JVM 的自动垃圾收集、 异常处理等机制的同时，又为 .NET 平台添加了多语言支持、组件自描述等新的特性。在 .NET 和 J2EE 平台上，程序的编译都经过两个类似的过

17、程。首先特定高级语言编译器将C# (及其他.NET语言)和Java源代码分别翻译成中间语言 (IL)和字节代码(ByteCode) 。 .NET 在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。J2EE的基石是Java语言，它最典型的特征是：一次编写，多次运行。跨平台是 J2EE 一直引以为豪的关键，这是通过 JVM 来实现的。其次，在执行时，中间语言被即时编译器 (JIT)编译成特定平台的二进制代码，字节代码则通过 JVM 解释执行，完成各自语言的指令功能。鉴于微软在“Win tel平台”上的代码优化功底， .NET 代码的执行速度较之于 Java 有明

18、显的优势 是不争的事实。但在 Unix/Linux平台上，由于 .NET 迟迟未能实现其跨平台的承诺， J2EE 几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java 虚拟机也都提出了 异常捕捉、类型安全、内存分配、垃圾收集 等自动化内存管理工作，大大减轻了现代软件的内存泄漏问题和程序员繁重的负担。面向对象程序设计在 J2EE和.NET平台中都获得了直接的支持， 单根继承加多接口实现是它们共有的特征 。但在面向对象之外， .NET 对现代组件编程提供了直接支持。当然，当下的很多企业中间件都是基于 J2EE 平台的，只是 .NET 从设计、编码、配置到运行给予

19、了组件编程更多、更直接的支持。一个能够为编程提供广泛服务的、可复用的 API 类库对于现代软件平台非常重要。从基础的集合、字符串操作到企业级的 API 接口，如 JMS、JDBC、JAX、JNDI 等，可以看到 J2EE 在这方面有着非常坚实的结构。微软 .NET 框架类库也不示弱，提供了从图画、网络、线程到 ADO.NET 、ADSI 、Windows 表单、 ASP.NET 等一系列的 API 。在这些 基础的和企业级的服务上两个平台很难一决高下 ，而且对功能集合的支持很多时候是一个时间问题，往往是一个平台推出了某一子功能集，另一个平台马上推出类似的功能集。除去 API 类库的无缝的功能复

20、用外， 对本地平台的调用操作也是值得关注的一点。 CLR和 Java 虚拟机都支持本地方法的调用。在异构平台方面，J2EE 更钟情于 IIOP (InternetInterORB Protocol )，而 .NET 则使用 SOAP 。(2)、相同的三层 /多层体系基于三层 / 多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET 和 J2EE 都提出了基于桌面的应用程序和基于浏览器的 Web 应用的开发组件： Java Application 与Windows 表单、 Java Servlet/

21、JSP 与 ASP.NET 双双形成犄角之势。但 Windows 表单依赖微软桌面系统的天然优势，不管在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。Servlet/JS P与ASP .NET是目前企业在 瘦客户端”应用的重点，两者都基于HTTP请求 /响应模型，通过 HTML 浏览器页面完成用户交互。虽然 ASP.NET 声称在底层通过编译执行获得了相当高的处理速度， 以及服务器方控件的浏览器自适应能力， 但目前并没有这方面的硬性数据，很难据此而论高下。在缓存、状态优化等方面两者可谓旗鼓相当。另一个和客户端应用相关的技术是 ActiveX 与 Applet ，但

22、从目前的趋势来看， 它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。在中间层， 分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架， 而.NET组件则是建立在新型的 COM+ 服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。 EJB 的核心是容器，容器是一个为组件提供服务的运行时环境，负责为组件提供诸如 事务处理、持久性、安全性、组建状态自动化管理 等服务，它 分离了商业逻辑和系统底层逻

23、辑 ，使开发人员的工作大为简化。 .NET 则通过元数据支持自描述性的组件开发、 XCOPY 部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。在后端数据层， 两个平台都为数据库连接量身定做了一套数据存取模型：J2EE 的 JDBC和.NET的ADO.NET 。它们在支持传统 SQL数据源的同时，也都支持新型的 XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。值得指出的是，在打造三层 /多层体系结构的同时， Web 服务作为新一代企业计算模型也得到了 J2EE 和 .NET 平台相当的关注，在后面的文章会有这方面的详细评述。(3)、不同的移

24、植、性能和扩展在移植性方面，微软通过 .NET 通用语言运行时来消除编程语言的差别，而 J2EE 则通过 Java 虚拟机来消除平台差别。 “选择 .NET 平台就意味着选择 Windows” ，这句话至少在可预见的一段时间里仍然是一个基本事实。 跨平台是 J2EE 的一大卖点， 也是在选择企业应用开发平台时的一个重要参考因素， 几乎所有的主流操作系统都提供了对 J2EE 的支持。 实际上如果要搭建跨 Unix 、 Windows 等多个操作系统平台， J2EE 平台几乎是惟一的选择 。J2EE 更关注跨平台而不是跨语言。 但微软认为， 如果企业的应用都能通过标准协议以 Web服务的方式发布，

25、那么平台都是中立的。 跨平台甚至是微软所不想的。为了吸引更多的开发者和鼓励广大企业厂商转到 .NET 平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。性能是 J2EE 和 .NET 喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是 Sun 一度以来作为J2EE典型应用的展示范例，但.NET “自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE 的1/3 ，效率却是 J2EE 的30 倍。但 Sun 的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优“Win tel平台”上我们业应用程序的平台 DNA ( Dis

26、tributed Network Architecture )，其中包括了许多已经被证实的技术， 并且这些技术已经在产品中得到实现， 包括微软的事务服务器、 COM+ 、消息队列、SQL Server 数据库等。而对于扩展性， 广为业界接受的事实是 .NET 平台的扩展思想是基于软件的横向扩展， 而 J2EE 平台的扩展思想则是基于硬件的纵向扩展 。这也符合微软和 Sun各自的产品利益。J2EE 另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是 J2EE 兼容的。这使得 J2EE 从制订之初就得到了广泛的支持。BEA 、IBM 、Oracle 等都相

27、继开发了符合 J2EE 的应用服务器，它们的产品相互之间甚至可很难想像会有一个非微软的 .NET 实现。4) Web 服务谁主沉浮(1)、 .NET 与 J2EE 对 Web 服务的支持的特征。可以说，-NET天生就是为 Web服务准备的开发和部署平台。 相对.NET而言，J2EE是一个比较 “老”的东西，最初它是为了将 Java 平台拓展到企业级应用领域而制订的一个平台框架规范。随着 Web 服务的兴起和发展， J2EE 平台作为一个企业级应用的开发和部署能作为我们判断的依据，目前也没有见到更客观的第三方评测报告。在 也许没有理由怀疑 .NET 的性能，而至于非 Windows 平台， .N

28、ET 和 J2EE 也不再具有可比 性。在平台的成熟度方面，两者也有一拼。 J2EE 在1999 年形成了其成熟的架构，并且到平台，无法回避业界的重大技术革命Web服务。随着 Web服务技术的发展，J2EE也不断地引入了对Web服务的支持。从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是 .NET的开发工具更为方便一些，集成度更高一些。.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前成功者的优点， .NET就大量地吸收了 J2EE平台的优点。其中，最重要的一点就是.NET

29、不再完全沿袭微软先前的技术，从 .NET开始，其应用不再以本地机JScript等都可以被编译成相同的中间代码，使用相同的运行库执行。(2)、第三方厂商的支持等在J2EE的实施上都有较大的投入。目前市场上最好的 J2EE应用服务器并不是 Sun与Netsca pe 合资的 iP la net,而是 BEA 的 WebLogic 和 IBM 的 Websh pe 年一度的 JavaONE就有成千上万的开发商参加。由于 J2EE是开放的规范框架，任意厂商只要有实力都可以按照规范来开发实现，不同厂商的组件也可以在一起协同使用， 当然最关键的是这些参与 J2EE的公司都不得不为此向 Sun支付一笔不小的

30、费用。同时也正因为 Sun对J2EE规范的独家控制，使得J2EE规范的开发进度缓慢，迄今为止， J2EE规范中并不包含对 Web服务的支持，Sun推出的WSDP只是一种插件形式的扩展支持。有消息表明，在今年年底前，Sun和Java领域的其他支持商，包括 IBM、Bea、Silverstream 等会就J2EE如何支持 Web服同时，由于J2EE对Web服务支持的步履维艰，各大厂商分别自行开发 Java平台的Web服务支持，IBM在这个领域的步伐是飞快的，它的 WSAD (Webshpere StudioAppIication Developer )集成了大量自行开发(部分来自于 Apache.

31、org，不过这个项目的前身是 IBM 发起，而后移交给 Apache.org ）的 Web 服务组件，业已成为 Java 领域开发Web 服务的最佳开发工具， 同时 IBM 的 Websphere 也慢慢向 Web 服务开发部署应用平台 的角色转化。而对于微软的 .NET 而言，虽然从一开始，微软就以独占、垄断、不开放的形象出现在 平台市场上。然而，它的 .NET 却表现出了前所未有的开放姿态。C#的标准化使希望在.NET 的主力开发语言 C# 已经提交给 ECMA ，开始标准化， ECMA 是一个致力于推 动行业范围内采用信息和通信技术的非特定供应商的国际标准组织。任何平台上都可以实现 C# 编程工具的公司能够实现其愿望。 微软 还向 ECMA 提交了微软.NET框架的一个子集， 叫做CLR （公共语言架构， Com mon Lan guage In frastruc