各种技术架构OA系统比较文档格式.docx

上传人:b****6 文档编号:17494394 上传时间:2022-12-06 格式:DOCX 页数:8 大小:25.28KB
下载 相关 举报
各种技术架构OA系统比较文档格式.docx_第1页
第1页 / 共8页
各种技术架构OA系统比较文档格式.docx_第2页
第2页 / 共8页
各种技术架构OA系统比较文档格式.docx_第3页
第3页 / 共8页
各种技术架构OA系统比较文档格式.docx_第4页
第4页 / 共8页
各种技术架构OA系统比较文档格式.docx_第5页
第5页 / 共8页
点击查看更多>>
下载资源
资源描述

各种技术架构OA系统比较文档格式.docx

《各种技术架构OA系统比较文档格式.docx》由会员分享,可在线阅读,更多相关《各种技术架构OA系统比较文档格式.docx(8页珍藏版)》请在冰豆网上搜索。

各种技术架构OA系统比较文档格式.docx

上有所欠缺。

与J2EE的技术对比表格如下:

比较内容

J2EE

DOMINO/louts

易用性

***

扩展能力

*

多平台支持

****

多语言支持

**

可靠性

性能

可管理性

**

重用性

负载平衡

开放标准

*****

在互联网普及之前,LotusNotes是在机构内外共享信息最为可行的方法。

LotusNotes被认为是满足所有群组软件需求的完美解决方案。

这些需求包括信息交流、文件的管理、共享及复制、数据库、用户界面、网络服务商、应用发展、传真、时序安排和日历功能等等。

这是一个很有雄心的目标,但为了实现这一目标,Notes不可避免地产生了一些严重的技术和结构缺陷。

1.从结构上说,LotusNotes违背了软件业发展的基本原则,例如模的设计。

LotusNotes把包括信息、数据库、日历、网络服务商安排、复制等等所有的东西都压缩到一个空间里。

2.LotusNotes的安装十分复杂,因为它需要完成很多事。

3.因为它的复杂性,LotusNotes的应用开发十分困难且花费巨大。

4.LotusNotes处理速度很慢因为它有很多层的界面。

5.同样由于它的复杂性,LotusNotes限制了第三方去创造新的应用的能力。

尽管Lotus有很多商业伙伴,但是大多数是系统集成和架构的顾问。

很多独立软件开发商的所开发的最好应用无法架构于Notes平台。

6.正是由于上述这些原因,导致了LotusNotes实际上只能解决所有的表面问题,而对任何事都无法彻底的解决,这就是限制Notes发展和它遇到有竞争力的威胁时会显得很脆弱的根本原因。

2、基于Microsoft平台的OA系统

(1)ASP(ASP.Net)+MSSQLServer模式

这是在Microsoft平台上应用较为广泛的OA开发模式,采用WindowsNT/2000/2003作为操作系统。

MSSQLServer数据库采用ASP或ASP+作为开发语言,提供内容存储,IIS提供Web服务。

采用这种模式开发的OA系统简单易用,采用B/S模式,客户端实现零维护,只需要浏览器(IE)就可以访问OA系统,开发速度快、易于维护等特点。

但该模式的运行只局限于Windows2003/2000操作系统,而不适用于Unix/Linux等其他操作系统;

其系统安全性相比另外两种平台较低。

适用于规模较小,需求简单,投资少的中小企业。

(2)ASP(ASP.Net)+MSSQLServer+Exchange模式

采用这一模式开发的OA系统与ASP(ASP.Net)+MSSQLServer模式基本相同,两者主要区别在于该模式增加了Exchange,可作为企业内部E-mail服务器,并利用Exchange作为OA中文档的传递工具。

MicrosoftExchange延续了Notes的道路,同样也沿续了LotusNotes的所有缺点。

MicrosoftExchange早已有了完美的信息传输能力,这是它的优势也是为什么它被广泛采用的主要原因。

然而,Microsoft现在正在加强它的文件夹,脚本功能和扩大它的网络能力,而这些和Notes对于互联网流行的反应而采取的措施是非常相似的。

当MicrosoftExchange继续采取强化功能和扩大应用面的方式和Notes竞争时,早已被LotusNotes的缺点和局限性拖进了一条死胡同。

在Notes和Exchange想要继续主导桌面技术的努力中,还犯了另两个错误:

.两种软件都是在网络革命以前开发和发展起来的。

当它们重新被定位成网络平台时,结构上的设计缺陷使它们无法充分利用网络的特性。

例如:

如果网络成为了文件的最终存储地,那么为什么一个企业还要使用Exchange的文件夹来发布?

.两家公司都未完全认识到群组软件和工作流应用都需具备高度可扩展(柔)性来适应现代商业组织复杂性的全方位应用。

我们没有理由相信会在一个压缩的软件包中获得重大的成功。

比较现实的用来表达工作流和群体组件的方式是结合那些具有特殊功能的最好的应用并且将它们互相整合。

.NET

现在有些企业正在Notes和Exchange平台上开发一些具有工作流功能的产品。

表面上,从使用者的角度看来,这个想法很吸引人,每个用户有一个适合所有类型任务的通用内核,因此,所有的任务都能工作在群件系统的范围内。

然而,如果仔细分析一下工作流自动化的要求和群件系统的要求就会发现:

群件系统和工作流自动化相对照,有很多的局限性。

群件是信息传送的最优化。

但它们并不是工作流自动化的最优化。

实际上,对电子邮件来说很好的群件系统的一些技术因素,对于工作流自动化来说就是很大的局限性。

1.对于商业流程,电子邮件不是一种强大的传输工具

群件系统提供了能够被用作内部电子邮箱的文件夹,这些文件夹能够接受工作流相关的表格,工作流信息和普通的电子邮件信息是同等对待的。

电子邮件对于发送信息来说功能强大,但是,对于商业流程信息来说,它不是一个强有力的平台。

我们都很熟悉网关,也知道当邮件的附件通过网关时,它们就会丢失。

如果群件系统的邮件被用来引导工作流信息,你很有可能会遇到这一问题。

很多情况下,附件的丢失和流程的停止没有什么区别。

当重要流程中相关信息丢失时,将带来严重的后果。

强有力的工作流系统不能依靠电子邮件来引导商业流程信息。

相反的,必须使用可靠的存储,比方说数据库和安全的通信协议,类似TCP/IP。

2.群件系统没有提供从队列中提取任务的方法

队列是工作流自动化中一个非常重要的概念。

它不是把任务安排给某一个人或是某一个工作功能,而是送到一个队列中去。

任何能完成任务的单元都可以从队列中提取任务,并完成它。

群件系统无法提供这样的外部队列。

某些队列的功能够通过公共文件夹的方式来实现,即使是这些也需要用户非常细致的工作和管理。

3.群件系统无法提供状态监控功能

对流程自动化中突发事件的的监控是工作流自动化中一个最重要的功能,也能节省很多的时间。

任何可行的工作流自动化解决方案必须要提供一种状态监控方案。

群件系统没有提供这样的功能。

以群件系统为基础的应用依靠"

周边间接工作"

,象发送电子邮件到每个用户来更新状态。

这就不必要的增加了网络流量。

因为即使那些并不需要了解状态的用户也会在状态改变时,得到一次状态的刷新。

4.群件系统没有提供突发事件中断的功能

在流程中出现突发错误的时候,及时中断工作流流程是十分重要的。

5.群件系统没有流程的逆向传递

在实际工作中,工作流并不总是由前往后的顺序传递。

最简单的例子是一份买卖合同总会返还给卖方手中。

群件系统并没有提供任何使工作流逆向传递的方式,如果突发事件发生而要求用户逆向传递,用户必须找到是谁发送了这个任务,然后给他发电子邮件。

一旦发生,工作流就不再自动传递下去了。

6.群件系统不是理想的文件存储方式

几乎每个工作流程序都要具有附带和工作一起传递的支持文件的功能,这些文件的保存是很重要的,因为这样才能使所有流程参与者都能很容易的理解。

群件系统确实提供了能用来保存文件的文件夹。

但是,群件系统的文件夹不是一些大型企业和组织的首选文件存储地。

相反的,最流行的文件紧急存储地是互联网,它被用来存储文件和对文件进行分类。

其次是使用SQL数据库,象MicrosoftSQL服务器的文件管理系统。

如果企业能选择,它们宁愿放到互联网上,而不愿放到群件系统的文件夹里,因为互联网更加开放、费用更低、更容易连接。

当网络继续完善它的功能,它会更加吸引我们在网上存储和分享各类文件。

相应的,企业也会不断把文件放到互联网上,使用SQL服务器或其他的SQL数据库来存储文件。

因此,如果文件对流程来说是很重要的,那么一个完美的工作流解决方案必须具备使文件和文档紧密结合的能力。

互联网和SQL服务器在这方面的功能要比群件系统强的多。

7.群件系统不是一个企业数据库

一个工作流解决方案必须能很容易的和数据库连接。

群件系统不是一个数据库。

很多企业使用SQL或是Oracle作为它们的数据库,特别是当要处理一些重要的工作流程序时。

群件系统在工组流程序和数据库之间增加了另一个层次,反而使工作流程序和数据库的连接变得更加困难。

既然群件系统无法提供和客户相联系的数据库,那么以群件系统为基础的工作流解决方案的一个最大的局限性就是它们需要ODBC和每个客户都有联系。

从管理和维护的角度看,这并不实际。

8.群件系统不是一个处理器

稍作分析,我们不难得出这样的结论:

一个工作流软件就是一个数据处理器。

工作流包括运用规则、角色和路由(Rule\Role\Route)来决定工作流中的下一个步骤。

这种信息都保留在数据库中,工作流引擎的主要任务就是不断地完善和更新数据库。

当出现了很多的工作流事件时,相应的数据库也会成倍的增加,而工作流引擎也就成?

quot;

处理器"

群件系统不是一个处理器,也无法提供使处理更加便利的措施。

9.群件系统没有提供群体管理功能

一个工作流解决方案必须具有管理大量用户同时工作的方法。

比如说当某一个用户由于紧急情况而缺席时,必须安排其他用户代理他的工作。

如果一个组织有很多人,那么从中心开始的辐射式管理并不合适,唯一可行的方法是使每个人都管理他的下一级的工作。

这也是实际商业活动中的工作管理方法。

群件系统是一个信息交互平台,它无法进行工作量管理,当然无法在组织中进行工作分配。

10.群件系统不可能实现所有功能

群件系统具有的功能包括信息传递、目录服务、文件夹、脚本、日历、时序安排、合作数据对象、传真和复制等。

从某种角度理解,把所有的东西都放到一个软件包中去也许是群件系统犯的错误。

这种做法的缺点很多:

a.程序变得复杂从而导致安装和使用的困难。

安装和使用群件系统需要花费很多的精力和时间。

b.产品变得难以开发,导致长时间的更新和升级周期。

c.把所有的东西都压到一个软件包的做法违背了软件开发的基本原则--模块化原则。

11.群件系统的客户不是Microsoft的主要客户

群件系统的客户不是Microsoft的主要客户。

相反,Microsoft的主要客户来自于IE。

IE是Windows的附带网络浏览器,也是Microsoft操作系统产品的一部分。

它代替了WindowsExplore成为浏览互联网、局域网和桌面的主要工具。

Microsoft正投入巨大的资金用于提高、升级和增加IE的功能和安全因素。

工作流自动化目标是到达组织的外部和内部每一个相关桌面平台。

因此,工作流自动化必然是到处存在的。

Notes和Exchange已经应用了10年了,在这段时间里,它们已经成为市场上主要的群组解决方案。

而随着科技的发展,以群件系统为基础的单一工作流自动化解决方案今天看来已不值一提。

3、基于JSP/Java平台的OA系统

基于JSP/Java平台开发的OA系统,其原理与基于Microsoft平台的OA系统类似,主要区别在于采用了JSP/Java开发语言,因此可实现跨操作系统平台,可采用WindowsNT/2000、Unix、Linux等多种操作系统,运行于多种硬件服务器,且该系统简单易用--采用B/S模式,客户端实现零维护,只需要浏览器(IE)就可以访问OA系统。

采用J2EE架构搭建的OA系统,在安全性方面可以得到保证。

此外,基于J2EE架构搭建的OA系统,在稳定性、扩展性方面具有明显优势,可以保证超多用户的并发使用并方便与其他系统进行集成。

然而,这类系统的开发和维护成本相对较高。

目前,特别是近年,我国许多政府采购、大中型企业,采用JSP/Java平台的较多,也成了一种趋势。

整体上看,基于JSP/Java平台开发的OA系统比较适合政府、大中型企业和工作流应用比较多的企业选用。

三种主流技术平台的对比:

DOMINO

系统平台特点

通用开放的应用平台

专业应用平台

可支持的运行平台

Windows系列

任何平台

类似实体bean,消息bean

没有

与第三方集成能力

自己编写API

JAC标准

厂商支持

广泛

行业应用及案例

经验系统安全性、高可靠性

Web应用能力

后台数据库的访问能力

应用程序通过ODBC/JDBC高效访问SQLServer、Oracle、DB2等关系型数据库系统

仅集成IBMDB2关系型数据库,其他关系型数据库结合能力弱

二、选择C/S还是B/S架构

现阶段C/S比较成熟,在应用中可能要好用一些,速度方面也要快。

但维护起来比较麻烦,需要安装客户端系统。

其固有的局限性,不适合大型集团公司,尤其是地理位置分散的企业选用。

B/S应该说正处于起步阶段,发展的速度很快,很多问题都在一定程度上得到了解决,由于用户需求越来越复杂多变,所以出现很多问题有待于解决。

但管理起来很方便,应该说是今后发展的主流方向。

三、选择项目式开发还是产品化OA

目前办公自动化市场上存在着项目式开发和产品化的OA等几种形式。

项目式开发是完全根据企业目前需要由软件企业量身定做开发。

“罗马不是一天就可以建成的”,软件产品也是一样,不可能一蹴而就。

而且就是今天是适应了你的需求,明天需求改变了呢?

选择项目开发对满足目前需要可能比较有用,但是对后期的维护和升级改造将带来很大的麻烦,成本也非常高。

产品化的OA有标准OA产品和通用产品加自定义平台两种。

标准化产品由于不能定制,或定制功能不强,可能无法实现个性需要,不能适应组织的长远发展需要。

通用OA产品研发时所依据的模型,是从成千上万、各行各业的企业管理案例,以及先进的企业管理理论中抽象出来的通用模型。

产品在实际应用过程中又不断加以改进,具备成熟、稳定的性能。

在保持通用性的基础上,具有国内领先的自定义平台。

四、OA系统技术选型的指导原则

1、最关键的是OA能帮你做什么

对于企业来说,OA系统毕竟是提高企业内部管理效率的一种"

工具"

,因此该工具具备哪些功能是企业选择OA系统时所应最为关注的因素。

2、OA采用什么技术开发

OA系统的开发技术和平台,决定了系统以后的可扩展性,也是企业需要考虑的重要因素。

3、尽量利用已有的服务器硬件及系统软件

这是充分利用企业在计算机系统的已有投资,降低信息系统总体成本(TCO)的重要原则。

4、在安全性与易用性之间找到平衡点

如果企业对于OA安全性的要求是至高无上的,那毫无疑问应选择基于Domino/Notes的OA系统(C/S)。

这就好比为了防止手机被盗,将其锁在保险柜里--固然在安全性方面达到了极高的境界,但同时丧失了手机本身应有的实用价值。

5、考虑与内部其它业务系统的结合

一般来说,企业的OA系统不会是一个完全独立的系统,而往往需要与企业内部已有的或准备将来实施的业务系统相结合。

这时,在选择OA产品时一定要重点考虑该产品的可拓展性、是否留有接口便于与其它系统快速整合。

并且,软件提供商能否承诺把其OA产品与企业的其它业务系统进行整合,也是企业选择OA产品时的重要考虑因素。

另外,以我们的经验来看,如果企业存在将OA系统与其它业务系统进行整合的需求,Domino/Notes平台往往不是最佳的选择。

因为企业的业务系统一般都基于关系数据库,查询和统计是其主要应用,而这恰恰是Domino/Notes弱项之一。

5、要充分重视OA系统的后期维护

计算机应用软件系统的客观规律是:

维护期的成本约占整个软件生命周期的30%。

因此企业在实施OA系统时一定要注意后期维护,重点要把握以下两个方面:

(1)要有合适的内部人员对OA系统进行后期维护,并且在最初的产品技术选型时就要考虑到这一点。

(2)要求软件提供商提供相应的售后服务承诺,并将其写入合同,以便在必要情况下要求软件提供商协助解决系统问题。

五、选型的标准

■软件系统稳定可靠

■技术架构设计先进易于扩展

■可以根据需求进行定制功能

■品质上乘

■实施企业具备强大的技术实力和丰富的实施经验

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 高中教育

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1