在使用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来测试好多了。以下是如何创建测试用消息端口、信道的步骤：
1)创建使用AIC作为传输口（transport）的消息端口（模板）；
2)信道可以使用空文档作为源文档和目标文档，不需要映射（map）定义。
3)使用BizTalk Editor生成一个合法实现（instance）文档；
4)改写SubmitSync.vbs的副本，使得文档提交到前面所述的信道；
5)使用浏览器将要提交的文档拖放到SubmitSync.vbs，BizTalk Messaging Service将传送该文档到AIC，并返回回复（response）文档。（这个vbs将回复写到同名的文件中）
对于定制开发的组件，无论AIC还是COM，交互式的debug都很有用。以下是debug技术步骤：
1)在开发环境中，设置断点，将工程设置为debug模式；
2)为了确保BizTalk Messaging Service没有加载一个非debug版的AIC，你必须停止并重新启动BizTalk Messaging Service；（你可以使用RestartBTS.cmd）
3)如果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等均需要作改变、刷新、重新编译。你可以遵照以下：
1)使用BizTalk Mapper更新所有的映射；
2)使用BTM_Refresh.exe来更新BizTalk实体；（你可以在…Program filesMicrosoft BizTalk ServerSDKmassaging samplesRefresh Messaging Manager找到这个程序）
3)使用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 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
当信道和消息端口都被准备好以后，你可以创建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-
<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
99
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
