Web Services 是网格服务的基础, 也是OGSA和IOGSI的奠基石(GT3). 理解WebService的架构是使用GT3，编写网格服务的基础。
最近 有很多关于"Web Services"的议论并且许多公司也开始为他们的企业应用作出反应。那么，Web Services究竟是什么？简单的说，他们是另一个分布计算技术（像CORBA, RMI, EJB等等），容许我们创建客户端／服务端应用。
举个例子，让我们假设我不得不为一个连锁店开发一个程序。这家连锁店分布在全国各地，但是我的产品主目录（master catalog of product）只存放在我的中心办公室的数据库中，并且分店的软件必须能够访问这个产品目录．我可以通过一个被称为ShopService的Ｗeb Service 来发布这些目录。
重要的是：在网站上发布的时候不能出错。在网站上的信息(像你正在读到的一样)是为人编写的。而在Web Service上的信息可以被软件访问，并不时直接被人访问(尽管存在人用这个软件的可能)。虽然Web Service 很大程度上依赖现有的Web技术（像我们正在看到的HTTP），但他们和Web浏览器与HTML没有联系。我们再重复一遍: 网站是为人服务的，而Web Service 是为软件服务的 :-)
客户端（在商店的PC）在那个时候将要连接(服务器上的)WebService,并发送一个需要目录的服务请求。服务器将会通过一个服务响应返回目录信息。当然这是一个描述Web Service如何工作的非常潦草的例子。等一下，我们将会看到一个非常详细的解释。
我们中的一些人可能会这么想:"嘿，等一下！我可以通过RMI，CORBA，EJBs,等很多其他技术来实现啊！"。那么。为什么还要Web Service? 好的，Web Service 也有很多优于其他技术的地方:
Web Service由于使用标准的XML语言因而是平台无关、语言无关的，这就意味着我们的客户端可以用C++编写在windows下运行，而Web Service使用Java编写而运行在linux下
大部分Web Service 使用HTTP传输消息(像服务请求和响应)。如果你想建立一个Internet范围的程序，这是一个主要的优点，因为大部分Internet's的代理和防火墙都不会破坏HTTP的传输(不像CORBA会在穿过防火墙时遇到麻烦)
当然了，Web Service也存在以下一些缺点：
压力过大。很明显所有在XML中的数据没有定义好的二进制代码效率高。在你赢得通用性的同时降低了效率。尽管那样，这个压力通常是可以被大部分应用程序所接受的，
用途狭窄。目前,由于他们只支持很基本的服务种类，所以Web Service 的用途不是很多。例如CORBA提供给编程者很多正在支持的服务（像持续服务，通知，生命周期管理，转换等等）。事实上，在我们可以看到网格服务可以真正的补偿了用途狭窄的缺点。
然而，分布式的Web Service有一个很重要的特点。像CORBA和EJB技术是面向关系紧密的分布式系统的，它们的客户端和服务端彼此非常依赖。但Web Services是面向松散关系的系统，客户端可以直到真正调用web service才知道Web Service的知识，例如基于网格的应用。
一个典型的Web Service的调用
这些都是如何工作的呢？让我们看一下一个完整的Web Service调用的全部的调用步骤。现在还不要担心那些缩写词(SOAP，WSDL,...)，等一下我们将会详细的解释它们。
正如我们前面所说的，一个客户端可以不知道Web Service是如何调用的.所以我们第一步是寻找满足我们要求的Web Servicede 的位置,例如我们想要找一个可以告诉我们美国城市温度的Web Service。我们可以通过与UDDI注册点联系得到Web Service的位置。
UDDI注册器将会返回告诉我们哪个服务器可以提供给我们我们想要的服务(像美国城市的温度)
我们现在知道Web Service的位置了，但我们还不知道如何使用它。我们确实知道它可以给我们美国城市的温度，但是真是的服务是如何调用的呢？我们调用的方法可能被称为Temperature getCityTemperature(int CityPostalCode),但是它也可以是
int getUSCityTemp(string cityName, bool isFarenheit).我们必须问Web Service 如何描述自己。（告诉我们如何使用它）
用被称为WSDL的语言返回信息。
我们终于知道Web Service的位置和如何调用它。调用方法是通过SOAP来实现的。那样我们就发送SOAP请求要求一个城市的温度。
Web Service 将会温和的返回一个包含我们想要的温度的SOAP响应，或者是当我们的请求信息错误时返回一个错误信息。
Web Service的寻址
我们刚刚看到了一个简单Web Service的调用过程。在一点上UDDI注册服务"告诉"了客户端Web Service的位置。但是....如何准确的寻址Web Service？这个答案非常的简单:就像我们的网页。我们使用朴素而简单的URIs（Uniform Resource Identifiers)。如果你熟悉 URL (Uniform Resource Locator)这个名词的话，那就不要担心:URI和URL事实上是同一样东西。
例如UDDI注册服务期可能会返回如下 URI:
http://webservices.mysite.com/weather/us/WeatherService
这个很容易被认为是一个网页的地址。然而Web Service 是通过软件来记住这个地址的(不再是让人直接记住)。如果你写一个Web Service的URI进你的Web浏览器，你可能会的到一个错误信息或者是难以理解的代码(一些Web Service 会显示给你一个漂亮的界面，但是这个界面和通常的不一样)。当你拥有一个Web Service 的URI时，你通常需要将这个URI交给一个程序。事实上，我们写的大部分的客户端程序都会把网格服务URI作为一个命令参数来接收。
Web Services 的架构
现在我们已经看到了在Web Service调用过程中的不同活动者，让我们来更清楚地了解Web Service的架构吧！
Service Discovery: 这部分容许我们寻找满足需要的Web Service。这部分通常由UDDI（Universal Description, Discovery, and Integration）来处理。GT3目前不支持UDDI.
Service Description: Web Service最有趣特点之一就是他们能够自我描述。这意味着一旦你定位了Web Service，你能要求他"描述自己"并告诉你如何操作和使用它。这是通过Web Services Description Language (WSDL)来处理的
Service Invocation: 调用一个Web Service(和一般的任何类似CORBA对象或者Enterprise Java Beand的分布式服务)的过程中包含在客户端与服务端之间传输的信息。SOAP (Simple Object Access Protocol)规范了我们如何格式化送往服务器的请求信息和如何格式化服务器本身的响应信息。在理论上，我们还可以使用其它调用语言（例如XML_RPC或者 even some ad hoc XML language).然而，SOAP是Web Service更乐意的选择。
Transport: 最后，这些所有的信息可以在服务端和客户端之间传输。架构这部分选择的协议是HTTP(HyperText Transfer Protocol),与访问Internet上的普通网页的协议相同!在理论上我们仍然能使用其他协议，但HTTP协议是目前使用最广泛的了。
Web Service 应用看起来是什么？
OK,你现在对什么是Web Service已经有了一个概念了，你可能可望立刻开始编写Wev Service.在你这么做之前，你可能像直到基于Web Service的应用程序的结构式什么样的。如果你曾经编写过CORBA或者RMI，这个结构会看起
首先，你应该知道尽管存在很多协议和在周围浮现的众多语言，Web Service 编程者通常不用写一行SOAP或者WSDL的代码。一旦我们到了我们的客户端需要调用一个Web Service那一刻时，我们授权给软件中一块叫本地stub(a client stub)的任务。好消息是有很多可以利用的工具为我们自动产生基于WSDL的Web Service描述的本地stub(a client stub)。
这样你不需要逐字地解释"典型的调用"对话过程。一个Web Service客户端通常不会在一个调用过程中经过所有步骤。一个更正确的事件流程如下：
我们通过UDDI定位一个满足我们需要的Web Service。
我们获得关于这个Web Service的WSDL描述。
我们产生stub，然后在我们的应用程序中包含它们。
这个应用程序会在每次调用Web Service 时使用stub。
服务端的编程比较容易。我们不用必须写一个复杂的需要动态解释SOAP请求和产生SOAP响应的服务程序，我们能简单的实现我们Web Service的所有功能，然后产生一个服务器stub(the term skeleton is also used)，这个stub负责解释请求然后将这些请求转交给服务器的实现部分。当服务器实现部分包含一个结果时，它将会把这个结果交给服务器stub，这样就产生了合适的SOAP响应。这个服务器stub还能通过WSDL描述产生，或者从其他语言(像IDL)定义的接口。此外的是服务器实现和服务器stub都通过软件中被称为Web Service容器的代码来管理，这个容器会确保提交给Web ServviceHTTP请求直接交给服务器stub。
下图描述了调用一个Web Service的步骤。
我们来假设我们的客户端已经定位了Web Service，从WSDL描述产生了客户端stub，并且服务端程序也产生了服务端stub。
无论客户端什么时候需要调用Web Service,它都需要调用客户端stub。这个客户端stub会将这个本地调用转换为合适的SOAP请求。这步经常被称为编组过程(marshalling process).
SOAP请求使用HTTP协议通过网络发送出去。Web Service容器接收到SOAP的请求后将它交给服务器stub。服务器stub把SOAP请求转换服务器实现程序能够理解的形式。这步经常被称为解散。
服务器实现部分收到从服务器stub转来的请求后，执行所请求的工作。例如我们调用了 int add(int a, int b) 方法，服务器实现执行加法功能。
执行请求的结果由服务器stub处理转换为SOAP响应。
SOAP响应使用HTTP协议通过网络发送。客户端stub收到SOAP响应并将它转换为客户端应用可以理解的形式。
最终客户端应用接受到调用Web Service的结果并使用这个结果。
最近 有很多关于"Web Services"的议论并且许多公司也开始为他们的企业应用作出反应。那么，Web Services究竟是什么？简单的说，他们是另一个分布计算技术（像CORBA, RMI, EJB等等），容许我们创建客户端／服务端应用。
举个例子，让我们假设我不得不为一个连锁店开发一个程序。这家连锁店分布在全国各地，但是我的产品主目录（master catalog of product）只存放在我的中心办公室的数据库中，并且分店的软件必须能够访问这个产品目录．我可以通过一个被称为ShopService的Ｗeb Service 来发布这些目录。
重要的是：在网站上发布的时候不能出错。在网站上的信息(像你正在读到的一样)是为人编写的。而在Web Service上的信息可以被软件访问，并不时直接被人访问(尽管存在人用这个软件的可能)。虽然Web Service 很大程度上依赖现有的Web技术（像我们正在看到的HTTP），但他们和Web浏览器与HTML没有联系。我们再重复一遍: 网站是为人服务的，而Web Service 是为软件服务的 :-)
客户端（在商店的PC）在那个时候将要连接(服务器上的)WebService,并发送一个需要目录的服务请求。服务器将会通过一个服务响应返回目录信息。当然这是一个描述Web Service如何工作的非常潦草的例子。等一下，我们将会看到一个非常详细的解释。
我们中的一些人可能会这么想:"嘿，等一下！我可以通过RMI，CORBA，EJBs,等很多其他技术来实现啊！"。那么。为什么还要Web Service? 好的，Web Service 也有很多优于其他技术的地方:
Web Service由于使用标准的XML语言因而是平台无关、语言无关的，这就意味着我们的客户端可以用C++编写在windows下运行，而Web Service使用Java编写而运行在linux下
大部分Web Service 使用HTTP传输消息(像服务请求和响应)。如果你想建立一个Internet范围的程序，这是一个主要的优点，因为大部分Internet's的代理和防火墙都不会破坏HTTP的传输(不像CORBA会在穿过防火墙时遇到麻烦)
当然了，Web Service也存在以下一些缺点：
压力过大。很明显所有在XML中的数据没有定义好的二进制代码效率高。在你赢得通用性的同时降低了效率。尽管那样，这个压力通常是可以被大部分应用程序所接受的，
用途狭窄。目前,由于他们只支持很基本的服务种类，所以Web Service 的用途不是很多。例如CORBA提供给编程者很多正在支持的服务（像持续服务，通知，生命周期管理，转换等等）。事实上，在我们可以看到网格服务可以真正的补偿了用途狭窄的缺点。
然而，分布式的Web Service有一个很重要的特点。像CORBA和EJB技术是面向关系紧密的分布式系统的，它们的客户端和服务端彼此非常依赖。但Web Services是面向松散关系的系统，客户端可以直到真正调用web service才知道Web Service的知识，例如基于网格的应用。
一个典型的Web Service的调用
这些都是如何工作的呢？让我们看一下一个完整的Web Service调用的全部的调用步骤。现在还不要担心那些缩写词(SOAP，WSDL,...)，等一下我们将会详细的解释它们。
正如我们前面所说的，一个客户端可以不知道Web Service是如何调用的.所以我们第一步是寻找满足我们要求的Web Servicede 的位置,例如我们想要找一个可以告诉我们美国城市温度的Web Service。我们可以通过与UDDI注册点联系得到Web Service的位置。
UDDI注册器将会返回告诉我们哪个服务器可以提供给我们我们想要的服务(像美国城市的温度)
我们现在知道Web Service的位置了，但我们还不知道如何使用它。我们确实知道它可以给我们美国城市的温度，但是真是的服务是如何调用的呢？我们调用的方法可能被称为Temperature getCityTemperature(int CityPostalCode),但是它也可以是
int getUSCityTemp(string cityName, bool isFarenheit).我们必须问Web Service 如何描述自己。（告诉我们如何使用它）
用被称为WSDL的语言返回信息。
我们终于知道Web Service的位置和如何调用它。调用方法是通过SOAP来实现的。那样我们就发送SOAP请求要求一个城市的温度。
Web Service 将会温和的返回一个包含我们想要的温度的SOAP响应，或者是当我们的请求信息错误时返回一个错误信息。
Web Service的寻址
我们刚刚看到了一个简单Web Service的调用过程。在一点上UDDI注册服务"告诉"了客户端Web Service的位置。但是....如何准确的寻址Web Service？这个答案非常的简单:就像我们的网页。我们使用朴素而简单的URIs（Uniform Resource Identifiers)。如果你熟悉 URL (Uniform Resource Locator)这个名词的话，那就不要担心:URI和URL事实上是同一样东西。
例如UDDI注册服务期可能会返回如下 URI:
http://webservices.mysite.com/weather/us/WeatherService
这个很容易被认为是一个网页的地址。然而Web Service 是通过软件来记住这个地址的(不再是让人直接记住)。如果你写一个Web Service的URI进你的Web浏览器，你可能会的到一个错误信息或者是难以理解的代码(一些Web Service 会显示给你一个漂亮的界面，但是这个界面和通常的不一样)。当你拥有一个Web Service 的URI时，你通常需要将这个URI交给一个程序。事实上，我们写的大部分的客户端程序都会把网格服务URI作为一个命令参数来接收。
Web Services 的架构
现在我们已经看到了在Web Service调用过程中的不同活动者，让我们来更清楚地了解Web Service的架构吧！
Service Discovery: 这部分容许我们寻找满足需要的Web Service。这部分通常由UDDI（Universal Description, Discovery, and Integration）来处理。GT3目前不支持UDDI.
Service Description: Web Service最有趣特点之一就是他们能够自我描述。这意味着一旦你定位了Web Service，你能要求他"描述自己"并告诉你如何操作和使用它。这是通过Web Services Description Language (WSDL)来处理的
Service Invocation: 调用一个Web Service(和一般的任何类似CORBA对象或者Enterprise Java Beand的分布式服务)的过程中包含在客户端与服务端之间传输的信息。SOAP (Simple Object Access Protocol)规范了我们如何格式化送往服务器的请求信息和如何格式化服务器本身的响应信息。在理论上，我们还可以使用其它调用语言（例如XML_RPC或者 even some ad hoc XML language).然而，SOAP是Web Service更乐意的选择。
Transport: 最后，这些所有的信息可以在服务端和客户端之间传输。架构这部分选择的协议是HTTP(HyperText Transfer Protocol),与访问Internet上的普通网页的协议相同!在理论上我们仍然能使用其他协议，但HTTP协议是目前使用最广泛的了。
Web Service 应用看起来是什么？
OK,你现在对什么是Web Service已经有了一个概念了，你可能可望立刻开始编写Wev Service.在你这么做之前，你可能像直到基于Web Service的应用程序的结构式什么样的。如果你曾经编写过CORBA或者RMI，这个结构会看起
首先，你应该知道尽管存在很多协议和在周围浮现的众多语言，Web Service 编程者通常不用写一行SOAP或者WSDL的代码。一旦我们到了我们的客户端需要调用一个Web Service那一刻时，我们授权给软件中一块叫本地stub(a client stub)的任务。好消息是有很多可以利用的工具为我们自动产生基于WSDL的Web Service描述的本地stub(a client stub)。
这样你不需要逐字地解释"典型的调用"对话过程。一个Web Service客户端通常不会在一个调用过程中经过所有步骤。一个更正确的事件流程如下：
我们通过UDDI定位一个满足我们需要的Web Service。
我们获得关于这个Web Service的WSDL描述。
我们产生stub，然后在我们的应用程序中包含它们。
这个应用程序会在每次调用Web Service 时使用stub。
服务端的编程比较容易。我们不用必须写一个复杂的需要动态解释SOAP请求和产生SOAP响应的服务程序，我们能简单的实现我们Web Service的所有功能，然后产生一个服务器stub(the term skeleton is also used)，这个stub负责解释请求然后将这些请求转交给服务器的实现部分。当服务器实现部分包含一个结果时，它将会把这个结果交给服务器stub，这样就产生了合适的SOAP响应。这个服务器stub还能通过WSDL描述产生，或者从其他语言(像IDL)定义的接口。此外的是服务器实现和服务器stub都通过软件中被称为Web Service容器的代码来管理，这个容器会确保提交给Web ServviceHTTP请求直接交给服务器stub。
下图描述了调用一个Web Service的步骤。
我们来假设我们的客户端已经定位了Web Service，从WSDL描述产生了客户端stub，并且服务端程序也产生了服务端stub。
无论客户端什么时候需要调用Web Service,它都需要调用客户端stub。这个客户端stub会将这个本地调用转换为合适的SOAP请求。这步经常被称为编组过程(marshalling process).
SOAP请求使用HTTP协议通过网络发送出去。Web Service容器接收到SOAP的请求后将它交给服务器stub。服务器stub把SOAP请求转换服务器实现程序能够理解的形式。这步经常被称为解散。
服务器实现部分收到从服务器stub转来的请求后，执行所请求的工作。例如我们调用了 int add(int a, int b) 方法，服务器实现执行加法功能。
执行请求的结果由服务器stub处理转换为SOAP响应。
SOAP响应使用HTTP协议通过网络发送。客户端stub收到SOAP响应并将它转换为客户端应用可以理解的形式。
最终客户端应用接受到调用Web Service的结果并使用这个结果。
