最常见的是ApacheSOAP ， 它提供一个servlet（RPCRouter）来接收传入的SOAP/HTTP请求 ， 假如需要的话对它们进行解码 ， 然后将它们传递给目标Java对象 。这是最初的实现 ， 但不幸的是它受到了一个主要问题的困扰：由于它使用DOM来处理XML ， 所以速度比较慢 。处理SOAP中使用的XML可能是最慢的 ， 而且可能是Web服务请求中最集中的处理部分 。由于这个和其他几个原因 ， 已经发起了另一个倡导 ， 并且这个倡导已经成了Apache项目Axis的一部分 。它对SOAP消息使用SAX解析 ， 这就为XML提供了一个简单而又更加快捷的接口 。Axis项目的工作正在进行中 ， 即将发行代码的beta测试版 。
这个项目使用Axis是因为它速度更快 。从理论上讲 ， 由于我们将对请求作异步处理 ， 因此性能在这里并不那么重要 。但这并不意味着我们就可以心安理得地慢下来 ， 或者能接受DOM解析器的额外处理要求 。我们只要解析XML就可以让服务器败下阵来 ， 更不要说Web服务自身的处理要求了 。
高级设计
高级设计使用的是启动时加载（load-at-startup）servlet 。这些servlet启动使用原始SMTP绑定到端口25并等待传入的电子邮件的守护线程 ， 或者周期性地向POP服务器轮询等待中的电子邮件的守护线程 。图1显示了POPservlet、轮询守护程序、处理器以及处理程序之间的一个对象交互图：
图1.对象交互图
【使用SMTP和WebSphere Studio的Web服务—引言和设计】
守护线程将根据它们正处理的协议做不同的工作 。对于原始SMTP ， 该线程将获得一个连接请求 ， 然后将套接字传递给一个处理器（Processor）类来处理SMTP协议并检索电子邮件 。对于POP实现 ， 该线程将周期性地轮询POP服务器 ， 并将各个电子邮件传递给特定于POP的处理器类 。
我们的处理器类实现一个MailProcessor接口 ， 并可以继续一个AbstractProcessor类 ， AbstractProcessor包含我们所需的每个电子邮件协议都有的公共函数 。这些类获得电子邮件并将它们传递给一串处理程序（Handler）对象 。
处理程序对象链可以被配置为执行日志记录、将服务请求传递给SOAP引擎或处理响应等独立的任务 。我们的处理程序类可以继续AbstractHandler ， 也包含公共函数 。
结束语
本文介绍了许多关于我们的SOAP/SMTP实现的背景知识 ， 包括SOAP/SMTP的优点、各种方法的优缺点和高级设计 。下一篇文章将讨论实际的实现 ， 包括怎样开始实现以及如何让该实现在WebSphereStudioIDE中运行 。
推荐阅读
- switch日版和港版区别
- SMTP在X.25上
- 手机QQWiFi免费上网 QQWiFi是怎么使用
- qq同步怎么转移照片
- 平移和旋转有什么相同点和不同点
- 太和殿屋檐上的仙人走兽分别叫什么名字
- 按键精灵安卓版找图 按键精灵安卓版找图使用技巧
- 萧道成和萧衍是什么关系
- 兰字的寓意和象征
- Motorola KRZR K1使用感受