#dominoforever

我前几天拿到了一份技术资料,题目叫《Java与Domino优劣分析》。原以为是某一位技术大咖的理论性分析论文,结果看了第一页我就发现作者其实连“技术”都不是,更别说什么大咖了。

为了避免引起论战或者产生人身攻击的嫌疑,我特意隐去文章的出处和作者。

我这篇文档分为“回答篇”和“结论篇”两个部分。

*** 内容比较长,请关心IT技术的朋友们仔细阅读。***

我必须说,拿Domino这种企业级中间件平台、文档型数据库系统和应用服务器软件与Java这种开发技术相比,其实是非常不对的。这种比较,就相当于拿着JBoss+MySQL,Tomcat+MySQL,PHP+MySQL等企业应用开发架构与Java技术对比一样,根本不在一个对比层次上。

为了让更多读者明白其中道理,我还是硬着头皮回答一下作者。

这里,我就将错就错,逐一解答之。

1. 技术层比较

1.1. 开发技术

Domino 专属于 IBM,有点类似于VB, 掌握DOMINO开发技术的人少之又少。是属于面向过程的开发语言。

JAVA属于SUN,是目前全球泛微内推广最普遍的开发语言,掌握JAVA开发技术的人在中国非常多。 属于面向对象的开发语言。

能够写出这个对比点的人,应该也做过一些Domino开发工作,但是只能说做得不够深入,没有达到“小本(小学本科)”水平。

Domino所使用的开发语言包括Java、Server Side JavaScript(服务器端JS)以及其特有的LotusScript。其中Java和LotusScript都是面向对象的开发语言。

LotusScript是Domino自有的一种脚本语言,语法类似于Basic,简便易学。在Domino开发中,我们会使用LotusScript的一些现成的类,也可以自己编写类库。Domino开发中,开发工程师可以针对某个对象,某个事件编写代码。LotusScript是一种面向对象的脚本语言。

从Domino V10开始,支持开发人员使用Node.js进行Domino应用开发。我不理解什么叫“面向过程的开发语言”,也许作者是想说“模块化开发语言”。

如果Java开发技术掌握的人非常多,那么能够使用Java技术开发Domino的人也同样多。我们欢迎Java开发人员在Domino开发中使用他们已经掌握的Java技能,编写Java Library和Java代理以及类、对象和事件的Java代码。

欢迎使用Java语言开发Domino程序

1.2. 开发工具

Domino必须用自带的安装程序安装开发端,客户端,管理端,并在开发端进行开发。

JAVA可以用各种开发工具着手开发。比如Editplus,eclipse, Myeclipse等等。

对的,因为平台的不同,开发工具的要求也不同。

Domino开发客户端Domino Designer是基于Eclipse的,你可以使用专有的Domino透视图模式进行开发,也可以使用Java透视图模式进行开发。

Domino Designer类似于MS VisualStudio.net,是一个集成化的开发环境。

不可否认Java程序员可以选择的开发工具很多,比如我就不喜欢MyEclipse,我喜欢使用NetBeans。

但是开发工具仅仅是一个编译调试环境,对于最终的用户体验没有影响。

基于Eclipse的Domino Designer

使用Java透视图模式

在Java透视图中开发Java代码

1.3. 接口

Domino接口大部分是IBM公司自己的接口,基本很少有第三方软件提供Domino接口,即使有,接口关联也非常不规范。

JAVA接口非常多,各接口之间基本按规范协作,JDK本身提供很多类,也可以在网上找到很多JAVA开发的类或函数。

第三方软件完全可以不用专门给Domino提供接口,它们只要提供Java SDK,C SDK,COM+组件等等就可以了。

凡是Java语言可以使用的第三方软件的接口,Domino均可以使用,谁让Domino本身也支持Java呢。所以,从接口上看,Domino支持的接口种类和Java语言是一样的——这点是必须澄清的。

比如Java语言可以使用SAP Jco去访问SAP R/3,Domino就用Java语言调用SAP Jco去访问SAP R/3就好了。

对于应用集成中的各种技术能力,不论是OAuth、SSO、Web Service还是REST API等等 ……,Domino均可以使用。

Domino里面可以直接使用自己编写的Java类库

1.4. 对关系数据库的支持

Domino由于本身就是文档数据库,所以对关系数据库支持很差,如果有集成,大部分数据采用JDBC方式创送。而且从结构上分析,不可能将所有数据全部写入关系数据库,DOMINO本身至少会存放80%的数据,关于日志的部分可以写入到关系数据库。

JAVA支持市面上的大部分关系数据库,ORACLE,SQL,MYSQL,DB2等等。对中间件的支持也很多。所有数据均可以写入关系数据库。

“Domino由于本身就是文档数据库,所以对关系数据库支持很差……”,这句话在技术原理上就说不通啊。这句话的语法结构就是:由于我本身是亓锋(男),所以我就不能和女人谈恋爱?

至于要不要把数据写入关系数据库,这取决于应用架构设计,想存就存呗,不想存就不存呗。我们当然可以在做应用架构设计的时候把数据存储设计成全部写入关系数据库。这个和使用什么开发语言和技术没有关系。

做一个Java应用,我也可以设计成把数据全部写入文本文件里面而不存入关系数据库。

如果真要从自身的数据存储能力来对比,熟悉Java体系和Domino体系的人,应该会这样对比:

Domino代码+Domino文档数据库(就是Domino自身)

如果这样对比,作者还敢对比数据操作性能吗?

利用Java技术,Domino开发人员(其实就是Java开发人员)也能自己做关系数据库集成

Domino本身可以支持关系数据库,实现数据写入关系数据库

一个强大的Domino Web应用架构——支持关系数据库的架构设计

Domino也可以做出强大的系统架构设计

1.5. 开发语言可学习性

学习Domino最好的方法就是查看安装客户端所带的帮助系统,但由于Domino开发技术掌握人员很少,且函数较少,可供学习的书籍也较少,所以培养一个好的Domino开发工程师需要2-3年。

学习JAVA最好的方法是参加专门的JAVA培训班或看书籍,目前国内有很多的JAVA培训班,比如北大青鸟等等,关于书籍方面JAVA有很多,比如:JAVA编程思想,或张孝祥编写的几种JAVA学习教材等等。所以培养一个好的JAVA开发工程师需要0.5年-1年。

培养一个好的Domino开发工程师的时间,与培养一个好的Java开发工程师的时间是一样的。随着开发能力的逐渐成熟,我们现在培养一个Domino开发工程师的时间已经缩短为3个月,而且仅需要中专同等学力。

但是,如果要想成为大神级的开发者,Domino开发工程师除了需要掌握Java和LotusScript,还要掌握各种通讯协议原理,各种企业级软件的架构知识。

作者可能一厢情愿地认为Domino只能使用LotusScript语言,其实我们也会让Java程序员开发Java代码。

除了我们不用JSP,而是使用XPage这种JSF技术之外,其它的开发方式和技术难度与Java应用开发是一样的。

从Domino R9开始,我们摒弃了传统的一些Java开发架构特性,采用OSGi等更加便于部署和维护的Java技术架构了。

2. 维护层比较

2.1. 针对OA的维护

Domino维护底层需要安装Domino自带的管理端,客户端和开发段,并安装中文语言包,安装过程比较复杂,维护界面也不人性化,没有专业的培训想做到。

Java开发的OA直接可以在B/S结构的界面上进行维护,并且可以分权管理维护,部门的人可以维护部门的人员,界面等。

这段技术描述有点问题。我不知道作者是想说“Domino平台维护难”还是“基于Domino的OA应用维护难”。

我就解答一下两个疑惑点:

关于“Domino平台维护难”的问题——Domino维护包括应用服务器维护、数据库服务器维护和应用维护三个层次,这个和Java平台(例如JBoss,Glassfish、Tomcat、Resin、Jetty)的维护不一样,因为Domino本身就是一个集成化的中间件架构。Domino提供了图形化的维护界面和客户端进行上述三个层次的维护。

Domino Administrator客户端是一个集成维护环境

关于“基于Domino的OA应用”维护难的问题——如果作者认为基于Java技术的OA应用维护简单的话,那么Domino OA应用也可以“照搬”Java OA的维护方式。Java OA怎么维护,Domino OA就怎么维护。这样就不用对比了吧?

Domino OA中的“个人(员工)”视图

Domino OA中的“组织树”视图

2.2. 数据备份机制

DOMINO备份机制必须采用第三方备份,由于Domino所有数据均存放在服务器本地管理端文件夹里,所以必须用第三方备份机制定期备份。

JAVA由于本身是一种开发语言,数据全部存储到关系数据库,所以备份机制很强大,可以用关系数据库本身的备份机制,比如ORACLE的异地备份等等。

作者可能真的不是技术大咖,所以把数据备份说的如此纠结。

数据备份的手段很多,常见的数据备份手段是“文件级别备份”、“专有插件备份”、“操作系统级别备份”和“存储级别备份”几种。Domino的数据备份方式可以采用上述四种方式,不一定必须采用“专有插件备份”的方式。

此外,Domino还提供了一种应用级别的备份方式:“群集备份”,可以实现多台服务器之间的实时数据同步,每台服务器的数据是一致的。

2.3. 数据安全方面

以前老的C/S架构的Domino还是很安全的,每个客户端都有一个唯一的ID,但C/S架构已经被淘汰,B/S架构的Domino体系安全性一般,在IE里面就可以通过地址(后缀名.nsf)来访问数据库。而且用户超级管理员可以查看所有流程,对于企业管理来言,存在很大的安全隐患。

JAVA体系可以采用动态密码卡,USB密码卡等方式保存密码,并且隐藏IE地址和右键属性,用户无法得知页面的实际地址。对于超级管理员来说,只能做到系统维护级,对于应用级的数据比如流程,超级管理员也无权查看。

我没有读懂作者是在对比什么。我来说说数据安全方面的对比。从数据安全方面,可能Domino或者Domino+关系数据库的架构方式比Java应用服务器+关系数据库的架构方式更加安全一些。我不就不谈Domino的C/S架构的安全性了,毕竟作者也认可“还是很安全的”。

1、IE地址栏里面输入URL来访问Domimo数据库?这个可能就不对了。用户真正访问的是Domino应用,而不是存储的数据本身。我可以做一个不存储任何数据的Domino应用数据库,所有数据在关系数据库中。URL仅仅是表明用户所访问的资源在Web服务器上的位置,和数据在哪里存储没有关系。

2、用户超级管理员可以查看所有流程?这是必须的吧。Java OA里面有没有超级用户可以查看所有流程?当然要有!这个取决于OA架构设计,而不是用什么开发语言和技术。

3、屏蔽IE地址和右键 , 这个本身是JavaScript的功劳吧,和Domino与Java有什么关系?

4、对于应用级别的数据,Java平台+关系数据库的方式反而最危险。请问作者,作为后台关系数据库的超级DBA(例如MySQL的root用户),我能不能SELECT所有数据库的所有表的数据?我是不是有可能看到关系数据库中存储的工资表的数据?如果连root都不能读取,请问你的Java代码用什么数据库用户或角色写入和读取的?Domino自带的Notes文档数据库可以把安全性做到一条数据记录上,即使你是超级管理员,只要你不在这条数据的读者权限里,即使你创建了这条数据,一旦写入Notes数据库我就可以让你看不到这条数据。

地址栏虽然是“xxxxxxxx.nsf”格式,但是查询的数据却在MS SQLServer中

3. 应用层比较(OA)

3.1. 表单

由于体系限制,Domino架构的表单如果客户想修改,大部分表单需要二次开发,无法真正的实现表单自定义功能,用户往往存在需要改变现有表单样式和操作习惯的情况。而且权限无法控制到节点和字段的关系。

JAVA体系对实现表单自定义功能很强大,用户可以自己根据实际需要制作表单,基本可以实现与现有表单样式一致,无需改变现有操作习惯。权限可以控制节点与字段的关系。

作者这么写的目的可能在吹嘘他们OA产品中的“表单自定义”功能。因为在开源Java开发工具中很少有提供“OA表单自定义”这种组件的,所以很多OA产品开发商自行研发了基于Web浏览器的表单自定义功能。

对于自定义用户表单,我觉得最好的开发技术反而是.Net,因为MS VisualStuio.net提供了非常强大的WinForm / WebForm 开发组件。

我来解答一下作者的疑惑:

1、如果需要生成一个“请假单”,无论使用Domino Designer还是作者提及的“表单设计器”,效果是一样的。但是以某些开发商的开发水平,他们绝对设计不出类似于MS VisualStuio.net那样的表单设计器来,而Domino Designer却可以。

Domino Designer自带的表单设计器,类似于VS.net的表单设计器,所见即所得

2、对于作者所说的权限和节点的权限控制,Domino也可以设计出来。在不同的审批节点上,用户所看到的表单格式和内容可以不一样。

3、制作表单的工作,使用的工具不一样,但是呈献给最终用户的UI可以是一样的,开发难度在于开发人员的技术水平。以“小学本科学历”来做一个复杂的流程表单,作者所说的“表单设计器”也没法做到。

3.2. 流程

由于Domino流程节点必须事先用域定义好,所以Domino流程节点有数量显示,大于一定数量(一般都少于40)个节点的流程就无法实现。

JAVA对节点没有限制,可以实现很复杂的流程。

Domino流程安全性较差,管理员帐号可以查看全部流程。

JAVA对权限控制较高,管理员帐号只能做到性能维护。

Domino流程配置起来很复杂,不同的流程需要到不同的模块去配置。

JAVA流程只需要在一个地方配置就可以。

由于平台限制,Domino流程 从 流程图中无法看到流程逆推,只能看到流程由上到下,无法看到特定节点有哪些流程出口,无法看到特点节点可以退回流程到哪个人。

JAVA很强大的图形显示,可以从流程图中看到某个节点有哪些出口,可以流出到哪里。

JAVA对技术要求不高,开发技术,接口等都为标准。

先说说图形化的流程设计吧。Domino也能做到。流程节点有数量限制?管理员可以查看全部流程?流程配置复杂?流程只能看到由上到下?我真的不知道作者是怎么认识“流程可视化工具”这个概念的。给大家上一张图,看看Domino是不是也能做到。

Domino自带的Workflow Architect,图形化流程设计工具

流程运行时的动态图示,展示了申请单的走向

我们给客户的商务保证是:“用Dominol流程引擎做不出来的流程,实行双倍退款”。作者敢不敢站出来,做一个我们已经实现的业务流程?

3.3. 页面显示

Domino主页风格比较死板,每类内容只能最多显示一条图片新闻,不能显示FLASH等信息。

JAVA支持多图片,FLASH,RSS等动态元素显示,让主页更有生气。

Domino可变换界面风格有限,只有几种颜色或风格可选。

JAVA支持自定义界面风格,只要有图片就可以配制显示风格等显示元素。比如上下显示,左右显示等等,包括按钮颜色,背景颜色都可更换。

Domino图片(LOGO,BANNER)等必须经过专业技术开发才能更换

JAVA只要公司自己有图片就可以随时更换LOGO与BANNER或登录图片。

作者可能想说一下自己的Java OA比Domino OA在页面显示上更有优势。如果作者看到的是“小本(小学本科)水平”的Domino OA,那么真的是很遗憾,作者没有见过大神级的Domino OA用户体验设计。

给大家看一看几个小模块的UI设计案例。

完全自主可控的Domino Web应用的用户体验设计——视频中心(模仿的是2015年的优酷的UI风格)

完全图形化的系统日志分析模块的展示——各种图表的数据展示

演示视频地址:

1、持续创新,激活Domino的无限潜力

==.html?spm=a2h0k..soresults.dtitle

2、Dominno的创新与Domino的用户体验

因为公众号的限制,请选择地址文本,然后在浏览器中访问。

如果你不能够深入了解Domino技术和Java技术,并且既做过Domino高级开发又做过Java高级开发,那么就根本不能客观地的对两种技术进行对比。

1、从技术架构方面来看,应该是两种应用架构体系的对比:

Domino应用架构:Domino应用服务器+Notes文本数据库+关系数据库

Java应用架构:J2EE服务器+NoSQL数据库+关系数据库

2、从开发技术本身进行对比:

Domino开发可以使用的开发语言是:Java语言,服务器端JS和LotusScript

Java开发:Java语言

Domino支持的常见的Java开发技术: Servlet , JSF , OSGi等

Java支持的常见的开发技术:Servlet,JSP等

Domino支持的嵌入的第三方开发技术: COM+,C++ ,JNI等

Java支持的嵌入的第三方开发技术: JNI等

我必须指出甚至连很多Domino技术人员也极容易误解的一些技术论证:

Domino自身就是Java技术得到广泛应用的一个最好例证!

Domino技术与Java技术并不是对立的、竞争的,而是“Domino技术中包括了Java技术”。

我们所谈及的Domino技术,从狭义来理解就是应用服务器技术、Notes文档数据库技术、支持Java与LotusScript等语言的编程技术、企业协作架构技术等等。

Java技术极大地扩展了Domino平台在企业级应用开发上的技术能力,是Domino技术体系不可分割的一部分!

3、从实施效果上看,二者并没有什么区别。对于根本不懂开发技术的最终用户来说,二者做出的应用可以完全没有任何差别。

4、从技术使用范围看,Java开发人员的数量是巨大的,而单纯做Domino开发的技术人员确实比较少。而Domino本身对Java的支持,确保了在开发Domino应用的时候,完全可以借助Java工程师来完成。

5、对于Domino客户来说,那些积极使用新架构、新技术的

曾经有一个客户和我说,我们打算采用Java技术。我当时就说:太对了!我们就是Java阵营的技术,在我们的体系架构中,Java是一个非常重要的架构。

可以说,作为从事Domino技术工作的人来说,他们非常了解Java技术,而单纯做Java技术的人却甚少了解Domino。之所以有人会产生误解甚至是偏见,主要的原因在于不了解,也不排除别有用心的人在混淆视听。

借一句老话——“理解万岁”!不论是什么技术,什么语言,最终都是面向客户,只要能做出客户满意的应用来,就是好的技术。技术没有好坏之分,只有是否适合,没有一种技术各个方面都强于另一种技术。

我等技术人员,应该站在客观、全面的角度去分析问题,而不要做欺骗客户和市场的事情。

提前祝大家新年快乐!欢迎进入2019年!