What is WebServices

同进程查找JDNI服务
比如说我们通过JNDI来查找Tomcat中配置的DataSource，代码如下
Context context = new InitialContext();
DataSource ds = (DataSource)context.lookup("java:/comp/env/jdbc/oracleds");
将这两行代码放到JSP页面中，在new InitialContext()之后，就能在JNDI服务上查到DataSource
这是因为JSP和JNDI服务是在同一个进程里的。但如果不是同一个进程，则不能new InitialContext()
这就好像是两间屋子里面的资源无法共享一样，除非穿墙，否则是无法拿到对面屋子里的资源的
所以在main()方法中是无法有效的执行这两行代码的
因为在运行main()方法时，它会在一个进程中启动JVM来解析class，而Tomcat那里又是另外一个进程
所以在这两个进程之间，只是通过简单的new InitialContext()是找不到JNDI服务的，事实上这个过程就是在远程调用
其实所谓的远程，并不是说跨机器、跨网络就是远程，只要是两个进程之间的调用，就算是远程调用了
也就是说只要是不在同一个JVM里面(更准确的来说是不在同一个地址空间内)的调用，它就是远程调用
也就是说如果我们在同一个机器上，启动两个进程，然后进行互相调用，那么这个过程就已经是远程调用了

分布式通信的基本原理
主要是使用客户端上的Stub(存根)和远程对象上的Skeleton(骨架)作为中介，来实现分布式通信的
在客户端会有一个叫做Stub(存根)的东西，其实现采用的是非常典型的代理模式，是远程对象在客户端的代理
Stub会封装所交互的数据的访问细节(如何压缩、压包、编码等)，然后通过相应的协议与Skeleton(骨架)交换数据
对于Java领域的分布式通信技术，较常见的有EJB技术、CORBA技术、WebService技术等等
如果是EJB技术，那么Stub就会采用RMI-IIOP协议来传送数据给Skeleton
如果是CORBA技术，那么Stub就会采用IIOP协议来传送数据给Skeleton
如果是WebServices技术，那么Stub就会通过SOAP(搜魄)协议来传送数据给Skeleton
也就是说Stub会按照特定协议将信息传送给Skeletion
而Skeleton会将Stub传送过来的数据解析成特定的语言对象并发送给远程对象，即服务端
比如说服务端是采用Java开发的，那么Skeleton就会将接收到的数据解析成Java对象，再传送给服务端
同理若服务端是采用C#开发的，那么Skeleton就会将接收到的数据解析成C#对象，再传送给服务端
接着服务端就会返回信息给客户端，于是Skeleton就会将所要返回的信息进行压缩编码并通过相应的协议传送给Stub
接着Stub就会将Skeleton传送过来的信息解开，再传送给客户端，所以客户端就获得了相应的服务端的返回信息了
这里的客户端对象和远程对象是位于不同的JVM中的，或者说是不同的系统平台中，此即分布式通信
它主要就是靠Stub和Skeleton来通讯，说白了，分布式通信也就是Stub和Skeleton之间的通信

分布式通信的举例
假设有两个服务器，本地的服务器采用的是Java开发的，远程的是一个采用C#开发的天气预报的服务器，二者可以通过以下几种方式通信
1、如果二者不采用某些技术来通信的话，也是可以的
     比如远程服务器开放数据库表，然后本地服务器使用JDBC访问这个开放的数据库表，也能够实现分布式通信
     只不过开放数据库表的做法，不太好。会暴露表结构、安全性也不是特别好、并且也是不标准的
     另外有些数据，并不是单纯的一张表就能体现出来的，可能要通过一定的算法计算出来结果的
2、如果二者采用WebServices通信的话，那么就是使用SOAP协议来交互数据，该数据就是采用HTTP协议传送XML文件
     但此时双方进行通信的过程中，由于采用的是SOAP协议，所以双方交换的数据是大文本(通常是XML文件)文件
     这时就有一个问题：假设需要请求10000条数据，那么所交换的这个大文本文件的体积，将会是非常大的，传送的过程就会很耗时
     有一个解决办法是：可以让Java通过它的ZIP  API压缩该XML文件，然后上传到FTPServer上，服务端再下载这个压缩后的XML文件
     接着服务端再解压缩这个XML文件，然后读取，再进行相应的处理，这也是解决SOAP协议传递大文本文件的速度特别慢的办法之一
3、可以令远程服务器把天气预报的数据，定时的上报到某一个FTPServer，然后客户端的Java程序也定时的到FTPServer上取数据
4、第三种方式的缺点是不实时。我们也可以让客户端发送消息给远程的服务端，服务端会侦听，然后再发送消息返回给客户端
5、二者采用纯粹的IIOP(属于CORBA技术架构)协议来通信
6、如果远程服务器是采用EJB开发的，那么二者可以通过RMI-IIOP协议通信。而RMI-IIOP协议采用的是二进制传输，效率会更快
     由于EJB也应用了CORBA的IIOP协议，所以在异构系统整合的时候，CORBA的互通性会比较好
     步骤大致是服务器端先把EJB注射到JNDI树上，然后客户端的Java程序lookup这个JNDI树上对应的名字，这样EJB就传过来了
     也就是说此时Stub就动态的传到客户端的Java程序中了，然后客户端就调用Stub，接下来就是Stub和Skeleton打交道了
     另外EJB只能使用Java来写，但是可以使用CORBA技术来调用EJB

EJB的前生
在EJB1.X的时候，对于分布式通信的服务的支持还很差
比如写一个EJB的话，则至少要写三个类，然后编译，编译成Stub和Skeleton，这时大约会编译出来5、6个类
后来有所改善，最先改的就是JBOSS。开发JBOSS的EJB容器的这个人，在Java技术上是非常厉害的一个人，传说中的大牛吧
他引入了JDK的动态代理来完成Stub的自动生成，所以EJB的开发就简单了一些，只写三个类就可以了，存根会在运行时生成
也就是在把EJB注射到JNDI上之后，我们就可以在另一个JVM里面lookup这个JNDI的名字，这样便得到了EJB
然后它就会序列化的把EJB传送到客户端，它传的就是Stub，而它在JVM内存里面是看不见的
当我们在客户端调用相应方法的时候，其实在内存里面调用的就是Stub，然后Stub再与远端打交道

WebServices——解决异构系统之间的通信
从标准上来说，整个技术架构是WebServices(带s的)， 有时会看到很多人写成WebService(不带s的)，其实这是不标准的
WebService指的是单独一个服务，而WebServices指的是它的技术架构
目前WebServices技术使用的稍多些，因为它走的是HTTP协议，它可以穿越防火墙，它天生就能穿越80端口
但是WebServices的缺点就是：慢！！因为WebServices是基于HTTP协议传送大文本，实际传送的是XML文件
而IIOP(属于CORBA技术架构)协议传送的就是二进制，所以它的效率要比WebServices快很多
所以在一些行业里，也大量的使用了CORBA技术，比如说电信网
而CORBA的缺点就是：编程模型复杂，它是属于重量级的

SOAP——简单对象访问协议
假设我们在本地通过Java写一个main()方法与远程的一个可以是用任何语言写的取得天气预报的服务打交道
如果打交道的过程中采用的是WebServices技术的话，那么它传送给远程的就是XML文件，使用的是SOAP协议
SOAP即简单对象访问协议，其实质就是HTTP+XML，也就是说它是通过HTTP协议来传送XML文件
也就是说SOAP是基于XML的简易协议，可以使应用程序在HTTP之上进行信息交换
或者更简单地说SOAP是用于访问网络服务的协议，而一条SOAP消息就是一个普通的XML文档
使用SOAP协议通信的过程中，远程对象会将所要返回的信息形成一个XML文件传给Stub
然后客户端就会把XML文件转换成Java对象，而当客户端在调用远程服务时
客户端就会把Java对象转换成XML文件作为参数传给Skeleton，而Skeleton就负责把XML文件转换成远程服务的相应语言的对象
比如说服务端是采用Java开发的，那么Skeleton就会将接收到的数据解析成Java对象，再传送给服务端
同理若服务端是采用C#开发的，那么Skeleton就会将接收到的数据解析成C#对象，再传送给服务端
所以，WebServices能够实现异构语言的通信，可以用来整合异构系统
同理，如果不是异构系统的话，也就没有必要使用WebServices技术
比如说客户端和远程对象都是采用Java开发的，那么就没有必要使用WebServices了
因为二者都是采用Java开发的，它们之间可以直接以二进制来传输数据，访问效率会快的很多
而WebServices其实就是基于XML的数据交换，即WebServices所传送的是大文本，效率自然就慢了
除非我们的系统是采用多语言开发的，那么就可以考虑使用WebServices技术
或者说我们的系统想做的通用一些，则可以采用并开放WebServices的一些方法
其实SOAP就是用来最终完成Web服务的调用的，而WSDL则用于描述如何使用SOAP来调用Web服务

WSDL——WebServices描述语言
仍以上面为例，即客户端采用Java开发，服务端是采用C#开发的天气预报的服务
作为客户端，它知道在服务端提供了一个能够获取天气预报的服务，并且客户端也可以调用该服务
但作为服务端，应该对这些服务进行描述，以告诉客户端都有哪些服务可供调用
而这个服务是不能用C#语言来描述的，因为采用Java开发的客户端是无法识别的
所以服务端就需要使用一套语言来描述它所提供的服务，这套语言就是WSDL
其实WSDL就是一个XML文件，也就是说WebServices定义了一套标准，里面都是XML格式
使用这套标准来描述服务端对外提供的服务，比如C#的方法名、参数名、返回值等信息
假设服务端的天气预报功能还没有使用C#来实现，并且客户端也没有使用Java来实现
这时突然要求定义一套标准来描述一下即将准备实现的服务端的天气预报的功能
并且客户端可以任意调用这个天气预报功能，此时就可以写一套WSDL来描述方法名、参数、返回值等信息
当服务端的C#得到该WSDL时，就可以通过WSDL生成C#代码，然后它就可以把取得天气预报功能的逻辑补充上
而客户端的Java在得到这个WSDL之后，同样可以生成Java代码，然后把相应的约定的接口实现补充上
在使用WSDL生成相应语言的代码的过程中，就需要用到一些引擎来实现
比如在WebServices中就有：Axis、CXF、XFire等框架，它们就可以根据WSDL解析成Java代码
所以WSDL是一种中立的语言
而CORBA架构中也有类似于WSDL的一种东西，叫做IDL，它的语法类似于C++语言，但IDL不是C++

UDDI——发现和整合服务
类似于JNDI。客户端去寻找服务端所能提供的服务时，可以找UDDI索要，而UDDI就会把WSDL传送给客户端
实际上，该过程一般不通过UDDI，而是直接把WSDL拷贝过来就可以了，可以通过Email或硬盘直接拷贝
当客户端得到WSDL之后，就可以通过SOAP协议与远程的服务端进行通信了

 

转截：http://blog.csdn.net/jadyer/article/details/6065037