Web services 设计两个系统之间交换数据的体系结构

我的任务是创建一个中间层，它需要在两个独立的系统（例如，接收方中间层（IL）发送方）之间交换数据（通过HTTP）。接收方和发送方都通过Web服务公开一组API。每次发送方系统中发生事务时，IL都应该知道它（我正在考虑创建一个Windows服务，不断ping发送方），对数据进行处理，然后将其传递给接收方。IL可以临时将数据存储在SQL数据库中，直到数据传输到接收方。我有以下问题-

WCF（没有经常使用）可以用来与发送者和接收者（都公开web服务）对话吗

我如何确保保证交货

我如何确保互联网上信息的安全性

处理并发问题的最佳实践是什么

错误处理的最佳实践是什么

如何确保数据的可靠性（数据不会被篡改）

如何确保将数据返回给发件人

我需要注意哪些约束条件

我需要使用自定义的.NET解决方案在MS平台上实现这一点。我被告知不要使用任何像BizTalk这样的中间件。接收器是SDFC实例，如果这很重要的话

---

非常感谢您的指点。谢谢。

一个Windows服务，可以让乐队进行交流，听起来不错。 是的，WCF可以处理传统的Web服务

我如何确保保证交货

为了确保交付，您可以使用来处理

接收者中间层

和

发送者中间层

，但我不会尝试一起做

您可能需要考虑某种排队机制来将数据发送到接收方；我想我更多考虑的是逻辑队列，而不是实际的队列组件。工作流框架也可以是一种选择

确保您有良好的日志记录/审计；确保它坚如磐石，有正确的信息，易于阅读。假设您编写的服务将在没有监督的情况下执行，因此操作/支持方面的要求更高

考虑一下场景：

• 您如何管理失败的交付
• 如果接收者（或发送者）在一段时间内不可用（这段时间有多长？）；例如：您是否需要通过电子邮件“上报”给操作员

我如何确保互联网上信息的安全性

HTTPS。假设其他现有客户端调用Web服务，它们如何确保安全性？（我在考虑加密）

处理并发问题的最佳实践是什么

嗯，可能是另外一个问题。你应该能够很容易地找到这方面的信息。我们采集了多少数据？什么频率？您想拥有多少个Windows服务实例？如果一个就足够了，为什么并发性会成为一个问题

错误处理的最佳实践是什么

与并发性相同，但我可以提供一些提示：

• 使用一个已建立的日志框架，我非常喜欢MS EntLibs，但也有其他框架（重新使用当前使用的东西可能会更有意义——如果有的话）
• 请记住，执行是无人参与的，因此请确保信息完整、清晰、明确。一旦达到舒适的程度，我会尝试记录更多的日志并将其调低
• 使用顶级处理程序确保没有丢失任何get；但是唐；不要害怕深入应用程序，在应用程序中仍然可以获得有用的上下文（如发送/接收数据的元数据）

如何确保将数据返回给发件人

包括它（发送收据）作为交易的一部分

从另一个角度看——看看CodePlex for ESB类型库，您可能会发现一些有用的东西：

---

例如，它似乎是一个可以重用的类库。

为什么不使用Biztalk（成本或技术问题）？同样的限制是否也适用于其他解决方案？那么开源呢？你真的必须自己写所有的代码吗？实际上不确定。但我认为这可能是成本，因为这是一家小公司。谢谢你的详细回复！非常感谢。我倾向于使用MSMQ来确保在事务范围内保证交付。即使中间系统关闭，消息仍在队列中，系统将在恢复联机后传输消息，这样我就不会丢失它们。根据您的回答，我正在考虑创建一个WCF客户端，它同时使用发送方和接收方的Web服务，使用广泛的日志记录，提供一个前端简单的Windows UI，以便普通用户可以看到什么被拉入和发送，使用广泛的日志记录，以及使用HTTPS。我走对了吗？回答你的一些问题，每天可能有几千笔交易，但不确定交易的频率。我正在考虑只使用一个Windows服务，但我有点担心将同一条数据处理两次。使用MSMQ，如果消息在队列中很长时间，我可以向管理员发送电子邮件。如果接收者或发送者不可用，它应该能够从中断的地方恢复（我如何实现这一点？）。非常感谢。是的，我认为你走对了路。我以前没有使用过MSMQ，我唯一关心的是如何将它与接收器web服务集成-如果你能找到一个好的解决方案。哦，是的-只要你开发正确，你就可以通过WCF使用消息队列（在引擎盖下使用MSMQ）。非常感谢你，Adrian K！