文件管理模块要点分析及方案设计（PDM）

文件管理模块要点分析及方案设计（PDM）

    电子仓库与文件管理作为PDM系统的一个重要功能模块，负责管理设计图纸、技术文档、规格说明书、各类说明文档等数字化文档的上传、下载、存储、查询、备份、恢复等功能的实现，直接影响到企业内部信息共享的效率及企业的生产效率。本章将对文件管理模块功能实现过程中存在的重点与难点问题进行分析，并对每个问题的解决方法进行研究，通过实验与对比总结出可行的实现方案。
 
1电子仓库与文件管理模块要点分析
    本文第二章节已对大规模制造型企业PDM系统对电子仓库与文件管理模块的主要功能及特定需求进行调研，包括更大容量的文件、更庞大的文件规模、更频繁的并发请求、更高的数据安全性要求等。针对这些需求，电子仓库与文件管理模块的实现问题被划分为文件传输方式，文件存储结构，文件转存方法的实现问题。本节将阐述这些问题在实现过程中的重点与难点。
 
    (1)文件传输是文件管理模块的一个重要问题。目前随着互联网的应用越来越普及，文件共享的需求越来大，网络文件传输方式也经历着翻天覆地的变化，从最早的FTP协议，应用最普遍的HTTP协议，到近年越来越流行的P2P、P2SP、P4P、UTP协议等，用户从互联网上下载资源变得越来越容易。
 
   但是P2P等下载方式多用于专门提供互联网资源上传下载的应用及服务，例如电驴、迅雷等，在企业内部的信息系统中，文件传输的实现仍然主要依赖于HTTP与FTP协议。但是HTTP协议对于大文件的传输不能提供足够稳定、可靠的支持，FTP协议亦不能与B/S结构的应用无缝接合，因此，需要使用改进的设计与技术，结合适当的文件传输协议来实现Web应用中的大文件传输。
 
    (2)文件存储是文件管理模块的另一个重要问题，包括文件存储结构，文件转存方法等方面。数据库是一个便捷而安全的数据存储及管理载体，但是传统的数据库已经无法承载海量大文件的存储及管理，文件柜存储模式成为大型制造企业PDM系统的唯一选择。
 
    文件柜模式的存取过程一般都需要经过两个步骤：例如上传，首先在对应的文件信息数据库中添加一条记录，包含上传文件的附加信息，例如文件的名称、文件类型、文件大小、操作时间、存储路径等，这些信息用来作为检索此文件的重要检索点；然后将文件上传到文件系统中。文件柜模式的效率及安全性问题是这一存储方案存在的最大问题，需要设计合适的存储结构以改善文件存取效率；而文件系统安全性的提高则需要设计更复杂的控制及跟踪机制，本文通过文件转存方案实现这一目的。
 
2大文件传输方式的研究与实验
    文件传输方式是文件管理模块的核心问题，采用何种传输协议，使用何种实现技术都是企业实施信息系统过程中必须考虑的问题。PDM系统管理着大型设计、生产型企业的数字化文档，并优化其管理流程。例如航空航天及船舶制造企业，其单个文档的规格往往很大，在几兆至上百兆之间。因此，如何在PDM系统中实现大文件传输，并且在高并发环境中提供稳定、安全、可靠的服务成为一个关键的功能模块。
 
    目前，用于文件传输的Web组件并不少见，也不乏优秀的成果。例如常见的ASP.NET自带的FileUpload控件，国内常用的Lyfupload组件等。但是绝大多数组件并不适合于大文件传输(大于30M，当大量用户同时上传大文件时，将造成上传速度慢，容易发生意外中断等结果。如何选择和使用适当的上传组件，或者使用何种技术开发文件传输模块，成为企业开发信息系统过程的常见问题。
 
    本节将对时下流行的几种基于.Net平台的大文件传输组件进行分析、实验和比较，总结出各组件的适用范围，并对文件传输模块的自主研发提出一些设计思路。在本节的最后将总结各种大文件传输方案的优缺点，并针对大规模制造类企业PDM系统的需求选择合适的解决方案。
 
2.1基于.NET的大文件上传组件
    目前流行的大文件上传组件有许多。本节将对FileUpload，SWFUpload及S1ickUpload组件的特性及可用性进行分析、评估。
 
    ASP.NET自带的FileUpload控件是最简单、最常用的文件上传方式。但是出于各种因素的考虑，特别是安全方面的原因，该组件对上传文件大小以及相应响应时间存在默认的限制，例如只能在规定的时间上限内上传小于4M的文件。为了解决大文件上传的问题，可以修改配置文件web.config中修改文件大小及响应时间的限制。然而这不是解决问题的根本方法。
 
    由于该组件是为传输较小文件而设计，会在所有请求数据全部上传到服务器内存后才进行相应处理。如果多用户同时向服务器上传大文件，会导致在短时间内消耗服务器大量内存资源，对服务器造成极大压力，甚至崩溃。因此，ASP.NET自带的FileUpload控件不能满足大规模制造企业文件传输的需求。
 
    SWFUpload是一个开源的轻量级的JavaScript/Flash库，它结合了JavaScript和Flash的功能，以提供一种超越了传统的浏览器中<input type=“file”/>标签提供的文件上传功能。通过它可以实现文件的异步传输，能够在界面更好地显示上传进度和上传信息，并且可以实现多文件上传。理论上通过SWFUpload可以上传服务器限制下的任意大小文件(如IIS限制传输文件最大为2G。但是，SWFUpload仍然是将文件数据一次读入服务器端的session对象。因此，多用户同时访问服务器并上传文件时服务器消耗大量内存的问题仍然不可避免。
 
    在支持大文件上传的组件中，国外的商业组件S1ickUpload在局域网内具有很好的表现：上传速度快，能显示进度条，上传文件大小不受限制。
    S1ickUpload的处理过程如下：
    (1)客户端初始化上传请求；
    (2) IIS接收请求并把请求传递给ASP.NET；
    (3) ASP.NET接收到请求；
    (4)在ASP.NET处理程序接收到请求之前，S1ickUpload截获该上传请求；
    (5) SfickUpload把接收到的请求，以流的方式写入数据存储设备；
    (6)当S1ickUpload处理请求的时候，客户端可以接收到处理进度；
    (7) SfickUpload完成请求处理；
    (8)ASP.NET继续处理除了上传数据之外的请求。
    具体实现方法是：S1ickUpload组件在浏览器端把上传表单(包括上传文件)封装成XML文件，然后使用XMLHttp技术异步发送。为了突破应用服务器对上传文件大小的限制，S1ickUpload在服务器端使用IHttpModule技术，在ASP.NET进程处理request请求之前截获request对象，然后使用隐含的HttpWorkerRequest对象通过分块读取和写入的方式来接收数据。这种方式对服务器接收过程进行优化处理，能够实现超大文件的上传，并提高上传速度。但是该收费产品仍然不能实现断点续传。
 
    为了验证以上三种组件在并发环境下的表现，分别使用三种组件搭建文件上传原型，并在实验室LAN网络环境中进行并发实验，观察并记录每种原型下服务器的运行状态。
    Web服务器：IIS7，内存2G，启动Web服务器无请求时CPU使用率处于7%左右。
并发请求：10条并发请求，每条请求上传200M大小的文件。实际企业环境中可能有更多的并发请求，但是每个用户上传文件的大小可能在3M-80M不等，故使用较大的文件来模拟更多的用户场景。
 
    3组实验过程及结果如下：
    (1)使用FileUpload控件，并在web.config中的<system.web></system.web>标签中加入如下代码：
    <httpRuntimeexecutionTimeout="600" maxRequestLength="512000"/>
其中maxRequestLength为请求数据流的最长字节数，executionTimeout为响应时间限制(秒)。
 
    实验结果：仅1人上传文件时文件传输成功；10个用户同时传输时，均传输失败，浏览器报错：服务器错误404一找不到文件或目录。服务器CPU使用率及内存使用情况如3-2所示。事实上，文件在完全载入服务器内存前传输就发生了错误，因此服务器内存占用情况并没有很大变化。实验结果说明：File Upload控件不能支持高并发的大文件上传要求。

    (2)使用SWFUpload开源库搭建文件上传原型，10个用户同时上传200M文件。由于SWFUpload使用F1ashPlayer的客户端处理技术对文件上传进行了优化，避免了同一时间请求信息过大造成的响应失败情况。实验结果：均上传成功，服务器CPU使用率及内存使用率均有明显提高，详情可见图3-3。

    (3)使用S1ickUpload组件原型进行相同的实验：10个用户同时上传200M大小的文件。由于该组件在传输和保存大文件过程中能够实现边上传边处理，因此能够避免服务器内存的大量消耗。实验结果：均上传成功，CPU使用率有一定提高，内存使用率略有增大。

    3组文件传输实验中服务器的资源消耗各不相同，详细的对比结果可见表3

表3-1大文件传输组件实验结果

    实验结果证实：由于FileUpload与SWFUpload均是把用户提交的文件一次读入内存再进行处理，服务器资源消耗大(或响应失败)的问题不可避免。但SWFUpload对数据流进行了一定优化，对于并发性不常见的企业，SWFUpload组件是一个良好的解决方案。而使用S1ickUpload组件时服务端能够边接收，边处理文件流，并及时存储，避免了服务器资源消耗大的问题。因此，在高并发的环境中，SfickUpload是较为理想的解决方案。
 
2.2基于AJAX技术的文件分块传输模式
    受S1ickUpload组件的实现原理启发，将文件分块传输、存储可能是解决大文件传输过程中CPU使用率过高以及实现断点续传问题的一个良好解决方案。问题转变为：文件如何分块、如何传输、如何存储、如何控制整个传输过程中的临时状态。
 

分块传输方案中文件上传的过程可以通过图3-5体现。

    使用ADO与AJAX技术可以实现以上流程：使用ADODB.Stream装载文件并获取文件块；使用XMLHttp对象作为文件块信息的载体；服务器解析接收到的XML信息，并存入文件系统，记录口志；异步刷新页面，逐步获取新文件块，直至整个文件传输完毕。
 
    ADO(ActiveXDataO句ects)是微软开发的数据访问组件，在微软各个版本的操作系统中都自带有ADO组件。ADODB.Stream对象可用来表示文本流和数据流，它允许开发者对字节型的二进制流进行读写，因此可被用于实现客户端的读取文件功能。XMLHttp是传送XML格式数据的超文本传输协议。
 
    XMLHttp的数据传输形式非常灵活：它上传的指令和下达的结果既可以是XML格式数据，也可以是字符串、流，或者是一个无符号整数数组，还可以是URL的参数等。通过XM LHttp可以方便地在异构平台之间进行XML数据交换。XMLHttp最大的用处是可以更新网页的部分内容而不需要刷新整个页面，因此，作为AJAX技术的重要成员，它在浏览器端的应用非常普遍。
 
    若文件在上传过程中意外中断，可以从服务器获取已上传的文件位置的记录，并从相应位置开始继续上传文件块，而无需重传一遍。根据以上设计方法，续传的过程如图3-6所示。

    利用ADODB.Stream装载文件并获取文件块，再通过XMLHttp把封装好的文件块发送给服务器的方法，能很好地解决大文件上传的问题。但是该方法需要复杂的设计和开发过程，并且对文件的加密、解析、事务控制、异常处理等均需要进行精心的分析与设计，开发人员需要花费大量的时间和精力完成文件传输模块的构建。企业在选择该方案时需综合考虑时间成本及稳定性等各种因素。
 
2.3 FTP文件传输在B/S架构中的实现
    以上讨论的文件传输方式均基于HTTP协议。超文本传输协议(HTTP、HyperText Transfer Protocol)是客户端浏览器或其他程序与Web服务器之间的应用层通信协议，是互联网上应用最为广泛的一种网络协议。但是大文件传输并不是HTTP的强项，使用HTTP协议传输大文件大多会有CPU使用率高或处理过程复杂化的缺陷。FTP(文件传输协议)是一种经典的C/S结构的文件传输方式，其优点是上传速度快、能实现断点续传，缺点是是部署麻烦、维护困难，不能实现与Web应用的无缝接合。
 
    FTP的实现是通过两个TCP连接完成的：一个称为控制连接，用于传输FTP命令；另一个称为数据连接，用于传输文件数据。FTP服务器端可以方便地以文件夹为单位控制用户对文件的操作权限、管理用户的访问信息等。

    FTP协议与HTTP协议的区别如表3-2所示。

表3-2HTTP与FTP协议传输文件的区别

    随着Web应用的普及，HTTP协议以其强大的功能及便捷的开发方式受到越来越多开发人员的喜爱，即使使用HTTP协议进行文件传输存在诸多缺点，大多数应用仍然采用这种方式实现文件传输模块，仅对文件大小进行一定限制。FTP不能实现与Web应用的无缝接合这一致命的缺陷阻碍了FTP文件传输方式在Web系统中的广泛运用。
 
    在浏览器实现FTP客户端功能可以有几种方法：ActiveX、Java Applet，以及SilverLight、Flex等富客户端技术。
ActiveX是一个开放的集成平台，为开发人员、用户和Web生产商提供了一个快速而简便地在Internet和Intranet创建程序集成和内容的方法。ActiveX的缺点是需要在用户机器中下载可执行代码，不仅维护麻烦，而且可能带来安全隐患。Applet(小应用程序)采用Java创建的基于HTML的程序。
 
    浏览器将其暂时下载到用户的硬盘上，并在Web页打开时在本地运行。由于可执行代码每次都是临时下载、运行，因此在客户端维护方面比ActiveX方便许多，但是为了防止其中带有的恶意代码对本机造成的破坏，Applet的限制较多。并且Applet要求客户机上装有JDK环境，因此该方案也渐渐被新技术所取代。
 
    SilverLight与Flex是支持RIA (Rich Internet Applications)的开发和部署的技术，可用于构建具有表现力的Web应用程序。由于它们具有编译器性能，可以支持客户端代码的运行，可以作为FTP客户端的技术载体，并提升Web页面的用户体验。但是客户端为了支持SilverLight必须下载并安装SilverLight插件，这是很多用户所不喜欢的方式。而Flex需要客户浏览器上装有Adobe F1ashPlayer插件，这类软件在客户机上比较普及。因此，在制造型企业的内部网络环境中，使用Flex优于SilverLight技术。
 
    使用Flex技术进行页面开发可以较便捷地实现FTP客户端功能，并且无需复杂的客户端代码维护工作，能够实现断点续传，是实现大文件传输功能的一个较合适的解决方案。
 
2.4文件传输方案综合评价
    以上各项解决方案都可以实现大文件的传输。对各种解决方案的特点及优缺点进行总结，得到表3-3所示结果。

表3-3各种文件传输方案比较

    综上所述，对于安全性要求低、并发程度不高，预算有限的小型企业信息系统，SWFUpload是一个理想的解决方案。而结合大规模制造企业对文件传输的特殊需求，使用S1ickUpload组件能很好地解决大文件上传的问题。若企业选择自主搭建文件传输功能模块，则使用分块传输方法或使用Flex实现FTP传输方案均是较理想的选择，但是分块传输方案需要较高的学习成本及时间成本。因此，在大规模制造类企业PDM系统中，采用S1ickUpoload及Flex实现FTP传输两种解决方案较为理想。
 
3文件系统存储结构设计
    大规模制造类企业PDM系统管理的文件数量众多，单个文件占用空间较大，因此，如何为文件系统设计合理的存储结构将对PDM系统的管理效率及使用效率产生重要影响。本节将从文件系统的目录结构设计、容量设计、存放规则及文件命名规则等方面对文件系统的存储结构进行详细设计。
 
3.1文件系统目录结构设计
    文件系统的目录结构应当脱离于PDM系统的产品文档结构。产品文档结构的节点信息从相应数据表中读取，而文件系统的目录结构应更多考虑其存取效率、管理效率，并让其脱离于业务逻辑，最佳效果是做到仅通过接口与PDM业务系统进行交互。为此，文件系统需要设计适当的层数，每层分布适当的文件夹，每个文件夹中设计适当的文件个数，并且记录文件系统的文件与PDM业务系统产品文档结构的对应关系。
 

文件系统的目录结构可以如图3-8所示：

    其中，根目录记作PDM_ROOT；一级目录设计如下：在根目录中按1，2......顺序建立子文件夹，直至子文件夹个数到达某个限制N。子文件夹的建立是一个动态的过程，即当子文件夹1存满(文件数达某限制数M)后新建子文件夹2,并在子文件夹2中开始存放文件。
 
    以此类推，而无需在系统部署初期将整个目录结构建立完整。当第一层子目录的N个子文件夹均存满文件时，启用第二层子目录：即在PDM_ ROOT\1中新建子文件夹PDM_ROOT\1\1，PDM_ROOT\1\2ww至PDM_ROOT\1\N存满文件后，在PDM_ROOT\2中用同样的方法建立子文件夹，以此类推。选择合适的M，N值可以使文件系统的层数尽可能小，读取效率尽可能高。
 
3.2文件系统容量设计
    为了获得每个文件夹存放子文件的数量限制M及子文件夹数量限制N值，对各种类型文件系统的特性进行调查如下：
    (1)对于FAT16文件系统，可以保存的文件体积范围是1 byte-4 GB(2^32bytes)；卷的最大体积是4GB；每个卷上最多可以保存的文件数量是65，536(2^ 16)个；根目录下可以保存的文件和文件夹数量最大值是512个 (如果使用了长文件名，该数字还会减小)。
 
    (2)对于FAT32文件系统，理论上可以保存的文件体积范围是1 byte-4GB(2^32 bytes)； Windows自带的工具可以创建的卷的最大体积是32GB ；每个卷中最多可以保存的文件数量是4，177，920个；一个特定文件夹中最多可以保存的子文件夹和文件的数量是65，534。
 
    (3)对于NTFS文件系统，可以保存的文件的大小范围理论上是1KB-16EB(2^64 bytes)(lEB=1024PB=1024TB=1024GB)，实际实现过的最大值是16TB(2^44 bytes)；卷的体积最大值，理论上可以达到2^64个簇，实际实现过的最大值是2^56TB(2^32个簇)；每个卷可以包含的文件个数的最大值是4，294，967，295个(2^32-1)。

    (4) ext3文件系统的一个目录下最多只能有32000个子目录。ext4的子目录最高可达64000。ext3文件系统下单个目录里的最大文件数无特别的限制，是受限于所在文件系统的mode数。
 
    综上，无论何种操作系统，同一文件夹内文件数量控制于65，534以内即可。事实上，随着文件数量增加，服务器的响应速度会受到影响。同时考虑到企业内部庞大的文件规模，初步设定当一个文件夹的文件数超过30000(M=30000时新建文件夹进行存储。
 
    当前Windows使用的主流文件系统为NTFS，Linux使用的主流文件系统为ext3以及升级版本ext4)ext3在文件传输效率及内存使用率方面均优于NTFS但是将文件从ext3复制到NTFS系统中比较麻烦。因此，对于搭建在.Net平台，运行于IIS服务器上的PDM系统，采用NTFS文件系统较为理想。
 
    为了比较文件夹层数与子文件个数对文件存取效率的影响，在NTFS文件系统中进行以下3组实验：
    (1)在某磁盘根目录中新建文件夹single_layer，并在其中新建30000个子文件夹，新建single_layer\layerl.txt文件(输出新建时间)以及读取文件内容(输出读取时间)；
    (2)在同一磁盘根目录中新建文件夹more_layer，在其中新建300个子文件夹，并在每个子文件夹中再新建100个子文件夹(2级子文件夹共有300*100=30000个)，新建more_ layer\testDIRI\layer2.txt文件(输出新建时间)以及读取文件内容(输出读取时间)；
    (3)文件夹结构同2，新建more_layer\testDIRl\testDIRl\layer3.txt文件(输出新建时间)以及读取文件内容(输出读取时间)；
    每组实验重复5次，得到表3-4所示结果。
    其中实验环境为一一实验主机配置：操作系统：Windows XP；主频：2.60GHz,
内存：2G。

                          表3-4文件系统分层结构实验结果

    发现3种情况中，新建文件的时间随层数增加略微有所增长，而3种方案读取文件的时间差别并不明显。
根据实验结果，可适当扩大每个文件夹中的子文件夹数。实验中同时发现，打开有30000个子文件夹的文件夹需耗费较长时间，又考虑到同一个文件夹中子节点数(子文件夹与子文件总数)不宜过大，故选择1000 ( N=1000作为每个文件的子文件夹数限制。
 
    通过以上分析，选择M=30000, N=1000分别作为每个文件夹的子文件及子文件夹的个数限制。此时，文件系统的2级目录中共可以存放M*N = 3千万个文件，N*N = 1百万个子文件夹，3级目录中共可以存放M*N*N=3百亿子文件，完全可以满足大规模制造类企业PDM系统的文件管理需求。系统可以做必要的扩展，当第n层的所有文件夹均存满文件时，从第n层目录的第一个文件夹起建立子文件夹，并向该子文件夹(第n+1层目录的一个文件夹)中保存新文件。但是事实上，n>3的情况可能永远不会发生了，若系统存放了近3百亿文件，该系统应当已运转数年，企业应早已启动必要的清理旧文件的程序或者启动为新产品线部署新系统的程序。
 
3.3文件存放规则及命名规则
    以上实验过程发现，打开有30000个子节点的文件夹时系统需要较长的响应时间，由于对根目录访问频繁，故设计根节点中仅存放1000个子文件夹，子文件从一级目录的第一个文件PDM_ROOT\1起依次存放，即PDM_ROOT\1中存满30000个文件后新建PDM_ROOT\2并存于其中……；当一级目录完全存放完毕(已存放M*N = 3千万文件)时，从一级目录的第一个文件夹中建立子文件夹PDM_ROOT\1\1，即从二级目录的第一个文件夹中开始存放，PDM_ROOT\1\1存满时新建PDM_ROOT\1\2文件夹并存于其中…wPDM_ROOT\1\30000存满时新建文件夹PDM_ROOT\2\1 w…以此类推。
 
    文件命名规则从以下2种方案中选出：(1)从文件名的简洁出发，以数字1,2, 3...…依次作为新存放文件的文件名存入文件系统。优点是文件长度较短，存取效率高，可以反映文件系统存储状况相关信息。相应的缺点是：并发控制复杂，不同文件夹中文件有重名，对文件系统进行旧文件清理时被保留文件的路径不可被改变。(2)从系统开发及维护的便利性出发，使用GUID作为新文件文件名存入文件系统。
 
    GUID，即全球统一标识符，是计算机上按一定规则生成的一串数值，它保证对同一时空中的所有机器都是唯一的。.Net平台提供了便捷的方式生成GUID，GUID在PDM系统中的详细设计及使用方法可见本文5.3.2节。这一方案的优点是生成方法简单，无需做并事务控制，整个文件系统中不会有重名，所有文件名长度一致。并且，即使某个文件下载地址被非法获取，其他文件名也不会被推断出，安全性较好。综合考虑两种方案的优缺点，随着计算机性能的提高，文件名长度对系统性能影响越来越小，为保证系统的正确性、稳定性及开发的简易性，最终选用GUID命名方案。
 
4文件转存方案设计
    若用户直接与文件系统交互，进行文件上传、下载，则需要把整个文件系统部署到Web服务器上，并且安全性难以保障。为避免用户与文件系统直接连接，可增加文件缓冲区，即命名为BUFFER的文件夹，使用文件缓冲区作为用户与文件系统的桥梁。在一个上传操作中，用户将文件上传至文件缓冲区，系统记录该操作的相关信息：包括文件状态，目标位置等。在系统空闲时间将文件更新到电子仓库文件系统。在下载操作中，系统先将文件从文件系统复制到文件缓冲区，用户从文件缓冲区取得文件。简要流程如图3-9所示。
 
为实现以上流程，系统需增加如下配置：
    (1)文件缓冲区：BUFFER FOLDER了该文件夹为中转文件夹，用于与用户直接传送文件，以及在系统闲时将中转文件转移至文件系统实际地址。
    (2)中转数据表记录中转文件的状态及中转地址与实际地址的对应关系。

表3-5中转数据表示例

文件增删改查的简要流程如下：
(1)文件上传
    当用户“创建文档”或“修改文档”时需要进行“上传附件”操作，此时系统执行图3-10所示工作。

    在用户点击“确认”按钮提交创建或修改文档的请求时，电子仓库将生成文件在文件柜中的目的路径，并在相关数据表中将该文件的目的路径、中转路径，以及它在文档属性表的对应记录关联起来。

    (2)文件下载
    同样为了避免用户通过Web服务器直接访问整个文件柜，则用户需要从缓冲区下载文件，但是这种操作可能降低文件读取效率。同时，下载可能使临时文件夹堆积大量文件，为防止影响文件上传，并且降低临时文件垃圾清理复杂度，可将上传缓冲区BUFFER_UPLOAD与下载缓冲区BUFFER_DOWNLOAD分开，这样，当BUFFER_DOWNLOAD中文件达到一定数量，例如30000时，系统可自动删除其中最长时间未被使用的文件。

    下载方法：检查缓冲区是否有该文件的副本，若有，从缓冲区下载该文件，否则，从电子仓库中找到该文件，复制到文件缓冲区中，用户从缓冲区下载该文件。文件下载流程如图3-12。

    (3)文件删除
    用户提交“删除”操作时，系统在中转数据表中记录该文件的路径信息并将状态改为“待删除”。系统将在定时任务中执行删除操作。
 
    (4)定时任务处理缓冲区文件
    在某一系统空闲时刻(例如每口00：00时刻)启动定时任务，对中转数据表进行搜索，对状态为“待更新”，即上传、修改成功的记录，将缓冲区中的对应文件复制到文件系统目标位置；对缓冲区中状态为“下载完毕”的文件执行删除操作，并修改相应记录状态(此步骤不影响文件系统的文件)；对状态为“待删除”的文件，将电子仓库中的对应文件删除。若文件缓冲区与文件系统属于不同服务器，则文件缓冲区与文件系统间可采用基本的SOCKET编程方法实现点对点文件传输，或使用磁盘共享的方法直接复制文件。更新过程见图3-13。

    通过文件缓冲区的设置，可以避免用户与文件系统直接交互，虽然对下载效率有一定影响，但是大大提高了文件系统的安全性。在航空航天、船舶制造等保密要求较高的企业的PDM系统中，文件缓冲区的存在是非常必要的。
 
5电子仓库文件管理整体解决方案
    本章对电子仓库与文件管理中的三个重要子问题进行了分析与研究，提出了每个子问题的解决方案。在此基础上，本节将进一步给出电子仓库与文件管理的整体解决方案。
 
    本文2.2节中已给出电子仓库的基本定义，作为文件管理模块的基本服务单元，电子仓库维护着PDM系统的整个数字化文档实体系统(即文件柜及其中的所有文件)，并向PDM系统的其他模块提供文件上传、下载、删除，以及文件系统管理等基本服务。
 
    图2-2也展示了常见的系统构造方法，该方法对文件的保护措施较弱。为了改进文件柜的安全性，本文设计了一个文件缓冲区用以隔离浏览器与文件柜，为文件系统增加了一层安全保障。图3-14展示了改进的文件访问流程，同时，该图也体现了PDM系统的构成。

    电子仓库是PDM系统的一个重要组成部分，除了作为文件柜的容器，还需要提供一系列文件管理基本服务，包括：
    ◇生成待存文件名；
    ◇生成缓冲区文件上传路径；
    ◇生成文件在电子仓库文件柜中的目标路径；
    ◇定位目标文件，将文件转移至缓冲区，并提供缓冲区下载路径；
    ◇删除文件服务；
    ◇清理缓冲区服务，包括转移新上传文件、删除下载产生的临时文件、删除文件柜目标文件等；
    ◇文件系统管理服务，包括修改文件柜根目录，文件柜容量限制等。
    除了电子仓库提供的基本服务，文件管理模块还在Web服务层提供可替换的文件上传组件，例如本文介绍的解决方案使用S1ickUpload大文件上传组件，能够实现高并发环境中大文件快速、稳定的上传。同时，该组件是容易替换的，只需要在页面修改控件的引用并进行简单的配置就可以使用其他上传组件，以满足系统需求可能发生的变化。
 
    综上所述，文件管理模块的综合解决方案由2部分构成：Web服务层的上传控件与电子仓库的文件管理基本服务。它们共同构成Web应用完成文件管理的基础。综合解决方案的结构如图3-15所示。

    本文的后续章节将针对该综合解决方案的具体实现，以及文件管理模块与其它工作模块协作完成PDM系统需求的方法做出进一步的分析、设计与实现。

6本章小结
    电子仓库与文件管理模块负责管理各种数字化文件实体的上传、下载、存储、查询、备份、恢复等功能的实现，该模块的实现对企业内部信息共享的效率及企业的生产效率都将产生重要影响。本章根据大规模制造型企业的特定需求，对文件传输方式、文件存储结构、文件转存方法等方面的具体问题进行了研究与实验，并根据分析结果提出综合的解决方案。


本文为御云清软英泰PLM软件原创文章，如想转载，请注明原文网址摘自于
http://www.plmsoft.com.cn/news/gsxw/147.html；否则，禁止转载；谢谢配合!