当企业准备使用移动情境应用来提供生产效率时，同时也为IT专业人士们带来了一些新的设计挑战。

对于大部分企业来说，下一步计划是要，在某一个活动点上，让工作人员通过使用移动设备而获得更多权限，从而提高企业生产效率。这些新应用程序通常需要不同的设计实践，其中包括界面和组件模型的设计。许多案例分析发现，这些应用程序涉及到Web前端因素和RESTful原理。

与此同时，这些可以提升生产效率的应用程序或许也包含应用SOA原理的各种组件。要想梳理清其中的内容，架构师们应该使用信息呈现的分层应用原则，仔细检查应用程序的背景和状态控制，并重新思考一些界面和ALM的设计问题。

在移动情境应用的使用过程中，工作人员可以通过在屏幕上使用移动设备而获得制定任务的一些信息或者帮助。从近期的一些实例中我们可以看到，通过传统的应用程序虽然也可以获取到任务信息，但是在这种特殊的环境中，工作人员要想以这种普通的方式访问任务信息而是非常苦难或者徒劳。这同时也意味着，移动情境应用是根据具体的信息服务而设计的，这样就符合设备的输送限制，可以对工作人员的导航菜单起到限制的作用，同时与传统应用程序之间形成一条明显的界限。

情境应用模型

许多架构师发现，一款应用程序的逻辑模型就是可以识别设备、识别情境的敏捷前端的逻辑模型，从现有应用程序的组件中提取有价值的信息，但是，千万不要替换掉专门为组件构建所设计的应用程序。这样，移动情境服务就可以非常好的融合到现有的应用程序中，其中包括ALM。

我们的目标是，在不破坏现有应用程序模型的前提下，增加应用程序的敏捷性和灵活性。我们接下来要使用Web技术建立GUI和应用程序门户，将现有应用程序和组件的变化隔离出来。

分层应用程序很常见，但是，移动情境服务却带来了两个问题：应用程序大规模的情境和性能。该情境可能部分来自于移动服务（定位服务），但是同样也需要工作人员输入一些内容。大规模性能意味着，要对可用性和延迟进行明确的界定，即使是许多工作人员同时使用该应用时，也要确保满足上述要求。后者是非常重要的，因为，要想精确地预测同一时刻具体的活动数是非常困难的。

工作人员情境对于多步骤任务的阶段进展是非常重要的。实际上，所有移动情境服务都会对期望任务进行一种特定的序列界定，这样就会满足最小范围的工作人员互动。我们可以在服务或者应用程序中维护扩展后的状态。对于任何一种机制来说这种方法都是适用的，但是，这种状态管理的信息量非常大。要注意的是，维护设备状态可以改善移动网络流量和网络延迟。

性能管理

同样，应用程序的状态管理也存在缺陷。软件组件中为用户维护的状态时难以复制的。要格外注意Web前端任务的扩大和缩小设计，确保状态信息不会太复杂。这通常意味着，应该在应用程序的Web前端流程与遗留SOA应用程序流之间的网关组件中适用状态控制管理和情境控制管理。

当我们正在使用后端状态控制管理时，最好是对负载均衡和缩放控制进行可视化处理。首先，包括Web前端组件在内，都要是无状态的，或者是要依赖移动设备的状态和情境。其次，要为实际的应用程序组件设立一个信息入口，引入后端状态控制。为了避免状态数据库在地理位置上过于分散，我们应该在前端组件中设置一种特定的网关入口。

前端和网关组件的组合集成为虚拟用户的现有应用程序组件，就如通过SOA和REST使组件彼此相连一样。移动情境服务与正常的工作流程相比有较多的交叉性，因此，不能在转向和测序中使用现有的服务总线逻辑模型。如果这样做了，他们或许也必须适用于BPEL。在同一种逻辑模型中，同时要适应无线移动网络或者情境输入和正常的工作流程。

无论是建议改变现有组件计划适应移动情境的使用，还是在组件数据包中加入新的信息元素，这种双元性或许都会打破现有的界面模型。如果组件数据模型发生改变，我们也要对BPEL进行修改，以此降低其对遗留工作流程系统的影响。

另一方面的影响就是ALM。因为移动情境服务在工作流程中大多都是以事件为导向的，因此传统的ALM也许会失去其相关性。我们很可能要在每一个应用程序元素、独立测试或者工作流程以及人员工作环境认证的单元组件行为模型方面格外留心。如果我们能够将工作人员的活动是为个人化工作流程，那么其对整个设计都会有促进的效果。但是，我们也有可能对ALM中操作实践的更改进行适当的调整，从而确保能覆盖所有情境。

如果移动性成为赋予工作人员的一项权利，那么为了适应移动情境服务所付出的努力将会对应用程序设计的修改产生主要影响。我们要记住的是，对移动工作人员提供更多的支持就是为迎接未来的移动世界做更好的准备。