Web services 顾问设计了一个系统，将电子邮件作为Web服务

我正在寻找一些针对提供的解决方案的可靠论据，其中面向公众的Web服务器承载一个aspx表单，并根据用户输入将表单内容以XML形式放置在电子邮件正文中，并将其发送到仅用于此解决方案的电子邮件地址。然后，公司防火墙后面的内部系统在从电子邮件服务器检索电子邮件后读取XML并从那里进行处理。我不认为这将是一个强大的解决方案，并关心如何维护它，所以我宁愿现在就更换它，但有压力保持解决方案

---

谢谢

使用电子邮件作为中继代理的问题是：

对我来说，创建一个允许公司内部系统直接拦截和解析XML系统的Web服务似乎要健壮得多

在传输协议（电子邮件）中封装XML mime类型本身就有风险

作为（2）的结果，存在两个故障点（xml转换过程中的损坏）和电子邮件服务崩溃的风险

除了故障点之外，您还使可追溯性复杂化了一个数量级

电子邮件管理通常与web服务的管理分开。除非有真正合法的理由，否则这听起来像是更令人头疼的维护问题

---

我同意所说的话，特别是在第4点上。应用程序和电子邮件维护可能是断开连接的实体

另一个要考虑的问题是，从任何地方发送邮件到后端，并以这种方式泛滥：

，在不知道具体约束的情况下，您基本上无法判断架构解决方案。 在某些限制条件下，这可能是最好的解决方案

让我们先来看看弱点：

• 由于邮件服务不可用，邮件可能会丢失
• 邮件对于邮件服务来说可能太大。（例如，在我的公司，我们有一个10Mb的限制。）
• 消息在传输时可能已损坏。（邮件服务可能会应用病毒扫描程序，并吹嘘这一事实，添加页脚，重命名附件等。）
• 如果消息流量过大，邮件系统可能无法应付额外的负担
• 交货顺序不保证
• 这个解决方案有点非常规
• 可能未履行安全和其他非职能

另一方面：

• 这可能是异步消息传递的一个（非常实用的）实现。异步消息传递通常比同步解决方案更强大、更可靠
• 此解决方案使用现有的基础架构
• 邮件系统通常不会丢失“仅此而已”的邮件。所以我们这里基本上有一个可靠的持久消息存储
• 邮件系统通常被认为是“任务关键型”的，因此它们通常是高度可靠和冗余的。因此，使用邮件服务实际上可能比引入新的软件/硬件组件更可靠
• 而且更便宜
• 可以用非常实用的方法进行测试
• 电子邮件有很好的库支持
• 您不需要昂贵的专业人员来实施

因此，想象一下以下约束条件：

• 构建异步消息处理
• 丢失一小部分消息并不是什么大问题
• 快点
• 便宜一点
• 又快又脏是可以的（“反正我们三个月后就把它扔掉了”）

在这些限制条件下，这可能是一个非常好且实用的解决方案。

要通过@techtrek解决这一点：

• “更健壮”-如上所述，邮件系统实际上可能比内部ESB基础设施更可靠。至少这是我的经验
• 同意，但没有那么危险。无论如何，附件通常不会损坏。否则，每当他们的PowerPoint幻灯片损坏时，管理层都会尖叫
• 电子邮件服务宕机——ESB或任何内部服务也可能宕机
• 我不太明白为什么电子邮件的可追溯性更复杂。我发了一封电子邮件，它要么到要么不到。如果不是，这就是邮件服务的问题。“复杂化”与什么相比
• 当然，邮件服务管理是独立的，为什么这是一个维护头痛？实际上，我们的所有平台服务（数据库、服务器、ESB等）都由不同的团队管理和维护。这是一个正常的做法，我不明白为什么这应该是一个问题。相反，通过邮件服务，您可能有一个专门致力于该传输通道可靠性的专业团队

---

坦率地说，我看到了很多ESB/MQ解决方案，我真的认为它们会便宜得多，如果几个不同的应用程序只是互相发送电子邮件，那么就更容易，事实上也更可靠。

这可能是关于主题的。这也意味着没有公共界面服务-取决于公司的基础设施，这可能是最好的解决方案。电子邮件在提供商处缓冲，“公司互联网”可以拥有移动IP（dsl风格），而无需费心。我认为这是一个“程序员想要最佳解决方案而忽略现实世界的限制”的例子。