现在的位置: 首页 > 综合 > 正文

智能客户端技术

2013年01月28日 ⁄ 综合 ⁄ 共 4814字 ⁄ 字号 评论关闭
文章目录

智能客户端(Smart Client),结合了瘦客户端(B/S模式)和胖客户端(C/S模式)的长处,是下一代的客户端软件技术。

    要了解智能客户端,首先要认识瘦客户端技术和胖客户端技术各自的优缺点。

    对于前者,典型的应用就是使用浏览器,通过输入URL远程访问服务端,并向服务端发送命令,获取服务端的资源,然后在客户端的浏览器上显示出来。由于这种技术数据库存放在服务端,客户端应用界面的也是由服务端的文件生成,因此在客户端上占用资源少,对客户端的设备要求不高,只需一个浏览器软件和可用的网络便能开始工作,另外,如果系统需要升级修改,只需要在服务端更新文件,当客户再次访问时,就可以使用新的应用系统了,因而部署和升级重点都放在了服务端,实现起来比较简单。但是,这种B/S模式依赖网络,当网络不可用时或出现性能不稳定的情况时就会导致客户端变成“死界面”——既不能将数据发送回服务端进行保存,又不能从服务端获取数据拿到客户端操作,一切的工作将要在网络恢复后才能得以继续。

    对于胖客户端技术,用户在使用这种软件时获得的最大的感官体验就是——它首先有自己独特的应用程序界面,而非通过浏览器,用户甚至还可以根据自己的喜好调整软件的布局,进行丰富的界面元素的设置,这些都是B/S模式的瘦客户端技术所不能媲美的。另外,用户还能获得较快的反应速度,程序可以充分利用本地机器的资源,在不使用网络访问远程资源时,本地资源的访问在正常情况下都能得到很快的处理。同样的,胖客户端技术也有着不尽人意的地方——在客户端进行部署时,由于客户端可能出现各种各样的情况,所以需要进行必要的设置,部署起来比较困难,如果对软件的版本进行升级,使用传统的DLL技术的那将更是一个大的挑战,因为在.NET之前,标准Windows
DLL或COM组件可能出现“DLL Hell”——注册和更新软件中的DLL时,发现共享的DLL被最新版本改写了,并使该机器上的其他软件也因此不能运行。胖客户端有可能需要在客户端实现数据库支持,数据库放在本地有可能导致一些安全问题,因为相对于更重视安全的服务端,客户端相对而言还是比较脆弱的。

    那么智能客户端技术便出现了,除了包括了胖/瘦客户端各自的优点外,它还具有如下四个最大的优点——

1)        充分利用终端设备的优势 (full PC, PDA, phone都可以满足),因为核心部分在服务端(可能Web Service),所以终端只需实现表示层和一些简单逻辑;

2)        能够调用 web services,在server端用web服务实现业务逻辑,处理各种请求,需要说明的是,由于业务逻辑实现放在客户端,因此一方面为客户端瘦身,另一方面也加强了软件的隐蔽性和安全性;

3)        支持在线和离线两种状态,用户可以在网络不可用时继续工作,并将数据临时存放在本地,当网络再次可用,数据便可传上服务器;

4)        能够如同Web应用程序一般简单方便的部署,.NET使用程序集技术,同一软件的不同版本可以共存于统一客户端。版本的升级也非常简单,软件访问服务端,能自动检测版本号,从而更新关键组件,实现升级。

 

二、      这种技术用途是什么?前景如何?

    其实Smart Client的观点在一些传统的软件技术中也可以看到一些影子,随后.NET的出现,才使这种技术的各个环节(客户端显示,数据连接,在线离线的操作和部署)得以无缝的实现。所以,这种技术是一种新型的客户端技术的解决方案,是一种技术方法,它可以在各种终端上去实现。

    将桌面级的软件做成智能客户端软件,可以增强其功能,因为网络无限,跳出桌面,就能获得更多的信息。

基于Internet或intranet及浏览器的B/S模式的系统,将其实现成智能客户端软件,可以扩大其工作范围,不用再依赖网络,还能充分利用本地资源,加快工作效率。易于部署的优势在企业级应用中,更有发挥的余地,开发人员只需简单的在服务端发布和部署,就能使客户端同步更新。

举些可以使用这种技术的应用——

“产品售后服务系统”:产品售后服务人员允许以脱机的形式在本地创建送修工单、装箱单等,这样可以加快本地的工作效率,当网络可用时,再将这些数据传上服务器。并可从服务器获得需要的信息。如果本地软件的版本低于服务端的最高版本,将提示用户进行在线无缝地升级,大大减轻了开发人员的部署指导工作。

    随着.NET技术的进一步成熟,尤其是Web Service技术的更广泛应用,乃至微软将来的系统全面支持.NET,我相信智能客户端技术将会成为首选的解决方案,应用到各种软件技术中。

 

三、      怎么运用这种技术(通过案例)

智能客户端程序一般都具有偶尔性连接的特征,所以我着重讲述偶尔连接的智能客户端应用程序。同时,其与网路的通讯又有四种方法——Enterprise Services,.NET remoting,Message Queuing(消息队列)和Web services。基于普遍的观点——Web 服务是生成大多数智能客户端应用程序的最佳方法。故在针对面向服务的方法和面向数据为中心的方法的选择中,我决定选择前者,因此,我重点讲述以Web Services作为首选通讯方式,面向服务的智能客户端技术

设计面向服务的智能客户端技术,关键要解决如下几个问题,为使讲述清晰,我将以一个案例作为例子。

我们要实现这样一个购书软件(姑且命名为BuyBook),服务端有数据库,包含两张数据表。一张表简单的描述了书籍的价格,这些价格是变动的,管理员可以通过工具对里面的数据进行改动;另外一张表则是书籍的订单,记录着订购者ID,订购书的ID和订购数量。两表只有书的ID作为主外键关联着。服务端还创建了必要功能的web服务,以供客户端调用。

下面继续接着讲面向服务的Smart Client技术关键解决的几个问题。

 

1)        连接的管理

 

智能客户端软件当然不能过于频繁地访问网络上的服务端,因为这样会严重影响软件的性能,另外,对于连接发生的更改(包含如手动连接、自动连接、连接意外中断和连接长期不用等情况)软件也要作出相应的反应,以体现其智能的特点。

那么关于连接的管理有些什么适合的方案呢,我将以我举的范例为例,设计其在这方面的处理方法。

BuyBook应该尽量避免和网络上的服务端进行交互,即使网络连接可用。可以优先假设为离线操作,在机器本地进行事务处理,当然这样会造成一定的问题,有可能系统数据没有和服务端数据同步,导致本地操作无效。如服务端书本的价格作为系统参数保留在本地,当系统的数据变化时,用户在客户端看到的书本的价格就不是真实的行情了。所以虽然优先离线操作,也要考虑到数据出现不一致的情况,在数据冲突处理会得到详细解答。

在一些特殊的例子中,如购买股票的情况,由于股票的行情是不断变化的,所以,为使本地数据能体现真实的情况,网络连接应该采用隔时便来一次与服务端交互的动作,这个“隔时”的时间长度,可以用户自定义,也可以是系统默认。                                                                                                                                                                       
                                                                                                         

我们还可以提供给用户这么一个功能,他只需点一个按钮,发送出一个访问服务端的命令,这时连接建立,并保持这个连接,直到手动断开,或网络不可用。我们称之为“手动连接”,与之相对应的是“自动连接”,当连接可用时,保持连接状态,将缓存中的数据处理,发送到服务端,并获取服务端最新的一些共用系统参数。

总而言之,对于连接,在设计系统时要把它看作是奢侈品,优雅的对待网络,无论网络处于什么状态,用户的数据操作都可以放在本地缓存。

 

2)        WEB服务的交互

 

面向服务的智能客户端应用程序,通过网络与服务端的交互工作重点就在于web service上。按照前面所言,应该减少这种服务端上的远程交互,可以将本地操作缓存,并且在与web服务交互过程中,不必等待返回信息,在这延迟中可以进行其他的操作。那么要实现这种延迟不影响工作的功能,最有效的办法就是使用异步通讯的方式,可以考虑使用多线程。

WEB服务使用XML技术,CRUD(Creat Read Update Delete)类型的数据库操作,可以都通过Web Service。那么,就要讲究Web Service里交互方法的定义了。当客户进行一个Create操作时,可能关联到系统参数,例如BuyBook应用程序,当客户提交订购单时,Web服务应该先检查本地的商品价格与服务端的价格是否一致,如果价格已经不同,应该提示客户更新最新的价格,然后再作订购行为的判断。Upate和Delete操作,很可能导致数据冲突。例如删除动作,应该在客户端上将相关记录标记为暂时删除,然后在服务器上将删除请求排队。服务端进行删除时一定要检测是否有数据冲突,如果出现冲突,还要进行数据冲突的处理。

 

3)        本地数据缓存

 

智能客户端为了能及时地响应用户的操作,同时也是为了满足脱机离线工作的需要,就必须将常用的固定的服务端数据缓存到本地。

如果连接是处于在线状态的,本地数据可以暂时保存在内存中,ADO.NET里的DataSet本身就是可以用内存临时存储的数据对象,数据在内存中存储只是一个临时过渡,当数据需要经过操作后保存回远程数据库时,方法可以使用DataSet的数据适配器DataAdapter将变化的量返回数据库操作,这样既加快了本地的反应又节省了带宽。

如果,应用程序在断线的状态下工作,则将数据保存回本地的数据存储结构,待再次连线时,装载进DataSet,进行处理。

 

4)        数据冲突处理

 

造成数据冲突最常见的原因包括用户在执行更新或删除数据的操作时,有可能该数据已经被删除掉了,这样应用程序找不到更新或删除的项,自然就会引发异常而出错。处理这样的情况,可以采用一个简单的办法,数据适配器DataAdapter能对DataSet变化进行判断——当数据往数据库返回时,DataAdapter的Update方法可以检查DataSet里每个DataRow的RowState,从而可以判断该DataRow是最新的,还是已修改或已经删除的,然后执行适合的数据库操作,像找不到数据的那种情况,DataAdapter将得知数据库受影响的行数不大于零,并产生异常,从而停止更新。然后,应用程序就可以通过这个异常来处理数据冲突。

处理办法是,如果服务端已经不存在用户需要删除的原始数据,那么,只要将客户端的该条数据删除。如果用户是对该数据进行更改,可以先检测服务端的数据,看是否存在,倘若不存在,则通知用户,并视用户的操作无效,同时将本地的那条过期数据删除。

 

四、      总结

智能客户端技术是颇有前途的下一代客户端技术,它能够在有网络连接和网络断开的情况下灵活地工作。对用户而言,这将是新的一种软件使用体验,能同时拥有C/S模式软件快速的反应、丰富的用户界面体验和瘦客户端模式那样简单的部署,升级。对开发者而言,开发的难度变大了,考虑的方面多了,但还是有灵活的方案可供选择,还可以结合.NET技术,使用面向服务或面向数据的解决方案,在开发中,要着重解决“连接的管理”,“WEB服务的交互”,“本地数据缓存”和“数据冲突处理”的技术点。

抱歉!评论已关闭.