系統與郵件集成

在我開發的業務系統中,用戶常常會要求系統提供一些提醒/報警功能,如庫存預警,工作提醒之類.通常開發人員會根據業務直接做一個窗口顯示要提醒的內容,在用戶登錄時彈出.或者採用論壇消息的方式來告訴用戶有緊急內容.而且也確實有一些中小企業沒有企業郵箱,也不準備在短時間內使用企業郵箱.
不過,隨着網絡不斷普及,其質量不斷提高,企業郵箱的成本越來越低,會有越來越多的企業會使用企業郵箱.這其中又孕藏着另一個商機:網管服務外包.這個就是後話了.不過對上面提到的用戶需求,我通常都會建議使用郵箱功能,把相關的信息發給需要被通知的人.這兩種方案各有優劣:
使用企業郵箱要求員工必須在工作時注意及時查收郵件,而使用消息,則只有業務系統的用戶纔可以接收消息,登錄到系統之後才能收到消息.
郵箱的處理相對簡單,而消息機制則要花費更多的功夫,消耗的資源相對較多.
郵箱機制的限制相對較少.
消息必須定期清理.
郵箱的反饋不及時.

我們可以得出一個有趣的結論,沒有完美的解決方案.在適合的地方採用適合的方案,如果你覺得消息機制更適合你的業務,儘管採用.反之,郵箱機制可以爲你提供更好的集成特性,爲什麼不選它呢?
而在我的項目中,有些業務流程的各個環節非常緊湊,但通常都是由同一批人來完成,不存在通知的需求.另一些則是非常重要但不急迫的事,比如發給供應商的通知,與客戶的溝通,甚至與企業內部其它部門(不使用系統)的單據往來,我都會採用郵件的機制.唯一的問題就是有些企業確實沒有使用郵箱的文化,而且一些崗位根本不可能使用電腦.這樣的話,就要使用短信集成了,我想這個方案唯一可能的缺點就是費用.
從上面這個案例得出的結論是:集成的方案往往比單一的方案有更好的適用性,能更好地解決用戶需求.同時也要求軟件供應商在技術方案上有更高的技術含量.不要以偏概全,不然就常常會看到類似iBatis與Hibernate之爭, JUnit與TestNG之爭,CMMI與Agile之爭....爭論是件好事,不過前提是你提出的觀點論據要有說服力.否則,最終會演變成一出鬧劇.