MENDIX白皮书

 

MENDIX白皮书

 

 

敏捷企业建模:

从软件工程到业务工程

 

 

 

 

 

 

 

 

 

 

作者：罗尔德Kruit（Mendix联合创始人兼首席技术官），德里克鲁斯（Mendix联合创始人兼首席执行官）

受众：业务经理，首席信息官的，业务分析，解决方案架构师，信息经理，开发经理，开发人员。

 

 

1      简介

1.1     应用发展现状

在写这篇文章的时候，我们正处于经济衰退之中。组织面临着削减预算和增加了对运营效率的压力。因此它已成为越来越重要的是减少整体金融风险和成本优化和重点项目与业务的影响，并立即返回投资。
因为这意味着对公司的影响的方式简化了业务流程，它是这样做的目的
白皮书讨论了我们应该自动化业务流程，建立新的业务的影响、解决方案和软件投资估价。我们认为这可能是时机改变一些规则，创造新方法和阐明业务自动化现状的不同光辉。

应用程序开发的主要研究结果和建议（Gartner 公司2009 年3 月）：

l  软件开发仍然困难并一直存在着需求

l  在项目的早期阶段，对业务需求转换成实实在在的设计师导致项目失败的一个主要来源

l  开发经理和业务分析人员应该寻找新的方法，更迅速的建立有吸引力的应用

l  开发经理和业务分析人员应制定新的方法、使用更新的工具和复杂的流程部署应用程序

l  IT 组织应着眼于采用模型成功描述业务需求和技术设计

1.2              传闻..

克里斯，首席运营官，全球货运代理：

“我需要降低项目的风险，优化经营成本和更快的投资回报率”

凯文，销售经理，公用事业公司：

“我需要能够轻松应对市场变化，而不是受限于我们后台办公系统的约束”

纳塔利，客户，健康保险运营商：

“我要更好的服务，更深入地了解和24 *7 在线访问所有的数据！”

黛安，客户服务主管，电信运营商：

“我想方便地访问到正确的客户数据，不管底层的系统。”

约翰，工艺分析师，零售银行：

“我希望我的流程图处于领先地位。我需要能够保证，我的图代表真正实施的内容。”

马克，IT 专家，再保险公司：

“我需要有更加灵活的工具包，这样我就可以更有效地集成门户应用。”

Vivek ，高级IT 架构师，当地政府：

“我要确保我能应对不断变化的法规，通过保持一个可管理的稳固的IT 架构。”

彼得，主管应用开发，世界各地的零售公司：

“我怎样才能使业务和IT 一起工作呢？... ”

 

1.3              传统应用开发技术出什么错了？

让我们来看看一个典型的新应用程序开发项目。在传统的应用程序开发周期，有是众多的角色：项目经理，业务需求分析，解决方案架构师，集成专家，可用性设计师，高级开发人员，初级开发人员，测试人员，关键用户，主任等，虽然这些角色有些可能是由一个自然人为代表，通常 “ 业务” 或“IT” 的角色区分性很强。如果是这样，“ 业务” 一边代表的是客户，业务分析家、需求工程师和关键用户，而“IT” 方面，包括开发工程师，架构师，测试人员和集成成员。或者换句话说：

• “ 业务” 负责“ 什么” 是要建立的
• “IT” 是负责“ 如何” 的创建事物

 

现在为什么这么多的IT 项目未能达到预算，时间或客户的 要求？我们能责怪谁？我们能责怪经常变化的要求，即便在后期业务发展阶段，甚至在“ 上线” ？我们能责怪最终用户，谁出于某种原因似乎并不能够确定他们的看法？我们能责怪IT, 它不能把握复杂的业务需求，没有能力 应付不断变化的需求？答案既简单又令人失望：不，我们不能责怪任何人。

这里是原因：

Ø    不可能看到全部的范围及其复杂性
对于新的应用项目， 在需求分析和设计阶段要了解整个范围和复杂性，几乎是不可能的。在“ 业务” 之前，通常不是面临工作原型，实体模型或演示的早期。在思想开始流动和尘埃落定，由抽象的概念讨论和结构设计、 决策过程之后才有“业务”。

白日梦1 ：如果我没有必要在先期详细描述需求，但 仍然能得到最终我想要的结果， 岂不是太好了？

Ø    很难在IT 与业务之间解释词汇含义
对于许多开发团队，将散文或抽象的“ 设计” 转换成工作文件是非常具有挑战性的。这种情况出现的主要原因是：经常有许多隐含要求和特定领域的细节，最终用户认为是自然的需要理解的，但对于开发人员，那些内容就像外星人一样。（或反之亦然），特别是如果开发人员不直接接触的“ 业务” 的一面，如： 大多数是离岸开发实践案例。尽管有人可能发很长的时间描述制定的意义和隐含的逻辑，往往有一个好系统和坏系统之间的良好分界线。细节是魔鬼。

白日梦2 ：那岂不是太好了，如果我可以自动转化业务需求为系统 功能，而无需向其他并非像我一样了解业务的人解释？

Ø    业务需求的变化
比方说，你在需求中完全指定每个小细节，并且大家都同意，事实上：业务流程是动态的，需求是变化的。即便不是今天，他们最终将变化。事实上，考虑到一个普通的软件实施项目期间，当出第一批成果的时候，有机会要求改变需求。如果这个变化需要几个星期，可能甚至是开发过程中很轻微的变化，都很容易导致工期，成本，满意度产生负面影响。并影响整体质量的最终结果。

白日梦3 ：那岂不是太好了，如果我改变需求的时刻，能自动处理他们，就像我梦想到它们的那一刻一样呢？

Ø  设计，文档和实现很容易不同步
有几个好的、很多坏的原因，为什么开发团队有时会变成火拼“ 编码” ，而不是良好的记录用例、需求和编写设计文档。 一个坏的（但常见的）说法是，这给一些开发经理和平（假的）的心境。从宝贵的开发人员上花费过多的时间资源在“ 文字” 或“Visio” 中， 他们看到会越来越紧张--- 而不是令人印象深刻的前瞻性代码语句与黑色的屏。 一个更好的理由不去的记录需求，就是一个简单的事实：这些需求文件到用的那一刻就已经过时了。事实上是，设计文件往往被作为抽象的，内容是大致方向的， 而不是硬设计。大胆的尝试保持同步设计、需求文件和实现，却很少制定有关费用，优先级或缺乏控制。相对于它们提供的回报，这些文件是过于昂贵。
白日梦4 ：如果可以保证我的设计文档、我的系统文件与实际执行代码总是自动同步，那岂不是太好了？

 

 

2       从软件工程到业务工程

有趣的是，我们发现，虽然从不同的根系描述同一主干是一个挑战，但他们可以有单一的解决办法。 如果我们仔细看看，我们可以分别改善以下几个方面：

Ø  释放业务分析人员“ 隐藏” 的力量
在实践中，我们看到，业务分析人员大多局限于Word 和Visio 的类似工具用于捕捉和沟通业务需求，他们的同事解释这些文件和手动转换为工作应用程序时（代码为基础）， 在转换过程中，往往存在许多误解和假设，构成了 “ 业务” 和“IT” 之间的` 沟通鸿沟' 。
现在，如果我们能够提供一个可视化建模工具给业务分析师和需求工程师，使他们以这样一种方式捕捉需求：可以从语义上执行设计模型，则他们可以承担大部分建设应用程序的任务（主要是“ 面向企业的东西” ，如表单，功能，过程设计， 业务规则和工作流），从而避免开发人员手工解释业务设计 。事实上，这也意味着“ 真正的” 开发人员能够专注于技术上更具挑战性（也许更有趣）的方面，如集成，性能和安全性。

Ø    缩短产品进入市场的时间
项目的持续时间常常因中后期意想不到的变化而延长，需要密集的测试. 如果我们通过消除文字处理，手工编程和测试技术的劳动密集的活动来缩短开发时间。 将是很好的例子。要做到这一点，利用模型驱动的应用开发方法：一个应用解决方案可以在可视化模型中自动测试，并像动态业务应用一样被执行。

Ø  提高灵活性
在设计中拥抱“ 变化” ，是个很好的案例。这个想法很简单：如果我们能在“模型”级管理需求（以及需求变更），我们可以自动应用该模型的回归检查，一致性检查和完整性检查功能。换句话说，如果我们利用正确的模型驱动的方法，我们会自动创造出“ 适应 改变的产品“ ， 此外，当我们使用可视模型是业务分析人员可理解和管理的，这样也就实现了“ 结对编程” 的现代版：不是两个开发人员，而是一个业务分析师和一个关键用户座在一个屏幕背后，或者在某些情况下，业务分析师和开发人员一起想象您的平均“ 需求变化” 的效率和变化的周期！

Ø    防止文档过时

在这个时代，无聊或无用的文档仍然是开发的关键组成部分 。尤其是如果应用程序需要支持一个有大量的业务逻辑的业务过程，无论从一个用户，管理员，维护人员或开发者的立场，系统资料保存完好都是非常关键的。在现实中，用户文档往往不是最新的，实际上应用程序运行的与设计文件描述的并不相干。 同样，如果我们使用“ 模型” ，不仅是描述而且直接运行应用功能，我们可以简单地保证模型的定义和实施100 ％同步。只要我们开发和发布不同规格的模型，我们只需很少或根本没有必要额外的手工文档。只要模型（= 应用程序）改变，文档（= 模型）就自动更新。

Ø  不要重新发明轮子
由于许多人发现创造 “ 从零开始” 的新应用程序具有挑战性，调整或者修改现有的应用或原型则容易得多。另外，最佳实践的使用，无论是作为最终方案或只是一个“ 创意” 设计阶段的起点，都能提高质量，进一步加快开发。我们应纳入建筑预制构件或模板的使用（或重用），作为开发方法和最终解决方案的核心。应该非常容易地发布和访问这些丰富的服务。
 

2.1     模型驱动开发的思考

多年来人们一直在努力使用抽象模型提高开发效率而不是低级别的程序编码。早在80 年代初期的重点是代码生成器，后来是CAiSE 工具、第四代语言与对象管理组织（OMG ）推介的模型驱动架构（MDA ）的概念。虽然一些工具的成功超过其他，其中大部分仍在出生的或因为不能履行其承诺而被拒绝。失败或消失的一些原因：专有的编程语言，不能完成“ 定制” 的需求，糟糕的商业模型，糟糕的工具，糟糕的营销。最近，“ 领域特定语言” 和 “ 模型驱动工程” 的概念出台，立即获得广泛的认同和欢迎。

 

模型驱动架构方法
模型驱动架构（MDA ）是一个开发软件系统的设计方法。 它提供了用模型表述规格，型号的结构指引。MDA 理念是：采用平台无关的模型（PIM ）定义系统功能，然后将其转化成平台特定的模型（PSM ），如。NET ，Java 的，PHP ， CORBA 等，然而这种转化微不足道，因为它需要相当复杂的映射，映射也常常使用查询视图转换（QVT ）方法转变。 该MDA 的概念，主要是针对可移植性，互操作性和可重用性的目标，而不是 生产力，灵活性或业务使能。在实践中直接编码往往是速度更快也更便宜的方案。

领域特定语言
特定于领域的语言（DSL ）是一种编程语言或规范语言专用于特定的问题域，是特定问题表述技术，和/ 或描述特定的解决方案的技术。 坦率地说，这一概念并不完全是新的，专用编程语言和各种规格建模语言一直存在，但是由于 “ 特定领域建模“ ，这个词已经变得越来越流行。对使用的DSL 方法的好处之一是，相对于一般用途的编程如C 或Java ，或如UML 通用建模语言言，DSL 的可以提供更多的表现方法来描述功能，增加内涵，消除误解。 一个很大的好处是，丰富的知识和很多经验可以嵌入在这些语言中。例如，DSL 可以设计为描述一个垂直的重点领域，如' 银行' 或' 保险' ，或是水平的解决方案领域，如` 业务规则' ，' 表单' 或' 安全' 。

 

结合最好的DSL ，UML 和一般用途的编程
在下一章我们将讨论为什么和怎样将特定领域的建模，通用目的的建模，通用目的的编程集成到Mendix 。

 

 

3       Mendix：业务工程面向服务的业务应用

3.1     简介

本章介绍Mendix 回应于前一章所带来的主要挑战。

我们将讨论Mendix 和构成了Mendix 解决方案的各组件的概念。我们会深入一些Mendix 的基本原则，其在企业中的可用性，以及在众多IT 产品和技术中的位置。

3.2     Mendix简介

Mendix 帮助企业精简及自动化复杂的跨越组织边界的业务流程。

Mendix 提供软件工具、方法和平台架构，以快速地在任何现有业务或者IT 环境. 建模、构建、测试、集成、部署、管理和优化面向服务的业务应用程序... 没有代码。不像其他的平台，Mendix 集成模型驱动和敏捷方法, 允许业务分析人员积极参与开发周期- 直接利用可执行的可视化模型——那些 动态业务及门户应用。

 

我们的使命和产品战略建立在以下支柱上：

Ø    释放业务分析师（潜在）的能量

Ø  大大加速新应用和服务的上市时间

Ø  提高业务灵活性

Ø  减少项目风险和总体拥有成本

Ø  开放系统的易于集成，重复使用和扩展

3.3     典型Mendix项目的特性

在与传统开发技术的客观比较（参考文献的RDF 集团）中，开发速度、灵活性、应用程序的质量和总体拥有成本（TCO ）等方面，Mendix 都有很明显的优势。 因为Mendix 项目的工作人员主要是“ 业务工程师” ，最好用特定行业或解决方案领域知识的业务工程师，对需求分析和设计的时间花费显着高于 传统项目。这最终导致更高的质量感知和（潜在）100 ％的解决方案适合性。

 

典型Mendix 项目的特点如下：

Ø  项目主要人员是“ 业务工程师” ，最好具备工业和/ 或解决方案领域的知识，

Ø  与“ 业务” 密切的互动

Ø  高度关注业务影响与十分注重投资回报率

Ø  敏捷迭×××发，前期不需要有清晰的画面齐全的需求规格

Ø  固定价格，固定日期

Ø  面向未来可伸缩性

Ø  100 ％合适

 

对比项目统计举例：

 

图1 。基准分析定制开发与Mendix 对比。

 

来源：RDF 的集团公司。 （www.rdfgroup.com ）。

3.4     在哪里放置Mendix？

看看今天的组织、企业架构和IT 景观，我们可以明确的区分不同的业务流程，一个在市场竞争中有更高的效率，更好的服务或独特的产品流程，另外的则并不那么独特 。
鉴别过程
我们在实践中发现，那些“ 有价值” 的过程往往比较稳定，不太复杂，因此非常适合标准化、现成的应用软件。例如，在一个特定的垂直市场，公司有管理的总帐，他们的人力资源管理或库存经常以类似的方式管理。幸运的是，往往有许多可用的应用证明，一个特定的业务支持功能，业务流程或部门。这些应用程序通常被称为“ 最佳的品种。”

通常情况下，在实施这些系统，业务流程本身首先需要改变或 “ 重新设计” ，以适应应用程序的标准化工作。不幸的是，组织经常失败或没有真正致力于以适应他们的流程系统，这被认为是一个项目的主要失败理由。 ERP 市场提供了大量的例子，有好有坏。

 

为了改变而构建

人们可以问自己，什么样的扩展业务流程能适应标准化的工作和应用 。事实上，难道业务流程不是领导？当涉及到这些有竞争力的业务流程，与众不同的优点，我们看到，这些是公司特有的，性质是非常动态的，因此，需要不同的系统，以支持他们：应用程序能够100 ％适合业务流程的需求，并且在流程动态性需要改变的时候能尽快改变。烟窗应用程序支持一个业务功能，是“ 构造为了持续” ，这些应用程序应流程驱动和“ 构造为了改变” 。正是这些与众不同的，富有活力和高增值工序，MENDIX 增加了最直接的价值。

 

扩展型企业

当仔细看看公司的组织方式，我们看到，大部分的业务流程不仅限于一个部门，一个系统甚至一个组织。事实上，我们发现许多流程跨越系统，价值链中人员、利益相关者、组织的边界。我们称此为“ 扩展企业“ 。

扩展型企业的一个重要特征是外部用户的积极作用，在这个过程中有如客户，供应商和政府机构。这也意味着，流程和系统超越了传统的内部组织控制跨度范围。因此，组织我们的过程和架构我们的IT 支持对市场动态有更为直接的影响。

 

下面这些就变得很重要：

 

Ø  自助服务功能，给予外部用户（客户和价值链合作伙伴）直接访问 我们（内部）的交易系统

Ø  以流程为中心的观点看企业

Ø  增加对可用性，用户友好性，性能和可伸缩性的聚焦

Ø  增加应用的灵活性，以应付不断变化的需求

Ø  整个价值链中系统与系统的集成

Ø  采用“ 开放标准” 和“ 工业业标准”

Ø  安全，授权和认证

Ø  能够通过门户网站界面扩展现有系统

Ø  集中的业务规则管理，独立于底层系统

 

 

 

除了提供灵活，可伸缩和可扩展的Mendix 平台，我们的理想定位是简化和自动化企业复杂的业务流程：
 

4       Mendix模型驱动平台套件

Mendix 模型驱动平台提供了一整套的套件，由几个“ 核心部件” 和 “ 额外的开发工具” 组成。 该平台是建立在一个开放的，基于标准的和可扩展体系结构上。

图2 。架构上的高级概述Mendix

 

图2 说明了技术结构的顶层视图，显示了核心部件组成的Mendix 框架。如图所示，设计时和运行时环境有明显的区别。使用Mendix 业务建模工具，定义你的图形化的SOBA 规格（面向服务的业务应用程序）， Mendix 业务服务器可自动执行（由使用“ 一键式部署” 的功能）该模型。该Mendix 业务服务器从基础数据存储（新的或预先存在的，通过连接管理器）检索数据和向客户提供服务。 这些客户之一是Mendix WebClient 产生的，为最终用户提供丰富的互联网（Ajax ）的用户界面。 图中所示，在一个运行时分层结构中，表示、逻辑和数据清楚地分开。

 

4.1.1            Mendix技术原理

在Mendix ，我们相信，我们找到特定领域具体的建模语言（DSL ）、通用目的的建模语言（UML ）和通用目的的程序设计（Java ，。NET ）三种语言的平衡。 所有三种方法完全集成在Mendix 框架中和谐地相处。我们认为，这是Mendix 解决方案的核心优势和特色之一。

重要的是，在构建Mendix 产品时，我们一贯的遵循以下技术原则：

Ø  业务与IT 之间的合作提高

从本质上讲，每一个模型提供了一个业务分析师和IT 工程师之间的共同沟通语言。因此，每个DSL 应提供具有图形和面向业务的界面，应该为业务分析师和IT 工程师所理解。业务分析师可以自己构造模型或者能方便地找到并不能完全满足业务需求的地方。IT 工程师可以检查模型是否与有关技术细节匹配。

Ø  所有DSL 都是运行时环境可执行的

该模型应该作为可执行的工作程序，没有额外的代码生成步骤，避免代码生成有关的维护和测试等许多问题

Ø  每个DSL 应该很容易用第三代编程语言扩展

这就是给开发人员留“ 出路” ，以应对任何特定情况。

Ø  需要尽量少的使用第三代编程语言

随着对DSL 的重视和开放标准的使用，很少需要其他手动代码Mendix （
“JAAV ACTION” ）平均一般在0-5 ％。当然， 开发人员仍然能够手动干预或添加任何现有类库的框架。

Ø  开放系统架构

我们不是明天的遗产。因为我们是开发商自己的公司，我们了解一个开放、可扩展技术平台的价值和重要性。因此，我们提供了一个广泛的API ，给予核心框架的底层级别的访问。尽管我们的主张是增强业务分析师的力量，但真正的开发人员将不会感到失望。

Ø  开放标准

Mendix 努力遵守有关开放和行业标准。每个模型应该是基于一个现有的行业标准，如果这样的标准存在。见本文的最后一章标准支持列表

Ø  流程驱动的业务自动化

防止烟窗或仓筒应用程序的构建，而不是' 自动化过程' 。 这意味着业务过程模型在模型的中心，并有可能实现跨越多个系统、部门、甚至可能在一个价值链上的公司。

Ø  服务组件架构

防止大型、单一应用程序。相反确保应用程序由服务和组件自动构建。各业务功能是为满足特定业务需要所提供的一系列服务组装起来的解决方案。Mendix 应用程序可以包含新的服务及业务从现有系统功能和组成部分复用的应用软件。 Mendix 应原生支持服务组合，包括创建可重用的服务组件，已有的应用功能。

Ø  可重复使用

尽可能很容易地复用模型、服务、组件、知识、现有的技术和技能。

4.1.2     Mendix业务建模器：统一建模空间

Mendix 业务建模者是Mendix 平台多用户建模工作室。总的目的是提供一个集成的，统一建模空间，在这里业务分析师和IT 工程师可以密切合作模型的各个应用元素。

图3 。截图Mendix 业务建模

业务建模的Mendix 包含各种图形编辑器，每一个特定的模型或特定域设计语言：

由于所有的DSL 是在同样的环境管理，它可以检查整个模型的完整性和一致性。这样，我们可以保证，该模型的一致性。事实上，系统将不允许不一致的模型部署，直到问题得到解决。同样机制可用于执行回归检查，很容易分析该模型变化的影响。因此，对测试的需要主要是在功能级别。

图4 。在一个模型空间建多个模型

 

版本控制、多用户管理和国际化
该Mendix 业务建模器支持多用户在同一模型工作，支持锁定、 开锁和版本控制。该Mendix 建模器还提供方便的国际化工具（I18N ） 应用：词典，批量翻译和语言的一致性检查。

图5 。微流程DSL 的编辑器举例

 

图6 。微流程示例

图7 。业务规则模型示例

图8 。领域模型示例

 

4.1.3     Mendix多用户端架构

一旦发现一个模型与Mendix 业务建模器兼容，它就可以部署到Mendix 业务服务器，在其打开执行时向一个或多个Mendix 客户端公开其模型。 该Mendix 平台具有多种开箱即用的目标客户端，包括流行的Mendix ajax 的WebClient ，这是一个高性能和个性化丰富的门户框架。其他目标客户包括（脱机）.NET 客户端，Java 客户端甚至iPhone 手机客户端。开发商如果喜欢建立自己的定制的部件，甚至建立自己的目标客户端（如PHP ，Python 语言，Flash ），广泛的API 和多客户端架构，提供所有必要的技术文件API 文档。

 

图9 。 Mendix 多客户端架构

 

4.1.4     加强与Mendix AJAX WebClient的用户体验

Mendix 的WebClient 提供了一个高性能，丰富的互联网接口（使用Ajax 的技术）, 支持所有主要浏览器，包括IE6 + ，Safari 浏览器，Opera, Chrome 和 Mozilla Firefox 。从本质上讲，Mendix WebClient 在浏览器的一个单页内呈现表单，报表和的图形。

 

模型驱动的混搭

门户网站的界面和布局可以使用图形化建模的形式在Mendix 业务建模器中搭建。一旦部署，Mendix 网络桌面帮助下，用户可以进一步个性化其仪表板，拖放RSS 源、快速链接、图表、报表和个人标签等portlet 页面。基于用户角色和授权等级的基础上，创建一个个性化的WebClient 用户体验，个人导航，种子，启动页和样式。

图10 。 DSL 的范例Formbuilder
 

图11 。Mendix 的门户示例

图12 。Mendix 门户示例

图13 。 WebClient 的例子中，Mendix

应用程序的外观和感觉很容易定制

任何应用程序的样式是完全基于层叠样式表（CSS ）。这样可以选择任何公司风格。对于IT 工程师，Mendix Web 客户端提供了一个广泛而文档化很好的 API ，因此用户控件可以添加到经验结果中。就像Mendix Business Server 的WebClient 提供了一个服务层与Mendix 业务服务器和其他所有 部件通信。 Web 客户端可以很容易地与现有的网站或企业门户集成。

 

4.1.5     Mendix业务服务器

Mendix 业务服务器是Mendix 平台的运行时环境。从本质上讲，企业服务器包含一个运行时引擎，用于解释和执行模型。

业务服务器本身有一个模块化结构的服务接口，连接所有的模块和服务 代理。每个模块提供诸如事件处理，对象操作的关键服务。服务代理提供诸如LDAP 整合和报表的可选功能。这些服务代理也可以是第三方提供的库。图7 给出了模块化结构示意图。

图14 。 Mendix 业务服务器

 

对象和动作

Mendix Business Server 的核心是基于两个重要概念：Mendix 对象和操作。一个Mendix 对象是一个具有多种表现形式的对象，如一个XML 文档、Java 对象或一个JSON 对象。每个客户端都可以请求按自己的偏好展现服务器的业务对象。例如: 一个Ajax 应用钟爱JSON 格式的对象，而一个企业服务总线（ESB ）需要一个XML 文件。无论表现形式如何，这些对象的逻辑保持不变。

要应用系统或流程逻辑，需要执行业务操作。每个业务操作Mendix 服务器称为一个' 动作' 。业务服务器提供了许多预定义的操作，如创建，读取，更新，删除（CRUD ）操作Mendix 对象，触发和执行工作流或微流程，执行业务规则或执行定制的Java 代码。每个动作可以执行其他操作，这些操作可以被定义为树型结构的事务。此外，每个动作都可以通过不同的接口调用，如HTTP ，web services 或Java API 。结合对象的多种表现方式和通过不同的接口执行操作，提供了对业务服务器整合其他系统的基础。

4.1.6     Mendix连接管理器

另一个Mendix 平台的关键组件是Mendix 连接管理器，它是一个双向的集成层，将外部系统的数据映射到Mendix 的对象定义。 连接管理器的主要任务是为Mendix 业务服务器提供Mendix 对象。这些数据对象可以从不同的数据存储位置检索，每一个有自己的特定接口。例如：数据可以通过JDBC 取自关系数据库，通过远程函数调用从外部系统（RFC ）获取，或 通过Web 服务从ESB 中获得。为了给业务服务器提供一个单一的界面，连接管理器转换XPath （分层）和OQL （关系）查询到特定的SQL 查询或Web 服务的通用语言/ API 调用。连接管理器支持所有主要的数据库管理系统，包括甲骨文， PostgreSQL 的，微软SQL 服务器，MySQL ，Informix 和DB2 ，以及Web 服务样式的文本和RPC 。

 

映射外部系统到业务对象模型

为了管理来自外部系统的连接和数据检索，仅仅翻译查询是 不够的。因此，Mendix 连接管理器还将外来数据结构映射到一个中央领域模型（“Mendix 领域模型” ），这是Mendix 对象的蓝图。所有映射采用MENDIX 建模器使用图形的方式建模。将低层次的整合问题提升到一个唯一抽象的业务对象模型，使业务的工程师专注于业务逻辑，而不是集成问题。

图15 。测绘的DSL 业务为例Mendix 莫德勒

 

4.1.7     用自定义代码扩展模型

集成第三代编程语言（比如用JAVA ）是Mendix 模型驱动开发方法的主要优势之一。从本质上讲，用户永远不会受限于特定的DSL 并随时诉诸Java 定制功能的使用。不同的DSL 的（例如表单，微流程，映射）可调用定制的Java 函数，并且其输出可用于模型内。各功能接口也都在模型中定义。名称、参数和返回值均在Mendix 业务建模器中声明。建模器将生成每一个功能的模板。只要接口有任何更改，该模板会自动改变而不会失去您的自定义代码。通过这些自定义代码，程序员能够全面的使用运行时引擎的核心API 。这是一个反射编程模式之外的低级别API ，。为了简化Mendix 的API ，使用Mendix 业务建模为每个领域对象生成代理，提供简单的getter 和setter 属性。使用这个工具，在模型中的变化可以很容易地传播到自定义代码。

 

图16 。定制的Java 集成在微流体行动

4.1.8     安全

既然Mendix 平台通常被用来支持主要业务过程，为内部和外部的大集团企业用户获取机密数据，安全性被认为是最重要的。因此，我们的“ 安全DSL” 是在Mendix 平台上最大的领域之一。 安全DSL 适用于技术框架的所有方面，从数据访问到导航。为了防止任何绕过安全机制的行为，它们在业务服务器和连接管理器的最低层框架实现。当然，所有的设置都在Mendix 业务建模器管理。

业务服务器的核心（服务接口） - 负责执行任何动作 - 有一个安全矩阵，其中包含每个用户角色的所有可执行的行动。这意味着，如非被安全模型授予了适当的权限，任何动作都不能在框架内执行。这种机制适用于所有模块和框架提供的服务代理以及第三方组件。

数据访问安全由连接管理器管理。就像Business Server 一样，连接管理器有一个包含每个角色及其数据限制的矩阵。该连接管理器将只提供允许用户访问的数据。业务服务器永远只能通过连接管理器检索数据（Mendix 对象），这使得它无法绕过安全机制。

Mendix 提供了记录所有用户行为和对象操作的选项，使审计能追踪到最低层次。此外，内置的安全角色和认证机制支持与现有LDAP （轻量级目录访问协议）集成和单点登录（SSO ）的标准。

 

4.1.9     可伸缩性和鲁棒性

为了支持该平台的重量级企业应用，Mendix 的建设过程就考虑了可伸缩性和鲁棒性。如果需要， Mendix 应用程序可以部署在分布式环境中，无论是通过分离服务组件或在运行时部署多个实例以共享负载和分布式体系结构。一种通常的高伸缩性和鲁棒性的部署如下所示。

图17 。可扩展的应用架构

这个架构包含多个层次。一个负载平衡器用在顶层分发所有的请求给处于中间层的Mendix 服务器的多个实例。每个Mendix 企业服务器能处理和执行客户端的任何请求，支持故障转移和高性能环境。负载平衡器可以是外部的软件或硬件。当然，一个可扩展的存储层（底部 层）是必要的。这是一个第三方数据库群集和/ 或共享存储网络。 不过，即使没有部署多个实例，业务服务器依然显示了非常高的性能。在不同情况下的性能指标可根据要求提供。

4.1.10             应用监测

该Mendix 平台配备了坚实的DTAP （开发，测试，验收，生产）的设置。 在不同的部署阶段，Mendix 提供了支持和监测工具。

开发

在应用开发过程中，通过使用内置的功能，记录和跟踪执行状态，或通过外部工具像Sun 的JConsole ，行为和应用程序的性能可以通过业务执行服务器来评估。后者允许跟踪应用程序特定部分的内存和CPU 使用率等数据。使得IT 工程师可以识别潜在的瓶颈。

生产

在生产环境中，应用程序的可用性和资源的使用趋势监测可集成在客户现有的监管架构中。 Mendix 提供各种系统插件，这可以很容易地了解用程序的性能，并不断通知性能或可用性问题。工具的例子包括，惠普OpenView ，Nagios ，一个开放的监控调度引擎，跟踪网络，系统和应用资源的可用性；Munin ，一个随着时间收集数据使用趋势的前端视觉表现应用。当在JEE 应用服务器（如IBM 的WebSphere 服务器）上运行Mendix 企业服务器时，JEE 容器可提供记录和监测的功能。

 

4.2     Mendix AppStore

为了帮助企业把精力尽可能集中在实际的业务解决方案，而不是这么多定制开发活动，Mendix 整合了模板作为其解决方案的核心部分。鉴于Mendix 平台提供所有的工具来构建和集成 业务应用，建设社区，让我们的合作伙伴，客户和用户发挥核心作用，构建一个最佳实践模板库，提供横向或纵向领域的解决方案。

Mendix 识别以下最佳做法类型：

Ø    过程模型（包括服务说明）

Ø  业务组件（包括与第三方服务集成）

Ø  领域模型

Ø  主题包

Ø  部件（包括portlet ）

 

因为我们相信Mendix 解决方案应该100 ％的适合用户需要，模板不被看作是现成的应用。事实上，他们应该被看做是半成品，用来快速启动和处理解决方案的交货，采用明确的（可重复使用）模型来捕获领域知识，进一步加快投资回报率。

图18 。 Mendix 解决方案堆栈。

 

4.3     系统要求

下表概述了Mendix 平台运行不同组件的运行时引擎：

 

4.4     使用开放标准和行业标准

我们致力于对开放和工业标准的支持。目前我们的产品符合下列标准：

 

 

 

5       在面向服务架构中如何定位Mendix

今天，由于越来越多的参考架构是基于面向服务的架构（ SOA）和业务流程管理（BPM）的原则，我们坚信，一个模型驱动开发的方法需要从你的SOA和BPM得到最大化的利益是至关重要的。

对一个 SOA的最重要原则之一是识别n-tier 多层体系结构（如：数据，应用，集成，过程和表示层）。 BPM一般在 SOA的过程处理层实现。然而，当组织业务流程自动化时，BPM的关键因素是将其置于中心位置。在这种体系结构的实现相当复杂，不能简单地完成。因此，Gartner公司提供了三个不同样式的SOA倡议（海沃德及Natis，2006）：

Ø 后端应用程序集成：这些项目的主要目标是整合后端数据和应用程序的业务逻辑。

Ø 复合应用程序和业务流程支持：这些项目的主要目标是实现复合应用程序和流程。由于这些项目在很大程度上依赖于可用性（预先存在的） Web服务，所以支持服务编排是最重要的。这些项目编排现有的功能，而不是创造新的应用。

Ø   新的面向服务的业务应用（ SOBA's）：这些项目的主要目标是实现新的和完整的SOBA。这些新的基本功能，提供了用户界面或Web服务。

 

复合应用程序以现有的 Web服务为基础，结合新的应用程序。理想情况下所有业务逻辑应该包含在这个过程层。然而，这意味着，Web服务将缺乏业务逻辑。这与现实情况相去甚远，因为即使是简单的数据验证也可以影响到业务逻辑。

此外， Web服务必须是几乎原子性的，以支持必要的有意义的业务灵活性。因此，以业务为中心的理念来构造应用将更加灵活。这就是为什么模型驱动开发确实在SOA和BPM架构上增加了附加值的原因。当正确使用模型驱动开发工具提供面向服务的业务应用，不仅提供SOBA本身的灵活性，也增加过程层的弹性。

 

如前所述，实现一个成熟的 SOA不是一蹴而就的， Mendix框架所处位置的不同取决于手头架构的阶段。在下面的章节中，我们描述了三个常见的场景中Mendix框架的定位。

 

Mendix 在SOA：场景1 - 单机

在这种情况下 Mendix框架作为一个完全独立的运行。不需要其它门户的帮助阿贾克斯的Mendix WebClient的可加载到浏览器。注意，在图10 Mendix业务服务器仍连接到其他应用程序。这是可选的，但在实践中的一些形式的集成始终是需要的。

图 19 -场景1：没有中间件或Portal 的Mendix业务服务器

Mendix 在SOA：方案2 - ESB和门户服务器

在一个成熟的 SOA实现中企业服务总线（ESB）是实现这一结构的中心。

Mendix框架将被定位在应用层，将从 BPM/流程层和集成层提供和使用WEB服务。框架的Web客户端可以直接出现在Mendix门户和现有的企业门户。

 

图 20 - 场景二：Mendix企业服务与ESB和门户服务器集成

Mendix 在SOA：场景3 - 门户服务器

在许多体系结构中， ESB尚未（完全）实现。在这种情况下Mendix框架得到了更中心的地位，使用（集成）连接框架的映射选项直接连接到其他应用程序或数据库管理系统。

只要实现了 ESB（场景1），将Mendix定位在应用层，仅仅需要一点点额外的努力。因为所有的映射已经定义，这只是一个简单的数据路由。

图 21 – 场景3：Mendix企业服务器集成了门户网站服务器

 

Mendix 在SOA：场景4 - Mendix和SAP

Mendix提供了一个集成方案， Mendix作为SAP NetWeaver的一个业务服务来实现。在这种情况下，我们利用SAP应用服务器。然而，在大多数情况下顾客喜欢的Mendix在SAP门户上应用。

图 22 - 场景4：Mendix企业服务器与SAP NetWeaver整合

 

6       Mendix开发方法

为了充分发挥Mendix 框架的最大好处，还必须采取正确的方法。 因此Mendix 引入了模型驱动和敏捷方法相结合的方法。

这意味着，在Mendix ，过程必须是方法论的中心。 第一步是设计需要自动化的业务过程。在Mendix 方法中这些过程的设计是不可以直接执行的。它们用于描述需求、文档、作为基于模型的组件开发的参考指南。在实践中，随着时间的推移，越来越多的信息可用，这使得有必要采用一个高度迭代的开发方式。

图23 。 Mendix 开发方法（时间的角度）

另一种方式来看待这个方法是从利益相关者的观点。 下表说明，不是每一步的方法是由同一人来完成。业务应用开发有中许多不同的角色参与：

图24 。 Mendix 开发方法（利益相关者的角度）

 

当业务流程分析师定义完过程（包括所有角色和系统）后，接下来是识别可以用工作流自动化的服务和过程。这个工作主要由业务工程师完成，这样给了架构师足够的信息识别发布服务所需要的构件。然后这些构件由业务和IT 工程师密切协作完成。

 

7       下一步

如果你有兴趣讨论Mendix 如何可以应用在您的组织，或者如果你是一个潜在的合作伙伴，想通过当前的服务或解决方案组合Mendix ，请直接联系我们。 还可以考虑参加我们的每月“Mendix 纲要” 事件，日期和地点公布在我们的网站上。欲了解更多信息，请访问 www.mendix.com

 

办事处

 

美国总部

Mendix

810 纪念车道102 室

剑桥，MA 02139

美国

电话：+1 （617 ）418-4111

 

EMEA 总部
Mendix
Westzeedijk 487
3024EL 鹿特丹

荷兰

电话：+31 10 276 0434

 

Mendix 斯堪的纳维亚

Mendix

Döbelnsgatan 89

113 52 ，斯德哥尔摩

瑞典

电话：+46 （0 ）70 494 88 74

Mendix 亚洲

487/1 斯里兰卡Ayudhaya 大厦

斯里兰卡Ayudhaya 路

Payathai ，Rachatayvee

曼谷10400

泰国

Mendix Asia

487/1 Sri Ayudhaya Building

Sri Ayudhaya Road

Payathai, Rachatayvee

Bangkok 10400

Thailand

 

免责声明

本白皮书提供的“ 原样” ，不提供任何形式的，明示或暗示的保证。 本白皮书的目的是描述Mendix 产品系列基本概念和想法的大纲。本资料仅供参考之用，并不提供任何Mendix 权利，担保或知识产权许可。本文介绍的某些功能可能无法支持所有的软件发行版本。所列出的组织或产品并不意味着任何背书，Mendix 不承担所列产品或工具的任何责任。

 

 

 

参考资料 ：

 

 MENDIX whitepaper   http://www.mendix.com