使用SMTP和WebSphere Studio的Web服务—引言和设计( 二 )


SMTP
SMTP协议的直接实现要求我们在标准SMTP端口(25)上安装一个侦听器 , 然后在调用者连接到该端口时执行该协议指定的交互 。假如调用者不是通过中间机器而是直接连到我们的服务器上 , 那么Web服务客户机就可以确定消息已被接收;否则它会收到一个通信错误 , 并可以立即对这次通信失败采取相应的措施 。然而 , 若服务器宕机 , 就无法再进行纯异步的请求 。
由于在多个服务器间分配电子邮件负载的机制得到了广泛的理解 , 所以可伸缩性是很轻易实现的 。只要这多个服务器能处理请求 , 那么任何通过服务器多个实例之间的连接的适当路由都会成功 , 同时还提供工作负载治理和故障转移 。
由于SMTP实现将侦听每个连接在它端口上的客户机 , 所以任何发送至服务器的电子邮件都会被处理 , 而不管目标用户(请想一下电子邮件中的To:域)是谁 。因此 , 分派器例程能够轻松地为各个用户路由请求 。
POP
POP协议直到服务器上的电子邮件被请求时才释放它们 。客户机程序必须用显式方法将它们删除 。您的电子邮件程序或许被配置为检索后删除电子邮件 , 但根据该协议这只是对服务器的一个单独请求 。分派器将周期性地轮询POP服务器来检索每封电子邮件 , 向目标Web服务发送请求 , 然后在这些请求被处理后将它们删除 。由于没有一个直接的机制来告诉调用者电子邮件已被接收或已经发生了通信故障 , 因此这个过程是纯异步的 。
对于纯SMTP实现来说 , 可伸缩性的实现更为复杂 , 因为必须在分派器服务器之间做一些协调工作以避免一个请求的多服务情况 。
POP协议要求一个明确的用户标识和密码来连接和检索电子邮件 。假如您想为许多不同的用户标识处理请求 , 就需要向POP服务器轮询多个用户标识 。若服务器不仅要处理Web服务请求 , 还要处理为客户机提供的响应消息 , 或者要根据目标用户标识做出不同的路由决定 , 这么做就显得尤为重要 。
设计时的注重事项
在实现这样一个框架时总是有许多注重事项 。首先 , 尽量使前两种实现(POP和原始SMTP)有更多的共性很重要 。在多个地方做类似的事情是个不好的习惯 。其次 , 您应当尽量灵活 , 答应部署多个能对请求起作用的对象 , 并在将请求传送到实际的Web服务实现前尽可能做一下认证或其他一些检查工作 。灵活性的另一方面是使扩展—比如为另一个协议(例如IMAP)添加支持—轻易进行 。
您还要尽量多利用其他实现 。为此 , 这一系列文章将实现在Java应用程序服务器的Web容器内运行的代码 。首先 , 您在支持HTTPS协议的同时最好也支持SMTP协议 , 因此 , 将两种实现放到同一个运行时内是有意义的 。使用应用程序服务器也使伸缩、配置、部署和运行时支持变得更加轻易 , 因为您可以利用现有的基础设施而不必自己新创建什么东西 。
这种利用一部分是使用JavaMail以便能与SMTP顺利交互 。JavaMail是J2EE的一部分 , 所以它将自动被包含在任何遵守J2EE的应用程序服务器中 。
由于对任何代码而言 , 确保无错误才是要害 , 所以设计时可测性很重要 , 包括实现几个JUnit类来支持类的自动测试 。
您可能还想让分派器尽可能快地处理请求 , 不要等一个请求处理完后才去处理另一个请求 , 这样就要为每个请求启动一个新线程 。还是为了简单起见 , 您可以只创建一个新线程 , 而不必使用一个ThreadPool来使开销达到最少 , 就象在一个业界水平的实现中一样 。
两个SOAP供给商的故事
有趣的是 , 对于一个SOAP供给商来说有多种选择 , 并且它们都是Apache项目的一部分!

推荐阅读