【2013年10月23日 51CTO外电头条】移动中间件，这一术语对于任何一位曾经创建移动应用、为员工提供移动设备支持或者实施客户体验战略的朋友来说都不会陌生。正确地选择并使用移动中间件能够从根本层面缩短开发时间、提升用户体验、促进安全性并推动合规性治理工作。虽然一般的移动中间件模式具备标准化方案，但在数据管理、映射以及全局应用程序设计等领域，中间件由于需要针对应用及政策做出优化而带来了一系列变数。
优化移动中间件设计
理想的移动中间件架构应当拥有服务器元素，并以此为基础实现逻辑应用交付。这些应用程序既可以代表数据的消费方、也可以代表对应外部服务或数据访问的应用程序接口（简称API），也就是中间件层的后端。位于服务器前端的API或者接口作为信息及体验的交付平台。综合起来，这就是传统四层式结构，即用户-服务器-应用程序-资源。
这种简单的结构为我们带来两个设计工作中需要面临的早期问题，即：应用程序是什么？资源又是什么？举例来说，Web API就可以被看作应用程序；这一定义意味着它有能力直接由用户实施访问。允许用户直接访问Web API的问题在于，这类访问会绕过登录、安全以及管理等一系列可能由中间件所提供的流程——可以算是纯粹的用户到资源连接。在某些情况下，例如以性能为主要诉求的视频数据交付流程，这类针对资源的直连机制无疑是大家需要尽量避免的。
由此带来的必然结果是，我们必须从应用程序创建的初期就融入良好的设计实践方案。从框架入手，大家需要为框架结构提供出色的安全性与合规性支持、活动登录以及其它多种因素，从而确保全部实践切实贯彻到位。
移动中间件应用框架的一大核心问题在于API的使用方式。如果大家希望支持浏览器访问（基本上这也是必备要素之一），那么基础应用必须提供RESTful前端。此外，大部分移动设备应用同样需要使用RESTful API。需要强调的是，如果需要使用RESTful API，大家必须根据表述性状态转移为前提设计应用程序。这意味着我们不能假定应用程序会保持状态。总之，对于应用程序到资源连接机制来说，这一点非常重要。
性能改进之路
如果应用程序会利用Web服务直接访问我们的中间件，那么大家需要审查BYOD政策（也就是针对为员工提供的移动设备建立起的实践机制）中每款平台对于API的支持效果。制作一份图表，其中列举所有受到每一款平台支持的API，以此为基础即可轻松找到适合自身需求的最低API使用数量。
移动中间件能够显著缩短开发时间。
在多数情况下，我们有必要为每一个API提供受支持的不同前端。与其将应用程序逻辑直接针对每种用户界面进行复制，大家不妨考虑创建一套多前端方案、从而使使调度同一套应用后端。这样一来，大家就可以为全部API建立起通用数据模式并将这套模式提交给特定API（以及HTML）。如果需要根据设备操作系统或者移动设备政策对API进行定期调整，这将简化应用程序生命周期管理流程。
从中间件的资源角度看，将API从应用逻辑中进行去耦处理也能带来实际帮助。我们针对API定义的通用数据模式从访问角度看只能算是基准方案，数据模式中包含了所有必要的资源因素。只要向数据模式中而非向用户提供应用需要使用的元素，我们就能够实现有效的资源优先模式。接下来，大家可以利用后端（实际上属于面向后端的前端接口）与任何资源实现对接。
这种处理方案的主要挑战之一在于性能，而多数情况下这都会成为移动中间件的主要障碍。为了获取最大程序的灵活性，大家可能希望应用程序在资源及用户角度都能拥有多API松散特性，这要求我们处理更多信息、也因此影响了性能表现。为了优化性能，我们往往不得不舍弃一部分灵活性与硬编码接口、甚至复制应用逻辑，从而缓解给用户及资源造成的压力。
另一种值得考量的性能改进途径在于对中间件的多个副本进行向外扩展处理。但这种方式同样存在局限性，即只有在应用程序、中间件以及用户API在连接方面存在性能障碍时才有效。举例来说，如果大家面对的性能问题源自数据库处理速度，那么复制中间件副本不会带来任何帮助。
当通过移动中间件移动大量数据时，请注意可能由虚拟化或者云计算引发的性能问题。根据虚拟机管理程序的使用方式以及数据通道的优化效果，网络流量很可能无法被高效传输至虚拟机端。如果移动应用需要在同一台主机内的多套虚拟机系统之间进行数据传输，那么网络连接的桥接效率会变得相当低下，从而导致严重的性能问题。这时需要向虚拟机管理程序或者云软件供应商寻求帮助，看看有没有合适的数据优化途径——这一点在交付移动视频时尤其重要。
移动中间件对于连接丢失问题非常敏感，特别是在移动活动涉及某些资源提交或者金融交易时，情况就更值得关注。对于涵盖全部活动类型的从用户到资源的路径，我们必须深入进行检查与测试，从而确保故障不会在用户不知情的状况下保留他们的提交信息或者无人管理的滞留资源。
