大型 Web 开发计划通常会由多个开发项目组成，这些项目由分布在不同地域的团队全天候同步进行。 由这些团队开发的各个组件需要尽可能实现无缝互操作。这类开发的关键要求是在负责构造不同组件的团 队之间建立好约定。一个好的模拟器框架通过实现各个接口约定所支持的全部请求和响应来保证尽可能的 团队独立性，并潜在地提高生产率。本文将描述在快速 Web 开发环境中使用模拟器框架，逐步演示如何 使用 Rational Application Developer 快速创建一个模拟器框架，并包含了一些示例与代码。
简介
复杂的开发项目往往要求各个阶段的开发流程尽可能相互独立。假设流程之间的接口 （不同子系统间的约定）已经在软件开发生命周期（SDLC）中尽可能地提前完成，一个好的基于模拟器的 开发策略能在开发过程中实现显著的优化。
这点对于将新应用程序和系统部署到现有环境期间尤其重要，比如在电信领域，该领域混合了大量的 Independent Software Vendor (ISV)，并且非功能性需求相当重要，尤其是管理系统延迟和吞吐量方面 。在这些复杂环境中，许多因素使得在现有环境中实际交付新应用程序变得很复杂。其中一些因素包括：
需要开发和发布某些功能，但是缺乏新的应用程序所依赖的所有系统和服务
需要最大程度 地同时进行与不同流程相关的开发活动，同时又要尽量减小流程之间的相互依赖
需要在发布功能 时证明新应用程序能够满足端到端的吞吐量和延迟需求
需要使开发团队避免对子系统进行修改， 他们需要在 SDLC 的编码和单元测试阶段依赖这些子系统
需要在一个可重复、稳定、可靠的流程 内轻松地提供各种测试数据场景
在所有这些领域中，一个功能健壮的模拟器框架将会很有价值。 本文将描述这样一个模拟器框架，并解释如何使用 WebSphere Application Server 来构造一个模 拟器框架。此处将重点讲解一个使用 Service Oriented Architecture (SOA) 的应用程序，可将此扩展 到其他类型的环境和架构中。
模拟器最佳实践
模拟器概览
韦氏词典对模拟器的定 义是 “能在试验条件下重现或表示出有可能会在真实情况中发生的现象的设备 ”。模拟器可 在 SDLC 过程中使用，通过为后台服务提供端点实现更加敏捷的开发环境，后端服务呈现为一个调用应用 程序，但实际上只是模拟真实的系统。模拟器以与实时后台服务相同的形式进行响应，并使用相同的请求 /响应约定，但只是简单地从配置数据返回预置数据。这样就可以对支持系统的功能性和非功能性特性建 模，即使您没有访问系统本身。
比较常见的和通用的编程实践是使用 stub 接口，这种接口绕过 了本地客户端接口调用，而是执行另外的本地代码路径并返回预置数据。很多情况下，stub 可加速初始 开发，但无法实现执行整个代码路径和调用工作接口所能获得的功能。使用 stub 方法时，应用程序需要 知道它正处在 “stub 模式” 下，这样才可以执行不同的代码路径。通过使用模拟器，应用 程序只改变端点，而不会知道响应来自于模拟的后台系统。
图 1 和图 2 显示出两种方法的区别
图 1. 应用程序使用本地 stub 代码，绕过 Web 服务调 用
