顧問設計了一個系統，使用電子郵件作爲web服務

Question

我正在尋找一個解決方案提供一個公共的webserver宿主aspx表單和基於用戶輸入的XML格式的內容在電子郵件正文並將其發送到僅用於此解決方案的電子郵件地址。然後公司防火牆後面的內部系統在從電子郵件服務器檢索電子郵件並從那裏進行處理之後讀取XML。我不認爲這將是一個強有力的解決方案，並且擔心維護它將只是現在取而代之，但仍有解決問題的壓力。

感謝

Answer 1

您大多不能在不知道具體的約束判斷一個架構解決方案的可能性。

在一定的限制條件下，這可能是最好的解決方案。

讓我們來看看薄弱點第一：

• 消息可能會丟失，由於無法提供郵件服務。
• 郵件服務的郵件可能太大。 （在我的公司，我們有例如10Mb的限制。）
• 傳輸時可能會損壞郵件。 （郵件服務可能會應用病毒掃描程序並誇耀這個事實，添加頁腳，重命名附件等）
• 郵件系統可能無法應對額外的負擔，如果郵件流量過大。
• 交貨順序不保證。
• 該解決方案有點非常規。
• 安全和其他非func可能不符合。

在另一方面：

• 這可能是（非常實用）實現異步消息的。異步消息傳遞通常比同步解決方案更加強大和可靠。
• 該解決方案使用現有的基礎架構。
• 郵件系統通常不會丟失「如此」的消息。所以我們基本上有一個可靠的持久消息存儲。
• 郵件系統通常被認爲是「關鍵任務」，因此他們通常構建高度可靠和冗餘。所以使用郵件服務實際上可能比引入一個新的軟件/硬件組件更可靠更多。
• 而且便宜。
• 可以用非常實用的方法進行測試。
• 電子郵件有良好的圖書館支持。
• 你不需要昂貴的專業人員來執行。

所以，想象以下約束：

• 建立一個異步消息處理。
• 失去一小部分消息並不是什麼大不了的事情。
• 快點。
• 做便宜。
• 快速和骯髒的是好的（「我們會在三個月內把它扔掉」）。

在這些限制下，這可能是一個非常好的和實用的解決方案。

要通過@techtrek解決了這一點：

• 1. 「更強大」 - 見上面，郵件系統實際上可能比內部ESB基礎設施更可靠。至少這是我的經驗。
• 1. 同意，但不是這樣有風險。無論如何，附件通常不會被損壞。否則，管理人員每次PowerPoint幻燈片損壞時都會尖叫。
• 電子郵件服務向下 - 好，ESB或任何內部服務可能會下降，以及。
• 1. 我不太明白爲什麼電子郵件追蹤更復雜。我發送一封電子郵件，它要麼到達，要麼不到。如果沒有，那麼這是郵件服務的問題。 「複雜」相比有哪些？
• 1. 那麼，郵件服務管理當然是分開的，爲什麼這是維護頭痛？我們實際上擁有所有的平臺服務（數據庫，服務器，ESB等），由不同的團隊進行管理和維護。這是一個正常的做法，我不明白爲什麼它應該是一個問題在這裏。相反，通過郵件服務，您可能擁有一支專門致力於該傳輸通道可靠性的專業團隊。

坦率地說，我看到好幾個ESB/MQ的解決方案，我真的認爲，這將是更便宜，更方便，在實際上更加可靠，如果幾個不同的應用程序將只是給每個其他電子-mails。

Answer 2

使用電子郵件作爲中繼代理的問題是：

1. 創建一個Web服務，可以讓您的公司的內部系統直接攔截並解析XML體系似乎更強大的對我。

2. 在傳輸協議（Email）中封裝XML MIME類型本身就是有風險的。

3. 作爲（2）的結果，有兩個故障點（xml轉換過程中的損壞）以及電子郵件服務發生故障的風險。

4. 除了僅僅失敗點之外，您還將追溯性複雜化了一個數量級。

5. 電子郵件管理通常與Web服務的管理分離。除非有真實的，合法的否定，否則這聽起來更像是維修頭痛？

Answer 3

我同意已經說過的話，尤其是對第4點。應用程序和電子郵件維護可能會斷開實體。

另一個方面要考慮的是TI從任何地方發送郵件到後端和洪水這種方式