随着网络的发展，实现4W是教学的必然方向，即：任何人（Who）在任何地方（Where）、任何终端上（Witch）都可通过网络获取他需要的知识（What），这就要求我们把课件都做成网页的形式。但是，我们通常在网络普及之前，就已经使用多媒体创作工具或编程工具制作了不少课件（以下简称课件），有的单位为了教学的需要，购买过一些课件。要把这些课件重新制作成网页是一项非常艰巨的工作，如何实现这些资源的共享成了当务之急。另外，在局域网带宽不是问题的情况下，课件与网页相比还有以下几方面[b]优点[/b]：

交互性更好。在网页中实现交互相对较难。

不易迷失航向。在网页中，当嵌套层次较深时，极易使读者迷失航向。

实时性好。由于在播放时，不需要将各种媒体首先下载到本地，所以，在局域网中使用课件不会有网页的那种明显的停顿现象。特别是，网页的HTML协议决定了，在网页中播放动画和录像不会有好的表现。

能充分利用服务器资源。当网页上使用到较多的动画、录像、图片，必须为浏览器预留足够的磁盘空间，并可能塞满终端机的硬盘。

开发工具多，可满足不同用户的需要。开发更容易。

因此，我们根据实际需要，决定开发一个多媒体教材库及基于此数据库的管理播放平台，以便最大限度地实现共享。

[b]多媒体教材库简介[/b]
由于课件由多个存放在多个文件夹中的多个文件文件组成，因此，每个相对独立的单位不是文件或文件夹，而是以课件为单位的文件组，我们借助于数据库的良好管理功能进行文件组管理，利用VB和VC编程。因此它是一基于数据库的网络管理程序，其难点却不在数据库本身。

就多媒体教材库本身而言，是一个简单的数据库。我们的目的是要用数据库良好的管理功能对多媒体教材进行有序的管理，并在此基础上实现数据共享，确保数据安全问题，实现在终端用同一播放平台播放不同开发工具创作的课件（多平台支持）。

程序分为两个部分，如下图所示：一部分是运行在服务器上的服务程序，以下简称服务程序；另一部分是运行在用户终端上的应用程序，以下简称用户或用户端。用户端程序有友好的界面，将用户同真正的文件操作隔离，既简化了操作，又确保了数据的安全性。

[b]多媒体教材库设计中的关键技术[/b]
在编程过程中发现，难点在服务程序，特别在具体编程中，如网络通信、进程协调、资源冲突等许多技术问题非常棘手，每一个问题都值得总结一下，但那只是编程技巧。 这里主要介绍设计多媒体教材库的一些关键技术，或许对同仁有些启迪。

共享与安全性

课件要实现共享有一个最简单的办法：有服务器上建立一个共享目录，让所有人都可以读写这个目录。此法的缺点很多，首先是毫无安全性可言，任何人都可能有意或无意将课件删除；共次管理无序，究竟有一些什么样的课件？这些课件如何按学科分类？播放它们需要什么样的播放环境？是否必须先安装？等等，所有这些问题都是一个未知数。好一点的方案是分别给每个教研室一个可写目录，此目录对其它任何人都是只读的。这也只能使查找容易一点面已，没有从根本上解决问题。这种方法还有一个问题就是，为了使所有用户都能通过网上临居看到共享目录，只好把所有用户都划分在一个V-LAN（虚网）中，这不仅严重影响网络安全，而且给网管增加了不少麻烦。

显然，课件的共享问题不只是简单地解决读写问题就可以的，还要让使用者对“它们是什么，如何分类分组，有何从属关系”一目了然，还要简化查询，回避包括如何读写（使用什么开发、播放环境，是否及如何安装）等一切对计算机水平要求较高的问题。在此基础上提高安全性。

课件播放的多平台支持

用不同多媒体开发平台开发的课件需要不同的播放环境，重新开发一个统一的播放环境是不现实的，我们的办法是分析各种常用的多媒体开发工具，将播放环境剥离出来，打包成一个统一的播放环境，用户在向服务器提交课件时，自动将课件的有关信息，包括开发者、课件开发平台（播放环境），教研室、科目、章节等信息记入服务器上的数据库，这些信息不由用户通过ODBC写入，而是由运行在服务器端的服务程序（以后简称服务程序）来完成。这就完全解决了数据库更新与课件更新的同步问题。用户在使用课件时，首先查找服务器上的数据库，确定文件所有位置和播放环境，再自动调用相应的播放环器进行播放。这一过程对用户透明，使用户觉得使用了统一的播放器，更加方便简单。这种方法还便于增加对新出现的播放环境的支持，以及对用编程语言编制的课件的支持。

由于使用现成的播放器，在课件播放时，只能直接对文件进行操作，也就是说，我们不能使用更底层的网络协议来读写服务器上的数据，失去了调节安全与共享的灵活性，在服务器上存放课件的目录至少有一个只读共享名。许多网管忌讳这一点。其实没有必要，由于课件一般不会成为黑客们的攻击目标，只要在共享名后加$符号，一般人看不到它，播放时无须将共享目录映射为村地资源，对知识产权的保护绝对不比网页差。

文件传输方法

在播放时，如果使用服务器上的播放环境，则通常必须将服务器上存放播放环境的只读共享映射为本地资源。为安全起见，在上载和下载课件时不能这样，那么使用什么协议呢？我们一开始使用FTP进行文件传输，整个过程对用户透明，用户只通过用户界面对课件进行操作，非常简单。但是，一个课件可能大到数百MB，用FTP上传一个课件实在太慢，因此，我们将服务器上课件所在目录给一个隐藏的可写共享名，用COPYFILE函数直接向服务器拷贝，速度明显提高。这样做的结果是留下了安全隐患，服务器上课件所在目录是不应该为所有人共享的，否则，无论是有意还是无意，都可能破坏服务器上的重要数据。

为了提高安全性，也为了实现简单，我们使用了一促改进方法。用户端每次在上传课件之前，先向运行在服务器上的服务程序发出请求，服务程序得到请求后，判断是否可以上传，如果可以，则随机产生一个共享名（如ABC$）并返回给用户（终端程序）。当课件所有文件上传完毕，用户端向服务程序发送一个结束信号，服务器取消先前建立的共享。

这种方法同样存在比较大的安全隐患，而实现起来比预想的难得多。其实，既然使用客户/服务器结构，完全可以将文件操作交给服务器端。方法是在服务器与客户程序之间建立一个管道，客户端在得到确认后，连续向管道写入数据，服务端负责将数据转移到相应的目录，此法比用COPYFILE略慢，比FTP快得多。

值得注意的是，同时上传课件的人数可能很多，从而出现数据塞阻，我院在某次课件评比的前一天就出现过这种情况，使上课不能正常进行。所以，根据我院的实际情况，服务程序最多允许15个终端同时上传课件，当满此数据时，强制中断那些上传时间1小时以上的用户(一定程度上限制课件大小)，如果设有，则返回一个“忙”信号，不让新用户上传数据。

播放时可将服务器上的共享路径作为播放器的参数，例如，播放一个宏图课件（物理.htl ）就可以用“Htool.exe Media_serverSFolder物理.htl”作为CreateProcess函数的参建立进程。因此，没有要解决的文件传输问题。

读写冲突的解决

如果每次只是上传新课件，由于新课件的信息是在课件上传完毕后才记录入数据库，用户看不到正在上传的课件，因此不会引起读写冲突。而如果用户试图重传一个课件，为了有序管理和节约服务器资源，我们总是希望将课件上传到原来课件所在目录，这就可能引起读写冲突。另外，在用户删除一个课件时也可能引起冲突。课件通常由许多文件组成，不能通过锁定文件来避免冲突。解决冲突要从读写两方面来着手：

在播放课件时，首先向服务程序发出请求，服务程序接到请求后，首先从数据库中检查课件的删除标记，若被删除或正在重传则拒绝播放，否则，将数据库中该课件的使用人数加一，返回播放参数（播放器、课件路径）。用户端根据播放参数进行播放。课件播放完成后，向服务程序发送一个结束信号，服务程序将课件使用人数减一。在提交课件时，服务程序按上图所示的方法处理：

其中，删除标记=0为正常状态，1表示删除，2表示上传中。由于用户端只能播放正常状态的课件，删除状态和重传状态的课件使用人数会很快变为0，此时，服务程序可将临时目录中的文件移到原目录，完成后将删除状态改为0。