各种关键技术架构OA系统比较.docx

各种关键技术架构OA系统比较.docx

《各种关键技术架构OA系统比较.docx》由会员分享，可在线阅读，更多相关《各种关键技术架构OA系统比较.docx（8页珍藏版）》请在冰豆网上搜索。

各种关键技术架构OA系统比较

各种技术架构OA系统比较

一、OA系统主流平台分析

当前OA系统重要有基于如下三种技术平台，分别代表了三种主流OA技术发展趋势：

1、基于LotusDomino/Notes平台OA系统

Domino/Notes是一种集文档数据库、邮件系统、动态Web信息发布、可视化集成开发环境于一体基本平台，适合解决办公协作流程中产生非构造化文档信息，并可运用灵活邮件机制在公司内部传递文档。

长处：

1）系统安全性高（这是在政府领域广泛应用重要因素）；支持各种操作系统平台；

2）系统开发速度快。

其局限性之处有：

1）对关系型数据查询记录功能相对较弱；

2）系统平台软件较贵；

3）对系统维护人员规定较高；

4）基于C/S构造，每客户端都需要安装软件。

虽也可基于B/S构造应用，但那样就必然牺牲Domino/Notes最为突出基于"交叉验证"高安全性。

5）易用性差。

如果公司对于OA安全性规定是至高无上，那毫无疑问应选取基于Domino/NotesOA系统。

然而在实际应用中，对于"安全性"追求并不是越高越好。

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

基于Domino/NotesOA系统在公司中应用没有政府部门普及，政府部门中基于Domino/NotesOA系统运用率也始终不是太高，其重要因素是系统在"易用性"上有所欠缺。

与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//作为操作系统。

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

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

但该模式运营只局限于Windows/操作系统，而不合用于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文献夹来发布？

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

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

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

与J2EE技术对比表格如下：

比较内容

J2EE

.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重要客户来自