让我们通过一个简单的例子看看这些改进。想象你们的组织有一个能执行超大规模计算的集群服务器。然而这个集群服务器位于你们位于芝加哥的总部，并且你需要位于纽约、洛杉矶和西雅图的分部的雇员很方便的使用这个集群服务器的计算能力。这对于Web Service看上去是一个很好的方案。
我们可以通过一个称为MathService的数学WebService提供类似于SolveReallyBigSystem(), SolveFermatsLastTheorem()等等操作。首先我们将能执行典型的Web Service调用:
调用MathService，要求它执行特定的操作。 MathService给集群服务器下达执行操作的指令。 MathService返回操作的结果。到目前为止还一切顺利。然而让我们稍微现实一点。如果你打算访问远程的集群服务器执行一个复杂的数学运算，你大概不会执行一步操作，而是一连串的彼此相关联的运算。然而Web Service是无边界和非临时的。"无边界"意味着Web Service不会记住你在从一个调用到另一个调用之间作过什么。如果我们想执行一串相关的操作就必须将一次操作的结果作为下一次操作的参数发送出去。此外即使在我们解决无边界问题(some Web Services containers actually work around this problem)的时候,Web Service还是非暂时的，这意味着他们都比他们的客户端的持续时间长。这点就说明当一个客户端使用完Web Service后，所有Web Service所记录的信息都能被下一个客户端所访问。事实上当一个客户端正在使用Web Service时另一个客户端也能访问Web Service并潜在的妨碍第一个客户端的操作。可以肯定地是，这不是一个非常好的解决方案。
工厂(Factorys)网格服务可以通过类似于Web Service的工厂来解决前面的两个问题。我实际上用一个中心MathService工厂代替被所有用户共享的无边界的大的MathService，这个MathService工厂负责管理一系列MathService实例。当一个客户端需要调用MathService操作时它会通知这个实例而不是MathService工厂。当客户端需要你得创建（撤销）一个实例时才会与工厂通信。
上图说明每个客户端不是都必须拥有一个实例的情况。一个实例可以同时被两个客户端共享同时一个客户端可以访问两个实例。这些实例都是暂时存在的，因为他们的生命期都是有限制的（最终会撤销实例）。每个实例的生命期可以根据应用的不同而不一样。这样每个客户端拥有自己的实例来工作。然而还有其他我们需要一个实例被多个用户共享的方案（scenarios），并且当没有用户访问时这个实例会在一定的时间内撤销。
网格服务的其他改进到目前为止工厂是网格服务所提供的最意义的改进。然而网格服务还有提供了更多的优点：
两种实现方法：网格服务既可以从一个框架类继承下来也可以使用委托模式来实现，引用过程都委派给一系列被称为operation providers的类。 生命期管理：网格服务提供了一些必须的工具，例如可以在网格服务生命期内特定时刻(创建，撤销等等)的回调函数 ，用于高效的管理它自己的生命期(for example, to make Grid Services persistent). 服务信息：网格服务有一组用来描述自己的相关服务信息。服务信息和WSDL不同，WSDL描述了像方法、协议等等的细节。服务信息在根据特点和能力来索引网格服务时相当有用。 通知机制：我们可以定义一个网格服务作为通知源并且某些客户端作为通知接收器（或者是订阅者）。所以当网格服务发生了改变后会通知所有的订阅者变化（不是通知所有的变化，只是网格服务想要通知的变化内容）。在MathService的例子中，假设所有的客户端用存放网格服务内的InterestingCoefficient变量执行确定的计算。任和客户端都可能定义这个变量增加全面的计算。但当这个变量发生变化时，必须通知到所有的客户端这个变化。我们可以通过网格服务的"通知"很容易做到这点。本文地址：http://com.8s8s.com/it/it42095.htm