我正在寻找一些可靠的论据来反对所提供的解决方案，在该解决方案中，面向公众的Web服务器托管aspx表单，并根据用户输入将表单的内容以XML形式放置在电子邮件正文中，并将其发送到仅用于该解决方案的电子邮件地址。然后，公司防火墙后面的内部系统在从电子邮件服务器检索电子邮件后读取XML，并从那里进行处理。我不认为这将是一个强大的解决方案，也不关心维护它，所以我宁愿现在就替换它，但保持解决方案是有压力的。
感谢
您在不了解特定约束的情况下大多无法判断架构解决方案。
在某些限制条件下，这可能是最好的解决方案。
让我们先来看看弱点：
- 由于邮件服务不可用，邮件可能会丢失
- 邮件可能太大，无法使用邮件服务。（例如，在我的公司中，我们的限额为1000亿英镑。）
- 消息在传输时可能已损坏。（邮件服务可能会应用病毒扫描程序，并以此为荣，添加页脚，重命名附件等。）
- 如果邮件流量太大，邮件系统可能无法应付额外的负担
- 交货顺序没有保证
- 这种解决方案有些非常规
- 安全性和其他非功能可能无法实现
另一方面：
- 这可能是异步消息传递的一种（非常实用的）实现。异步消息传递通常比同步解决方案更强大、更可靠
- 此解决方案使用现有的基础架构
- 邮件系统通常不会丢失邮件。因此，我们在这里基本上有一个可靠的持久消息存储
- 邮件系统通常被认为是"关键任务"，因此它们通常是高度可靠和冗余的。因此，使用邮件服务实际上可能比引入新的软件/硬件组件更可靠
- 而且更便宜
- 可以用非常实用的方法进行测试
- 电子邮件具有良好的库支持
- 您不需要昂贵的专业人员来执行
因此，想象一下以下约束：
- 构建异步消息处理
- 丢失一小部分邮件并不是什么大不了的事
- 快一点
- 便宜一点
- 快速和肮脏是可以的（"无论如何，我们会在三个月后把它扔掉"）
在这些限制条件下，这可能是一个非常好且务实的解决方案
通过@techtrek:来解决这一问题
-
- "更加健壮"——如上所述，邮件系统实际上可能比内部ESB基础设施更可靠。至少这是我的经验
-
- 同意，但风险不大。附件通常不会损坏。否则，每当他们的PowerPoint幻灯片被破坏时，管理层就会尖叫
-
- 电子邮件服务坏了，ESB或任何内部服务也可能坏掉
-
- 我不太明白为什么电子邮件的可追溯性更复杂。我发了一封电子邮件，要么收到，要么不收到。如果没有，那么这就是邮件服务的问题。"复杂化"与什么相比
-
- 当然，邮件服务管理是分开的，为什么这是一个令人头疼的维护问题？实际上，我们拥有由独立团队管理和维护的所有平台服务（数据库、服务器、ESB等）。这是一种正常的做法，我不明白为什么这里会有问题。相反，对于邮件服务，您可能有一个专门致力于该传输通道可靠性的专业团队
坦率地说，我看到了很多ESB/MQ解决方案，我真的认为如果几个不同的应用程序只相互发送电子邮件，它会更便宜、更容易，而且事实上更可靠。
使用电子邮件作为中继代理的问题是：
-
创建一个允许贵公司内部系统直接拦截和解析XML系统的Web服务对我来说似乎要强大得多
-
将XML mime类型封装在传输协议（电子邮件）中本身就有风险。
-
由于（2），存在两个失败点（xml转换过程中的损坏）以及电子邮件服务崩溃的风险。
-
除了故障点，您还将使可追溯性复杂化一个数量级。
-
电子邮件管理通常与web服务的管理分开。除非有真正的、合法的回报，否则这听起来更像是维护方面的头痛？
我同意所说的，特别是在第4点上。应用程序和电子邮件维护可能是断开连接的实体。
另一个需要考虑的方面是从任何地方向后端发送邮件并以这种方式泛滥的可能性