用Java Web服务打造聊天程序

核心提示：Web服务是什么或者应该是什么有许多定义，每个或多或少都可以理解，用Java Web服务打造聊天程序，很有趣的事情是最简单的东西往往是最难描述的，眼前就有一个很好的例子：一个Web服务是一个可以和外部世界交换文档的实体，它还不是SOAP，它只是一个用于运行在相同JVM上的客户端的可工作的聊天服务器，这个实体是自我描述的

　　Web服务是什么或者应该是什么有许多定义，每个或多或少都可以理解。很有趣的事情是最简单的东西往往是最难描述的。眼前就有一个很好的例子：一个Web服务是一个可以和外部世界交换文档的实体。这个实体是自我描述的并且拥有一个唯一的特性。

　　这个文档内容是xml；严格来说是SOAP。SOAP（简单对象存取协议）定义Web服务消费和生成的XML文档的内部结构。SOAP被认为是一个行业标准并且被许多跨平台软件供给商、硬件平台、操作系统或者编程语言广泛地采用。

　　每个Web服务都有一个地址。这是它的ID。这个地址由一个URI（亦称URL）定义。一个Web服务存在于并且被它的URI标识。这个地址经常被称为一个终端。这个ID和内容的安全性毫无关系。本教程的服务存在于http://localhost:6060/ChatService/。

　　Web服务带有它自己的描述。这告诉你它交换的是什么类型的文档。它说明了服务存在于什么地方（URI地址）。并且它还说明了它可以使用哪个传输协议来交换文档。Web服务描述使用的语言是WSDL（Web服务定义语言）。一个Web服务完全由它的WSDL文档描述。为了和一个独立Web服务通讯，你只需要WSDL文档。即使WSDL在它自己的上下文中描述Web服务，它还是无法描述多个Web服务组合起来所形成的美妙的乐章。

　　Web服务有一个地址，但是为了访问它，你需要发现它在哪儿。换句话说，你需要一个电话号簿列表Web服务。UDDI (通用描述、发现和集成）是行业标准的电话号码薄。UDDI处理寄存器并且发现Web服务。

　　综合起来，一个Web服务就是和现实世界交换SOAP文档的一个实体，使用一些URI定位，使用WSDL文档描述并且可以使用UDDI注册来列出并发现。 一个真实的示例

　　无数类型的文档可以被发送到Web服务并来源于Web服务。它可以是一个钢厂中的周期的温度报道，它可以是一个地方政府定义的退税请求，或者它可以是一个从一个软件组件到另一个组件的RPC调用的文档风格表现。同样的情况也发生在文档交换方案中。 你可以设想单向的消息或者请求-响应消息传送，这里面都需要跟随一个响应文档的请求文档。 Web服务大部分当前的用法遵循XML模式上的远程过程调用。这就是为什么开发者可以很轻易转到开发Web服务，而不要对现有的应用程序做重大的修改，或者之需要付出最小的努力就能创建用于Web服务的客户端。Web服务框架经常可以隐藏底层体系结构的复杂性。他们通常提供了用于从语言到WSDL和从WSDL到语言生成的工具。展示象Web服务这样的语言结构比手工处理XML文档快得多并且轻易的多。现在，Web服务经常用作一个集成工具，让开发者和系统设计师互连不同的应用程序。

　　即使本文中的Web服务和它的客户端遵循XML模式上的远程过程调用，但是Web服务的应用范围是非常宽广的。近期，有许多基于松散耦合的纯文档交换模式实现。

　　一个简单的聊天服务器

　　在本文中，我试图创建一个比闻名的股票行情服务更具挑战的应用程序，但是仍然简单易读。它是一个聊天服务器应用程序。聊天服务器的功能是非常简单的客户端或者发送新消息并读取它们。

　　这个聊天服务器实现是与Wasp和Web服务完全互不相关的。它可以成功地被编译并且用于任何其他的java环境。这个聊天服务器还描述预存在的业务逻辑。请查看代码来领会。你可以在这里下载用于聊天实现的源代码（而不是Web服务，那个还没有写）。

　　设计聊天服务器

　　聊天服务器的全部的实现被分割到好几个类中。接口定义在程序包com.systinet.simplechat.server.iface中。它由三个类组成；聊天服务器的接口类IChatService.java和用于聊天消息的表现两个结构和participants-ChatMessage.java和ChatPerson.java。

　　聊天服务器的实现在程序包com.systinet.simplechat.server.impl中。它把简单的接口的实现从后端业务逻辑中分离出来。我使用了适配器设计模式，那就是说，到ChatService.java的调用被委托给一个后端处理机。业务逻辑是相当简单的。它是在一个集合中保存消息的SimpleBackendImpl.java类的单一实例。

　　初看起来，置配器/后端实现看起来对于用于一个简单的教程太复杂了。然而，即使复杂的现有的业务逻辑可以被重使用来变成一个没有任何改变它的代码的需要的Web服务。这是一个常见的现实的使用案例。即使应用程序没有使用原来的适配器模式，编写一个象ChatService这样的包装类，不需要重写原始的后端程序逻辑。然而，后端可以使用JDBC和一个关系数据库来实现，否则作为一个EJB，甚至调用外部非Java应用程序的本地方法。可能发生的事是无穷尽的。适配器模式只答应你很快地触发新的后端逻辑。 把一个聊天服务器转为一个Web服务

　　现在，这个聊天服务器只是一个Java实现。它还不是SOAP。它只是一个用于运行在相同JVM上的客户端的可工作的聊天服务器。下一步就是生成聊天服务器发言SOAP并且创建一个描述它的WSDL文档。