| |
Java FTP客户端库的选择 |
|
时间: 2006-06-20 来自：blog |
 |
|
变动管理
在我们项目中的某些点上，特别是在项目快结束彻底测试时，很有可能我们想修改我们的库。这样一种变化影响了所有我们的调用代码：我们的类将不再编译，一些应用部分必须重新编码，以便适合不同的方法名称和新库的不同设计。
既然管理这样一个变动证明是很烦的，特别在项目快结束时，时间成为一个关键资源时我们应该将改动限制在一个个别的类中。典型的，我们应用Fa?ade模式，当FTP库当作后终端时，见图2。
 图2 Facade 模式 应用到一个FTP库中 |
应用Facade模式到FTP库上的一个好的影响是我们可以添加值到库本身上。例如，我们可以编写一个Fa?ade程序，用它下载整个远程目录到一个当地压缩文件或者一个程序上。该程序执行库中缺乏的任何基本属性。
最后，有相同签名的两个库运行时间不一定相同。因此，从一个库切换到另一个库上，也能影响我们应用程序的运行时间。这样一种影响是令人难过和不舒服的。因为发现运行时间的区别要难得多，尽管详细的测试情况可能有所帮助。
在上述标准的阐述中，我简洁的描述了几种不能解决的问题。在这个部分，我要进一步讨论并解决它们；我建议一个长期的解决方案和一个短期的解决方法。
目录列表
缺乏对LIST响应的任何权威性说明书导致了许多不同的FTP服务器的出现。这个缺乏对与FTP客户端程序员来说是最大的问题，并且它仍然是一个开放的难题。
由于问题的根本在于协议的定义，我推荐相关的权威性机构，因特网工程任务组织（IETF）,用一个新的参考文档说明书（一个RFC）定义了LIST响应结构。
过程是漫长的，同时，最灵活的解决方案是使用一个提供了可插入的格式解释器的框架的库。
文件时间标签检索
就像我刚才讨论的一样，没有方法通过FTP检索一个远程文件的最新的修改时间标签。我为传送从服务器到客户端的时间标签建议两个长期的解决方案：
1. 在LIST响应中包括精确而且完整的时间标签
2. 标准化MDTM命令和响应
对于两种方案来说，都要在通讯过程中考虑服务器的时区问题。
再次，因为问题的根本在于协议定义，我推荐IETF定义一种或者上述两种方案作为一个权威性的规范使用。
同时，最常用的短期解决方法就是使用对LIST和MDTM响应捕捉都支持的库，并且开发这两种属性的联合体。
变动管理
在上述相关部分，我推荐了Fa?ade模式在库更替过程中减少变动影响。就像我说到的，模式并不是一个万能药，因为库中行为的缺乏仍能在运行时间内影响我们整个的应用程序，它是难以控制的。
因为这个方面是一个纯粹的编码问题，我建议Sun公司出版一个标准的设计良好的API，定义精确的程序和行为。任何人包括Sun公司在内，都能执行这个程序。程序员能使用界面程序并用它们指定的执行过程支持他们。任何从一个库到另一个库的切换会对应用程序的剩余部分产生最小的冲击。Java Mail和JDBC（Java数据库连接）API是示范性的引用单元。
Java FTP API标准化项目旨在组织一个用户、开发商、和供应商的联盟，把改进请求作为一个Java规范请求引入Java社区进程中。你的支持当然对该项目有用，它的主页可在Resources中找到。
为你的需要找到最好的库
在本文中，我阐述了如何用Java编写FTP客户端代码并且列举了JDK和第三方的库的FTP客户端支持。我也展示了在计算不同的库的过程中要考虑的重要标准和库之间比较的标准。我希望决策者在面对Java FTP客户端库的选择时在本文中找到有用的提示，从而作出最好的决定。
最后，我说明了对所有FTP库普遍存在的不同的问题，并且建议了短期的解决方法以及可能被权威性机构像IETF和Sun公司采用的长期解决方案。我希望这些先导和行为有助于铸造Java FTP客户端库的未来。
|
|
|
|
|
|
|
|
