GridService

讓我們通過一個簡單的例子看看這些改進。想象你們的組織有一個能執行超大規模計算的集羣服務器。然而這個集羣服務器位於你們位於芝加哥的總部，並且你需要位於紐約、洛杉磯和西雅圖的分部的僱員很方便的使用這個集羣服務器的計算能力。這對於Web Service看上去是一個很好的方案。

我們可以通過一個稱為MathService的數學WebService提供類似於SolveReallyBigSystem, SolveFermatsLastTheorem等等操作。首先我們將能執行典型的Web Service調用:

1.調用MathService，要求它執行特定的操作。

2.MathService給集羣服務器下達執行操作的指令。

3.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變量執行確定的計算。任和客户端都可能定義這個變量增加全面的計算。但當這個變量發生變化時，必須通知到所有的客户端這個變化。我們可以通過網格服務的"通知"很容易做到這點。