BizTalk Framework定义文档 [英] BizTalk Framework definition document
问题描述
Hi Folks，
我的任务是做一个BizTalk Framework定义文档，并希望得到关于你认为可能会涉及到的内容的反馈，我的初步想法如下：
I have been tasked with doing a BizTalk Framework definition document and wanted feedback on what you think might go into it, my initial thoughts are below:
- 架构版本控制
- 服务版本控制
- 集成设计模式
- 日志和工具
- Windows Communication Foundation Bindings
- Windows Communication Foundation Bindings
- 企业服务总线消息标题
- Enterprise Service Bus Message Header
- 错误处理（关于如何使用ESB Toolkit异常管理的编码标准文档的大部分内容）
- Error Handling (majority to go into the Coding Standards document on how to use the ESB Toolkit Exception Mgmt)
- 路由和转换
- 审计 - 跟踪
- Auditing - Tracking
- 贸易伙伴管理 - 点亮此处，因为大多数是EAI解决方案
- Trading Partner Management - light here as the majority is an EAI solution
- 测试工具（BizTalk和SOA）
- Testing Tools (BizTalk and SOA)
然后我在考虑一些经典：
Then I was thinking about some of the classics:
- 松散耦合
- 抽象
- 可互操作
- 可重复使用
- 业务流程模式
- 架构和终点模式
- Schema and Endpoint Patterns
- 异步通信模式
请分享您的想法，并提出建设性的批评：）
Please share your thoughts and dish out constructive criticism :)
*注意我也在编写标准文档，所以那里可能会有些重叠，但我可以根据自己的需要切片和骰子。
*Note I'm doing a coding standards document too so there might be some overlap but I can slice and dice as I feel fit.
干杯
推荐答案
请考虑以下几点：
1。 Schema Root命名空间。
1. Schema Root namespaces.
2。类库命名空间。
3. 我已经为一般工作创建了自定义框架，例如异常处理和电子邮件发送等。这个框架可以被我的诉讼中的任何应用程序使用（不仅仅是biztalk应用程序）。尝试也考虑这种情况。
3. I have created Custom Framework for general work like Exception handling and email send etc. This framework can be used by any application in my suit (not only biztalk application). Try to consider this scenario as well.
4。对于丢失耦合的应用程序，尝试以这样的方式设计应用程序，以便将来不需要进行重大更改。就像使用编排时一样需要行动，否则数据转换使用发送/接收端口上的地图。
4. For losely coupled application try to design application in such a way that in future no major changes require. Like use orchestrations where it is actullly required otherwise for data transformation use map on send/receive ports.
这篇关于BizTalk Framework定义文档的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
