论 Java 技术在因特网平台上的应用通信服务平台的应用.docx
- 文档编号:5658512
- 上传时间:2022-12-30
- 格式:DOCX
- 页数:18
- 大小:41.78KB
论 Java 技术在因特网平台上的应用通信服务平台的应用.docx
《论 Java 技术在因特网平台上的应用通信服务平台的应用.docx》由会员分享,可在线阅读,更多相关《论 Java 技术在因特网平台上的应用通信服务平台的应用.docx(18页珍藏版)》请在冰豆网上搜索。
论Java技术在因特网平台上的应用通信服务平台的应用
论Java技术在因特网平台上的应用——通信服务平台的应用
【正文】
数据通讯是当前十分活跃与热门的计算机与信息技术的应用领域。某大型通信公司开发了其业务的主要支撑平台,在这里,我们简称之为“通信信息服务平台”,用于在全国与全球开展数据业务的需要。该平台是一个典型的Java技术应用于Internet的项目。
作为信息技术公司中的一名技术骨干,我有幸参加了该系统的分析与设计工作,承担了相当多的Java应用开发任务。此系统中的软件部分大多由Java来实现,在全系统中我们是这样来用Java构架系统的:
(1)本系统可分为4层,分别是Browser、表示层、中间件层和数据层。
(2)表示层用Java中的JavaScript来实现页面输出。
(3)中间件层用Java来实现CORBA,即实现Component(构件),主要实现业务逻辑的封装与复用。
(4)数据层主要是数据库和存储过程的实现。
我们在应用Java技术时,所采用的技术和策略可大致上归纳为以下5个方面:
(1)使JavaScript尽量简单,因为JavaScript在我们系统中是放在服务器端执行的,该语言是通过一个解释器解释执行的,相对速度很慢,我们采用了两台HP前置机来运行JavaScript,但是其运行速度还是不理想,所以我们在设计中把JavaScript仅用来显示从中间件层所得到的数据,生成动态页面。在最初的设计中表示层(JavaScript)曾承担了一些业务逻辑处理操作,导致效率不理想,因此,我们不得不尽量地减少JavaScript的程序量。
(2)用Java实现CORBA时,应尽量考虑共享和复用。在本系统中,最初的设计是让Java在实现Component时,只是执行一些数据库表的操作,导致表示层的负载较大。后来,我们重新设计时,总结归纳了所有的UseCase,找出了其中可供共享和复用的接口,把相同的业务逻辑操作封装到一个接口中去。因为Java的执行效率比JavaScript要高,因此提高了系统效率。
(3)在别的项目中,我们曾大量地使用过Java中的JSP技术和Servlet技术,一般人可能不能区分这两种Java技术的区别。为了得到系统的一些执行速率的数据,我们采用了一个著名的压力测试软件——LoadRunner来测试这两种技术的差别。测试表明:
用JSP和Servlet完成同样的一个操作,并且保证是在相同的测试环境中(相同服务器、压力测试工作站与数据库环境),得到的测试数据却有着很大差别,JSP完成一个操作的平均执行时间大致会是Servlet程序的两倍。在一个企业级应用项目中,这可能是一个很关键的瓶颈。因此,我们得出的结论是:
在可能的条件下,尽量地多使用Servlet。当然,与Servlet相比,JSP编程快速,修改方便,在访问量不是很大的应用场合下也是可以接受的。
(4)使用Java作为整体解决方案时,应尽量使用相同版本的JDK。在用Java作为编程语言的项目中,几乎大多要遇到“汉字”问题,即Java在没有经过转换的情况下,在输出汉字时,很可能会出现乱码。采用不同版本的JDK,解决的方案是不一样的,比如V1.2.2版本的JDK和V1.3版本的JDK解决方法就会有一些不一样,把V1.2.2的Java程序放在V1.3的JDK中,就不能顺利输出汉字了。
其根本原因在于Java使用了Unicode编码,和我们中国的国标编码不一样。所以在这个意义上一些人竭力鼓吹的“一次编写,到处运行”似乎不一定能在所有的场合都行得通。
(5)使用Java时,应尽量遵从软件规范。在Java中有一个JVM的概念,即在Java虚拟机中使用了一个垃圾收集器,专门用来回收内存。但是该垃圾收集器在给编程人员带来方便的同时,也隐埋下了隐患。在程序设计中,并不能强制执行垃圾收集器,所以,开发人员不能确定某对象是否已释放,常常让编程人员养成依赖自动收集的坏习惯,因此我们要求:
在Try,Catch之后必须明确要求回收内存(当然,也只能是通知垃圾收集器来回收垃圾),这样可以有效地提高系统稳定性。
以上这些实用性的技术与策略,是我们在实践中的一些实际体会,仅供各位开发人员根据实际情况参考。
当然,在使用Java作为解决方案时,也会遇到很多让我们头疼的问题,这些问题导致同时执行的并发性比较差,系统速度慢等等。归纳起来看,我们曾遇到过的主要具体的问题有:
(1)用Java来实现CORBA中的Component,有时效率会比较低。
(2)用Java来建立数据库连接往往会比较慢。
(3)用JSP编程时容易导致系统信息的扩散。比如,如果有黑客攻击一台运行JSP程序的服务器,他可以故意地输入一些非法字符或异常信息给JSP程序,
于是程序执行将出现异常。这时,就会在页面上打印出相应的错误信息。很不幸的是,这些信息极有可能暴露出这台服务器的JDK的版本号与路径信息等内容。
这往往容易让黑客们有机可乘,有可能去抓住系统的漏洞。
在发现了这些问题后,我们经过仔细研究,找出了一些解决办法。比如:
(1)既然用Java实现Component比较慢,我们就尽量减少Component所执行的业务逻辑量。争取把能够放在存储过程中实现的操作,尽可能在存储过程中加以实现。众所周知,数据库的存储过程操作,比起在Java程序中执行数据库操作要快得多。
(2)既然用Java建立数据库连接比较慢,我们就可以把数据库连接封装成连接池(ConnectPool),从而能非常有效地提高系统效率。我们也曾经用
“LoadRunner”作过压力测试,使用连接池比不使用连接池的速度要快上3~5
倍。
(3)为了对付JSP程序与Servlet程序会打印出异常系统信息的问题。我们曾查阅了很多JSP或Servlet的资料,最终是毫无头绪。但是我们可以换另一种思路,即是不从程序下手,而从WebServer着手,我们可以把Apache配置成为使这类异常信息不再打印出来,而是使之仅出现一个通用的异常说明的页面,这样,就能十分有效地解决这个问题。
在我们使用Java作为编程语言的这么多项目中,绝大多数是比较成功的。
Java语言作为一种快捷、稳定的计算机语言,开发基于因特网应用的项目大多是相当稳定和比较适用的。
在我个人看来,Java的应用前景十分光明,大体上可以着眼于以下方面:
(1)在因特网上将会有更加广泛的应用。
(2)在嵌入式设备中,Java也大有用武之地。比如,在最新推出的Java技术中,Java已经进入了手机领域。
(3)Java程序大多以线程运行,占用资源少,会逐步代替ASP与CGI程序。
根据第三方测试表明:
JSP程序比ASP程序要快2倍以上。用JSP代替ASP应是大势所趋。
(4)Java在无线互联网中的应用将会更加广泛。Java支持WAP,可以方便地用Java开发WAP程序,实现WAP应用。
(5)Java与XML的无缝连接使Java在数据传输和异构网络通信方面有着很大的优势。
就我个人而言,我将会在相当长一段时期内致力于Java在无线互联中的应用,为我国的移动通信事业开发出更多的优秀实用的项目。
【评注】
评注;参与了一个较大的项目后有实践体会。全文都采用1、2、3、4方式,
文章的风格显得单调,不大吸引人。但是本文的优点是;
(1)写得很有条理。
(2)内容的选择合适。
(3)所列举的策略、注意事项与发现的问题都很现实可信。
论Java技术在因特网平台上的应用——银行业的应用
【摘要】
因特网上应用的日益普及与深化,为Java技术的运用提供了广阔的活动舞台,也大大推进了Browser/Server模式的企业内联网应用与网络计算。
作为某信息公司中的技术骨干,我有幸承担了某银行信贷管理与查询系统等的开发任务,独立地完成了其中的系统设计、类设计、部分开发及测试工作。
整个系统完全按照J2EE的标准来设计。前台界面应用了JSP技术,控制部分采用了Servlet来开发,业务逻辑应用了EJB技术来封装,应用服务器采用了支持J2EE标准的BEA公司的Weblogic,后台的数据库选用的是Informix7.3,
目的是为了与银行中其他业务系统数据库保持一致。在硬件平台上,我们选用的是HP公司的某台中型服务器机器,操作系统是HP-UX。
该系统界面运用的是IE,它不仅兼容性较好,而且已为广大用户所熟悉。
系统运行后,各个支行都普遍反映界面友善,功能强大,开发的效果令人满意。
【正文】
在银行应用中私人的储蓄、企业的会计、国际的业务、信贷、财务管理都是十分重要的,它们构成银行的基础业务系统。我从事开发的信贷业务更是银行利润来源的重要部分。与储蓄,对公等以交易事务为主的业务模式有所不同的是,
尽管信贷也是交易,但需要更多其他辅助信息的支持。如客户的基本资料,在本行内业务发生状况、信用等级、是否有逾期贷款未能归还等。各个支行的有关业务人员及分行管理人员都希望能方便及时地了解这些信息。传统的基于终端的用户界面难以传递这么多信息给用户,所以我们决定采用基于测览器IE的用户界面,一方面IE使用方便,不需要专门培训,另外它是与Windows操作系统捆绑在一起的,也可节省前台费用。在开发技术上有ASP,JSP可供选择。
由于考虑到Java技术在Internet上的迅速发展,J2EE更是提出了全新的用语言来统一平台的思路,于是我们决定采纳J2EE标准,并选用了JSP。在设计上,基本上是采用了一个交易画面对应于一个JSP程序,充分发挥JSP动态处理页面的长处。
为了使设计有更好的可扩性、灵活性与逻辑性,能为以后扩展奠定坚实的基础,我采用了(Modelu,View,Controller)的MVC设计模式,View全部由JSP实现,而Controller则是设计了一个Servlet程序,它负责处理前台浏览器传送来的所有请求,并按事先定义好的路径/程序关系,分发给相应的JSP程序去处理。由于Servlet本来就是为Java服务器端编程来设计的,因此由它来负责服务器端的处理是相当合适的。
在开始设计时,我运用了构件技术,由EJB承担起设计模式的Modelu角色。
具体的贷款开户,放款,结息逾期贷款,归还贷款等交易都对应一个具体的EJB。
为了将这些处理逻辑与相应的数据库操作分离开,能更加便于维护,我将处理业务的EJB设计成SessionBean,而为每个SessionBean再配备一个相对应的EntityBean,用于访问后台的数据库。贷款管理中有很重要的一点是进行查询,
我按照需求分析的结果,为每类查询都设计了相对应的Bean,其目标是尽可能地提高查询的速度。
在对数据库的存取中,我本来的设计应用InformixJDBC所带的DriverManager,这样,在存取数据库中的Bean中就要把Driver及Server写入,后来考虑到应尽量提高应用的平台独立性,在参阅了J2EE中JDBC部分的说明后,改用了DataResource的处理方法,这样,即使以后数据库换成Oracle或其他产品,程序也不用修改,只需要在配置时进行变动即可。
在这次信贷管理系统的开发过程中,Java的平台无关性优势,在开发人员从事开发的活动中体现得淋漓尽致。由于经费相对紧缺,我们的开发环境是各个项目组共用一台HP机器,虽然每个开发小组都搭建了自己的环境,但项目一多,
特别是遇上结息与批量测试等场合,机器就显得不堪重负,使开发与测试工作的效率大为下降。我们小组由于采用的是Java技术,大家可以在自己的NT机器上搭建相同的环境。这样一来,大家平时的开发工作,包括JSP,Servlet,EJB的程序,都可以在本地完成,只是到测试或展现阶段才需放到HP开发机器上进行。
以前我们开发的Web应用,往往只是应用了部分的Web技术,如采用ApacheWebServer、ASP开发语言等。整个体系的集成与组合往往不够理想,
这次由于我们采用的一整套符合J2EE标准的组件,整个系统的协同性与一致性非常之好。再加上有一个支持J2EE的应用服务器——BEAWeblogic,以往我们做得不理想的复杂配置,模块间的连结,如今都用不到再操心了,只需在图形化的配置工具中,输入系统所需要的配置,如路径与实际应用程序的关系,组件中的EJB引用,DataResource的属性等;全部配置完成后,Weblogic会替我们完成项目的部署,并将这一切有关的程序都封装起来。
原来,我们开发小组的文档编制任务显得非常之繁重,因为整个系统既有交易部分,又有管理查询部分,交易、数据与源程序都很多。为了解决这个问题,
我们直接应用了Java源程序中的Javadoc导出文档,这样不仅文档美观,而且能够保持与源程序的一致性,实乃一石二鸟之举。
整个项目完成后,用户使用下来都觉得界面友好,操作简便。但是我心里知道.这个系统还有很多可以加以改进的地方。
首先,基于Java系统的开发需要资金较多的投入,由于该系统受到经费的限制,只申请到一台生产用机,这样,WebServer、ApplicationServer、
DBServer只能被挤放在一起。虽然Weblogic能实现部分负载平衡,但在将来的业务发展时,这样的分布肯定不是最理想的。好在我们在设计时已经考虑过尽量有良好的扩展性,在以后条件许可时,只需进行在不同机器之间的进一步部署即可,应用程序大体上无需改动。
其次,在设计上,可以采用UML的产品,如RationalRose,另一方面,
RationalRose具有自动代码生成功能,也可以大大节省开发的成本。
最后,目前的信贷管理系统相对用户数目量不多,当推广类似系统需要拥有大批用户时,基于Java的系统的响应时间与系统分布都会有较为突出的矛盾出现。
以上这些,都是我在今后的系统设计与开发中需要加以注意的地方,也是运用Java技术应当努力的方向。
【评注】
评注:
讨论具体,应用较为深入,表达清晰。存在的问题属实。
论改进Web服务器性能的有关技术—银行业的应用
【摘要】
基于Web技术的数据库应用是当前应用的一个热点,在用户数目与通信负荷很大的场合,提高Web服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发,阐述了提高Web服务器的性能应渗入到项目论证、
选型、开发、运行和管理的各个环节,只有各个环节都能充分考虑到性能与质量的需要,系统的性能才是真正可保证的和可扩充的。
文章从系统的实际运行与相应的经验出发,阐述了性能改进方面的一些具体措施。
比如:
在本文中讨论了Web服务器平台的选型考虑;Web服务器的配置管理;
应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容。
通过技术上的分析与改进,综合性地运用多类措施与手段,在实际系统中,Web服务器运行的性能得到了一定程度的保证。
【正文】
我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。
随着金融电子化建设的发展和商业银行之间市场竞争的加剧,各主要商业银行不断通过信息技术提供新的金融产品,并且希望能整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务。在这种背景下,本人参与了开发新一代网上银行产品,涉及到提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干,在整个项目开发过程中始终要处于第一线,从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多,在本文中简要讨论如下,希望与读者们共享经验。在Web服务器配置与优化方面,我有如下几方面主要的体会:
第一方面是Web服务器选型考虑。
在Web服务器选型及网上平台搭建之初,我们就已充分考虑整个网上平台的性能及可扩展性问题。这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。
某银行原有的一些网上产品由于开发较早,故而采用的是老式的HTTP
Server+CGI程序调用的方式。这时,每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理,系统的开销相当大,系统的扩展能力也很差,性能已不能满足业务处理的需要,故而在为此银行系统具体选型的时候,我们一开始就否决了这种方案。
通过市场上同类产品的比较选择,我们选择了国际商业机器有限公司IBM的WebSphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为WebSphere基于使HTTPServer和应用服务器相分离的整体架构,同时支持JSP、Servlet和企业组JavaBean等轻量级线程规范,所有的请求对应于应用服务器上的处理线程,系统的开销低、效率非常高,同时WebSphere整个体系结构相当的灵活,为适应扩展需要可以作不同的横向和纵向扩展,从而可以满足各银行未来的扩展需要。
正是因为在一开始选型的时候我们就已考虑到未来的扩展需要,整个系统在接下来的几次性能改进方面,我们大体上都能相对顺利地达到了预期目标。
第二方面是Web服务器的性能配置。
在一开始系统上线的时候,由于系统的负荷不是很大,为了节省系统总拥有成本TCO投资,我们在一台较低配置的IBMRS6000上投产了该系统。整个系统的HTTP服务器、应用服务器、通信服务器等均位于该台机器上,由于初始投产时用户不多,所以系统的性能基本上能令人接受。
但随着业务的发展和用户访问量的增大,我们发现该服务器的响应变慢,
系统的CPU利用率和内外存交换显著增大。经过跟踪,我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用,当内存不足时,大量Session信息被迫交换至硬盘,大量CPU时间消耗在等候内外存的交换上,系统效率迅速下降。
鉴于这种情况,我们把该服务器的内存由2GB扩充为4GB,同时相应调整用会话信息的保存时间,这样整个系统的效率又回到较为理想的状况。
由于新应用的不断投产及数据库操作的日益增加,我们后来逐渐监控到系统的数据库处于繁忙状态,系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下,我们认为整个系统由于硬件配置所限,应该进行横向扩展,因此我们把数据库服务器分离出来,配置到另一较高性能的服务器上,相应定义的数据库资源也大幅增加,这样整个系统的性能又处于较为理想的状况。
第三方面是对应用系统进行相应的优化以提高性能。
Web服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径,但应用系统的优化也是应该重点加以考虑的,毕竟它能够在投入较少的情况下提高系统的运用效率。
在开发的初期,我们就已经十分注意系统的利用效率,比如提醒程序员尽量不要利用用户会话信息(Session)来传递大的对象,对于内存要注意回收等。
同时,通过内部的交流会推广与介绍一些小的、有用的编程技巧来提高开发人员的水平,通过代码的抽查,希望能在早期就发现问题等。
在系统运行期间,我们通过监控发现,应用服务器所基于的Java虚拟机,
其内存堆的空闲空间有不断下降的趋势,每隔若干天导致空间消耗殆尽、无法分配新对象空间,从而导致系统重启。在排除了系统本身问题的原因外,我们确定为应用系统的开发有问题。通过从网上万载IBM公司检测Java虚拟机的相关工具对JVM进行监控后终于发现系统内部存在着不能回收内存的对象,再通过查找相应的程序发现在该程序中有“环状”的对象引用,从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦,但由于该问题不能通过升级硬件或增加资源配置而得到根本解决,会给系统带来很大的隐患。所以,整个过程的分析与解决是完全值得的,更何况通过查找故障原因的过程,给整个项目组上了生动的一堂软件质量保证课,对项目组的质量意识起了很大的促进作用。
所以说改进Web服务器的性能井不单纯是系统管理方面的工作,它渗透到开发以及系统运行等一系列环节中。
第四方面预先考虑未来的扩展与性能需要。
随着系统的发展及成熟,考虑到用户访问量的不断上升,为了预留系统的发展空间,我们最近又对整个系统作了一个系统性的升级。通过引入多台HTTP服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要,这一项的升级无需对整个系统的体系结构作根本的变革,对应用程序来说,更是没有造成任何影响。整个项目历时近两年,从这两年的系统情况来看,整个系统是成功的。根据我亲身的经历,系统性能并不单纯是系统运行与管理阶段的问题,而是渗透在项目论证、开发以及运行的各个阶段。只有在各个阶段都能充分考虑性能方面的需要,在实际运行时,整个系统的性能才可能真正有保障。在技术方面来看,可以综合利用选型评估、硬件扩展、应用优化和系统配置优化等一系列的手段;比如在硬件扩展方面,又可以分为主要部件扩容,纵向升级、横向升级等方面。在我们的项目实践中,曾综合地利用了上述的各种手段。比如某银行的整个系统从日访问量不足1万至现在的每日超过I0万次以上的点击的发展情况来看,整个系统的性能保障及提高方案是比较成功的。
【评注】
实践过程较有说服力。条理与思路相当清晰,技术措施与管理措施的推进也很明确。所论述的技术还有一些局限,不够开阔。
论改进Web服务器性能的有关技本——数字图书馆类的应用
【摘要】
一个大中型的图书馆信息系统涉及到许多方面的技术与方案,本文着重讨论与Web服务器性能有关的一些内容。
本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于Web应用软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、全文、图像或音频视频等多媒体信息,对Web服务器性能有着较高的要求。
结合实际工程的经验,本文将从硬件实现手段(缓存服务器、均衡负载设备、
Web双机镜像、CPU和网卡的提升、网络带宽扩充)和软件实现手段(三层C/S软件结构设计、应用程序部署)等两个大方面论述如何提高Web服务器的性能,
以便使用户能够更快捷、高效、安全地使用应用系统。
【正文】
随着Intranet信息技术的发展,图书馆为了更好地发挥其图书流通、资料检索和学术交流的职能,图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆的行列,已经启动了一部分的数字图书馆工程。
该数字图书馆工程主要包括对外信息Web发布系统,交互式检索网、后台馆藏信息管理系统、多媒体资料采集制作以及VOD点播系统等。本人有幸作为项目负责人之一,参与了整个数字化信息系统的总体设计,并参与了基于Web的一些应用(如对外信息发布系统、图像/全文混合检索系统、VOD点播系统)的开发。
某图书馆数字化信息系统从网络环境上讲,主要划分为
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 技术在因特网平台上的应用通信服务平台的应用 技术 因特网 平台 应用 通信 服务