在使用 BizTalk Adapter for Web Service 的 EAI 解决方案中，不同的、分离的组件被整合在一起完成统一的商业逻辑。在解决方案中，各种组件必须很好的在一起工作。有两条关键的原则（ key principle ）可以使得你的 BizTalk 解决方案更完美：
KP1 ：在搭建解决方案时，每一步实现均进行测试；
KP2 ：丛最前端开始向后端推进，或丛最后端开始并向前端推进，一步一步进行增量开发。每进行一步增量开发，均要保证增量后解决方案可以使用。
下面分别加以描述，并对其中的技巧进行指导。
** 1 ** ** ． Back-to-Front Strategy **
** 从后端到前端的策略 **
使用 BizTalk Adapter for Web Service 解决方案时，从后端的开发开始是一个比较好的策略。因为这一解决方案通常是通过提供 Web Method 接口来实现复杂的服务程序。开始时，第一件事情是在 BizTalk Server 以外的环境检验后端的进程（ process ）。如果你可以进行一次独立测试（ stand-alone test ）是非常好的方法。
** 1 ** ** ． ** ** 1 Component Tactics **
** 组件技巧 ** ** **
实战时，需在组件装配到 BizTalk 之前进行测试。下面是一些优化建议和查错（ troubleshot ）建议：
如果你使用 XLANG Schedule 来连接后端的进程（ process ），可以将 COM 组件作为桥接（ bridge ）来使用。 COM 组件可以是第三方的适配器组件（ adapter ）也可以是定制组件。无论那一种，请进行测试控制，如：适用 Visual Basic scripts 来进行一次单元测试。
如果你使用消息端口（ messaging port ）来连接后端的第三方组件或定制 AIC ，那么创建一个测试用消息端口和信道（ channel ）比使用 Visual Basic script 来测试好多了。以下是如何创建测试用消息端口、信道的步骤：
创建使用 AIC 作为传输口（ transport ）的消息端口（模板）；
信道可以使用空文档作为源文档和目标文档，不需要映射（ map ）定义。
使用 BizTalk Editor 生成一个合法实现（ instance ）文档；
改写 SubmitSync.vbs 的副本，使得文档提交到前面所述的信道；
使用浏览器将要提交的文档拖放到 SubmitSync.vbs ， BizTalk Messaging Service 将传送该文档到 AIC ，并返回回复（ response ）文档。（这个 vbs 将回复写到同名的文件中）
对于定制开发的组件，无论 AIC 还是 COM ，交互式的 debug 都很有用。以下是 debug 技术步骤：
在开发环境中，设置断点，将工程设置为 debug 模式；
为了确保 BizTalk Messaging Service 没有加载一个非 debug 版的 AIC ，你必须停止并重新启动 BizTalk Messaging Service ；（你可以使用 RestartBTS.cmd ）
如果 XLANG Schedule 使用你正在 debug 的组件，你可能需要停止所有的运行中的 XLANG Schedule 。（你可以使用 XLANG Event Monitor ）
到此为止，你可以开始了
** 1 ** ** ． ** ** 2 Document Tactics **
** 文档技巧 ** ** **
为了避免错误的文档实现带来的错误，建议你测试你的文档及其定义。以下各点是如果减轻文档错误带来出错的建议：
使用 BizTalk Editor 来生成文档。
当使用一个例子文档来测试时，使用 BizTalk Editor 来校检文档格式，然后在进行测试。（详情请参考 BizTalk help ： Validate a Document Instance ）
同样的，如果你作了任何文档定义的改变，你需要重新作校检。
如果你作了文档定义的改变，相应的映射文件也需要改变，相关的 BizTalk 实体，如：信道、信封（ envelope ）、 XLANG Schedule 等均需要作改变、刷新、重新编译。你可以遵照以下：
使用 BizTalk Mapper 更新所有的映射；
使用 BTM_Refresh.exe 来更新 BizTalk 实体；（你可以在 …\Program files\Microsoft BizTalk Server\SDK\massaging samples\Refresh Messaging Manager 找到这个程序）
使用 Orchestration Design 打开更新、重编译 XLANG Schedule 。
** 1 ** ** ． ** ** 3 Orchestration Tactics **
** 编排技巧 ** ** **
XLANG Schedule 可以被实时的测试，以下是建议：
BizTalk Orchestration Designer 只有在所有动作（ Action ）都与实现相连接后才能编译。
使用 XLANG Event Monitor 来监控调度运行情况。
使用 Windows 2000 Event Viewer 即事件监视器来监控。
** 2 ** ** ． Front-to-Back Strategy **
** 从前端到后端的策略 **
也有可能从前端开始工作。可能的情况是从 Web Service 和 Web Method 开始，然后通过 BizTalk Messaging Service 得到信道、消息端口、文档定义映射。当你采用前端到后端的策略时，你不必使用后端到前端的策略中的方法。
** 2 ** ** ． ** ** 1 BizTalk Messaging Services Tactics **
** BizTalk ** ** 消息服务技巧 ** ** **
你不能直接在前端通过 BizTalk Adapter for Web Service 进行工作，因为你需要呼叫（ request ）文档和回复（ response ）文档的定义，而且出于生成 Web Method 的要求，还需要定义信道。以下是你在将 Web Method 与信道相连之前要作的事情：
得到或自己创建呼叫 (request) 和回复 (response) 文档定义。
创建消息端口。测试时，可以使用 ResponseFile 组件（在包含的例子中）。
创建信道。可以将信道配置为无文档定义的，以使得呼叫文档格式或映射文件格式部会在影响信道的配置。
要单独测试信道和消息端口，可以将测试用文档拖放到 SubmitSync.vbs 来提交一个呼叫并且显示回复。当然，事先你需要对 SubmitSync.vbs 做一定的定制，使之适应你的信道、端口和文档定义。
如果你配置信道没有使用文档定义、或没有校检文档，你可以考虑加入这一特性，并在将其连接到 Web Method 之前重新测试信道。
** 2 ** ** ． ** ** 2 BizTalk Adapter for Web Service Tactics **
** BizTalk Web ** ** 服务专用适配器技巧 **
当信道和消息端口都被准备好以后，你可以创建 Web Method 来提交呼叫（ request ）到信道。很重要的一点是应该将“ Web Service Administration ”理解为一个设计工具而部是一个管理工具。这意味这当你成功创建一个 Web Method 以后，你不能使用这一工具进行错误定位（ troubleshoot ）工作。
** 2 ** ** ． ** ** 3 Using the BizTalk Adapter Trace Utility Tool **
** 使用 ** ** BizTalk ** ** 适配器跟踪工具集 **
如果你确信你需要对 BizTalk Adatper for Web Service 进行错误定位工作，你可以使用“ BizTalk Adapter Trace Utility ”来收集工作状态下适配器中数据交换中的详细信息。（详细情况可以参考 BizTalk Adapter for Web Service Help 中的“ Running the BizTalk Adapter Utility ”一节）
** 3 ** ** ． Closing the Loop **
** 闭环 **
当完成研究学习“前端到后端（ front-to-back ）”和“后端到前端 (back-to-front) ”策略后。你可以在实际应用全过程中混合使用两种方法。“后端到前端”的策略通常止于消息端口，而这个消息端口使用的 AIC 和 SOC 。你可以使用一个测试框架（ test framework ）来激活 AIC 或 SOC ，也可以使用专用信道和消息信道来测试。
“前端到后端”策略通常以一个测试用的 AIC ，而这个 AIC 与某个消息端口相关联。在软件产品设计的测试中，你可以使用产品使用的 AIC 或 SOC 来替代测试用 AIC 。
可见，与消息信道相关联的 AIC 或 SOC 就是你融合两种方法策略的结合点。当你融合两种策略时，这个闭环和该闭环的实现就以 Web Method 的形式完成了商业逻辑。
-end-