基于的网络关键技术

基于的网络关键技术_网络地理信息系统

4.3.2　基于J2EE的网络GIS关键技术

1.空间数据连接池

1)地理空间数据连接池

GIS实体组件是共享组件，用于数据库建立连接，进行SQL操作，取出空间数据，断开数据库连接。最基本的实现方法如图4-17所示。GIS实体组件通过数据库驱动程序直接访问空间数据库，特点是直接通过数据库管理器获取和释放数据库连接，主要问题是连接的打开和关闭。由于GIS实体组件是共享组件，因此对每个客户机请求都要进行几次获取和释放数据库连接的操作。数据库资源管理器进程创建和摧毁对象需要花费时间，特别影响GIS应用服务器的性能。

图4-17　通过驱动程序直接访问数据库的方法

改进的方法是在GIS应用服务器上内置共享的连接池管理器(陈能成等，2002a)。如图4-18所示，它允许请求客户机透明共享资源池的多个连接对象，在这种情况下，因为池管理器预先在启动时创建连接对象，所以，GIS会话组件可以使用连接对象，而不会导致数据库资源管理器上的系统开销。GIS应用服务器在其内存空间实现池管理器，并根据需要动态改变池的大小，从而优化空间数据库资源的使用。当程序中需要建立数据库连接时，只需从内存中取一个来用而不用新建。同样，使用完毕后，只需放回内存即可。而连接的建立、断开都由连接池自身来管理。

图4-18　GIS应用服务器上内置共享的连接池管理器方法

与此同时，我们还可以通过设置连接池的参数来控制连接池中的连接数、每个连接的最大使用次数，等等。通过使用连接池，将大大提高程序效率，还可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。下面我们以一个名为ConnectionPool的实例来分析连接池的实现。连接池中连接数量下限、连接池中连接数量上限、一个连接的最大使用次数、一个连接的最长空闲时间、同一时间的最大连接数和定时器这些属性定义了连接池中的每个连接的有效状态值。连接池管理器所需要的基本接口包含:初始化连接池、连接池的销毁、取一个连接、关闭一个连接、把一个连接从连接池中删除、维护连接池大小、定时器事件处理函数。通过这几个接口，已经可以完成连接池的基本管理，在定时器事件处理函数中完成连接池的状态检验工作，维护连接池大小时连接池至少保持最小连接数。因为我们要保存每一个连接的状态，所以还需要一个记录连接池是否被使用标志、最近一次开始使用时间和被使用次数属性的数据库连接对象。连接池的自我管理，实际上就是通过对每个连接的状态、连接的数量进行定时的判断而采取相应操作。如图4-19所示，其管理流程如下:

步骤1:连接池定时器定时触发事件给连接池管理器，连接池管理器通过内省机制判断是否存在连接，如果否，执行步骤7;如果是，从连接池中取得一个连接，执行下一步。

步骤2:判断当前取得的连接是否关闭。如果关闭，那么就从连接池中删除，继续遍历剩下的连接;如果没有关闭，则执行下一步。

步骤3:判断当前取得的连接是否空闲。如果不空闲，那么判断连接是否超过最大使用时间。如果否，继续遍历剩下的连接;如果是，那么就执行连接的关闭，从连接池中删除当前连接，继续遍历剩下的连接;如果空闲，则执行下一步操作。

步骤4:判断当前取得的连接是否超出最大空闲时间。如果是，那么就执行连接的关闭，从连接池中删除当前连接，继续遍历剩下的连接;如果否，则执行下一步操作。

步骤5:判断当前取得的连接是否超出最大使用次数。如果是，那么就执行连接的关闭，从连接池中删除当前连接，继续遍历剩下的连接;如果否，则继续遍历剩下的连接。

步骤6:存在连接遍历完成，检查连接数据数量是否小于最小连接数据量。如果是，则执行下一步。

步骤7:创建新的连接，使总的连接数达到最小连接数据量。定时器开始计时。如此循环反复，保证连接池管理器实现自我管理。

它的致命的缺点是:GIS组件必须导入特定于供应商的实现类，以使用资源的连接合用设施。很明显，这种做法降低了GIS组件的可移植性，不利于GIS应用服务器的发展。理想的做法是内置一个可用于任何空间数据资源类型和所有连接管理功能(包括合用)的通用连接接口，称为基于资源的空间数据连接管理器。

图4-19　连接池管理器的自我管理过程示意图

面向资源的地理连接管理器示意图如图4-20所示。在这种方法中，包含了GIS会话组件、资源适配器、连接管理器、事件监听器和资源存储5个部分。其中GIS会话组件完成客户与GIS应用服务器的会话逻辑;资源适配器包含了连接、连接厂和可管理的连接3个部分，用于空间数据资源和空间数据资源处理组件的管理;连接管理器用于完成资源连接的管理(连接的创建、调用、销毁和删除);事件监听器监听资源的增加、修改和删除消息，触发连接管理器完成连接的管理。这种连接管理器允许空间数据资源类型的临时扩充和地理信息处理组件的动态装载，即能够在资源适配器中注册、登记、加入和发现扩充的数据资源类型和动态装载的地理信息处理服务。

图4-20　面向资源的地理连接管理器示意图

GIS组件调用连接的流程如下:GIS组件的本地接口执行连接厂的资源命名查询，然后发出连接的请求;连接厂将请求委托传递给连接管理器;连接管理器在应用服务器中查询连接池的实例。如果没有可用的连接池，则管理器使用可管理的连接厂来创建一个物理(不合用的)连接。

2)连接池实现

如图4-21所示，连接池实现由3个主要的类ConnectionObject、ConnectionRunner和PoolObject共同完成。类ConnectionObject代表加入连接中的对象，包含空闲时间、使用时间等属性;类ConnectionRunner代表连接池的一个线程，用于销毁连接池中的一个物理连接;类PoolObject代表一个连接池对象，用于添加、修改、取代和删除连接对象。除了根据时间触发的自我管理外，连接池也可以根据用户的会话请求创建、取得和销毁连接。

如图4-22所示，连接管理器由4个主要的类实现。其中DBConnectionManager类支持对一个或多个由属性文件定义的数据库连接池的访问，是客户程序可以调用方法访问本类的唯一实例;DBConnectionMonitor类是一个守护线程，用于监视连接池，每隔一分钟检查一次连接池，若有空闲连接超时或有异常抛出，则关闭该线程;DBConnectionPool类定义了一个连接池，它能够根据要求创建新连接，直到预定的最大连接数为止，在返回连接给客户程序之前，它能够验证连接的有效性;LogWriter类实现连接池管理的日志读写操作。

图4-21　连接池实现类UML示意图

图4-22　连接管理器实现UML示意图

2.海量矢量数据远程查询技术

1)海量数据远程查询的特点

海量数据的远程查询(陈能成等，2002b)包含空间几何对象和属性的查询。属性查询由于是规则的SQL查询，通常采用ASP和JSP查询方法就能胜任;由于几何数据对象的不规则、多样性和大数据量的特点，几何数据在网络环境下的查询有其特殊性，具体表现在如下方面:

①查询结果集表达的限制。由于网络带宽是有限的，在当前的Internet环境下一般每秒只能传输64K数据，而几何空间数据往往是海量的，这种海量数据与有限带宽的矛盾随着数据量的增加越来越突出，这种矛盾光靠几何空间索引是远远不够的，需要寻找其他解决的办法。MPEG和JPEG的编码和传输方式为问题的解决提供了新的思路。

②查询会话时间的限制。会话层的主要功能是向用户提供建立连接并在连接上有序地传送数据的一种方法，这种连接称为会话。会话层可以将一个终端登录到远程的计算机，或者用来传输文件以及其他许多应用。HTTP会话使用面向连接的会话模型。在同一时刻，一个运输只能对应一次会话。它具有提供给表示层的服务、数据交换、对话管理、同步、活动管理和例外报告的功能。空间对象的请求可以用两种规则完成:一种是请求某一个地物类(在数据库中可能相应地为一个表)的所有几何对象集合;另一种是请求某一范围内的所有地物类的对应的几何对象集合。无论是哪一种请求，都可以认为是一次完整的会话。基于因特网的会话时间是有限制的，不可能无限长。

③GIS查询会话为有状态的会话。会话可以分为有状态的会话和无状态的会话两种。对于有状态的会话，用户一次会话后与服务器的连接仍存在;对于无状态的会话，用户一次会话后与服务器的连接不存在。由于存储在空间数据中的数据量比较大，不可能把所有的空间数据下载到客户端进行显示、查询和分析，必须多次请求空间数据库中的数据。因此GIS客户一次会话后，如果为无状态会话，那么下一次的GIS请求就必须重新建立一个会话连接，即客户机与Web服务器之间要建立一个新的面向连接的请求，要耗费一定的时间。而如果为有状态的会话，那么下一次请求空间数据时，驻留在应用服务器上的代表用户的GIS会话组件只要从连接池中取得一个连接就可以完成与空间数据库之间的会话请求，可以节省客户与Web服务器之间连接的建立。例如，GIS客户在客户端做了100次的漫游操作，如果为无状态的会话，那么客户与Web服务器之间就要建立100次的连接;如果为有状态的会话，那么客户与Web服务器之间只需建立1次的连接。

海量空间数据远程查询是一个复杂的事务过程，它的事务往往具有时间长和时间变化大的特点。典型地讲，事务是指存取数据库的操作，对应地，GIS事务是存取空间数据库的操作，包含插入、修改、删除、回滚和读取等基本操作。基于网络的数据请求是客户机和服务器之间会话通信的过程，由于海量数据通常存储在数据库中，因此海量数据远程查询实质上是一个会话、处理和执行事务的过程。所有对空间数据库的存取都是在事务的环境中完成的。由于对空间实体之间的关系缺乏完整的描述框架，在GIS空间数据模型与组织方面存在不少问题。事务处理时空间实体的封锁粒度甚难把握，基本上采用图层封锁的办法，难以组织有效的原子事务和嵌套事务机制，直接影响了GIS复杂应用的操作难度(陈斌和方裕，2001)。对于存储在空间数据库中的实体对象，由于空间对象往往是海量的，因此存储空间对象时花费的时间比较长，为长事务。同时，由于空间实体对象不定长，数据量相差比较大，事务处理的时间相差比较大，为变长事务。例如，把8层原始E00数据导入到Oracle8i Spatial Option(SDO)中，相应地有22个几何对象表，每一层的事务处理时间与会话时间的对照表，如表4-2所示。其中，数据量大小指的是原始E00数据量;读取时间指的是GIS应用服务器从oracle读取对应层的几何对象数据时间的总和;解析时间指的是把Oracle 8i的SDOGEOMETRY对象解析成特定格式数据对象的时间总和。读取时间与解析时间构成了事务处理的时间，会话时间指的是客户发请求到服务器响应的时间总和，客户显示时间指的是地理信息数据在客户的显示花费的时间。

表4-2　空间对象读取事务处理与会话之间时间对照表

查询具有不透明性。由于一个查询操作要经过客户机、网络、防火墙、Web服务器、GIS应用服务器和数据库服务器，因此查询操作很可能不能如期完成。尤其是在网络阻塞时，问题更加突出，有可能发生中断。

2)海量数据远程查询机制设计

①空间数据查询设计

例如，在某一个地图窗口中查找某一个矩形区域的几何对象和属性的过程如下。

步骤1:客户端用户得到矩形区域的坐标和要查询的地物类名称。

步骤2:客户端用户根据矩形区域的坐标和要查询的地物类名称，得到落入当前矩形区域的几何对象OID集合，把这些信息绑定到HTTP协议，生成数据请求发给Web服务器。

步骤3:Web服务器接收到请求，并根据一定的规则把数据请求发送给GIS应用服务器。

步骤4:GIS应用服务器根据地物类名称、矩形区域坐标和客户已经具有几何信息的OID集合，从Oracle空间数据库中取出符合规则的数据，并根据一定的存储方式打包发送给Web服务器。

步骤5:Web服务器把GIS数据响应结果绑定到HTTP协议，作为应答发送给客户端。

步骤6:客户端接受响应，并且根据一定的会话规则，把数据解析成客户应用程序能够理解的格式，在客户端进行表现和显示。

图4-23所示，是把HTTP协议作为内部传输协议，针对GIS系统的特点进行扩充，构造了一种适合Internet网络环境下的“有状态”的传输协议。在系统的拓扑结构上添加的代理服务层主要包括客户端信息代理子模块和服务器端的Web服务代理模块两部分，它们都遵守代理协议规范。通过代理服务层把客户端浏览器和GIS应用服务器联系起来，前者提交请求、接受结果数据，后者处理请求、发送对应查询返回的结果，由代理服务主要记录用户端和数据库端的当前状态以及将客户提交的请求和服务器返回的请求转换为规定的内部传输格式，对HTTP协议进行了优化。而这一切对于用户是透明的，用户所看到的只是对图层数据操作、提交查询和返回结果。在服务器端，Web代理层对传输信息进行解释和判断分析，组织成GIS应用服务器所能识别处理的信息格式，由GIS应用服务器接收该信息并调用相应的模块，把得到的空间信息传给代理层，由代理层把得到的空间信息和附加代理信息一同发回浏览器;浏览器的代理子系统通过分析处理，代理信息了解服务器和空间数据的有关情况，并作出相应的反应。这种代理服务机制可以尽量减少网络中数据的传输量，使系统降低对网络带宽的要求，更合理地发挥Client/Server体系结构的优势，提高应用系统的处理能力和响应速度。

图4-23　基于查询代理空间数据远程查询的过程示意图

②几何对象属性查询设计。

属性查询、动态页面浏览服务，是一个动态网页生成的过程。目前，动态网页生成的模式主要有3种:ASP，PHP和JSP。下面，主要从(JSP+ Servlet)的方式阐述属性查询、动态页面浏览服务的设计。如图4-24所示，利用Oracle8i海量数据库系统管理数据，用Servlet等高性能服务端程序作为后台总控程序，JSP在前台运行，Servlet接受用户的输入，分别调用不同的JSP程序向客户端反馈信息。JSP/Servlet通过HTTP协议连接在服务端和客户端传递数据，它并不使用JDBC技术直接访问数据库系统，而是把参数传递给事先编好的JavaBeans和EJB组件，由它们对数据库进行操作，通过中间件应用服务器访问Oracle8i数据库中的属性信息。终端用户通过用户验证后进入属性信息的查询界面。查询方式可以为选择查询、条件查询和组合查询。在此界面中输入查询的基本信息，点击提交的命令，把信息提交到Web应用服务器，应用服务器启动属性查询、动态页面浏览服务组件，访问和获取元数据库中符合查询条件的数据，生成JSP或ASP文件，返回到客户端进行显示。

3)海量数据远程多级查询实现

矢量数据查询代理服务可以由一些简单的接口和类来实现。如图4-25所示，在GeoSurf的Oracle Spatial查询代理服务部件中，包含了数据提供厂、数据库数据提供器和Oracle数据库数据提供器三个层次。数据提供厂是一个实例，规定了一系列创建数据提供器的静态方法;数据库数据提供器从数据提供器接口中继承，包含初始化、设置连接池和设置坐标参考系统的一系列方法; Oracle数据库数据提供器实现了数据库数据提供器中的方法。

图4-24　几何对象属性查询的过程示意图

图4-25　矢量数据查询代理服务实现UML示意图

3.海量影像数据多级缓冲技术

现有的地理信息Web服务系统在支持海量空间数据分发、多源异构空间数据(影像、矢量和DEM)访问和多层体系结构部署方面能力不强，主要原因之一为服务效率不高。为了提高在线海量影像数据服务质量(陈能成等，2007)，本书从多级比例尺数据库存储、多通道数据处理和Web缓冲三个角度探讨多级缓冲技术在海量影像数据在线服务中的应用。

1)多级比例尺影像数据库存储

影像的比例尺与空间分辨率一一对应，多级比例尺的存储就是通过一定的索引机制，在数据库中建立起同一个地区分辨率从高到低的数据表。这种数据表称为工程，数据表的逻辑组合称为超工程。应用服务器访问数据库时，根据分辨率、坐标范围去查找工程中对应的记录，重新采样，生成影像数据结果集。

假设影像的原始数据为0.847m，通过抽取得到2.5m、5m、10m、25m、50m和100m六个不同地面分辨率的影像数据，存储在Oracle数据库中，根据不同的组合建立如下的七个影像数据库金字塔超工程，依次为超工程1(0.847)、超工程2(0.847、100)、超工程3(0.847、10、100)、超工程4(0.847、5、25、100)、超工程5(0.847、2.5、10、25、100)、超工程6(0.847、2.5、5、25、50、100)和超工程7(0.847、2.5、5、10、25、50、100)。取范围为{(3.8415728E7，2558264.0)(3.8431016E7，2569028.0)}，从服务器端下载分辨率依次为10m、15m、20m、30m、40m、50m和60m，相应的数据量为607K、282K、161K、107K、76.3K、43.3K、28.4K和20.4K的JPEG编码图像，不同金字塔层数对影像第一次请求下载时间影响如表4-3所示。

表4-3　不同存储方式下影像数据从读取到发送平均时间对照表

根据响应时间和数据库缓冲类别可以得到不同分辨率的折线图。如图4-26所示，如果在数据库存储中，只有原始的分辨率影像，那么第一次请求响应时间在60～95s;如果在数据库分别存储地面分辨率为0.847m和100m的影像，那么第一次请求响应时间在60～70s;如果在数据库分别存储地面分辨率为3～7个分辨率的影像，那么第一次请求响应时间在0～5s。因此多级分辨率的存储对于影像数据的实时在线浏览提供了可能。在此工程中，7层金字塔的数据是原始分辨率数据的1.213倍，即存储只增加20%左右，而响应时间却降到原来的1/30，反映了以空间换时间的数据库存储，大大提高了效率，使得海量影像数据在线浏览成为可能。

图4-26　多级比例尺数据库对在线影像下载第一次请求响应时间的影响示意图

2)应用服务器多通道多线程影像数据缓冲池处理技术

应用服务器中的影像数据服务提供影像库元数据的查询、几何范围查询、图幅查询和多种形式影像数据的分发功能，逻辑上可分为三层:数据层、影像服务层和客户应用层，根据提供服务层次的不同，服务层可以细分为服务接口层、通信层和影像服务层。

服务接口层为影像应用客户提供统一的调用接口。在设计时采用UML建模语言，实现了接口的统一描述，分别实现了C和Java语言的接口。

通信层是影像数据服务子系统服务层客户服务结构的基础设施层。它用于支持多用户线程或进程，通过系统提供的服务接口层并发地向影像服务层请求影像服务。通信层实现上主要考虑影像传输的效率，其次是影像数据服务子系统的分布性和可移植性(UNIX、LINUX和WINDOWS)。利用操作系统提供的SOCKET机制，可以保证客户进程和影像服务进程间通信的效率，同时为客户进程和服务进程部署在不同主机上的分布式应用提供可扩展空间。

影像服务层是影像数据服务子系统提供可靠地理影像服务的设施层。它使用影像金字塔的形式组织影像数据库，并为提高数据使用效率提供影像数据的缓冲机制。它以每客户一个线程的方式响应客户的服务请求。每个服务线程从通信层获取客户的请求消息和发送客户响应消息，从系统的数据层获取客户请求消息对应的影像数据。

影像数据块缓冲结构用于管理系统从影像数据库中获取的影像数据块。此结构实现数据块的快速查询并且建立多线程间对结构的同步访问机制。影像块缓冲由两个层次组成:一个是管理实际影像数据块的缓冲，成为影像工程数据块缓冲;另一个是管理影像工程数据块缓冲的全局缓冲。每个影像工程对应一个数据块缓冲，这些结构使用影像工程名唯一标识，所有影像工程的数据块缓冲结构由一个缓冲堆结构-全局缓冲进行管理。

考虑到多线程的同步缓冲区数据访问包括读缓冲区数据和添加数据块到缓冲区，在缓冲区结构和缓冲区管理结构缓冲堆中需要加入数据访问的互斥成员。在缓冲堆结构中使用一个堆成员管理有影像工程名索引的缓冲区结构。同时在两者结构中对可缓冲最大数和缓冲占有最大空间进行定义，以便于定制和扩展缓冲区的应用。

每个影像金字塔都对应一个影像缓冲结构进行影像数据的缓冲管理，根据影像数据库工程的组织方式，影像缓冲区机制为影像超工程的所有影像工程建立对应的缓冲队列，从而可根据不同影像工程调整数据缓冲队列的空间和大小。实现时的具体配置如下所示，包含通道、系统线程和缓冲池的配置。

3)Web服务器影像数据结果集缓冲

通常而言，基于J2EE的应用服务器和Web服务器提供了JSP和Servlet级别的结果缓冲机制。使用服务器端的结果缓冲机制能够有效地提高服务器的执行性能。它的思想是对一定时间内的用户请求分门别类，对于相同的请求直接使用缓冲中的结果集，而不是采用代码重新生成结果。这种机制对多用户访问情况特别有效。其思想可用如图4-27所示的流程表达:客户向地图引擎发出数据下载的请求，在Web服务器端根据检校准则对照请求，如果与缓冲结果集中的请求一致，则从服务器端的缓冲结果集中取出一个结果作为客户的应答;如果与缓冲结果集中的请求不一致，则把请求转发给应用服务器端的Servlet引擎，Servlet引擎根据用户的请求处理后返回结果给客户并且把结果保存在服务器端的缓冲结果集中。

在一个地图引擎中，检校原则不可能像文本请求那么简单，它往往是一个复杂的组合。例如在一个影像下载服务中，典型的表达式为“http://geoserver/NASApp/imagedbserver/Image ProviderServlet?sx=3.8415728E7＆sy= 2558264.0＆ex=3.8431016E7＆ey=2569028.0＆dr=30”，其中“?”前半部分为引擎的名称，后半部分为引擎的参数，包含左上脚、右下脚(X，Y)坐标和地面分辨率。我们假定请求的区域范围一定，把影像地面分辨率作为检校的参数，影像下载引擎设计成“http://geoserver/NASApp/imagedbserver/ imageCache?dr=?”，缓冲时间设计成900s，缓冲大小设计成100K，以地面分辨率dr作为检校原则，则缓冲创建的条件为连续的，如下所示。

图4-27　Web缓冲结果集原理示意图

＜Caching＞

　　＜cache-mintimeout＞900＜/cache-mintimeout＞

　　＜cache-size＞100＜/cache-size＞

　　＜cache-option＞TIMEOUT_CREATE＜/cache-option＞

＜/Caching＞

其中，“Caching”标签代表缓冲的开始，“cache-timeout”代表缓冲时间，“cache-crite”代表缓冲的检校原则，“cache-option”代表缓冲创建的方式选项。

取5个不同分辨率的请求依次为30m、25m、20m、15m、10m作为参数，获得的影像数据量依次为76.3K、107K、161K、282K和607K(JPEG编码)，没有缓冲和有缓冲时，分别获得从接受请求到发送数据完毕的时间，那么第一次请求和连续5次操作的平均时间如表4-4所示。

表4-4　影像数据从读取到发送平均时间对照表

从实验结果可以得出以下四个结论:对于第一次请求的响应，有无Web缓冲时，处理时间基本保持一致;对于无缓冲情况，连续后5次平均响应时间比第一次请求的响应时间低，这是由于已经去除数据库连接的耗时;对于有缓冲情况，连续后5次平均响应时间为“0”，即数据获取并没有经过引擎的处理，而是从Web缓冲中直接获得;有缓冲相对于无缓冲而言，能够大大降低应用服务器计算能力的要求，尤其对于多用户访问来说，更有意义。