GridService

Web Service 是一基於Internet客戶端與服務端之間鬆散的應用程式所選擇的技術。那樣使他們成為形成基於格線下一代套用的的自然選擇。然而，記住Web Service只能做有限的工作。事實上，樸素的Web Service（由W3C當前所描述）對建立一個格線套用幫助不大。但進入格線服務後，在Web Service的基礎上在特點和服務上有很大的改進。

基本介紹

• 外文名：GridService
• 性質：應用程式
• 涉及領域：網際網路
• 主要對象：Internet客戶端與服務端

基本信息

讓我們通過一個簡單的例子看看這些改進。想像你們的組織有一個能執行超大規模計算的集群伺服器。然而這個集群伺服器位於你們位於芝加哥的總部，並且你需要位於紐約、洛杉磯和西雅圖的分部的雇員很方便的使用這個集群伺服器的計算能力。這對於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變數執行確定的計算。任和客戶端都可能定義這個變數增加全面的計算。但當這個變數發生變化時，必須通知到所有的客戶端這個變化。我們可以通過格線服務的"通知"很容易做到這點。