系统与邮件集成

在我开发的业务系统中,用户常常会要求系统提供一些提醒/报警功能,如库存预警,工作提醒之类.通常开发人员会根据业务直接做一个窗口显示要提醒的内容,在用户登录时弹出.或者采用论坛消息的方式来告诉用户有紧急内容.而且也确实有一些中小企业没有企业邮箱,也不准备在短时间内使用企业邮箱.
不过,随着网络不断普及,其质量不断提高,企业邮箱的成本越来越低,会有越来越多的企业会使用企业邮箱.这其中又孕藏着另一个商机:网管服务外包.这个就是后话了.不过对上面提到的用户需求,我通常都会建议使用邮箱功能,把相关的信息发给需要被通知的人.这两种方案各有优劣:
使用企业邮箱要求员工必须在工作时注意及时查收邮件,而使用消息,则只有业务系统的用户才可以接收消息,登录到系统之后才能收到消息.
邮箱的处理相对简单,而消息机制则要花费更多的功夫,消耗的资源相对较多.
邮箱机制的限制相对较少.
消息必须定期清理.
邮箱的反馈不及时.

我们可以得出一个有趣的结论,没有完美的解决方案.在适合的地方采用适合的方案,如果你觉得消息机制更适合你的业务,尽管采用.反之,邮箱机制可以为你提供更好的集成特性,为什么不选它呢?
而在我的项目中,有些业务流程的各个环节非常紧凑,但通常都是由同一批人来完成,不存在通知的需求.另一些则是非常重要但不急迫的事,比如发给供应商的通知,与客户的沟通,甚至与企业内部其它部门(不使用系统)的单据往来,我都会采用邮件的机制.唯一的问题就是有些企业确实没有使用邮箱的文化,而且一些岗位根本不可能使用电脑.这样的话,就要使用短信集成了,我想这个方案唯一可能的缺点就是费用.
从上面这个案例得出的结论是:集成的方案往往比单一的方案有更好的适用性,能更好地解决用户需求.同时也要求软件供应商在技术方案上有更高的技术含量.不要以偏概全,不然就常常会看到类似iBatis与Hibernate之争, JUnit与TestNG之争,CMMI与Agile之争....争论是件好事,不过前提是你提出的观点论据要有说服力.否则,最终会演变成一出闹剧.