未来BizTalk商业整合之路，还有多远（ 一）

不同的协议，规范以及公用技术都是通过 网络构建的，每个都能解决特定的问题。这些通用的网络缩写不仅仅是一个命名，通常一个命名能引起一整套模型集合来解决问题。以FTP, HTML, XML或 SOAP为例，我将把ISB补充到日益增长的缩写模型里。

    一个ISB就是一个服务“结构”，完全在网络上操作，而不是像Enterprise Service Buses和其他信息技术一样，主要在Enterprise上操作。几个月前，微软发行了Community Technology Preview (CTP) ISB，命名为BizTalk Services。BizTalk Services CTP对于企业应用程序集成或信息世界就像Hotmail 或者 GMail属于邮件世界一样。因为BizTalk Services CTP是以EAI和Messaging解决方案为基础的，因此可以把BizTalk Services CTP看成是以EAI服务或信息解决方案为基础的自由的"as-is" 软件服务。

    下面我会解释BizTalk Services的所有部件，因此你可以创建自己的EAI or Messaging解决方案。本文除了创建一个信息解决方案以外，最重要的是，你能感觉到BizTalk 和 WCF未来的潜能。

The BizTalk Services Tapestry

   BizTalk Services引进了Internet Service Bus (ISB)的概念。集成产品一般作为代理或者消息而工作，并且在许多解决方案中提供 安全。一个ISB服务同一个目的，它只是网络间的一种服务，而不是非得配置或保持在你的构建中。和许多集成解决方案一样，BizTalk Services包括SOA概念，这些概念都是建立在WS* (SOAP, WS-Trust等)基础上的。

   回顾了BizTalk Roadmap以后，明显看出WCF and WF是未来BizTalk解决方案的常用“结构”。但是却不容易看出：还要走多远，这些新的解决方案才能解决这些商业问题。过度强调“缺陷”和“开发新方 法”让人觉得BizTalk Services想打开一个对话来回答这个与深度有关的问题，想给微软定一个方向，在通往未来BizTalk 和.NET Framework的路上，哪里才是第一个站。

    就目前的构造而言，BizTalk Services是一个Community Technology Preview。当我们在BizTalk Labs上阅读资料时，很明显就能看到这点。和许多CTPs一样，它不是一个完整的解决方案，因为现在他只是为创建.NET Framework.的新特性提供了一个试验场。

BizTalk Services 和 .NET Framework

   BizTalk Services建立在Windows Communication Foundation (WCF) 和Cardspace的顶端。在这篇文章中，我们不会完整地回顾WCF and Cardspace。

   BizTalk Services结构体系包括以下部分：

B2B解决方案的连接服务（作为中继）：中继 服务器由微软控制。使用中继连接的应用程序向中继发送信息。收听应用程序听从于中继，并从中继重新找回信息。

身份证明服务处理安全：Identity Service是一个安全标记服务。在客户方，Identity Service依赖于Cardspace。

中继连接是BizTalk Services SDK的主要组件。和所有WCF解决方案一样，一个连接命令传输，信息译码器，信息交流模型以及一个Channel Stack。

工作流量支持被隐藏为后来的数据，但是在这篇文章中我们就不再列出了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27035/viewspace-331214/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27035/viewspace-331214/