边想边学WebService

　　WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。　
　　第一次看到这么一个概念，有点不知其意。经过各方面知识的拓展。现在通过自己的经验来分析一下。Webservice是一种可以接收从Internet其他系统中传递过来的请求。先说请求：初学时就知道一个get请求和一个post请求，这都是http协议的。而网络协议多多，请求类型也很多，近期接触一个项目用到的就是soap请求。Soap-simple object access protocol简单对象访问协议，这个就是发送一个xml./http请求，得到的数据也都是xml形式。我们的需求就是用web程序去某c/s构架的系统中采集数据，这个系统提供一系统的北向接口，我们就可以通过soap得到该系统的一些数据。这也算是系统之间的简单交互了。但是，我们做的这个针对性特别强，我们要采集这个系统的数据，就必须使用这个系统提供的接口。那么webservice 一定是一套通用的接口。也就是说，你的系统想提花这样的接口就得按webservice的标准去提供，别的系统想用你系统的数据，就得按webservice提供的取法去取。

――――――这是学习前的一点猜想，下面带着这些猜想去看看webservice到底能干什么！
　　在网上查了点资料。看到webservice更为实质性描述了。Web Service是单一的、构件化的程序功能实体，能够通过网络，特别是万维网来描述、发布、定位及调用。Web Service的体系结构描述了三个角色（服务提供者、服务请求者和服务中介者）及三个操作（发布、查找和绑定）。这个跟我想的没多大的差异，三个角色，三个操作。我本来想着是两个角色，一个提供的，一个取的。两个，其实还有一个中介者。服务提供者不用想了，服务请求者也不用想，服务中介者不太清楚。三个操作。发布，这是服务提供者要做的，查找，这是请求者要做的，绑定，难道是中介者要做的吗？兴趣越来越浓，go on!
仔细看了一下在仔细想一下：中介者就出来了，如果像我上面的那种针对性很强的需求来说，根本用不上中介者这个概念。因为我就要到这一个系统上面去采数据。就我们两个就够了，你在这里，我在这，我跟你要，你给我！这就够了，但是想想现在要面对的是整个万维网。服务提供者多多，我怎么知道你在哪里，我得找到你才到跟你要东西啊！所以这个中介者就出来了，像租房的中介一个样！首先服务者在中介那里注册一下想提供哪些服务。请求者去中介者请求，中介查找到对应的服务提供者，ok，两个绑定一下。
刚刚又看到这么几句：

当开发人员开发新的应用时，可以登录服务中介者所提供UDDI搜索引擎的Web界面，并在UDDI注册表中查找自己所需要的Web Service，并通过UDDI注册表中的连接找到Web Service的调用细节，具体调用细节采用WSDL描述。开发人员可以使用开发工具或通过手工方式还原该调用细节，然后在自己的应用程序中根据WSDL的描述开发Web Service的客户端调用程序——这样开发出的应用就可以通过SOAP调用指定的Web Service了。如果Web Service应用仅在特定组织机构中使用，服务调用者完全可以通过其他途径获取Web Service的WSDL就可以移除系统架构中的服务中介者了。
看来跟我想的一样了，不知道去哪里找的时候就去中介找，在中介找到具体的地址以后，自己去连接这个服务，向这个服务发请求得数据。但是如果本身自己就知道这个服务的话，那么直接连，省去了，查找这一步。在想了一例子，比如想得到有关天气预报的一些信息，不知道去哪取，就应该先去中介找一下，看看哪有提供此项服务的，找到地址以后，直接发请求，取数据！理解的对不对还得接着学！
　　　　　　――――――――――――――概念更加清析了一层。但是，webservice到底怎么用还是不知道。
现在知道这么一个概念还不清楚具体要他干什么。我假设一个需求：javaeye网站是用ruby做的。但是全文查找想用lucence，但是lucence又是java写的，它用不了，那么我另开一个java小系统专门提供查找这项服务。不管你什么语言，你按标准的请求方式给我一个xml请求或是别的请求，我也给你一个你能看懂的数据。应该是用xml来传递。这就应该是webService主要的用武之地了吧？这是假设的，是不是这样，我还得往下看！
在往下看就到技术了。想实现这么一个需求，都要用到什么技术？
在Web Service的世界里，发布服务用UDDI（Universal Description, Discovery and Integration：统一描述、发现和集成）；查找服务使用UDDI和WSDL（Web Services Description Language ：Web Service描述语言）；而绑定服务使用WSDL和SOAP
现在知道技术有什么了，在上网查一下，有专门写webservice的框架，其他的就一点不知道了，看了一下，有两个框架比较惹眼，一个是axit 2,一个xfire.用哪个好？
Denis Robert 是这样说的：
No question about it, stick with XFire. You’ll be
happy about it. My only gripe with XFire is the docs,
which are woefully incomplete. Hopefully that will
change with time. For the time being, you have to
plow through the source for any complex service.
But architecturally, it’s really sound.

Axis2 is a nightmare. Even with XFire’s incomplete
docs, I was able to go through the source to figure
out what I needed. Axis2 is such a jumble of code that
doing the same thing would take weeks, not hours.

Also, compared to Axis2, XFire’s docs are positively
brilliant! Not only are Axis2’s docs fragmentary
at best, half of it doesn’t correpond to the current
version.

XFire looks like it’s going in the right direction,
and Dan Diephouse (the lead) seems like he’s on top
of the project.

You also have to take JAX-WS into account. Whether or
not it’s all it’s cracked up to be is another
discussion, but it nevertheless is the official standard.
The Axis2 team have made clear that they have
no intention of supporting it. JAX-RPC was horrible,
but it was at least common ground, and was the API
used by most enterprise users. Same will end up happening
with JAX-WS and JAXB 2. Websphere users will
end up using that, and knowing it’s out there will
make interop a lot easier. XFire has taken a “can’t
beat ‘em, join ‘em” approach here.

The way I see it, the Axis team dropped the ball on
this one, and the new kid has taken the lead.
It’s the circle of life…
看来应该选择Xfire。不过，看见网上用axit 的也不少，不多说了，分别做一个例子感觉一下！
有点操之过急了，还得把开发webservice的三剑客介绍一下。
最主要应该就是
Soap.这个东西，如果你的需要webservice了，就应该接触过soap了，soap可以在多种协议下通过xml传输和请求数据的一个东西，比较简单，举一个例子：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
  <header soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" soapenv:mustUnderstand="0" xmlns="xmlapi_1.0">
   <security>
    <user xsi:type="xsd:string">admin</user>
    <password xsi:type="xsd:string">c36b885125105c462d34774140eec076</password>
   </security>
   <requestID xsi:type="xsd:string">SAMOCollect@CM@1184849580000@116.79.255.67</requestID>
  </header>
</soapenv:Header>
<soapenv:Body>
<find xmlns="xmlapi_1.0">
<fullClassName>security.User</fullClassName>
   <resultFilter>
    <attribute>name</attribute>
    <attribute>objectFullName</attribute>
    <attribute>userName</attribute>
    <attribute>password</attribute>
<attribute>state</attribute>
<attribute>userGroup</attribute>
<attribute>userGroupDisplayName</attribute>
    <children/>
  </resultFilter>
</find>
</soapenv:Body>
</soapenv:Envelope>
上面是我发的一个soap请求，请求方式为<find xmlns="xmlapi_1.0">叫find请求，请求的数据是，securiy.User下面的那些属性。  <security>
    <user xsi:type="xsd:string">admin</user>
    <password xsi:type="xsd:string">c36b885125105c462d34774140eec076</password>
   </security>
   <requestID xsi:type="xsd:string">SAMOCollect@CM@1184849580000@116.79.255.67</requestID>
  </header>这是一个请求头。
比如，你想去 A系统请求他提供的一些数据。就像例子中的User对象的一些数据，你在请求头上要写上你要登陆A系统的用户名，密码以及一个requestId。以http的形式发过去，A系统就给你返回结果了：
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"><SOAP:Header><header xmlns="xmlapi_1.0"><requestID>SAMOCollect@CM@1184849580000@116.79.255.67</requestID><requestTime>Oct 28, 2007 3:06:19 PM</requestTime><responseTime>Oct 28, 2007 3:06:19 PM</responseTime></header></SOAP:Header><SOAP:Body><findResponse xmlns="xmlapi_1.0"><result><security.User><password>c36b885125105c462d34774140eec076</password><userName>admin</userName><userGroup>securityManager:userGroup-admin</userGroup><state>active</state><userGroupDisplayName>admin</userGroupDisplayName><objectFullName>securityManager:user-admin</objectFullName><name>user-admin</name></security.User>…………
就是这么一个以xml形式传送的N个User对象。
简单对象传输的概念也就出来了。以xml的形式传递数据，估计不管什么语言写系统都应该可以做到吧？这个webservice也应该是以这种方式来在不同系统之间传递数据的吧？
我也不清楚。还得学啊！
WSDL——Web Service描述语言
随着通信协议和消息格式在Web中的标准化，以某种格式化的方法描述通信变得越来越重要，其实现的可能性也越来越大。用WSDL定义的一套XML语法描述的网络服务方式满足了这种需求。WSDL把网络服务定义成一个能交换消息的通信端点集。WSDL为分布式系统提供了“在线帮助”。
一个WSDL文档将服务定义为一个网络端点或端口（End Point）的集合。在WSDL里，端点及消息的抽象定义与它们具体的网络实现和参数格式绑定是分离的。这样就可以重用这些抽象定义：消息——需要交换数据的抽象描述；端口类型——操作的抽象集合。针对一个特定端口类型的具体协议和数据格式规范构成一个可重用的绑定。一个端口定义成网络地址和可重用绑定的连接，端口的集合定义为服务。因此，一个完整的WSDL在定义网络服务时包含如下的元素：
— 类型：使用某种类型系统（如XSD）定义数据类型；
— 消息：通信数据抽象的带类型的定义；
— 操作：服务所支持动作的抽象描述；
— 端口类型：一个操作的抽象集合，该操作由一个或多个端点支持；
— 绑定：针对一个特定端口类型的具体协议规范和数据格式规范；
— 端口：一个单一的端点，定义成一个绑定和一个网络地址的连接；
— 服务：相关端点的集合。
UDDI——统一描述、发现和集成
UDDI是一套Web Service信息注册标准规范，Web Service信息注册中心通过实现这套规范开放Web Service注册、查询的服务。
UDDI的核心组件是UDDI业务注册，它使用一个XML文档来描述企业及其提供的Web Service。从概念上来说，UDDI业务注册所提供的信息包含三个部分：
— 白页（White Page）：包括地址、联系方法和企业标识；
— 黄页（Yellow page）：包括基于标准分类法的行业类别；
— 绿页（Green Page）：包括该企业所提供的Web Service的技术信息，其形式可能是一些指向文件地址或URL的指示器，而这些文件地址或URL是为服务发现机制服务的。
所有UDDI信息注册信息都存储在UDDI信息注册中心。通过使用UDDI提供的注册服务，企业可以注册那些希望被别的企业发现的Web Service。企业可以通过UDDI商业注册中心的Web界面，或使用实现了“UDDI Programmer’s API标准”的工具，将信息加入到UDDI的信息注册中心。UDDI的注册信息在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定复制规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其他UDDI根节点，于是就能被任何希望使用这些Web Service的人所发现。
上面两个概念应该是在说，你这个xml请求文件不能乱写，得有规范，这样才可以让所有系统都认识。这就是那个wsdl。关于那个注册的，还没有此类需求，不好讲。遇上以后在想想。
有了这些知识在准备用框架开发webservice就痛快多了。关于用框架开发webservice的例子网上一大把。不过，框架不如思想重要。在学习的时候在把思想整理一下！