从Java要收费谈模型驱动开发

 

（一） 从Java收费说起

 

最近开发人员社区里热烈讨论的一个话题是Oracle要对Java收费的事情。Oracle在今年四月宣布，自2019年1月起，Oracle将不再提供Java SE 8更新的免费下载，如想继续获得更新，需向Oracle另外购买技术支持服务。

 

另外，针对新版Java 11，Oracle修订了用户使用协议，若想将Oracle JDK 11用于商业用途则需购买许可，这意味着免费了23年的Java再也不免费了。

 

于是大家开始讨论怎么办？有人建议转Kotlin语言，方法是在IDEA开发环境里将Java代码粘贴到Kotlin文件，可以实现Java到Kotlin的自动转换。这里不得不提一提Oracle与Google长达八年的Java官司，Oracle认为Google的Android操作系统抄袭了Java代码，要求Google赔偿26亿美金，至今此官司还没有最后尘埃落定，不过Google已经宣布Kotlin语言成为Android开发的一级编程语言。

 

也有人建议转C#语言，毕竟微软是老牌软件公司，开发工具一流，而且现在微软对开源的拥抱和支持是各大厂商之中最有力的，就在今年6月，微软斥资75亿美元收购代码托管平台GitHub。

 

 

图一：TOP 10编程语言TIOBE指数走势（2002-2018）

 

对已有的用Oracle JDK开发的Java程序怎么办呢？一种方法是将Oracle JDK换成开源的Open JDK。不过对那些需要做长期准备的公司（比如Google）来说这并不牢靠，他们一定在计划如何摆脱对Java的依赖（也就是对Oracle的依赖）。

 

（二）用新的编程语言重写应用

 

对一个使用商业软件，特别是ERP等业务软件的公司来说，底层技术实现是无关紧要的，一个使用财务软件的公司为什么要关心这个财务软件是用Java编写的还是用Kotlin编写的呢？只要这个软件能够正常运行，没有性能和操作上的问题，不妨碍业务的正常运营，能够满足业务的快速增长和不断变化的需要，这个软件就可以一直使用下去。

 

但事实是，随着时间的推移，由于软件的架构老化，软件使用的编程语言的进展缓慢，新的编程语言、设计与架构、开发方法和开发工具的出现，以及业务的快速增长，和外部商业环境的变化，等等，使得软件到了不得不重写的地步。

 

但是，重写一个大型应用是非常困难的。

 

SAP ERP是由ABAP语言编写的，ABAP是SAP自己在1980年代开发的一个编程语言，目前ABAP仍然是编写SAP ERP应用的主要语言。在2000年左右，Java和SOA兴起，SAP曾经雄心勃勃的准备把所有ABAP应用转到Java语言上来，还因此收购了几家Java公司，其中包括一家JVM公司。不过最后这个想法并没有实现，现在绝大多数ERP模块仍然是ABAP，只有非常少的模块是Java（比如PI）。

 

可见重写大型应用的难度是非常大的。

 

另外一个例子，大中型银行核心系统的程序大多是用COBOL语言编写的，这些程序运行在IBM主机系统上。随着业务需求急剧增长，银行需要逐步淘汰这种集中式的架构，转而为一种分布式的架构，即在一个x86 PC服务器集群和一个分布式的数据库上运行核心系统程序，程序语言也由COBOL转为Java。

 

 

图二：银行核心系统架构迁移

 

从上图可以看到，不仅要转换程序语言，而且要迁移整个软硬件架构，硬件平台、操作系统、数据库、以及中间件都需要迁移，这个工程是非常大的。

 

问题是，成百上千万行COBOL程序如何转换成Java程序？完全手写的效率肯定是很低的，如果采用自动转换工具，但只是简单的一行一行的翻译，得到的Java程序肯定是无法读的，代码维护性很差，Java程序员必定是避之唯恐不及。这就需要比较高级的程序转换工具，但是即使有了这样高级的程序转换工具，也要求需转换的COBOL代码本身必须是高质量的。

 

领驭软件公司提供一套可视化开发工具，可以将COBOL程序自动转换成中间语言ADML程序，ADML是由领驭软件公司设计，面向对象的、支持可视化开发的编程语言。借助图形化的开发工具，开发人员可以进行业务建模、应用设计和应用开发，并对现有程序进行维护。然后，开发人员有两个选择，他可以从ADML反向生成COBOL程序，在IBM主机上运行COBOL，或者他可以从ADML生成Java程序，在一个分布式的x86 PC服务器集群或者云环境上运行Java。

 

 

图三：COBOL程序到Java程序的转换

 

 

（三）模型驱动开发

 

事实上，ADML中间语言描述的是一套应用模型，领驭软件公司提供的可视化开发环境CBF是一个采用模型驱动开发（MDD）方法论的集成开发环境。

 

MDD的最大优势在于可以提高开发效率，经验显示，采用MDD方法的开发效率比传统开发方法的效率提升十倍以上。（相关内容请参见本公众号以前的系列文章，此处从略）

 

MDD的另一大优势在于应用本身与应用的具体实现技术的分离。

 

考虑一个业务应用，比如一个财务系统，它大致上可以分为两部分，一部分是业务应用的定义（或者叫做模型），包括业务流程定义、业务逻辑定义、数据定义，以及界面定义，这是关于应用的业务描述部分，跟技术无关，只跟业务本身相关；另一部分是业务应用的技术实现，如果是用Java语言，那么就是Java程序，如果是用C#语言，那么就是C#程序，这部分跟具体技术相关。

 

使用传统编程模式开发应用，其业务应用部分与技术实现部分紧耦合在一起，没办法分开。如下图所示：

 

 

图四：传统编程开发

 

而使用MDD开发应用，其业务应用部分与技术实现部分是互相分离的。如下图所示：

 

 

图五：可视化建模开发

 

业务应用部分与技术实现部分的分离给应用带来巨大的好处。第一，你不需要把自己局限于某一种特定的技术，比如Java，当你不再对Java感兴趣（无论什么原因），你可以选择其他的技术，比如Kotlin或者C#。

 

第二，你可以更加关注于业务本身，而不是技术实现，因为你的开发工作其实是在建模，而不是在写某种程序代码，你的开发工作在更高级别的抽象层面，你的开发效率因此大大提高，你的应用因此更加符合业务需求。

 

第三，你可以根据业务需求的变更，更加方便的修改应用，因为你只需要调整模型，然后用工具再次自动生成程序代码，你不需要钻进几百个代码文件的成百上千万行代码中寻找哪些地方需要修改。

 

需要指出的是，我们一直挂在嘴上的“应用程序”这个词，其实是两个东西，“应用”（application）和“程序”(program)。应用是属于业务的范畴，程序是属于技术的范畴，这两个东西是可以分开的，MDD的开发方法让你开发“应用”，而“程序”则由工具自动从“应用”生成。