几种体系架构与开发工具的组成

几种体系架构与开发工具的组成三层体系架构WebServer/AppServer开发工具核心技术备注J2EEWebsphere(IBM)Jbuilder9.0WSAD5.0Eclipse(Java)免费WebLogic(BEA)Jarguas(SYBASE)PB9.0+PJ非主流技术.NETWindowsServer2003(WebServer+AppServer)Asp.NET北京瑞得公司、杭州创业公司采用.NETStudioBorlandC++;DelphiCorbaDephi非主流技术卫宁公司采用项目上体系架构与开发工具的选择序号方案优势缺点备注第一种Websphere(IBM)+Eclipse单CPU价格：30-50万(估计)跨平台技术，易移植和多平台产品集成技术方案比较完整开发工具免费技术比较复杂Websphere价格比较高（如果采用Bea也比较高）如果技术人员对IBM的技术比较熟悉可采用此方案，但Websphere的价格问题需要斟酌与解决第二种.NET(Asp.Net)50用户价格：5万以下（winserver2003版）技术简洁，开发简单价格上也有优势（.Net是内嵌在Winserver2003中）只能在Windows平台上使用因为考虑该项目需要集成的项目不多，没有跨平台的需要，再加上技术简单，容易掌握，如果人员比较熟悉微软的技术，建议采用此方案可以参考看如下几篇文章：J2EE与.NET的比较毫无疑问，程序员，软件开发商，企业IT经理一直都在密切的关注着J2EE和.NET的发展，但是选择一个在性能，价格，时间上满足他们需求的平台却并不是一件简单的事情。本文试图在技术上做一个简单的比较，希望对于他们做选择时有所帮助。一.技术概观在表现形式上，J2EE是一组规范，而.NET更象是一组产品。但它们的目的都是为了企业应用提供分布式的，高可靠性的解决方案.它们在架构上有着很多的相似之处，下表是一个简单对照:J2EE.NET

通信协议RemoteMethodInvocationoverInternetInterOrbProtocol(RMI/IIOP)，XML

编程语言JavaC#，VB.NET，COBOL

运行时环境JavaVirtualMachine(JVM)CommonLanguageRuntime(CLR)

胖客户端JavaSwingWindowsForms

目录服务JavaNamingandDirectoryInterface(JNDI)ActiveDirectoryServicesInterface(ADSI)

数据访问JavaDatabaseConnection(JDBC)，JavaConnectorsADO.NET

异步消息处理JavaMessageService(JMS)MicrosoftMessageQueue

表示层技术Servlets，JavaServerPage(JSP)ASP.NET

中间层组件模型EJB，JavaBeanCOM+，COM

安全访问JAASCOM+Security

CallContext

事物处理JavaTransactionServer(JTS)MicrosoftDistributedTransactionCoordinator(MS-DTC)

开发工具WebGainVisualCafé

BorlandJbuilder

IBMVisualAge等

(第三方提供，规范本身没有定义)VisualStudio.NET

J2EE平台的构成EJB-J2EE中间层，完成商业逻辑；JAAS-J2EE处理认证和授权的API;JavaConnectors-J2EE用于连接异种数据源的API，对上层来讲是透明的;JSP，JavaServlets-J2EE的表示层技术，用于生成用户界面;JavaVirtualMachine-Java语言运行环境；JDBC-J2EE数据库访问；JMS-J2EE的异步消息队列；JNDI-J2EE的名字查找API，独立于目录服务器；JTS-J2EE用于处理交易的API；RMI/IIOP-J2EE的分布式对象的通讯API，提供了和CORBA交互的能力。.NET平台构成.NETFramework-.NET应用运行的基础；IL(IntermediaryLanguage)-所有的.NET语言首先被编译成该中间语言，然后在CLR中运行；SOAP-用于服务访问的工业标准；DCOM-组件间通信协议；MS-DTC-用来在.NET平台上使用两阶段提交协议来处理分布式交易；CLR-.NET应用的运行时环境；COM+-.NET的中间层模型，用于构建商务逻辑；ADO.NET-.NET对数据访问的API。此外.NET平台还包括其他一些产品象ApplicationCenterServer，BizTalkServer，NLBS(NetworkLoadBalancingService)，CommerceServer，EnterpriseServers，HIS(HostIntegrationServer)，ISAS(InternetSecurityandAccelerationServer)用来提供象防火墙，安全访问，B2B交易，负载平衡等服务.J2EE规范本身没有定义这些服务，但可通过选择第三方产品来满足类似的要求。二.技术比较1.一vs多一种语言vs多种语言，一个平台vs多个平台.这似乎是大家最喜于津津乐道的话题，也似乎是所有问题的焦点。两种平台主流的开发语言Java和C#在架构上有着惊人的相似：虚拟机技术，基于沙箱的安全模型，分层的命名空间，垃圾回收等。所以从第一眼看上去，C#简直就是Java的克隆。但微软并不这样认为，微软的说明是：“它集成了C++，Java，Modula2，C和Smalltalk等多种语言的精华，对它们共同的核心思想象深度面向对象(deepobject-orientation)，对象简化(object-simplification)等都一一做了参考。”一方面，C#的大多数关键字来源于C++，使它在书写上有别于Java。但另一方面，C#的严格的类型转换等概念却明显来自于Java(当然，它的原始类型的定义更严格，并且据微软声称没有影响到效率.)，使其在内涵上有克隆之嫌.但即是Java，其有些特性也和Smalltalk颇有渊源.所以评价一种开发语言的优劣不仅是看其外在的表现形式，更重要的是其实实在在的功效.作为一种新语言，C#加入了基于XML的标记，可以被编译器用来直接生成文档，C#的另一个特点:一站式软件(one-stop-shoppingsoftware)强调了自解释(self-describing)的编码方式，即头文件，IDL(InterfaceDefinitionLanguage)，GUID和其他复杂的接口无需再被引用.也即是C#，VB.NET等代码片断可以任意的被加入到其他语言中.这无疑在多种语言混合编程的模式中是一次飞跃，但是，其难维护性也是不言而喻的。微软的.NET的平台提供了象C#，VB.NET，COBOL等多种开发语言，C#是新的，而其他的每一种语言都是在原有的基础上改造而来.这是微软煞费苦心并且也是不得以的要为习惯于这些语言的程序员铺一条便捷之路.但是，这些语言的改造与其说是整容到不如说是一次开膛破肚的大手术.首先是观念变了，Basic，Cobol等语言先天的缺少面向对象的内涵，现在却变成了面向对象的语言，这就不是要求其传统的程序员仅仅熟悉一些额外的关键字那么简单的问题了.基于面向对象的软件分析设计开发测试是完全不同于基于传统过程性语言的质变，所以这一过程的转变对传统程序员来讲也是一个痛苦和漫长的过程.在传统程序员面前，微软看似提供了丰富多采的解决方法，但对于实际问题而言，却怕是有些力不从心.所以一个简单的办法是:直接使用C#.对于独立软件开发商来讲，其转换成本不容忽视.其次，在一个软件项目中使用多种语言，开发商必须同时拥有多种语言专家和多个独立的难以互相支援的开发小组，无疑的，这也使其软件的维护的成本已非线性的曲线增长.多样性是双韧剑，实施时需仔细斟酌.跨平台是J2EE的最大卖点，也是至今为止还绊住微软的栅栏.当开发商完成了符合J2EE规范的软件时，其客户可以依据其喜好和实力来选择不同应用服务器.从基于opensource的免费软件到高端满足B2B需求的商业套件来搭建自己的平台.但是由于J2EE的规范还不完善，各个J2EE服务器的提供商为了使其提供其各自理解的完整的功能，不得不添加一些额外的特性.这就使得使用了这些特别功能的应用软件，绑定到了特定的应用服务器上.随着J2EE规范的发展，这种差别会逐渐减小.微软的跨平台解决方案是Webservices，它解决的是异种平台上不同应用之间的连通性问题.从技术角度讲，它除了以XML为介质之外没有什么新意.但它的重要意义在于:它是微软这样一个重量级选手所推出的，前景不容小视.构造和使用Webservices的过程较为简单:服务提供者用他所选择的语言构造服务;服务提供者用WSDL(theWebServicesDescriptionLanguage)来定义该服务;服务提供者在UDDI(UniversalDescription，Discovery，andIntegration)中注册该服务;使用者的应用程序从UDDI中查找已注册服务;使用者的应用程序通过SOAP(theSimpleObjectAccessProtocol)来调用服务.(SOAP使用HTTP来传递基于XML为表现形式的参数)正如我们所讨论的:Webservices解决的是异构平台上服务连通性的问题，但在现实中所更迫切需要的是如何在异构的平台上构造具有可扩展性，高可靠性，高可用性，故障冗余，错误恢复能力的企业应用.缺少这一点，从结构上讲，.NET平台还远未完善.2.中间层基于组件的软件开发技术可以在较高的级别上实现软件复用，加快企业软件开发的进程.在J2EE构架中，JavaBean和EJB(EnterpriseJavaBeans)被用来完成事物逻辑.其中EJB和JavaBean有着类似的模型，但它被用来创建分布式的企业应用.它定义服务器端组件的模型，具有以下一些特性:生存期模型；访问模型；安全模型；事物处理模型；会话处理模型；数据封装模型；部署模型根据这些模型，简单的编码就可完成复杂的功能。在微软的.NET平台中，旧的COM和COM+的组件模型被新的组件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且实现了多重接口继承，扩展的元数据和新的代理模型等.旧有的COM和COM+组件也可被映射到新的运行环境中。综上所述，两众架构在基于组件的中间层的设计上各有千秋，对于创建分布式的，复杂的，高效的，高可靠性的的应用程序都有着足够的能力。3.表示层两种架构都同时支持胖客户端和瘦客户端.即C/S模式和B/S模式.对于C/S模式，J2EE提供了替代JavaAWT的JavaSwing，同时作为可视化组件的JavaBean也可用来构造系统。对于B/S结构的表示层，J2EE使用servlet，JSP(JavaServerPage)，HMTL，WML，XML等工具来实现。微软的胖客户端技术则由WindowsForms代替了MFC.它们起的作用相同，在结构上WindowsForms被插入到.NET的运行时框架(runtimeframework)和组件模型(componentmodel)中.在瘦客户模型中，ASP.NET代替了旧有的ASP和HMTL，WML，XML作为表示层。在ASP.NET中，C#，VB.NET等语言的代码片断可被自由引用.ASP.NET页面被首先转换成中介语言(IntermediaryLanguage)，然后再被中介语言及时编译器(just-in-timeILcompiler)编译，最后运行于公共语言运行环境中，并且ASP.NET提供了页面的缓冲，所以，其运行速度要远远快于ASP。大体上，两种架构所使用的表示层的技术非常类似，虽在细节上各有所长，但总体功能当在伯仲之间。4.数据访问J2EE和.Net已不同的形式支持数据的访问。JDBC和ADO一样和所连接的数据库无关，并且通过连接，命令语句和结果集来对数据进行操作.所以属于中间层次的API.更高一级的数据封装和数据管理是通过实体EJB(entityEJB)来完成的.基于容器管理的实体EJB使开发更快捷，管理更方便.事实上，由于实体EJB的load()和store()方法的同步机制，将大大缓解因并发而使数据库产生的瓶颈.也可以采用不属于J2EE规范的第三方数据访问工具，象WebGain的TopLink。而微软的.NET的数据访问工具则由基于XML的ADO.NET代替了基于COM组件的ADO.任何以XML为输出的数据源都可以作为ADO.NET的数据源.相应的结果集升级为数据集(DataSets)，命令语句则升级为数据集命令(DataSetCommands).从形式来看，微软的ADO.NET更新潮和时髦一些，基于XML的特性使其可以处理极其丰富的数据源，并且，因其构架在HTTP协议之上，易于穿透防火墙，使沟通更为便利.但由于XML本身的基于标记的特性，很明显限制了在有超大数据量和有网络瓶颈的应用中的使用.而J2EE的数据访问规则则显得略有单薄，但同时却更简单，更有效.并且通过对应用程序有效的层次的设计，对于数据库和基于XML的数据源的访问，也是可以无缝的整合的。三.整体评价在微软还没有足以和Java平台相对抗的产品的时候，微软所乐于做是大声的宣传:"w