OA协同办公软件在不同技术平台的优劣分析

OA协同办公软件在不同技术平台的优劣分析 对于办公自动化系统或是协同产品的选型而言,确定系统平台的方向是第一个应该做的工作。否则就可能使后续工作走很大的弯路。比如,如果企业要求的可以在Linux或Unix系统下支持跨平台运行的系统,但花很多精力去了解评估一个基于.NET平台的产品,则完全是在做无用功。 办公自动化软件(协同办公软件)的系统平台,目前主要有两类五种: 第一类:是早期的以群件为基础,主要是基于IBM Domino(即Lotus Notes)的和基于微软的Exchange的两种。Domino是一个从邮件系统发展起来的类似于文档数据库的产品,早期曾是OA系统的主流,随着OA应用的不断发展出现了不少基于Notes和Domino 的OA产品,功能也从原来最简单的收发文、信息共享发展到包括工作流等较全面的功能。Exchange则是完全基于微软平台的一个产品,其本质是一个邮件服务器,但有一些增强功能,也有少数公司基于它开发了一些OA产品。 第二类:是以开放平台为基础,主要是基于J2EE(Java)的、基于微软的.Net平台(严格地讲,其中部分产品是基于ASP而非.Net)、以及基于其他一些程序开发语言(如PB等)的三种。它们都是基于程序开发语言来实现的,后台采用标准的数据库如Oracle、SQL Server等,采用标准的B/S三层架构。 下面对于这两类五种平台的特点及适用范围进行一下说明: Domino:优点是有较多的基于它的成熟产品。从历史的角度,由于它本身就是一个面向基本的协同工作及信息共享的产品,所以早期的OA应用大都选择以它为基础,曾经是这 一领域主流的选择。缺点在近期则逐渐显现得较多,主要是它不是一个开放的系统,无论从数据的利用,还是与其他应用系统的协同而言,都有较大的困难,系统的灵活性受一定局限,也给新功能的二次开发带来一定的困难。另外,购买正版的Domino软件本身也是一笔较大的投资。当然,如果功能很明确,对于企业小型的业务应用,目前Domino应该说仍然是一个可选择的平台。 Exchange:它有一些Domino也具有的优点,同样有Domino的缺点。但它不象Domino 及Notes那样曾经是主流产品,现在在市场上基于它的OA产品也极少。并且它局限于只能基于Windows平台。可以说除非恰好有一个产品非常适用,否则没什么理由要由这种平台的产品。 J2EE:J2EE是当今软件开发的两大主流方向之一(另一个是.Net,但J2EE的影响力还是要比.Net大很多)。用J2EE做应用软件,包括OA协同办公系统已经是现在的主流方向。它的优点很明显,标准的数据库、开放的接口可以很好地与其他系统进行交互,也很容易可以在上面增加各种功能,具有很强的灵活性。并且,有一点是.Net不具备的,就是J2EE可以跨平台运行。 .Net:简单讲,就是除了它只能局限于微软平台一条缺点外,从应用角度看它其实与J2EE 的优缺点差不太多。不过,从专业开发人员的角度,.Net的地位似乎比J2EE要低一些,有一种用.Net开发产品显得技术能力不足的感觉。 基于其他程序开发语言:如PHP、ASP等,市场上也有少量这样的产品。其问题是非常大的,一是受所用开发语言或工具的局限,能实现的功能、灵活性等方面都会有很大困难;二是由于使用面窄,二次开发、维护等等的问题都很多。 根据这五种平台的特点,在选择OA的系统平台的我们建议如下: 1)如果是大系统,即功能多、用户量大的系统,一定要尽可能选择J2EE平台。 2)如果功能有限,与其他业务系统应用没有关联的小型OA应用,可以在J2EE、.Net的产品中以功能为核心去选择。 不过,在功能相差不大的情况下,还是建议优先考虑J2EE平台。 Domino技术架构分析与OA产品的选择 主要是它不是一个开放的系统,无论从数据的共享利用,还是与其他应用系统的协同集成而言,都有较大的困难,系统的灵活性受一定局限,也给新功能的二次开发带来一定的困难。另外,购买正版的Domino软件本身也是一笔不小的投资。用J2EE做应用软件,包括OA 系统已经是现在的主流方向。它的优点很明显,标准的数据库、开放的接口可以很好地与其他系统进行交互,也很容易可以在上面增加各种功能,具有很强的灵活性。DOMINO平台主要的问题主要集中在以下几点: 1.速度太慢。Domino 是基于文档的数据库、不具备数据快速检索功能。当数据库中文档数超过二到三万条时,几乎显得无能为力而且没有没有分页功能。Domino 使用解释性的客户响应机制,在采用Browser-Domino 结构响应Web 请求时,Server 端实时地将Domino视图转换或解释为HTML 文档传送回客户端,对于复杂视图转换时间长。在客户端Browser 上利用Java Applet 实现数据的互操作性,客户端启动Java VM就需要耗费很长时间,Java VM 启动后,还要解释运行缓慢的Java Applet,用户等时太严 重。在PIII500 PC 服务器上对1 万个文档的数据库目录列 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 就需等待1 分20 秒左右,超出一般用户的可忍受程度。如在10 M 共享网络上,10 个用户同时查询具有1 万个文档的数据库,将费时数分钟 2.综合统计分析能力太差。在办公信息系统中,实时地对公文运行状况进行分类汇总、监控是必不可少的功能。而Domino 是基于文档型数据库,如要求进行多维数据汇总,其实现过程十分复杂,效率极其低下,反应缓慢,远不如关系型数据库。这在以后企业做信息系统集成和智能辅助决策时会有瓶颈; 3.实现复杂的应用效率太低。大型的协同办公信息系统的面界一般具有众多的界面元素。如文件会签界面上至少有文件标题、正文、附件、起草人、起草时间、处室审核人、审核时间、司局审核人、签发人、签发时间、会签部门………等等数十项,在Domino 的视图上实现如此众多的界面元素十分困难,在Domino R5 版本中,对于复杂视图在Notes 中有时竟然无法正常显示而导致死机,而采用Browser 方式需将复杂视图在服务器端转换成HTML + Java Applet 传送到客户端运行,耗时太多,运行缓慢。 4.界面呆板,实现美观的界面困难。Domino 的界面主要由帧、视图、大纲等一些固定 格式 pdf格式笔记格式下载页码格式下载公文格式下载简报格式下载 组成,缺乏灵活性,样式粗糙呆板,与HTML 或应用程序界面相比过于原始化、简单化,缺乏个性和艺术性。对于要求自定义系统界面的客户来书是个痛苦的难题; 5.Domino数据共享、导入、导出受限。Domino 文档数据库不支持ACCESS, EXCELL,Fox Pro等早期通用前台数据库的共享访问,也不支持各种SQL 检索工具通过ODBC 访问,不支持SQL 语句查询,数据共享性能极差、数据批量格式化导入导出困难, 必须开发专门的ETL工具才可实现,在流行的Internet/Intranet环境下,难以满足用户端数据访问多样化的需求。 6.开发成本较高。使用Notes-Domino 构筑办公平台在成本上与基于 .NET-SQL、J2EE架构或其他当前通用解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 相比,其成本不在同一数量级,有可能高出数倍。 7.硬件要求高,带宽需求大。Domino 是一种传统的Clent/Server平台,尽管为适应Internet环境进行了B/S升级更新,但其核心技术依然源于过时的Clent/Server方式。在多用户的Client/Server环境下,采用Notes-Domino 解决方案,对服务器的性能要求大大高于ASP-SQL 等先进的Browser/Server 解决方案,前者对网络带宽的要求同样也很高。 8.可扩展性差。Domino 与其他程序的用户接口实现困难,致使程序扩展性能差,不利于与各类输入输出设备(如扫描仪、IC密码机、打印机等)实现无缝链结,以及与其他程序有机整合,难以做到办公信息系统的文档一体化。(VB、C API、C++、Java)、对已经实施各种业务系统的集团企业(尤其ERP系统的)来说,采用Domino平台会在今后给企业带来巨大的系统集成和数据共享改造开发成本。为今后消除信息孤岛带来障碍; 9.不符合中国企业和政府有关办公办会的实情。我国大部分企业和各级政府机关政务办公信息系统不适合使用基于文档型的数据库平台。Domino 适用于小型简单办公系统,一般为某人起草一个文件、传给某主管上司批示、办结这一简单流程,特别适用于一般简捷办公模式,办公文档也没有太多的字段,一般情况下仅有文件标题、正文,起草人,批示人等十个左右的界面元素。而我国企业协同办公系统和政务办公系统中的文档,每一个正文往往附带数十个附加字段,如一个普通的集团会签文件就有文件标题、正文、附件、起草人、