我在网上读到，您将“外部模式”与“内部模式”分开，并且永远不要将“内部模式”暴露给任何外部参与者。
如果我的解决方案仅充当消息总线来在两个现有系统之间创建松散耦合，我真的需要任何内部模式吗？
System A makes a Request(Message with SchemaA) to Biztalk
Biztalk Maps SchemaA to SchemaB
Biztalk forwards request of type SchemaB to SystemB
SystemB returns ResponseB
Biztalk maps ResponeB to ResponeA
Biztalk routes the result back to System A
我看不出拥有内部架构和地图的优点：
架构 -> 内部架构 -> 架构
?
期限canonical schema http://en.wikipedia.org/wiki/Canonical_model通常用于描述内部模式的创建（SchemaInternal在你的最后一个例子中）到诸如 BizTalk 之类的集成机制。
使用规范模式被广泛认为是一种最佳实践 http://msdn.microsoft.com/en-us/magazine/cc163423.aspx，因为它将您的 BizTalk 流程控制映射与任何“其他”系统的架构解耦（此处的其他系统可能位于您的组织内部或外部，例如供应商、客户或合作伙伴系统）。这样，如果通过 BizTalk 集成的任何系统发生变化，它只是外部架构，并映射到需要更改的规范架构。它还可以防止外部架构中固有的外部约定、命名和层次结构差异泄漏到您的内部 BizTalk 工件中。
一般来说，传入消息到规范模式的转换是尽早完成的，例如在接收时，同样，尽可能晚地完成规范转换，例如在发送端口映射上。
规范模式 (CS) 的常见场景是多个交易方共用一个编排或消息流（例如，您可能有许多具有不同系统的供应商，但是它们都提交发票进行处理）。在这种情况下，每个新的供应商系统只需要与您的 CS 集成 - 不需要添加或复制新的处理逻辑 - CS 实际上可以减少这种情况下的总体工作量。 （n x m问题详细解释here https://www.ibm.com/developerworks/community/blogs/SOAPatterns/entry/the_canonical_message_model_pattern?lang=en）。 CS 至关重要的另一个例子是您的业务需要交换消息 - 例如医疗行业交换机将有许多医生和执业系统发送授权请求和发票，这些需要映射并路由到多个医疗基金（医疗援助）系统。
还有FWIW：
- 当 BizTalk 是 EAI 或 ESB 场景中的端到端解决方案时（例如，IMO CS）最有意义。直接集成 2 个或更多业务线系统。否则，如果 BizTalk 只是大型企业 ESB 上的一个端点，那么使用企业 ESB 架构可能是有意义的内部，因此将外部模式直接映射到 ESB 模式（即不需要anotherBizTalk 中的 CS 集（前提是您的企业拥有良好的变更管理/版本控制机制）。
- 如果标准模式（例如EDIFACT http://en.wikipedia.org/wiki/XML/EDIFACT）对于您的行业来说存在，因此采用这些作为内部 CS 是否是一个目标是没有意义的。一般来说，这些可能与以下的含义相冲突典范因为行业模式通常需要很详细才能对文档的所有风格和“边缘情况”进行建模）。就我个人而言，我会确保我有一个到/来自所述行业模式的映射，但会在内部使用自定义模式。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
