B/S技术架构（精选10篇）

B/S技术架构 第1篇

1 系统结构设计

大型桥梁结构健康监测系统面对多用户,无论是现场的技术人员,还是桥梁维护的管理者和决策者,都需要及时了解桥梁结构各方面的状况;其二、很多大型桥梁跨建在城市郊区河流之上和偏远山区的高山之间,不便于进行经常性的实地检测和系统维护;其三、各个子系统分别在不同的硬件和软件环境下运行,如何保证不同功能的子系统在物理上、逻辑上和功能上的相互连接和协同工作,这些都要求系统有一种合理的结构,保证预警等系统的高效、有序运行,最终完成和实现大型桥梁结构健康监测与安全的诊断、预警功能。B/S架构是两层的C/S架构在Web上的一种应用,即浏览器/服务器/数据库服务器的三层结构(如图1),它通过引入一组业务对象将Web客户端应用程序从业务逻辑和数据访问代码中分离出来,客户端只是负责最终数据的显示,隐藏在业务对象后面的所有复杂性都与它们无关。B/S架构体系简化了客户端,无需像C/S架构那样在不同的客户机上安装不同的客户应用程序,而只需安装通用的浏览器软件。这样不但可以节省客户机的硬盘空间与内存,而且使安装过程更加简便、网络结构更加灵活。另外,它简化了系统的开发和维护。系统的开发者无须再为不同级别的用户设计开发不同的客户应用程序,而只需把所有的功能都实现在服务器上,并就不同的功能为各个组别的用户设置权限就可以了。各个用户通过请求在权限范围内调用服务器上不同处理程序,从而完成对数据的查询或修改。

基于B/S架构的大型桥梁结构健康监测系统充分发挥了WWW浏览器技术优势,通过结合使用ASP.NET+AJAX等多种组件技术,能节约开发成本,实现在一个平台上有效地集成各个子系统,可以完成原来需要专用软件才能实现的强大功能,用户通过浏览器就能方便地进行远程访问。系统在管理维护时,也不必更新所有的客户端软件,只需通过远程操作修改监控现场的服务器端软件就可以进行系统升级。

2 系统开发关键技术

2.1 ASP.NET AJAX技术

在大型桥梁结构健康监测过程中,为能充分反映桥梁的结构特性,捕捉一切引发异常的线索,在大桥上布置了大量的各类测点。在系统中要真实反映这些测点所监测到的情况,并能使工程技术人员、桥梁维护管理和决策者方便地掌握桥梁现场的结构数据变化,需要对传统的Web系统交互方式进行优化。在B/S架构的大型桥梁结构健康监测系统中应用基于ASP.NET AJAX技术的Web无刷新页面数据粒度更新方法使监测系统交互性得到了前所未有的提高,大大增强了系统应用的实用性和实时性。

ASP.NET AJAX(Asynchronous Java Script+XML)是微软公司推出的用于.NET 2.0环境下的AJAX框架。它是目前对AJAX最完备且功能最强大的封装,包括完善的面向对象编程的支持,丰富的客户端/服务器端组件、为远程Web Service提供本地客户端代理等非常强大的功能,极大优化了Web应用程序的交互性[3]。

其工作总体思路如图2。客户端程序将用户查询指令传递到布设在桥梁现场的监控中心Web服务器;在服务器端,Web服务器响应用户请求并连接中心数据服务器生成查询命令,获取相应数据。Web服务器不再将查询整体结果以HTML页面的形式传递给浏览器,而是转变成一个XML文件传送给客户端,然后在客户端恢复数据集的格式(这部分工作由图2中的AJAX引擎来完成),由客户端进行数据的排序、分页等操作,在网页上进行显示[4]。这样做的优势是:

(1)减轻了监测系统中Web服务器的负担。因为AJAX技术是按需取数据,对桥梁不同结构截面测点数据进行提取,以点的方式在页面上显示,最大可能地减少了冗余请求和响应对服务器造成的负担。

(2)无刷新粒度更新页面,减少用户的等待时间。在图2中,用户和服务器之间增加了一个中间层,使用户操作与服务器响应异步化。但并不是所有的用户请求都提交给服务器,如一些数据验证和数据处理等都交给AJAX引擎来做,只有确定需要服务器读取新数据时再由AJAX引擎代为向服务器提交请求。

(3)可以创建更加丰富、更加动态的Web应用程序用户界面,其即时性与可用性甚至能够接近本机桌面应用程序。

2.2 系统数据库的设计

大型桥梁结构健康监测系统在长期运营过程中,数据采集系统积累了海量数据。面对监测系统采集到的海量数据的查询分析,仅仅依靠数据库管理系统地查询检索机制和统计学分析方法已远远不能满足现实需求——桥梁维护的管理者和决策者需要对桥梁不同结构部位、相同结构部位不同监测内容等关系数据库进行大量计算才能得到结果,而简单查询的结果并不能满足决策者的需求[5]。SQL Server 2000中的联机分析处理(OLAP)致力于处理浩如烟海的数据,能针对特定分析需求进行联机数据访问,能够自动、智能地将有用的信息和知识从待处理的数据中转化出来,能够真正为用户所理解,并真实反映桥梁结构特性,通过快速、一致、交互地访问各种可能的视图,帮助桥梁维护管理者和决策者实现对数据的归纳、分析和处理,为桥梁结构健康监测系统提供决策支持[6]。

OLAP的显著特征是它能提供数据的多维概念视图(Multidimensional)。“维”是人们观察数据的特定角度,例如,桥梁维护管理人员常常关心同一监测对象在不同结构部位的差异情况,这时,它是从桥梁结构的角度来观察监测数据,所以桥梁结构就是一个“维”,同理,时间也是一个“维”。数据的多维视图使最终用户能从多个角度、多侧面、多层次地考察数据库中的数据,从而深入地理解包含在数据中的信息及其内涵[6]。

在大型桥梁结构健康监测数据仓库模型中,以应力测量主题为例,选定与之相关的5个维——时间维、桥梁结构维、测点维、温度维、传感器维,其星系模型如图3:中间2个表表示应力测量情况(事实表)和温度测量情况(事实表,且是应力测量事实表的维表,与之共用桥梁结构维和时间维),四周4个表表示与之相关的信息(时间、桥梁结构、测点、传感器——维)。每个维表有自己的属性,通过维关键字,将事实表和维表进行连接,就组成了“星”型的数据仓库,几个“星”型的集合就组成了图3中的“星”系模型。其中各个维表描述的是同一问题相关的各个因素,而事实表是星型结构的核心,记录了这些因素限定下对主题监测的结果。例如,如果从时间维和测点维角度考虑问题,分析某一段时间内某一个测点应力变化趋势,事实表记录的就是这2个因素限定下对应力的监测结果,就是一个时间序列的样本集。如果从桥梁结构维和时间维、测点维、温度测量维角度考虑问题,分析某一段时间内某一桥梁结构中某一测点应力测量值与温度之间的关系,应力测量事实表记录的就是前3个因素限定下对应力和温度的监测结果。使用星系模型过程中,事实表包括了主要的监测数据,只要扫描事实表就可以进行查询,无需连接多个庞大的数据表;同时,维表一般都很小,与事实表连接时,其速度很快,大大提高了查询速度。另一方面,星系模型比较直观,方便使用者根据需求组合各种查询,进而做各种因素的关联分析,为桥梁维护管理提供科学决策支持[7,8]。

3 系统应用

基于B/S构架的大型桥梁结构健康监测系统采用SQL Server 2000作为系统数据库,在SQL Server 2000中构建OLAP数据仓库,通过编制应用程序、扩展存储过程等实现数据的存储、清洗、转换等等;服务器端采用Microsoft公司的Web服务器IIS 5.1,以VC6.0和VS.NET 2005作为开发平台,并采用ASP.NET技术和COM组件技术。系统成功应用于某大型斜拉桥结构健康监测中,其主要界面如图4所示。

4 结语

本文对基于B/S架构的大型桥梁结构健康监测系统进行了研究分析,在对Web应用中的B/S模式和C/S模式进行比较的基础上,分析了B/S模式在桥梁结构健康监测中应用的优势,并引入ASP.NET AJAX技术解决了传统B/S模式下Web开发的一些难点,对某大型斜拉桥结构健康监测系统进行需求分析,设计了一个OLAP数据仓库,并将这些技术成功应用于监测系统中,取得了良好的效果。

参考文献

[1]Aktan E,Chase S,Inman D,and Pines D.Monitoring and Managing the Health of Infrastructure Systems[C]//Proc.Of the2001SPIE Conference on Health Monitoring of Highway Transportation Infrastructure,SPIE,March6-8,2001.

[2]张启伟.大型桥梁健康监测概念与监测系统设计[J].同济大学学报,2001,29(1):65-69.

[3]杨华.AJAX在ASP.NET中的实现[J].现代电子技术,2006(12):79-82.

[4]Ballard P.Sams Teach Yourself Ajax in10Minutes[M].US:Addison-Wesley,2006:1-200.

[5]丁幼亮,李爱群.润扬长江大桥结构损伤预警系统的设计与实现[J].东南大学学报自然科学版,2008,38(4):704-708.

[6]沈兆阳.SQL Server2000OLAP解决方案-数据仓库于Analysis Services[M].北京:清华大学出版社,2001.

[7]杨锦园.基于数据仓库的桥梁健康监测数据分析与处理系统研究[D].武汉:武汉理工大学,2006.

B/S技术架构 第2篇

【关键词】B/S架构；一卡通；建设研究

随着我国网络技术，计算机技术等先进技术的不断发展，信息化迅猛发展，基础设施建设初具规模，为学校教学、管理创造了信息化环境。校园一卡通系统是针对目前使用的证件繁多、管理繁杂的情况而设计的，用一张卡代替目前使用的菜饭票、考勤卡、洗浴票、开门钥匙、巡检记录本等等，从根本上实现“一卡在手，走遍校园”的设想。通过校园的综合网络，逐步将各处的电脑联成一个比较大的数据网，实现校园各类数据的统一性和规范性，使校园走向科学化、现代化管理，大大提高了校园的内部管理和内部形象。

一、B/S架構校园一卡通平台优势

（一）实现了应用、数据大集中.校园卡系统是在学校一个相对独立的组织范围内，以一张卡将组织内的多元化管理功能整合起来的信息管理系统。在“数字化校园”中，校园一卡通系统因涉及到校园生活的方方面面，而成为校园信息化建设的基础和重点，它为学校的学生、教师和管理提供了具有开放性、灵活性、面向学校的应用服务管理平台，给校园带来了全新、方便的现代生活和工作方式。

（二）B/S与C/S结合模式采用B/S与C/S两种模式优势结合，扬长避短。实时任务处理使用C/S结构实现，数据查询管理报表打印等使用B/S结构实现，校园各部门、各个营业场所（食堂、小卖部等）、各用户都可以使用浏览器登录使用系统，完全不受地域的限制，维护容易，升级成本低。

（三）灵活的权限设计。独立高效安全可靠的身份认证和权限管理，可以针对各种用户群体制定其相应的使用权限而不是传统的单一的用户管理模式。客户端零维护各用户采用浏览器直接访问系统，客户端不需安装和维护系统，实现客户端零维护。

（四）丰富的报表功能。系统自动生成一些固定格式的报表，如营业、出纳、考勤门禁等，这些报表的自动生成既迅速又准确，大大提高了统计工作的效率。同时又由于这些报表是建立在实际业务运作的数据基础上，因此是对现有综合业务管理的数据反映，高层管理者可通过对多种数据进行综合分析，从而进行更为理智、科学的评定。

二、一卡通总体设计原则

在坚持稳定性、安全性的基础上，直接借助校园网（或专网）传输数据，实现学校各类商务消费、浴室水控、门禁考勤、上机收费的一卡通行。

（一）实用性与可行性原则

实用与可行性是系统的基本要求也是最高要求，要使规划设计的系统实用可行，除了要全面了解技术上的动态之外，更要了解实际需求，要做到一切面向应用，要根据真正需要确定系统的规模、采用的技术。当然在这种前提条件下，一定要要考虑管理的发展，考虑技术的进步，考虑需求的膨胀，从而确保系统的持续稳定增长。

（二）开放性与标准化原则

系统的开放性就是指系统结构的开放性，连接的开放性、协议的标准性以及应用的开放性，开放性的考虑要贯穿于系统的整个规划、设计全过程。一卡通系统涉及与银行、财务、业务等多个单位的信息交换与连接，不把握开放性原则，就难于将各系统融会贯通。

标准化包括格式统一规范，统一标准和统一接口。系统设计要确定标准代码和标准信息分类编码，规定各系统间数据交换的统一接口。

（三）可靠性与稳定性原则

对一卡通系统在技术上应该优先考虑系统的可靠性与稳定性，以保证系统具有良好的运行状态。系统平台的可靠性与成熟性要从软、硬件平台、网络构建、通信介质等多方面进行考虑。通过采用关键节点的设备和模块冗余、线路冗余，建立后备系统和灾难恢复机制等一系列措施来保证硬件系统平台的可靠性与稳定性。

三、一卡通平台建设体系架构

平台+应用”的1+N架构一卡通平台是架构在网络基础上，利用计算机、网络设备、终端等设备，充分发挥网络优势，实现先进的信息化管理和卡片交易的系统。系统的设计应有明显的时代特色和预见性，留有十分灵活方便的扩展接口，为数字化校园建设的持续发展打下坚实的基础。依据以上建设原则和分析规划，校园一卡通系统应达到如下建设目标：

（一）以建立校园一卡通系统为契机，建立学校各类学生、教职员工、各种组织机构基本的、统一的信息化标准，促进数字化校园的建设。校园一卡通系统基础数据总平台的基础上，可以随时向持卡人提供准确的校园卡使用情况，包括本人帐户数据、电子钱包数据以及在其他场合使用的流水帐，方便持卡人个人理财。

（二）建设财务结算中心，该结算中心与学校的财务管理部分一体化设计，为学校财务管理提供更加科学、有效、安全、便捷的理财服务，实现各校区的财务统管。内所有的证件都由校园卡代替，所有用证、用卡的信息管理系统，可扩展身份识别部分连通校园一卡通系统，实现身份识别的数据共享。可扩展实现与教务管理系统的对接，实现持卡人按学期的学籍注册选课管理，同时实现校内公用机房的上机收费管理，图书馆收费管理，机房管理系统等。

（三）平台使用混合C/S、B/S模式的多层体系架构，以“平台+应用”的1+N架构，，即一个平台（一卡通平台）N个应用（一卡通管理及应用子系统），在此平台上，各种应用子系统以“可插拔”的方式进行接入，这为将来新增的应用提供了无限的接入扩展。

集中平台包括三大业务中心，为系统提供服务：

身份数据中心：为一卡通提供身份数据管理。

财务中心：为学校进行财务数据服务。

服务中心：为一卡通用户提供信息服务。

四、总结

学校作为管理机构可利用校园一卡通系统规范和统一校内管理，避免了人为损失，极大地提高了工作效率。而作为持卡人的学生则用一张智能卡，取代了校内使用的各种证件及卡，自由地在校内和校外进行消费。既方便了生活，又真正实现了“一卡在手，走遍全校”。

参考文献：

[1]马荣飞；校园一卡通系统的设计与实现[J]；计算机与现代化；2005年03期.

[2]朱煜，赵谨，高敦岳；基于C/S体系结构的一卡通局域网管理系统[J]；计算机工程；2002年02期.

B/S技术架构 第3篇

的需求及特点,利用单服务器集群技术进行系统设计以满足高可用性等的要求。

1 设备系统的架构设计

设备系统的平台将利用产销系统平台资源的扩展能力进行扩展,同时保障系统的稳定性和可靠性,在选用成熟技术的前提下,充分地利用新的技术和方法,既符合当代信息技术发展趋势,又具有成功的经验。系统设计思想如下。

(1)系统架构的高可用性。

从设备管理系统的功能需求分析看,系统的主要特点是:联机事务处理和交易量大,需要支持500个以上的联机客户端。应用处理的特点是在同一时间段内,相同模块的并发处理量大,模块间的应用逻辑相关性强,而且每个模块所涉及的关联数据表相当多,造成每个应用需读取和修改大量的数据库表,且所涉及的数据库表之间的关联相当复杂。针对这些特点,决定采用单数据库服务器和应用服务器设计,同时需要特别考虑数据库表与记录的合理分布问题,通过在设备管理系统中设备编码的设计,使不同的设备以不同记录来存储,相同设备通过设备编码的子项以相同记录的不同字段来存储,保证相同的功能模块在访问数据库时所涉及的记录能保证不同,以提供最佳的“读”一致性。在B/S设计架构下,通过集群技术将B/S架构下的应用服务器和数据库服务器组成互为热备的系统。在正常情况下,应用服务器和数据库服务器各自运行各自的功能,在故障情况下,如应用服务器发生故障,其功能通过集群技术切换到数据库服务器上,数据库服务器承担起应用服务器和数据库服务器的功能,反之亦然。从而使B/S架构下的单服务器系统可以提供高可用性。

(2)将Web服务器层和应用服务器层合二为一。

B/S三层架构模式的特点是客户端的“0”安装(只需浏览器)以及Java的平台无关性,使客户端不需要安装维护,极大地降低了系统运营维护成本。逻辑上B/S模式分为客户端层、Web服务器层、应用服务器层和数据服务器层。在不锈钢分公司内部的Intranet范围内,设备管理系统用户数量与Internet相比,系统规模不是非常大的情形下,具备将Web服务器层和应用服务器层合二为一的条件。

(3)利用现有产销系统资源的扩展能力。

不锈钢分公司产销系统由两台HP Superdome服务器组成数据库服务器,构建了SAN的存储环境等基本的系统硬件条件,在此系统硬件环境下,通过对现有系统的扩容,实施设备综合管理系统。设备综合管理系统采用B/S三层架构,系统硬件方案设计充分考虑了对现有系统的投资保护,利用现有产销系统扩展能力,在产销系统的两台HP Superdome服务器上各增加两个硬件分区(各8CPU,16GB内存),作为设备管理系统的应用服务器和数据库服务器,共享现有的SAN环境、对SAN交换机、XP512存储磁盘阵列系统,通过应用服务器和数据库服务器互为热备的集群系统,实现系统的低配置、高可靠性的设计。

(4)利用现有的网络资源,满足客户端接入的需求。

宝钢股份不锈钢分公司在建设产销系统时,同步建设了相应的公司主干网络,并覆盖到相应的外协单位,采用B/S三层架构使企业外部的协力单位可以通过授权方式,方便地使用设备管理系统。

根据不锈钢分公司设备管理系统规模大、终端用户遍布全厂的特点,采用三层逻辑架构[2],如图1所示。三层架构模式是伴随着中间件技术的成熟而兴起的。核心概念是利用中间件技术将应用分为表示层、业务逻辑层和数据库服务器层三个不同的处理层次,以中间件作为构造三层架构应用系统的基础平台。基于三层架构的应用系统不但具备大型机系统稳定、安全和处理能力高等特性,同时拥有开放系统成本低、可扩展性强、开发周期短等优点。[3]系统同时增加一台虚拟磁带库作为设备管理系统及现有产销系统的备份设备。[4]系统硬件体系结构如图2所示。

2 集群技术

2.1 集群技术的特点

集群是以网络技术连接起来的一群计算机组合,在工作时像一个整体资源。集群技术继承了从分布式系统的研究中获得的大部分成果,但是它们之间有一些显著的区别。集群是典型的同构和紧密耦合系统,分布式系统可以由具有不同种类的异构计算机组成;集群系统的节点互为信任关系,而分布式系统必须处理无信任关系节点的请求。集群可以以多种方式配置,有PC集群、工作站集群和SMP集群,在节点操作系统上有Linux,NT,Solaris,AIX和HPUX。集群配置方式取

决于存储系统、客户机、监视、资源共享、节点数、故障的屏蔽能力。

集群技术可以使用户以较低的成本来改进用户的计算机处理能力。在集群软件的支持下,应用程序的性能将得到改善,同时集群计算更具有故障恢复能力。基于应用目的的不同,集群可以分为科学计算和高可用应用,就形成了高性能集群和高可用性集群;基于节点间归属的不同,可以分为专用集群和非专用集群,专用集群是指个人拥有系统的全部资源,非专用集群是指系统的资源是共享的。宝钢不锈钢设备管理系统采用SMP计算机架构,组成非专用的高可用性集群系统。

2.2 集群软件MC/ServiceGuard

本设备系统采用MC/ServiceGuard集群软件,它是HP9000系列计算机的高可用性集群软件,当计算机硬件和系统软件出现故障时,可继续执行应用程序的服务。它采用一种基于应用可迁移的方法,使多个通用系统通过网络相连,用SCSI或光纤通道连接需要物理共享的外存设备,但同时只有一台机器存取一个物理设备。系统间定时发送heartbeat信息,一旦对方系统故障,故障系统中的应用自动切换到备机上运行。[5]

MC/ServiceGuard管理应用以Package(应用包)为单位,一个Package包括一个浮动的IP地址、系统进程、若干应用进程以及应用进程所用的硬盘。不管应用包如何切换,为前端用户提供服务所对应的IP地址是固定的,这样保证应用切换对用户是透明的。集群系统中没有一台机器是空闲的,各自运行自己的应用,使系统能力得到了充分发挥。

MC/ServiceGuard系统中系统硬件和集群软件相配合,完成单点故障的系统切换。设备管理系统的集群硬件结构如图3所示,如果在集群系统中,应用服务器节点的硬件、服务、网络或其他资源出现故障,MC/ServiceGuard 则自动将程序包的控制权转移给集群中的另一数据库服务器节点,保证服务在系统中继续进行。图中虚线部分是发生单点故障情况下后备磁盘的访问路径。

MC/ServiceGuard集群软件,是在操作系统和磁盘卷组管理软件之上的系统软件,其软件层次结构如图4 所示,MC/ServiceGuard组件是集群系统软件,程序包由用户根据不同的应用自行编制。

MC/ServiceGuard共有九个守护进程,分别是:配置守护进程、集群守护进程、日志守护进程、逻辑卷管理守护进程、Object Manager守护进程、SNMP 子代理(可不运行)、服务助手守护进程、共享磁带守护进程和仲裁服务守护进程。

3 系统和集群的配置设计

3.1 网络设计

集群系统需要设计两个独立的网段,分别是服务网段和心跳网段。服务网段供服务器对外提供应用程序访问服务,网络IP地址的设计采用浮动IP地址,物理上并不存在于网络系统,这样可以保证网络的安全性,访问服务只有配置了Oracle,Weblogic和集群软件MC/ServiceGuard后才能使用。心跳网段用于集群环境中集群服务器之间传输心跳信号,采用单独的局域网络设计,仅仅在集群服务器间建立网络联系。

3.2 FC Switch 光纤交换机的端口与Zone配置

为了提高系统的可靠性,所有设备都通过冗余的通道分别接到FC 交换机上的两块交换网卡上以减少单点故障。此外,在设计时需要考虑在交换机上划分不同的Zone以避免相互之间的性能干扰,并提高数据访问速度和安全。服务器各配置二块光纤通道卡,在与光纤交换机连接时,保证二块光纤通道卡连接在不同的光纤交换机上,以避免单点故障。在Zone的划分上,原本也应该将各不同的服务器配置在不同的Zone里,但是在本方案中,由于采用的是单机互备的高可用设计,因此,对需要进行互切的服务器,相互配置在各自Zone里,以保证在发生故障时,服务器上的应用切换到备机上,同时原服务器上访问的存储资源也能被新的服务器访问。

物理存储系统为本地存储和阵列存储,本地存储主要为系统软件的安装,在进行存储系统逻辑单元的划分时,对每一个逻辑卷都提供两个独立的FC访问通道,将XP512上相对应的两个FC通道分别连接到不同的FC交换机上,主机能通过存储系统上不同的光纤通道访问同一个逻辑设备,从而保证SAN环境的高可用性和高效率。

3.3 集群设计

在集群的设计上,由于需要将应用服务器和数据库服务器互为备份,因此,在应用服务器和数据库服务器上的集群配置文件采用不同的配置,通过配置,使一个集群上的不同节点运行不同的程序包配置文件。当集群节点发生故障时,可以通过这些不同的程序包配置文件,并通过运行不同的程序包文件,使发生故障节点上的应用在备机上自动启动,达到应用的高可用性。应用服务器上的pkgapp.sh和数据库服务器上的pkgdb.sh分别为启动应用和数据库的脚本文件。

3.3.1 集群的拓扑和集群配置文件设计

集群拓扑设计包括定义集群的名称和节点。集群的网络配置采用双网卡设计,同时定义浮动IP地址作为对外提供访问的访问地址,这些定义通过集群的配置文件来完成。通过集群管理器配置文件定义和保存这些参数,并通过发布命令,发布到集群中所有节点上。

3.3.2 集群程序包配置文件和程序包文件设计

设计集群的程序包文件就是定义一组应用程序服务,程序包文件由集群软件的程序包管理器在集群中的所有节点上运行,由程序包管理器运行这组应用程序服务,该配置还按优先级顺序列出了可运行该程序包的集群节点,并定义了允许该程序包使用的可接受故障切换类型。程序包配置文件可以通过SAM 的方式和程序包生成命令进行生成和配置程序包配置文件。

程序包必须包含有一个独立的、可执行控制脚本,放在程序包目录中,并且必须与程序包配置文件的RUN_SCRIPT 和HALT_SCRIPT 参数中指定的名称相同。可以用程序包生成命令生成模板文件,然后进行编辑,形成集群的程序包文件。

3.3.3 集群启停、切换

在集群的各节点机上,分别配置上述3个文件(集群配置文件、程序包文件、程序包控制文件)。集群启停、切换过程如下。

(1)通过集群的配置命令检查配置文件的正确性。

(2)生成和分发二进制文件。

(3)集群的启动。当完成配置文件检查、生成和分发后,使用集群启动命令启动集群。其中可以通过参数选项来指定特定的节点。如果没有选项,将启动所有节点。

(4)集群的关闭。需要在集群所有节点上,先停止程序包软件,然后关闭所有集群节点,最后将整个集群关闭,相关的集群命令有 #cmhaltpkg pkg1,#cmhaltnode clnode1和#cmhaltcl。

(5)查看集群状态信息。采用cmviewcl命令可以查看集群的运行情况。在集群运行和关闭时,还可以通过集群系统的log文件查看集群运行过程中有无错误信息(在/etc/cmcluster/pkg1目录下,用#tail control.sh.log 查看)。

(6)集群的故障切换。当集群中某节点发生故障的时候,由于在集群的程序包文件定义了自动切换参数(AUTO_RUN YES),因此在发生故障时,程序包会自动切换到另一节点,程序包切换包括移动程序包和将它们的相关IP 地址移动到新的系统中。故障切换时,原TCP 连接将丢失,应用程序必须重新连接。当故障修复后,程序包的恢复有自动和手动两种策略(在参数FAILBACK_POLICY中设置)。故障的手动切换由程序包采用手动命令切换,即用cmhaltpkg命令在一个节点停止程序包(#cmhaltpkg pkg1)。当用cmviewcl命令看见pkg1程序包的状态为down时,用cmrunpkg命令将程序包切换到另一个节点上(#cmrunpkg -n clnode2 pkg1)。

4 结束语

该系统于2006年投入试运行,系统的测试和实际运行表明,系统能够支持应用功能的要求,并能很好地体现系统的高可用性。设备管理系统实际的客户端数为500个,数据表数150个,数据量为200GB,每天交易量约为5000,涵盖的应用主要有设备资产管理、现场设备管理以及支持这些管理所需要的各种基准和标准等的管理,共计11个管理子系统。在实际运行过程中,曾经出现过应用服务器故障停机的现象,但集群发挥了作用,服务器进行了自动切换,应用在数据库服务器上自动启动,相关的系统软件和应用软件也在数据库服务器上自动启动,并对外提供服务。系统能够在20s内完成切换,用户仅仅感觉到页面有一个停顿现象,通过刷新,应用又重新连接到切换后的服务器上。运行实绩显示,采用单机的B/S三层架构模式的设备管理系统是完全可行的,并且有良好的可靠性和可用性,具有在完成信息化基本建设的冶金企业中推广的价值。

参考文献

[1]赵敏.企业设备管理系统的建立与思考[J].矿冶,2006(2):103-106.ZHAO M in.Approach to the estab lishm ent of enterpriseequ ipm entm anagem ent system[J].M in ing and M etallur-gy,2006(2):103-106.

[2]谈春燕.综合设备管理系统的关键技术及实现[C]//2007年中国科协年会论文集.武汉:湖北科学技术出版社,2007.

[3]Robert O rfali,Dan Harkey,Jeri Edwards.C lient/ServerSurvival Gu ide[M].Newyork:Johnw iley&Sons,INC,1999.

[4]谈春燕,吴劲松.信息系统整体架构设计在大型钢铁企业的应用[C]//冶金企业MES和ERP技术实践论文集.北京:冶金工业出版社,2005.

B/S技术架构 第4篇

关键词：ASP；B/S架构；中医药信息化；数据库；信息系统

中图分类号：TP311.52

随着计算机技术、通信技术以及Internet的高速发展，利用先进的信息技术手段加强中医药信息资源的建设，将中医药有效信息转化为数字化知识，已经成为中医药信息化发展必须面对的一个问题[1-3]。目前，各地都相继开展了各类中医药信息网的建设，文献收录的中药已有万余种，但是中药数据量巨大而且品种繁多、成分复杂，在查询过程中经常出现部分药有同药异名、异药同名、一名多药、一药多名的情况，而且中药的两重性和双向性使中药信息量更大，关系较为复杂。

如何为广大用户和各级人员提供准确、及时的中医药信息，已成为中医药信息化要解决的主要问题。针对以上情况，本文通过运用Web开发技术设计并建立一个基于B/S架构的中医药信息数据库系统，，对目前常见的中医药信息进行规范及统一整理，为完善中医药信息查询提供了准确可靠的信息平台。

1 系统规划与设计

1.1 系统功能分析。准确、快捷是开发中医药信息查询系统的首要目标，系统功能分析是在系统开发的总体任务的基础上完成的，该系统实现的功能主要有：（1）可任意输入中药的中文名称、拉丁名、化学成分等内容的一部分，即可快速检索出符合条件的所有中药列表，并可依次详细查看各种中药的中文全称、拉丁名、药性、药味、归经、用法、储藏方法、禁忌、毒性、配伍、功能、主治、药理作用、西医病名等内容；（2）可任意输入中药的科名、药性、药味、归经等内容的一部分即可快速查询相关的中药信息；如输入科名“豆”，即可检索出“豆科、红豆杉科、肉豆蔻科”三类科名及各自所对应的中药列表；（3）可任意输入西医病名、功能、药理作用、主治中的一部分即可快速查询相关的中药信息，如输入“感冒”，即可检索出“风寒感冒头痛、感冒咳嗽、流行性感冒、普通感冒、胃肠型感冒”及各个感冒类型对应的中药列表；（4）可通过中药的用法用量、禁忌、毒性、储藏方法、用药部位、配伍等内容，查询到符合条件的中药列表。

1.2 系统架构设计。系统采用较为普及的浏览器/服务器（Browser/Server，简称B/S）结构，B/S结构的模块可扩充性强，对数据库兼容性良好，能够处理来自不同数据源的数据，允许用户在线更新数据，能够支持多用户同时访问，同时简化了客户端、简化了系统的开发和维护。

1.3 主要技术。（1）ASP技术。ASP即Microsoft Active Server Pages的简称[4]，是微软公司开发的代替CGI脚本程序的一种应用，是一种服务器端脚本编写环境，可以用来创建和运行动态网页或Web应用程序。ASP网页可以包含HTML标记、普通文本、脚本命令以及COM组件等。利用ASP可以向网页中添加交互式内容（如在线表单），也可以创建使用HTML网页作为用户界面的Web应用程序。（2）SQL Server数据库。SQL Server是美国Microsoft公司推出的一种关系型数据库系统[5]。SQL Server是一个可扩展的、高性能的、为分布式客户机/服务器计算所设计的数据库管理系统，实现了与Windows NT的有机结合，关系型数据和结构化数据提供了更安全可靠的存储功能，可以构建和管理用于业务的高可用和高性能的数据应用程序。

2 数据库设计

数据库在一个信息系统中具有举足轻重的地位，数据库结构设计的好坏将直接对应用系统的效率及实现的效果产生影响[6]。根据前期对系统的调查分析及数据库的规范化准则，同时以权威教科书为数据来源，对数据不一致及存在的矛盾现象进行数据清洗及相关数据整理。

目前数据库主要包括六张表，如中药、主治、药理作用、功能、西医病名、配伍等数据表，分别存储了中药的科名、拉丁名、药性、药味、归经、化学成分、储藏方法、用药部位、用药禁忌、用法、用量、毒性、配伍、中药相关的功能、药理作用、主治、西医病名等相关数据。其中，中药表主要存储中药的药性、拉丁名、科名、出处、药味、归经、毒性等属性。

3 系统实现

在该中医药信息系统中，主要支持精确查询和模糊查询两种方式，如对于数据库中的常见中药，若只了解中药的名称中有一个“白”，则可在模糊查询中输入“白”，则可以查询出和中药中包含“白”的所有中药，如“白扁豆、白矾、白附子、白果、白芨、白茅根、白前、白芍、白术”等，共计31味，如图1所示，同时，可继续在中药的查询结果中查询任一味中药的详细信息，如白茅根的药性药味归经等信息，如图2所示。

另外，除中药的基本信息查询外，还可以通过拉丁名、科名、药性、药味、归经、化学成分、储藏方法、用药部位、用药禁忌、用法、用量、毒性等17种属性查询相应的中中医药信息。

图1 中药名称中包含“白”的查询结果

图2 中药“白茅根”的查询结果

4 结束语

这个系统信息录入、信息查询功能已经实现， 但在数据统计、分析方面以及数据的处理效率还需要进一步的完善。在今后的研究工作中，要对数据的处理效率做进一步的研究，做出稳定性好、执行效率高的系统，另外，拟增加图片检索模块对中药数据进行检索，如用户上传中药图片，则系统搜索出图片相关的中药信息，同时继续增录系统中的中药资源，为中医药的应用研究提供数据支撑。

参考文献：

[1]中药现代化发展纲要（2002-2010年）[J].中药研究与信息，2002（11）：7-9.

[2]叶含笑，来平凡，黄卫敏.中草药资源信息化基础平台设计[J].浙江中医药大学学报，2007（05）：648-649.

[3]方睿.中药信息学研究进展[J].中国中医药信息杂志，2009（01）：2-6.

[4]戴丽思.ASP程序设计基础[M].北京：清华大学出版社，2009.

[5]王珊，萨师煊.数据库系统概论（第4版）[M].北京：高等教育出版社，2006.

[6]Abraham Silberschatz，Henry F.Korth，S.Sudarshan.数据库系统概念（原书第6版）[M].北京：机械工业出版社，2012.

作者简介：王哲（1981-），女，河南临颍人，讲师，硕士，主要研究方向：信息检索、数据库与数据挖掘；姜姗（1981-），女，讲师，硕士，主要研究方向：计算机系统结构、数据库与数据挖掘。

基于B/S架构的路灯监控服务设计 第5篇

路灯是城市基础设施的重要组成部分, 路灯监控的信息化水平反映了一个城市的智慧化程度。 文献[1]、 [2] 提出基于GPRS与Zig Bee混合网络结构的路灯监控解决方案, 终端采用SIEMENS的RTU控制器, 能实现单灯及多灯的远程控制。 文献[3] 选择通过GSM网络短消息业务实现数据远程传输, 终端则选用SIEMENS的无线调制解调模块, 从仿真结果来看其效果满足对单灯的控制需求。 GPRS+ZigBee或GSM两种方式, 代表了路灯监控领域两种典型的技术途径, 由于后者必须借助短消息功能, 而短消息在时效性方面存在一定的缺陷, 因此对于需要传输较多路灯状态及指令信息的应用场景而言, 往往不如前一种方案更具优势。 从这个角度看, 随着4G网络的普及, 基于GPRS+ZigBee的方案势必成为路灯监控领域的主流。

同是基于GPRS+ZigBee通信, 在用户端则存在多种技术途径。 文献[4] 描述了一种具有代表性的应用模式, 以张家港路灯监控系统项目为背景, 设计了基于WCF的路灯监控系统, 实现了面向服务的软件架构 (SOA) 。 该系统的优点在于采用了WCF框架, 使得扩展性较好, 但由于仍采用传统的C/S架构, 需要监控用户在PC机上安装特定的客户端软件, 才能实施路灯监控, 因此局限性较大。

WCF是一个面向SOAP消息的通信框架, 采用基于终结点 (Endpoint) 的通信手段。 终结点由地址 (Address) 、 绑定 (Binding) 和契约 (Contract) 三要素组成, 即Endpoint=ABC;其中地址是路灯控制终端RTU的网络IP; 绑定要素决定了SOAP消息基于何种网络协议; 服务契约制定了服务调用的接口规约, 不论服务采用何种语言编写, 只要遵照服务契约的方法名、 参数名和参数类型对服务实施调用, 就可以获取期望的返回值。

WCF提供了路灯控制终端RTU与用户浏览器之间实现数据通信的SOA架构, 通过服务软件与控制终端的松耦合, 能有效降低服务软件的开发成本, 并且支持用户端采用基于Web的实现方式, 使得用户不仅在PC机, 而且在移动终端也能轻松实现路灯的远程监控。

2 YunControl:云端的监控服务框架

2.1 系统需求

考虑一个典型应用场景: 集成移动通信模块的嵌入式终端C, 通过GPRS接入Internet; 用户希望在家里或任何场合简单打开计算机或手持智能设备中的Web浏览器, 登录一个公开的地址S, 点击页面上的图形化按钮对C实施远程控制, 同时在必要的时候实时采集C的运行状态, 并通过Web页面上的显示窗口, 对这些状态信息进行监控。 上述需求如图1所示。

系统需求主要归纳为以下几点:

1) 需要一台Web服务器。

2) 采用B-S架构。

3) 移动终端与Web服务器之间双向通信。

此外, 系统的设计约束为:

1) 移动终端无操作系统, 执行ANSI C代码, 支持TCP/IP协议。

2) Web服务器可租用公共空间。

3) 尽可能节约成本。

2.2 架构设计

满足2.1 需求的系统架构有两种选择, 分别如图2、 图3所示。

上述二者的共同点是中心.NET服务器与纯C嵌入式客户端软件结构基本一致, 不同点是架构2 增加了一个中继转发.NET服务器。

中心.NET服务器 (以下称S) 基于.NET平台构建, Web部分采用ASP.NET MVC技术, 由于较好地实现了显示与逻辑分离, 页面代码得以独立自由开发, 使用Ext.NET框架具有美观友好的人机界面; 数据部分为SQL Server, 与业务代码采用LINQ技术交互, 易于开发与维护; 通信部分采用WCF中间件, 其优势在于对底层协议的良好封装, 使得客户端仅需很少的代码就能访问中心.NET服务器对象的各项业务方法, 而且对WS-* 标准的完整支持为系统带来充分的扩展潜力。

纯C嵌入式客户端 (以下称C) 的程序开发不受服务器端的约束, 只需和Internet上的远程主机通过TCP Socket进行通信即可。 该客户端通过GPRS网络接入Internet, 因此必须支持GPRS通信功能, 可采用GPRS模块如Simens的MC35i等。

理论上, 只要做好上述S-C两端的软件开发就能实现2.1的全部需求了, 也就是架构-1 所示的情形。 然而, 必须向移动运营商申请APN专网业务, GPRS模块才能实现公网IP与SIM卡绑定, 从而作为服务器接受TCP/IP连接请求。 这并不满足2.1 所述 “尽可能节约成本” 的设计约束。 于是在架构2中增加一个中继转发.NET服务器, 该服务器通过普通宽带拨号连入Internet, 可与用户任一上网计算机共享带宽, 无需支付额外的网络费用。

中继转发.NET服务器 (以下称D) 主要包含一个Windows服务程序, 该服务在操作系统后台自动运行, 负责将S发来的WCF消息解析后转发给C, 并将来自C的TCP消息以约定格式转发给S。 在这种情形下, S仅与D通信, 由于二者都基于.NET构建, 因此直接通过WCF即可完成全部消息交换; 对C而言, 也无须了解S的有关信息, 它仅与D通信, 该流程如图4 所示。

上述流程的关键在于由C发起连接, 保持连接状态, D保存该连接引用, 在随后任一时刻向该连接发送消息, 完成所有消息收发后, C主动关闭该连接。 由于C向D发起长连接, 因此D无需了解C的IP地址、 端口等信息, 即可直接向C发送消息。 这就避免了将GPRS模块当作服务器, 节约了运行成本。

2.3 关键技术

2.3.1 WCF端与非WCF端的双向通信

WCF平台上的服务器- 客户端通信非常简单, 直接利用.NET提供的相关API就行。 WCF端与非WCF端的通信相比之下就麻烦多了。

首先考虑非WCF端向WCF端发起通信。 由于平台的不同, 非WCF端无法利用WCF提供的一系列应用设施, 必须按照标准协议向WCF服务器发送消息。 如前文所述, WCF是SOAP风格的Web Service架构, 因此WCF消息都符合SOAP标准格式。 SOAP消息结构是以Envelope为根元素, 内含Header和Body的一类XML文档, 任何满足此类格式要求的XML都可作为SOAP消息在系统之间传递。 SOAP规定了消息格式, 但并未限定通信协议, 默认采用HTTP传输, 一般无特殊要求的也都采用此选项。 HTTP是一种请求-响应模式的信息交换协议, 它建立在TCP连接之上, 客户端每发起一次请求, 服务器就在80 端口建立一个TCP连接, 并在返回客户端请求文档之后关闭此连接, 因此HTTP通常被称作无连接或无状态的应用层协议。 HTTP的特性, 对Web具有天然的吸引力, 因此成为Web时代最普遍的互联协议。 它可以自然而然地通过服务器的80 端口, 防火墙一般不会对它做任何手脚。化身为HTTP的SOAP, 同样继承了HTTP这些便利, 所以SOAP风格的Web Service往往都遵循HTTP协议进行传输。典型的这类消息如下所示:

SOAP消息很容易理解, 首先是消息头, 声明了HTTP方法名称、 内容类型、 目标地址及端口、 内容长度、 预期响应、连接状态等; 接下去是消息内容, 这一规范的XML文档构成SOAP消息的主体, 其描述了Web Service的地址、 接口、 名称、 方法、 参数等用于远程过程调用 (RPC) 的必要信息。 由于WCF完全符合SOAP标准, 因此WCF服务器通过80 端口接受到上述消息后, 检查语法如无错误, 则返回响应消息, 仍是SOAP格式如下:

响应消息的Body部分通过名为 “服务方法名+Response”的节点定义了RPC返回信息, 客户端接收上述消息后, 需要解析Response节点, 提取其名为 “服务方法名+Result” 的子节点, 即完成一次完整的WCF服务方法调用。 WCF端将非WCF端发来的消息以图形化方式加以显示, 就实现了2.1 所述 “在必要的时候实时采集C的运行状态, 并通过Web页面上的显示窗口, 对这些状态信息进行监控”。

非WCF端向WCF端发起通信, 基本原理都是采用上述构造SOAP消息的方式, 但是这里尚未考虑消息加密等因素, 因此用于实际项目中的SOAP消息还要更复杂一些, 有必要借助于特殊的构造工具, 确保消息传输安全可靠。

接下来考虑WCF端向非WCF端发送消息的情形。 这里对非WCF端的要求是具有可接受TCP/IP连接请求的对外IP和端口号, 就是说非WCF端不仅能够主动建立TCP/IP连接, 向远程主机发送消息, 而且具备充当服务器的条件, 能接受远程主机向自己发起连接, 并接收消息。 这一点非常重要, 一般的GPRS模块通过Sim卡接入Internet后, 并不具备充当服务器的条件, 这也是从节约成本出发必须引入中继转发.NET服务器的原因。 如果非WCF端具有可连接的公网IP, 比如GPRS模块向移动运营商申请APN之后, WCF端通过某一IP地址和端口号就可以向非WCF端发起通信了。 WCF提供专门API, 用于获取当前连接发起方的IP地址和端口号, 因此只要记录此项信息, 并在需要时主动与该地址建立连接, 非WCF端就能收到WCF端发来的消息。 由于非WCF端直接通过TCP Socket取得消息, 因此并不要求消息格式遵循HTTP或SOAP, 只需按照双方约定的格式解析即可。 WCF服务增加一条方法, 供Web客户端使用; 调用.NET的Socket相关API, 实现向远程主机发起TCP/IP连接, 并按一定格式发送消息, 使得远程主机根据消息内容做出相应动作, 就达成了2.1 所述“点击页面上的图形化按钮对C实施远程控制” 的目标。

2.3.2 中继转发服务程序多线程设计

图3 所示系统架构-2, 通过引入中继转发.NET服务器, 使得中心.NET服务器 (S) 与纯C嵌入式客户端 (C) 相互解耦, 前者无需考虑与非WCF端通信的问题, 后者也不必费力构造SOAP消息主动向WCF端发起通信, 有利于提高开发效率。 中继转发服务程序的设计显得至关重要, 因为其性能影响到整个系统的综合表现。 通过对该程序的功能进行梳理, 发现其主要需求如下:

(1) 可容纳10个C的TCP/IP长连接。

(2) 与S通过WCF通信。

(3) 实时地将S发来的消息转发给特定的C; 将每个C发来的消息转发给S。

由于需要处理多个TCP/IP连接, 所以中继转发服务程序必须采用多线程技术来设计, 其具体流程如图5 所示。

程序包含3 类线程, 主线程用于处理服务接口, 维护公共信息; 接收线程用于监听固定端口, 将发来的消息按照地址分别记录; 发送线程用于按目标打包消息, 将消息准确路由到特定目标; 其中发送线程由接收线程触发, 启动后发送完消息即告结束, 主线程等待接收线程结束后退出。

程序设计的重点在于接收线程对远程主机的管理, 对于最多10 个的C连接和1 个S连接, 主线程需要维护这样两个线性表, 分别存储与C端和S端有关的信息, 以供接收线程进行分配。 接收线程每监听到一个TCP/IP连接, 首先判别它是来自C或S, 然后分别记录到相应的线性表中, 接着对消息稍加处理, 将C消息转发给S, S消息转发给特定的C。 由于C不止一个, 因此在收到C消息后, 必须在消息头上增加C的特定标识, 如第一次接收时分配的id号, 进而将重新打包过的消息转发给S。 同样地, 在收到S消息后, 首先解析消息头部的C标识, 进而将消息内容转发给该指定的C。

在实际项目开发过程中, 很可能遇到线程间公共信息的访问死锁现象, 因此需要借助.NET中线程安全的同步机制, 确保公共信息的一致性。

2.4 试验结果

经验证, 用户可以在家里或任何场合打开计算机或手持智能设备中的Web浏览器, 登录一个公开网址, 实时监控远程控制器的工作状态, 并通过简单的页面操作, 对控制器发送消息, 使后者完成预期动作。

3 结语

Yun Control框架以较低的成本、 简单的架构、 标准的通信手段, 实现了嵌入式移动终端向Web的集成, 具有良好的可扩展性, 使得用户仅仅面向Web就足以对多个远程终端实施监控及发布指令, 无需安装复杂而繁琐的服务器与客户端软件, 体现了软件作为服务按需使用的原则, 为解决同类问题提供了有价值的借鉴思路。

摘要：提出一类基于B/S架构的路灯监控服务框架Yun Control, 设计并实现服务软件与嵌入式终端的双向通信模式, 以具体案例演示该模式的可行性, 展示其在同类应用领域的实践价值。

关键词：路灯监控,B/S架构,服务,SOAP消息,WCF框架

参考文献

[1]张立新, 杨程.一种基于物联网技术的智能路灯监控系统设计[J].宁夏工程技术, 2014, 13 (3) :234-237.

[2]陈强, 南周羽.无线路灯监控系统远程终端设计[J].电子与封装, 2013, 13 (7) :38-42.

[3]于星亮, 刁海滨.基于GSM网络的路灯监控系统数据远传仿真[J].智能建筑与城市信息, 2014, 8:80-82.

B/S技术架构 第6篇

一、体系结构

B/S结构和C/S结构是两种常见的体系结构模式, 现行的很多软件系统都是在这两种模式之上的架构。在系统的性能方面, B/S占有优势的是其异地浏览和信息采集的灵活性, 任何时间、任何地点、任何系统, 只要有操作系统和浏览器, 就可以使用B/S系统的终端。但是采用B/S结构, 客户端只能完成浏览、查询、数据输入等简单功能, 绝大部分工作由服务器承担, 这使得服务器的负担很重。C/S更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑, 客户端和服务器端都能够处理任务, 但是C/S程序一般是典型的中央集权的机械式处理, 交互性相对低。在某些特定的领域下, 纯粹的B/S或C/S都不能完全适应需求, 于是B/S、C/S混合软件体系结构就应运而生了。采用C/S和B/S模式棉花仓储环境监测系统, 能够实现对各地的棉仓统一控制与管理, 大大提高整个系统的运行可靠性、稳定性、兼容性和可扩性。

二、系统设计

1. 基于C/S的监控系统。

C/S即客户端/服务器, 客户端运行用户请求服务程序, 并将请求传送给服务器。服务器则负责管理数据资源, 它把从现场监控单元采集的数据信息发送给客户, 并进行数据库操作, 服务器被程序化, 可接收并响应同时来自客户机的多个请求。其架构图如图1所示。

2. 基于B/S的监控系统。

B/S结构即浏览器/服务器结构, 用ASP.NET+SQL数据库等技术, 实现网页登陆监控远程服务端。B/S功能的实现主要集中在浏览器、Web服务器和数据库服务器上。浏览器可为用户提供监控界面, 并通过网络向Web服务器发送复杂的计算和数据服务请求;Web服务器执行相应程序与数据库服务器连接, 数据库服务器执行数据操作并将运行结果提交给Web服务器, Web服务器利用HTTP协议将结果显示在Web浏览器上。其架构图如图2所示。

三、B/S+C/S混合模式的棉仓环境监控系统

在本系统中, 系统的架构采用B/S和C/S相结合的方式, 也就是对于数据的浏览都采用B/S, 系统的安全控制采用C/S;或者说涉及数据修改的部分, 都在C/S中实现, 而且C/S要求客户端必须安装客户端才可以运行, 这样从客户端这里就防止了试图对系统进行攻击, 保证了数据实时、顺畅传输, 提高了应用系统的稳定性、安全性。

C/S模式的系统用于中央人员对全局信息进行修改和设定。系统的设计划分为区域管理模块、角色管理模块、主体管理模块、权限管理模块及用户管理模块。可以访问和控制全体棉库的信息, 包括生成角色、生成棉库管理员、报警管理、设备管理等。本地应用程序负责本地用户管理、规划所属角色、设备管理 (设备准入) 、棉仓管理。

B/S模式的系统主要用于合法用户对拥有权限的数据进行浏览。在B/S系统中, 中央人员根据权限的分配, 可以访问所有棉库的信息, 而棉库人员只能访问本地的展示系统。中央展示系统包括:实时数据、历史查询、事件处理、质量分析、日志管理、系统管理、系统帮助等功能模块;本地展示系统包括:实时数据、历史查询、事件上报、质量分析、日志管理、系统管理、系统帮助等功能。系统的Web程序采用ASP+SQL2008的架构, 可实现用户网上登录和管理。B/S和C/S相结合的方式其功能结构如图3所示。

B/S模式下的三层架构模式 第7篇

B/S (Browser/Server) 模式的三层架构模式是传统的客户/服务器结构的发展, 是一种严格的分层定义, 它首先将整个软件系统的开发分成相对简单的几个小分块, 然后在每一层中只实现系统相应层的功能设计, 层间的交互由相邻层对应的功能模块进行调用, 信息传递只由接口进行传送。利用三层架构实现系统功能的设计是为系统提供一个可行的实现方案, 并方便程序设计人员将此方案转换为实现应用系统功能的具体B/S模式, 是从传统的C/S发展起来的计算方式。对应于三层架构的多层结构, 其含义是一样的, 只是细节有所不同。

2 三层架构的三个层面的划分及功能

2.1 表现层 (UI)

位于最外层 (最上层) , 离用户最近。主要是JSP和HTML页面, 用于显示数据和接收用户输入的数据, 为用户提供一种交互式操作的界面。

2.2 业务逻辑层 (BLL)

针对具体问题的操作, 对数据层的操作, 对数据业务逻辑处理是系统架构中体现核心价值的部分。

业务逻辑层在体系架构中的位置很关键, 它处于数据访问层与表示层中间, 起到了数据交换中承上启下的作用。由于层是一种弱耦合结构, 层与层之间的依赖是向下的, 底层对于上层而言是“无知”的, 改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时, 遵循了面向接口设计的思想, 那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下, 理想的分层式架构, 应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此, 业务逻辑层的设计对于一个支持可扩展的架构尤为关键, 因为它扮演了两个不同的角色。对于数据访问层而言, 它是调用者, 对于表示层而言, 它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上, 如何实现依赖关系的解耦, 则是除了实现业务逻辑之外留给设计师的任务。

2.3 数据访问层 (DAL)

有时候也称为是持久层, 该层实现了持久化逻辑 (JD-BC) , 也就是专门跟数据库打交道的, 简单的说法就是实现对数据库表的查询 (Select) 、添加 (Insert) 、更新 (Update) 、删除 (Delete) 等的操作。

三层之间的关系:业务逻辑层通过访问数据库操作层提供的接口来访问数据库操作层, 同样的数据库操作层则通过访问数据库访问层提供的接口来访问数据库访问层, 而在客户端我们则通过界面层来访问业务逻辑层.在三层架构之间派生类去实现接口, 去调用派生类的方法和属性, 三层之间相互调用。

完整的三层架构如图1所示。

为了更好地理解三层架构, 我们就拿养猪来示例。

图2是三层架构化的养猪产业流水线趣味对此图。

对比图1与图2, 我们可以看出:

数据库好比猪圈, 所有的猪有序地按区域或编号, 存放在不同的猪栏里。

DAL好比是屠宰场, 把猪从猪圈取出来进行 (处理) 屠杀, 按要求取出相应的部位 (字段) , 或者进行归类整理 (统计) , 形成整箱的猪肉 (数据集) , 传送给食品加工厂 (BLL) 。本来这里都是同一伙人既管抓猪, 又管杀猪的, 后来觉得效率太低了, 就让一部分人出来专管抓猪了 (DBUtility) , 根据要求来抓取指定的猪。

BLL好比食品加工厂, 将猪肉深加工成各种可以食用的食品 (业务处理) 。

Web好比商场, 将食品包装成漂亮的可以销售的产品, 展现给顾客 (UI表现层) 。

猪肉好比Model, 无论是哪个厂 (层) , 各个环节传递的本质都是猪肉, 猪肉贯穿整个过程。

通用类库Common相当于工人使用的各种工具, 为各个厂 (层) 提供诸如杀猪刀、绳子、剪刀、包装箱、工具车等共用的常用工具 (类) 。其实, 每个部门本来是可以自己制作自己的工具的, 但是那样会使效率变低, 而且也不专业, 并且很多工作都会是重复的。因此, 专门有人开了这样的工厂来制作这些工具, 提供给各个工厂, 有了这样的分工, 工厂就可以专心做自己的事情了。当然, 这里只是形象比喻, 目的是为了让大家更好地理解, 实际的情况在细节上会有所不同。这个例子也只是说明了从猪圈到商场的单向过程, 而实际三层开发中的数据交互是双向的, 可取可存。

3 三层架构的优缺点

三层架构优势如下:①开发人员可以只关注整个结构中的其中某一层;②可以很容易地用新的实现来替换原有层次的实现;③可以降低层与层之间的依赖;④有利于标准化;⑤利于各层逻辑的复用。

三层架构式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。从开发角度和应用角度来看, 三层架构比双层或单层结构都有更大优势。三层结构适合群体开发, 每人可以有不同分工, 协同工作使效率倍增。开发双层或单层应用时, 每个开发人员都应对系统有较深的理解, 能力要求很高, 开发三层应用时, 则可以结合多方面的人才, 只需少数人对系统全面了解, 从一定程度上降低了开发的难度。另三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层, 减少了入口点, 把很多危险的系统功能都屏蔽了。而且三层架构还可以支持如下功能:Remote Access (远程访问资料) , 例如可透过Internet存取远程数据库;High Performance (提升运算效率) 解决集中式运算 (Centralize) 及主从式架构 (ClientServer) 中, 数据库主机的运算负担, 降低数据库主机的Connection Load, 并可藉由增加App Server处理众多的数据处理要求。

分层式结构的缺陷:①降低了系统的性能。如果不采用分层式结构, 很多业务可以直接造访数据库, 获取相应的数据, 现在却必须通过中间层来完成;②有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能, 为保证其设计符合分层式结构, 可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码;③增加了代码量, 增加了工作量, 相应降低了程序的运行效率。

摘要：随着软件行业的发展, 软件系统的开发效率越来越重要, 尤其是大中型的项目中, 迫切需要三层架构的分层开发思想。三层架构能带来的是软件开发效率的提高, 程序员的工作变得更具创造性, 同时纷杂的程序代码也将变得安全。

关键词：三层架构,模式,数据库,体系

参考文献

[1]何天, 候宗浩.基于Pet shop与Duwamish的多层架构设计与实现[J].计算机应用, 2007 (12) .

[2]伽玛.设计模式——可复用面向对象软件的基础 (第1版) [M].李英军, 译.北京:机械工业出版社, 2005.

基于B/S架构的二手房交易系统 第8篇

本系统就是在这个背景下产生的,针对二手房交易的地理时间等限制因素,基于B/S架构和ASP.NET技术实现了互联网上的二手房交易系统。

1 系统分析

我们将网上二手房交易系统的功能划分为客户对功能的需求和管理员对功能的需求两个部分。他们的需求如下所列:

用户需求分析:从易用性和网站安全两个方面出发考虑的需求分析如下。

1)用户注册;

2)登录,获得“信息发布权限”;

3)浏览二手房信息;

4)发布二手房信息;

5)基于标题的关键词搜索。

管理员需求分析:

1)删除用户;

2)二手房信息修改;

3)公告发布。

2 逻辑设计

按照需求分析的结果,从用户功能和管理员功能两个方面,设计逻辑功能如图1所示。

3 物理设计

3.1 登录模块

用户进入首页后即可免费浏览二手房信息,但是“信息发布”功能则必须要求用户进行注册及登录。登录模块见图2所示。

3.2 二手房发布模块(见图3所示)

3.3 二手房编辑模块(见图4所示)

3.4 公告发布模块(见图5所示)

4 数据库设计

逻辑模型:该数据库中包括这样几张表,userinfo(用户信息表)、admin(管理员信息表)、houserinfo(房源信息表)、bulletin(公布栏表)。

物理模型:数据库中各表关系如图6所示。

5 总结

通过运用现在的信息技术、网络技术等,设计和实现了基于.NET的二手房交易系统。此系统以提供信息服务为宗旨,以才C2C模式和自由交易为设计理念,较好的克服了传统二手房中介过程中地理、时间等限制因素,具备了实用性和一定的社会效益。

参考文献

[1]刘友华.信息系统分析与设计[M].南京:南京大学出版社,2005.

B/S技术架构 第9篇

【摘要】随着教育改革的深入和计算机网络技术的发展，计算机自动化考试已经成为一种趋势，针对目前考试系统只具备组卷评分功能，缺乏教师与学生的沟通互动及用户使用范围受限的问题，本系统采用B/S网络结构模式扩展了用户使用区域，并增加评价与推送功能，完善了教学反馈环节。本系统首先进行组卷、阅卷、评分，完成对学生知识点的考核，然后统计每个学生知识点的得分、错题率等信息，生成教学方案反馈给老师以促进教学改革，同时把错题知识点汇总，通过APP客户端发送给学生。

【关键词】无纸化考试 B/S架构 C语言考试系统

【基金项目】2013年，省级教研项目：基于“理实贯通、多元协作”的信息与通信工程学科教学创新研究，项目编号：2013286；2015年，湖北工业大学校级项目：基于PBL教学模式的智能考试、评估、推送C语言学习方案研究，项目编号：校2015062；2014年，湖北工业大学校级项目：面向电子信息类专业的一体化CDIO工程教育改革实践，项目编号：校2014013；2013年，湖北工业大学校级项目：电气卓越工程师培养程序设计类课程改革研究，项目编号：校2013011；2015年，华中师范大学中央高校基本科研业务费项目：基于设备指纹的数字音频被动取证关键技术研究，项目编号：CCNU15A05054；大学生创新创业训练计划项目（201510500035）。

【中图分类号】G64【文献标识码】A 【文章编号】2095-3089（2016）04-0211-02

一、引言

C语言作为国际上广泛流行的计算机高级程序设计语言，在广大高校的计算机及相关专业中是一门必修课程。对于C语言的考核虽然已经走向计算机自动化阅卷的道路，但目前的考试系统的设计局限于技术细节改善，如客观题评分标准的完善、随机组建算法设计，而忽视了教学的本质——考试只是教学的一个环节，而不是终极目标。

（一）系统需求分析

根据现在考试系统的现状，针对目前考试系统只具备组卷、评分功能，缺乏教师和学生的沟通互动，信息反馈及用户使用范围受限等问题，本系统强化考试后的反馈环节，在题库的数据库组建时，考虑题目与知识点的对应关系，题目的难度分级。学生在预习时，通过查看其它学生的考试结果，可以预判学习的重难点，合理分配学习时间。

（二）系统设计分析

二、系统的设计与实现

（一）系统总体设计

根据系统需求分析，在线并发C语言考试系统由两个PC客户端和一个Android客户端组成，设计分为两个阶段实现：（1）先完成基于B/S模式的教师和学生的PC客户端系统；（2）在PC客户端的基础上开发基于Android手机平台的反馈和师生交流系统，在线并发C语言考试系统采用B/S架构，用户可以在PC客户端进行系统访问，PC端进行数据的读取和存储，并提供完善的考试管理系统，该系统采用Basic语言在VB开发环境下实现。

（二）学生考试模块

1.考生登录模块

首先判断考生输入的账号和密码是否正确，若账号或密码错误则给出相应的错误警告，验证通过后进入后台数据库提取相关数据转入答题界面，并且记录登录次数，限制只能登录一次，否则给予相应警告。

2.考试答题模块

在后台数据库中抽取题目，将题目以选择题、判断题、填空题和程序设计题的形式在不同窗口中显示，并提示考试时间和答题结果，在时间完成后自动交卷，并将考试数据自动存入后台数据库。

3.分数显示和本地推送模块

在考试完成并提交答案后将激活分数显示和推送模块，首先将考生的答案和数据库标准答案进行比对，对比正确答案进行统计，然后将考生答案和得分情况存入后台数据库并显示到本界面，反馈给相应的考生，推送模块只有考生在点击本页面的推送按钮时才被激活，然后根据统计结果将相应的知识点和学习方案推送到本地客户端，同时将反馈的内容一并上传到教师端数据库，供教师端进行整体统计使用。

4.管理模块

在学生端管理模块部分主要实现对账号和密码的修改，考生可以在管理界面对自己的信息进行修改，首先输入初始设置的账号和密码，确认正确后就可以修改为更加安全的账号密码，保证个人的信息安全。

（三）教师管理模块

教师端登录模块与学生端基本相似，在此不做另外介绍，着重介绍几个主要的模块。

1.记录工具模块

在登录完成后便激活记录工具模块，并获得相应记录ID，初始记录为空，教师可在此记录相关的工作日志等信息，并只有相同ID才可以访问其内容，保障其安全性，另本系统工具模块自带浏览器，相关问题可随时上网查询而无需切换界面。

2.导入试题模块

点击进入导入试题模块，可以进行选择题、判断题、填空题和程序设计题的导入工作，教师输入完成并确认后系统将自动分配题号并存入后台数据库。

3.试题浏览模块

本模块主要对数据库中生成的临时temp表进行显示，点击确认后生成正式试题表并发送至学生考试客户端。

4.考生信息查询模块

考生信息查询模块主要对学生端反馈的信息进行汇总后在本地显示并供教师端查询使用，查询方式为单条件方式查询和组合式查询，查询结果在本界面进行显示。

三、系统的实现

（一）学生端功能实现流程

参加考试的考生首先进入一个登录界面，考生输入正确的账号和密码登录，进入登录界面后系统自动开始进行倒计时，考生选择相应的试题类型进入相应答题界面，答完题后返回并选择其他未作答的试题，直到答题结束后，点击提交试卷，系统自动进行处理和判断，得出考试分数并显示出来，考试分数会自动存入相应数据库的表中，考试系统会自动在本地的数据库中链接生成推送的知识点内容和相应的方案，考生可以在本地浏览或者在连接的APP客户端中进行浏览。

（二）教师端功能实现流程

教师在输入正确的账号后登录教师端，首先是组卷界面，教师可以在这个界面选择自动组卷或者人工组卷，组卷完成后可以点击预览模式进行对试卷的预览，确认无误后就可以点击确定来发布生成的试卷到学生端供考试使用。

参考文献：

[1]李雪玲，管群. 基于 PHP技术的在线考试系统设计与实现[J]. 计算机与现代化， 2009，（2）： 118-121

[2]张朋. 用数据库编程开发考试系统[J]. Computer Knowledge and Technology 电脑知识与技术， 2009，（6）： 1374-1375

作者简介：

B/S技术架构 第10篇

软件架构是软件需求和设计之间的一个桥梁,是指根据设计原则,从不同角度对系统的各部分进行搭配和安排,为后面的系统设计定好框架。随着软件系统规模越来越大,越来越复杂,整个系统结构的规划显得越来越重要。好的软件架构是软件质量的重要保证,就像一个建筑的主体框架对整个建筑物的影响起决定性作用一样,因此大型项目在概要设计前必须要进行架构设计[1]。

目前流行的系统架构有C/S(Client/Server客户端/服务器架构)和B/S(Browser/Server浏览器/服务器架构)两种。在C/S架构的应用程序中,数据存储在数据库服务器上,应用程序在客户端上运行,并通过网络访问数据库服务器上的数据。一旦数据库服务器启动,就随时等待客户机发来的请求,一旦收到请求就进行处理,并将处理结果返回给客户机。这种结构数据的存储管理功能较为透明,但是每一个客户端应用程序都要进行升级,系统维护成本高。网络管理工作人员既要对服务器维护管理,又要对客户端维护和管理,这需要高昂的投资和复杂的技术支持,因此维护成本很高[2]。

B/S架构是随着Internet技术的兴起,对C/S架构的一种变化或者改进的架构。在B/S架构中,客户端是通过Web浏览器来访问在Web应用服务器上运行的应用程序,主要业务逻辑在服务器端实现,大大简化了客户端电脑负荷。对应用程序的升级只在Web应用程序服务器上进行,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本。以目前的技术看,局域网建立B/S结构的网络应用,并通过Internet/Intranet模式下数据库应用,相对易于把握、成本也是较低的。它是一次性到位的开发,能实现不同的人员,从不同的地点,以不同的接入方式(比如LAN,WAN,Internet/Intranet等)访问和操作共同的数据库;它能有效地保护数据平台和管理访问权限,服务器数据库也很安全[2]。

由于B/S和C/S架构各自都有优缺点,对于大型的复杂应用系统来说,两者相结合的架构是一个不错的选择。对于用户层次复杂、分布地点离散的子系统,为提高系统可维护性,可以采用B/S架构;对于仅限于内部使用的子系统,从尽可能减少用户投资的角度出发,可以采用C/S/S架构。C/S/S架构是目前信息系统架构的一种新的发展方向。C即应用客户端,后面两个S分别代表业务服务器和数据库服务器。该种结构能够很好地支持分布式办公,既发挥了桌面系统的处理性能,又通过对服务的集成,利用远程数据计算技术,减少了桌面系统的维护。

如果考虑到应用的多变性,各架构的内部实现还可以采用层次化设计思想。例如:表示层可以采用Flex技术。Flex是一种专用于开发Web应用程序表示层的框架,其页面表现力极为丰富、交互性强,一方面具有桌面应用程序的响应速度快的特点,另一方面又具有Web应用程序客户端的免安装、免维护等特点。Flex采用XML标准,与Web Service具有良好、高效的接口。业务层采用Web Service技术。Web Service是一种部署在Web上的对象/组件,是新一代网络应用编程的核心。它具有封装性好,安全性高,松散耦合,内部实现对用户透明等特点。通过使用标准协议和规范,可扩展性强,具备良好的异构性。数据层采用Oracle 10g数据库管理平台。Oracle是目前应用最为广泛、安全性最高、技术最为成熟的数据库管理系统。作为大型应用系统的数据库,Oracle自然是首选。这样一来,每层实现特定的功能,并通过标准接口向上层提供透明的服务,最大限度地实现了系统各模块的功能独立性,每一层的改动不影响其它层次。这样可以方便地添加、修改和删除应用,提高系统的可维护性。系统在设计之初要考虑到系统以后的扩展。采用层次结构,保证功能实现与通讯接口最大限度的独立,加上在与通信平台的接口设计上采用标准化,可以在以后实现和新系统的无缝连接。

分层设计的松散耦合好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发[3]。分层设计的思想还为后面的开发带来了极大的便利。例如:开发人员可以只关注整个结构中的其中某一层的开发;可以很容易地用新的实现来替换原有层次的实现;可以降低层与层之间的依赖;有利于各层逻辑的复用等。

二、系统开发模式的选择

确定系统架构之后,下一步则是选择系统开发的模式。常用的开发模式有:瀑布、螺旋、喷泉、V模型、敏捷开发等。根据项目需求变化的频度、用户本身对需求的清晰度、项目团队的技术能力、项目的工期限制和各开发模型本身所具有的特点进行分析来决定采用哪种开发模型。

1)项目的需求变化频度及风险程度:如果系统的业务需求在未来的变换频度和风险程度都较低,可以考虑选择瀑布开发模型;如果变换频度和风险程度较高的系统,则可以考虑选择螺旋开发模型;如果需求变化快,用户又希望频繁看到系统新的版本,则可以考虑采用敏捷开发。

2)用户对需求的清晰度:如果用户对项目的需求不是非常明确,开发人员需要和客户多次沟通确认才能确认需求,且需求一改再改,则在瀑布模型基础上结合原型化方法是一个不错的选择。

3)项目团队的技术沉淀:应尽量选择项目开发成员比较熟悉的开发模式来开发,即能保证进度,又能保证质量。例如,之前的项目绝大多数都是使用瀑布模型进行开发的,因此开发团队对于瀑布开发会有比较深刻的理性认识和丰富的实践经验,则选择选择瀑布式比较适宜。

4)开发模型本身的特点:瀑布开发模型适和需求变化不频繁但是风险程度较低的项目;原型化方法则具有开发周期较短、节省成本的优势,同时用户参与程度高,可以有效地明确用户的需求;螺旋开发模型适合需求变化频繁、风险程度高的项目。

随着软件技术的不断发展,开发模型也在不断地进行变化。由最开始的瀑布模型,演化模型等向更适应需求变化的改进型瀑布模型、螺旋模型、喷泉模型、RUP(Rational Unified Process,Rational公司开发和维护的过程产品,将项目管理、业务建模、分析与设计等统一起来,贯穿整个开发过程,提高了开发效率。)模型等转变,然后又从重量型的RUP向轻量级的XP(Extreme Programming,极限编程)模型等转变。而近年来,随着软件交付周期的日益加快,迭代化开发似乎已经成为大多数软件开发团队的首选。但是迭代化开发对整个团队的需求把握、架构设计、团队协作及系统测试能力都提出了更高的要求[4]。相信软件的开发模型还将继续变化和演进,向着更注重过程管理、更可裁减、更体现个人技巧和团队合作的方向变化。

鉴于软件的发展趋势,系统不再是单一的B/S或者C/S架构,大型复杂的系统开始采用B/S和C/S相结合的多层架构设计,以实现较好的可维护性、较高的安全性和可扩展性。开发模型的选择需要综合考虑用户对项目的需求是否明确、需求变化是否频繁、项目的规模和风险程度、项目团队的技术力量等实际情况。

参考文献

[1]张友生.系统分析师教程[M].清华大学出版社,2010.

[2]赵卓君,等.Java程序设计高级教程[M].清华大学出版社,北京交通大学出版社,2011.

[3]百度百科.PetShop4,互联网[EB/OL].http://baike.baidu.com/view/1737978.htm,2012.5.20.