CÔNG NGHỆ GRID COMPUTING VÀ ỨNG DỤNG THỬ NGHIỆM TRONG BÀI TOÁN QUẢN TRỊ MẠNG - 4 docx

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 55 -
+ ServiceProvider
Chịu trách nhiệm xây dựng các service, tạo các bản mô tả cho chúng, đăng
ký bản mô tả các service cho một hoặc nhiều ServiceRegistry; tiếp nhận, xử lý các
thông điệp yêu cầu sử dụng service từ các ServiceRequestor.
+ ServiceRequestor
Là các thực thể sử dụng các service cung cấp bởi ServiceProvider.
ServiceRequestor tìm kiếm các bản đặc tả service trong các ServiceRegistry, lựa
chọn service cần thiết và thích hợp, rồi sau đó kết nối đến ServiceProvider và sử
dụng service mong muốn.
+ ServiceRegistry
Chịu trách nhi
ệm quảng bá các service do các ServiceProvider đăng ký cho
nó, và cho phép các ServiceRequestor tìm kiếm các đặc tả service trong danh sách
đăng ký của nó.

Lưu ý
, một thành phần của ứng dụng có thể đóng một hay nhiều vai trò trên.
2. Các hoạt động chính
SOA có 3 loại hoạt động chính giữa các thành phần trên : Publish, Find và Bind.
+ Public
Là hoạt động giữa ServiceProvider và ServiceRegistry. ServiceProvider thực

hiện đăng ký giao diện service nó cung cấp cho ServiceRegistry thông qua phương
thức Public.
+ Find
Là hoạt động giữa ServiceRequestor và ServiceRegistry. ServiceRequestor
sử dụng phương thức Find để lấy danh sách service và ServiceProvider thoả mãn
các yêu cầu của nó. Có thể có nhiều điều kiện tìm kiếm trong phương thức Find,
ServiceRegistry sẽ tìm trong danh sách các ServiceProvider rồi trả về thông tin
thích hợp.
+ Bind
Là hoạt động giữa ServiceRequestor và ServiceProvider. Nó cho phép
ServiceRequestor thực hiện kết nối đến ServiceProvider trước khi thực hiện các lời








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 56 -
gọi sử dụng service. Cho phép ServiceRequestor khởi tạo proxy phía client cho
service cung cấp bởi ServiceProvider. Thao tác kết nối này có thể thực hiện động
hay tĩnh. Trong trường hợp kết nối động, ServiceRequestor phát sinh proxy dựa trên
các thông tin lấy được từ ServiceRegistry, trong trường hợp còn lại, proxy được
phát sinh trong lúc phát triển ứng dụng.
3
3
.
.

2
2
.
.
2
2
.
.




W
W
e
e
b
b


S
S
e
e
r
r
v
v
i
i

c
c
e
e


Web Service là một công nghệ được sử dụng rộng rãi để triển khai mô hình
SOA vào thực tế, nó đưa ra mô hình liên lạc, trao đổi giữa ứng dụng với ứng dụng
trên cơ sở ngôn ngữ đặc tả XML. Web Service là nền tảng của Grid Service (sẽ giới
thiệu sau).
Web Service sử dụng ngôn ngữ Web Services Description Language (WSDL)
để mô tả nội dung và cách sử dụng service; sử dụng protocol SOAP để trao đổi các
thông điệp giữa các Web service; sử dụng ngôn ngữ đặc tả Universal Description,
Discovery and Integration (UDDI) để cho phép các nhà cung cấp Web service đăng
ký service của mình và cho phép người sử dụng Web service tìm được nhà cung cấp
thỏa điều kiện mong muốn. Ngoài ra, còn một số chuẩn về định nghĩa và triển khai
chất lượng dịch vụ của Web service đang
được xây dựng như WS-Security, WS-
Reliable Messaging, WS-Coordination, và WS-Transaction,…
Về bản chất, Web service cũng là một công nghệ tính toán phân tán như các
công nghệ CORBA, RMI, EJB, … Tuy nhiên, Web service có một số lợi điểm mà
các công nghệ khác không có:
+ Web service độc lập với ngôn ngữ lập trình, độc lập với nền tảng thực thi
ứng dụng do được xây dựng trên chuẩn XML. Đây cũng là lý do chính để chọn
công nghệ Web service làm nền tảng cho Grid service để giải quyết thách thức lớn
nhấ
t của công nghệ Grid computing là quản lý và sử dụng các tài nguyên phân tán,
đa dạng, phức tạp, trên nhiều nền tảng khác nhau.
+ Hầu hết các Web service đều sử dụng protocol HTTP để truyền thông điệp
(các yêu cầu service và kết quả trả về từ service), nên hỗ trợ xây dựng các ứng dụng

tầm cỡ toàn cầu qua nhiều site, nhiều vùng bảo mật, nhiều vùng quản trị khác nhau








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 57 -
trên nền tảng Internet, do các lưu thông dạng HTTP thường không bị chặn lại khi
gặp firewall hoặc proxy. Trong khi đó, việc truyền thông của các công nghệ khác
thường gặp vấn đề với firewall.
+ Một sự khác biệt nữa là, các công nghệ như CORBA và EJB hướng đến
các hệ thống phân tán có độ kết hợp cao (highly coupled), trong đó client và server
phải phụ thuộc chặt chẽ vào nhau. Các công nghệ này thường lý tưởng cho các ứng
dụng trong mạng cục bộ
. Còn với công nghệ Web service thì ngược lại hoàn toàn,
client không cần biết thông tin về server và service cho đến khi nó thực sự cần sử
dụng service. Do đó, công nghệ Web service thường thích hợp nhất để xây dựng các
ứng dụng có phạm vi rộng trên Internet, như các ứng dụng hướng Grid. Công nghệ
Web service có thể được sử dụng để quản lý tài nguyên thay đổi động theo thời
gian.

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 58 -
3
3
.
.
2
2
.
.
3
3
.
.


O
O
G
G
S
S
A
A

3
3
.
.
2
2
.
.
3
3
.
.
1
1
.
.




G
G
i
i
ớ
ớ
i
i

t
t
h
h
i
i
ệ
ệ
u
u


Dựa trên những kinh nghiệm có được khi phát triển bộ GT đến phiên bản 2.0 hỗ
trợ việc xây dựng các hệ thống, ứng dụng Grid cùng với việc phân tích các khía
cạnh kỹ thuật và lợi ích của công nghệ Web Service, tổ chức Globus Alliance, sau
đó là cùng với tổ chức Global Grid Forum(GGF) đã xây dựng, phát triển các mô
hình và giải pháp để giải quyết các vấn đề, các thách thức của công nghệ Grid
Computing. Chuẩn OGSA ra đời từ những nỗ lực trên. T
ổng quan về OGSA đã
được giới thiệu trong chương 2
, phần này giới thiệu sâu vào chi tiết của chuẩn
OGSA.
Tư tưởng chủ đạo của mô hình giải pháp OGSA là xem Grid như là một tập hợp
có thể mở rộng các Grid service, các Grid service này có thể được kết hợp theo
nhiều cách khác nhau để thỏa mãn nhu cầu của các VO, và đến lượt chúng, các VO
này lại được xác định bằng các service mà chúng cung cấp và chia sẻ.
Việc tiếp cận hướng service (service orientation) giúp giải quyết gần như trọn
vẹn các thách thứ

c về quản lý, sử dụng tài nguyên, về liên kết hoạt động trong Grid.
Nhờ tiếp cận theo hướng này, vấn đề liên kết hoạt động có thể được chia thành 2
vấn đề nhỏ hơn là định nghĩa giao diện của service và xây dựng các protocol để gọi
sử dụng một service cụ thể.
Việc tiếp cận hướng service còn làm đơn giản quá trình ảo hóa, có nghĩa là gói
gọn các cài đặt cụ thể tuỳ
môi trường, tuỳ nền tảng, … trong một giao diện chung.
Quá trình ảo hoá đưa ra một cách thức sử dụng tài nguyên cố định, chung nhất trên
các tài nguyên khác nhau, đa dạng về nền tảng, cho phép ánh xạ nhiều thực thể tài
nguyên logic trên cùng một tài nguyên vật lý. Việc ảo hoá còn cho phép kết hợp các
service cấp thấp thành các service cấp cao có chức năng phức tạp hơn mà không cần
quan tâm đến chi tiết cài đặt của các service cấp thấp.








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 59 -
3
3
.
.
2
2
.
.

3
3
.
.
2
2
.
.






M
M
ô
ô


h
h
ì
ì
n
n
h
h

s
s
e
e
r
r
v
v
i
i
c
c
e
e


O
O
G
G
S
S
A
A


Trong mô hình OGSA, mọi thứ đều được đại diện bởi một service (là một thực
thể kết nối mạng cung cấp một số tính năng nào đó thông qua việc trao đổi các
thông điệp). Tất cả các tài nguyên đều là các service. Chi tiết hơn nữa, OGSA xem
mọi thứ như là một Grid service : là một Web service hỗ trợ các quy ước và

interface chuẩn mà mỗi Grid service cần phải có.
Các Grid service được phân loại bởi các khả năng mà chúng cung cấp. Mộ
t Grid
service có thể có một hoặc nhiều interface, mỗi interface định nghĩa một tập các
phương thức có thể được gọi thực hiện bằng cách trao đổi các thông điệp theo thứ
tự được xác định trước. Grid service interface tương ứng với portType trong
WSDL. Tập các portType cung cấp bởi Grid service cùng với các thông tin liên
quan như phiên bản được xác định trong serviceType (một thành phần mở rộng từ
WSDL) của Grid service.
Các Grid service có thể quản lý các thông tin trạng thái nội bộ của chúng trong
thời gian sống. Việc tồn tại các trạng thái khác nhau giúp phân biệt một thể hiện
(instance) của Grid service với một service khác có cùng interface. Ở đây sẽ sử
dụng khái niệm Grid service instance để chỉ một thể hiện cụ thể của Grid service.
Các service sẽ liên lạc với nhau bằng cách trao đổi các thông điệp. Trong môi
trường phân tán, phức tạp, không thể đảm bảo một thông điệp được gửi đi chắ
c
chắn đến nơi, do đó cần phải sử dụng một protocol đảm bảo thông điệp gửi đi và tới
nơi.
Các service có thể được tạo và huỷ một cách động. Service có thể bị huỷ tường
minh hoặc bị huỷ, không thể truy cập được do hư hỏng hệ thống, hết tài nguyên. Do
đó, Grid service có các interface để quản lý thời gian sống của mình. Vì các Grid
service được tạo và huỷ mộ
t cách động nên cần có cơ chế để phân biệt các instance
khác nhau được tạo ra. Mỗi Grid service instance được gán một tên duy nhất không
trùng với bất kỳ ai, Grid service handle (GSH), GSH dùng để phân biệt một Grid
service instance cụ thể với tất cả các instance khác đã tồn tại, hiện đang tồn tại, và
sẽ được tạo lập trong tương lai.

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 60 -
Grid service có thể được nâng cấp trong thời gian sống của nó, ví dụ để hỗ trợ
một phiên bản mới của protocol hoặc thêm các protocol thay thế. GSH không mang
thông tin xác định về protocol hay thông tin đặc biệt của instance như địa chỉ mạng
và các protocol hiện đang liên kết (binding) với nó. Thay vào đó, thông tin này
được đóng gói cùng với các thông tin khác cần thiết để liên lạc với một instance
vào một thực thể trừu tượng đơn lẻ, Grid service reference (GSR). Không giống như
GSH luôn cố định, GSR có thể được thay đổi trong thời gian sống của instance. Một
GSR chỉ tồn tại trong một khoảng thời gian cụ thể, hoặc có thể trở nên không hợp lệ
trong bất kỳ thời điểm nào trong quá trình sống của instance. OGSA đã định nghĩa
một số cơ chế, sẽ trình bày sau, để lấy một GSR đã cập nhật. Lưu ý rằng, khi có
GSR cũng chưa chắc có th
ể truy cập đến Grid service instance, các chính sách cục
bộ hoặc các ràng buộc truy cập có thể ngăn chặn các yêu cầu sử dụng dịch vụ.
Mọi thứ trong OGSA đều là service nên cần phải xây dựng các Grid service thực
hiện quản lý các Grid service khác. Các tác giả OGSA đã xây dựng một tập các
interface cơ bản, mềm dẻo, các interface này sau đó có thể được kết hợp theo nhiều
cách khác nhau để tạo ra một lượng phong phú các Grid service. Bảng … cho biết
tên và mô tả
của các interface được định nghĩa cho đến hiện tại (06/2002).
Một lưu ý là : OGSA xác định các ngữ cảnh của một Grid service instance như
cách nó được tạo ra, được đặt tên, cách quản lý thời gian sống, cách liên lạc với một
instance,… Tuy vậy, OGSA không giải quyết vấn đề cài đặt chúng như thế nào, ví
dụ về mô hình lập trình, ngôn ngữ lập trình, môi trường thực thi,… Trong thực tiễn,

các Grid service được tạo ra trong các môi trường thực thi cụ thể
hay hosting
environment (môi trường chủ). Một hosting environment cụ thể xác định không
những các mô hình lập trình, ngôn ngữ lập trình, các công cụ phát triển, gỡ rối, …
mà còn cách một cài đặt của Grid service thỏa mãn các quy định của nó để cung cấp
chức năng của mình. Các ứng dụng hiện nay đang dựa vào các tiến trình của các hệ
điều hành cụ bộ như là hosting environment của mình, ví dụ việc tạo ra một service
instance liên quan đến việc tạo ra một tiế
n trình trong hệ thống.








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 61 -
3
3
.
.
2
2
.
.
3
3
.

.
3
3
.
.




C
C
á
á
c
c


i
i
n
n
t
t
e
e
r
r
f
f
a

a
c
c
e
e


c
c
h
h
u
u
ẩ
ẩ
n
n


Bảng 3-1 là danh sách các interface (trong WSDL là portType) định nghĩa nên
một Grid service. Lưu ý, chỉ có interface GridService là phải được cài đặt bởi tất cả
các Grid service, còn các interface khác là tuỳ chọn. Các interface phục vụ phân
quyền, quản lý chính sách, và các mục đích khác hiện đang được xây dựng.
PortType Phương thức Mô tả
FindServiceData Truy vấn hàng loạt các thông tin về các Grid
service instance, bao gồm các thông tin cơ
bản nội bộ (GSH, GSR, khóa chính,…) , các
thông tin về interface, các thông cụ thể của
từng instance… Hỗ trợ nhiều ngôn ngữ truy
vấn khác nhau.

SetTerminationTime Thiết lập (Lấy) thời gian hủy bỏ của Grid
service instance.
GridService
Destroy Hủy bỏ một Grid service instance.
Notification-
Source
SubscribeTo-
NotificationTopic
Yêu cầu thông báo về các sự kiện liên quan
đến service. Cho phép phân phối thông qua
các hệ thống chuyển thông điệp bên thứ ba.
Notification-
Sink
DeliverNotification Tiến hành phân phối bất đổng bộ các thông
điệp thông báo.
RegisterService Thực hiện đăng ký một GSH Registry
UnregisterService Huỷ đăng ký một GSH
Factory CreateService Tạo một service instance mới.
HandleMap FindByHandle Trả về GSR hiện đang liên kết với GSH được
cung cấp.
Bảng 3-1 Bảng các interface chuẩn quy định bởi OGSA.
3
3
.
.
2
2
.
.
3

3
.
.
4
4
.
.






M
M
ộ
ộ
t
t


s
s
ố
ố


c
c
ơ

ơ


c
c
h
h
ế
ế


c
c
ủ
ủ
a
a


O
O
G
G
S
S
A
A


1. Tạo các service ngắn hạn : Factory

OGSA định nghĩa một lớp các Grid service triển khai một interface phụ trách
việc tạo lập các Grid service instance. Interface này được gọi là Factory và service
triển khai interface này là một factory (nhà máy). Phương thức CreateService của
interface Factory tạo mọt instance của service được yêu cầu, trả về GSH và khởi tạo
GSR cho service instance mới.
Interface Factory không xác định cách thức cụ thể để tạo ra service instance.
Một cách chung nhất, interface Factory được triển khai trong các host environment








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 62 -
cung cấp các cơ chế chuẩn để để tạo ra (và sau đó là quản lý) các service instance.
Hosting environment có thể quy định cách thức tạo service instance cụ thể, nhưng
điều này là trong suốt đối với các người dùng service trong OGSA, họ chỉ thấy
interface Factory mà thôi. Một cách khác, trong các môi trường Grid phức tạp, có
thể xây dựng hệ thống các factory phân cấp trong đó các factory cấp cao tạo ra các
service instance bằng cách uỷ quyền qiải quyết yêu cầu tạo lập cho các factory cấp
thấp hơ
n, để đạt được các yêu cầu cụ thể.
2. Quản lý thời gian sống của service
Việc đưa ra khái niệm các service instance ngắn hạn dẫn đến việc phải xác
định thời gian sống của service, có nghĩa là phải xác định khi nào thì có thể hoặc
cần phải kết thúc service để giải phóng các tài nguyên liên quan. Trong môi trường

hoạt động bình thường, các service instance ngắn hạn được tạo ra để thực hiện một
nhiệm vụ nào đó và kết thúc khi nhiệm vụ hoàn thành hoặc khi có yêu cầu từ client.
Tuy nhiên, trong các hệ thống phân tán, các thành phần có th
ể không hoạt động, các
thông điệp có thể bị mất nên service instance có thể không bao giờ nhận được thông
báo kết thúc, điều đó khiến nó tồn tại vĩnh viễn, gây lãng phí tài nguyên trong hệ
thống.
OGSA giải quyết vấn đề này bằng cách xác định một thời gian sống cụ thể
cho từng Grid service instance được tạo ra. Thời gian này có thể được mở rộng theo
yêu cầu của client hoặc một Grid service khác đại diệ
n cho client. Nếu hết thời gian
sống mà không nhận được yêu cầu nào để kéo dài thời gian sống thì host
environment hoặc chính Grid service instance có toàn quyền tự kết thúc và giải
phóng tài nguyên.
Việc quản lý thời gian sống được thực hiện thông qua phương thức
SetTerminationTime trong interface GridService.
3. Quản lý các Handle và Reference
Như đã giới thiệu trên đây, factory sau khi tạo service instance sẽ trả về GSH
và GSR. Trong khi GSH là cố định thì GSR được tạo ra với một thời gian sống xác
định và có thể thay đổi trong thời gian sống của service. Trong khi chiến lược này
mang lại khả năng mềm dẻo trong việc xây dựng và bảo trì các service, nhưng cũng








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2

- 63 -
xuất hiện vấn đề mới, đó là làm sao lấy được một GSR hợp lệ khi GSR khởi đầu hết
hạn, Vấn đề trên có thể phát biểu lại như sau : Bằng cách nào có thể giao tiếp với
một Grid service instance khi chỉ biết GSH của nó.
OGSA tiếp cận theo hướng xây dựng một interface ánh xạ từ GSH sang GSR
(HandleMap). Các phương thức cung cấp bởi interface này sẽ lấy một GSH và trả
về một GSR hợp lệ
tương ứng. Các phương thức này có thể được áp dụng các chính
sách quản lý truy cập và do đó, các yêu cầu sử dụng có thể bị từ chối. Một bản cài
đặt của interface HandleMap có thể theo dõi xem Grid service instance nào hiện còn
đang tồn tại và sẽ không trả về GSR của instance mà nó biết hiện đã kết thúc. Lưu ý
là khi có một GSR hợp lệ trong tay cũng chưa chắc là có thể liên lạc được với Grid
instance, nó có thể không hoạt động, hoặc kết thúc trong khoảng thời gian từ lúc
đưa ra GSR đến lúc lấy được GSR.
Tiếp theo, khi đã có interface HandleMap, việc giải quyết vấn đề làm sao lấy
được GSR theo GSH sẽ dẫn đến việc cần phải giải quyết 2 vấn đề nhỏ hơn:
+ Xác định service handleMap nào đang chứa GSH cần tìm.
+ Liên lạc với handleMap để lấy được GSR tương ứng.
Cách giải quyết 2 vấn đề trên như sau:
Để đảm bả
o luôn luôn ánh xạ được từ GSH sang GSR, yêu cầu tất cả các
Grid service instance phải được đăng ký với ít nhất một handleMap, được gọi là
home handleMap. Việc đưa vào GSH mã nhận dạng của handleMap giúp dễ dàng
trong việc xác định handleMap nào phải liên lạc để lấy được GSR. Làm sao để xác
định home handleMap cho GSH? Bất kỳ service triển khai interface HandleMap
cũng là Grid service, và cũng có GSH, nếu với cách khởi tạo như trên, sẽ trở lại vấn
đề là phải cố gắng lấy
được GSR liên kết với GSH handleMap service. Để giải
quyết triệt để vấn đề này, cần phải có một cách lấy được GSR của handleMap mà
không cần một handleMap khác. Để giải quyết được, tất cả các home handleMap

service đều được xác định bởi một URL và phải hỗ trợ liên lạc với cùng một
protocol chuẩn mà ai cũng biết, ví dụ HTTP. Lúc đó, thay vì phải dùng GSR để xác
định protocol liên lạc với handleMap service, sẽ sử dụng phươ
ng thức GET của








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 64 -
HTTP đến URL của home handleMap và GSR của handleMap dưới dạng WSDL
được trả về.
Lưu ý về mối quan hệ giữa các interface HandleMap và Factory khi cài đặt.
GSH trả về từ một factory phải chứa URL của home handleMap service, và ánh xạ
GSH/GSR phải được đưa vào và cập nhật trong handleMap service. Factory cần có
trách nhiệm quyết định xem service nào sẽ là home handleMap.

4. Service Data và Service Discovery
Đi kèm với mỗi Grid service instance là một tập các service data, một tập các
thành phần XML được đóng gói như các thành phần dữ liệu của service. Mỗi thành
phần bao gồm một tên duy nhất trong toàn service instance, một kiểu, thông tin về
thời gian sống để sử dụng để quản lý thời gian sống.
Interface GridService định nghĩa hoạt động WSDL chuẩn, FindServiceData,
phục vụ việc truy vấn và lấy về các service data.
Bản đặc tả về Grid service xác
định cho mỗi interface Grid service một tập

các thành phần service data phải được cài đặt trong bất cứ Grid service instance nào
hỗ trợ interface đó. Đi kèm với interface GridService, do đó cũng đi kèm với tất cả
các service instance một tập các thành phần chứa thông tin cơ bản về Grid service
instance, như GSH, GSR, khoá chính, home handleMap.
Một ứng dụng của phương thức FindServiceData là chức năng tìm kiếm
service (service discovery). Những gì được trình bày ở trên giả sử rằng một ai đó đã
có GSH c
ủa service mong muốn, làm sao chúng ta lấy được GSH mong muốn lúc
đầu tiên. Đã đến lúc cần dùng đến chức năng service discovery, là một quá trình xác
định một tập các GSH có các thuộc tính thỏa mãn các yêu cầu cụ thể của người
dùng như tải hiện hành, số lượng yêu cầu đã phục vụ, các chính sách hoạt động.
Grid service hỗ trợ chức năng service discovery được gọi là registry. Một
registry service được xác định bởi 2 thứ : một interface Registry, cung cấp các
phương thứ
c để đăng ký các GSH, và các thành phần service data được dùng để lưu
trữ thông tin về các GSH đã đăng ký. Từ đó, interface Registry được sử dụng để
đăng ký một GSH và phương thức FindServiceData của interface GridService dùng
để lấy các thông tin về các GSH đã đăng ký.








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 65 -
5. Notification
OGSA notification framework cho phép client đăng ký nhận các thông tin

cần được thông báo từ các service instance và hỗ trợ việc phân phối bất đồng bộ,
một chiều từ nguồn đến đích (client) các thông báo cần thiết. Để có thể nhận các
thông điệp, client thực hiện đăng ký GSH của mình và các thông tin cần được thông
báo cho service instance nguồn, sau đó nguồn sẽ gửi các thông điệp về các thông tin
được yêu cầu cho client, trong khi client gửi các thông điệp định kỳ để báo cho nơ
i
gửi biết là mình vẫn còn cần nhận thông tin.
3
3
.
.
2
2
.
.
4
4
.
.




O
O
G
G
S
S
I

I


v
v
à
à


G
G
r
r
i
i
d
d


S
S
e
e
r
r
v
v
i
i
c

c
e
e


Như đã biết, OGSA không đi sâu vào việc đặc tả các Grid Service. Nó chỉ cơ
bản phác thảo một mô hình của các hệ thống Grid với các Grid Service và phác thảo
những thứ mà một Grid Service cần phải có. OGSI là một chuẩn nhằm triển khai cụ
thể các khái niệm đưa ra bởi OGSA, nó đưa ra các đặc tả chính thức mang tính kỹ
thuật về Grid Service dựa trên công nghệ Web service. Nói một cách khác, OGSI là
một chuẩn để xây dựng các Grid Service. Theo OGSI, Grid Service Chuẩn OGSI
1.0 ra đờ
i với các mục đích cụ thể:
+ Giới thiệu các quy ước dựa theo WSDL được sử dụng trong các đặc tả về
Grid service, các quy ước này hiện đã được tích hợp trong WSDL 1.2 (đang phát
triển).
+ Định nghĩa service data, đưa một cách thức chuẩn để trình bày và truy vấn
các siêu dữ liệu (metadata) và các thông tin trạng thái của các service instance.
+ Giới thiệu các thuộc tính chính, cơ bản của một Grid service, bao gồm:
¾ Định nghĩa Grid service description và Grid service instance.
¾ Định ngh
ĩa cách tính thời gian của mô hình OGSI.
¾ Định nghĩa Grid Service Handle và Grid Service Reference.
¾ Định nghĩa một hướng tiếp cận chung để chuyển các thông tin lỗi từ
các hoạt động. Hướng tiếp cận này xây dựng một lược đồ XML và các ngữ
nghĩa liên quan cho các thông điệp lỗi WSDL để hỗ trợ một cách hiểu chung.

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 66 -
Hướng tiếp cận này chỉ đơn giản định nghĩa và các định dạng chuẩn cho các
thông điệp lỗi mà không thay đổi mô hình truyền thông điệp lỗi của WSDL.
¾ Định nghĩa chu trình sống (lifecycle) của một Grid service instance.
Phần này sẽ giới thiệu một số điểm chính về các Grid Service được quy định
trong OGSI, các thông tin chi tiết xin xem trong tài liệu tham khảo
3
3
.
.
2
2
.
.
4
4
.
.
1
1
.
.

G
G
r
r
i
i
d
d


S
S
e
e
r
r
v
v
i
i
c
c
e
e


D

D
e
e
s
s
c
c
r
r
i
i
p
p
t
t
i
i
o
o
n
n


v
v
à
à


G

G
r
r
i
i
d
d


S
S
e
e
r
r
v
v
i
i
c
c
e
e


I
I
n
n
s

s
t
t
a
a
n
n
c
c
e
e


Trước hết cần phân biệt giữa 2 khái niệm service description và service instance
+ Grid Service Description (Bản mô tả về Grid service)
Là một tài liệu WSDL định nghĩa Grid service interface, mô tả cách thức một
client giao tiếp với các service instance, bao gồm các portType, phương thức, khai
báo serviceData, thông điệp, và kiểu. Lưu ý, trong tương lai, có thể sử dụng các
kiểu định dạng khác thay vì WSDL.
Một service description được sử dụng với 2 mục đích chính. Trước hết, với
vai trò một bản mô tả service interface, nó được sử dụng cho các công cụ tự động
phát sinh các client interface proxy, … Thứ hai, nó được sử dụng để
tìm kiếm
service, ví dụ như tìm một service instance triển khai một service description nào
đó, hay tìm một factory có khả năng tạo ra các instance với một service description
cụ thể.
+ Grid Service Instance
Là một thể hiện của Grid Service Description như là một thực thể hoạt động.
Một Grid Service Description có thể được sử dụng trong nhiều instance. Mỗi
instance có:

¾ Các trạng thái được mô tả trong service description.
¾ Có một hoặc nhiều Grid Service Handle.
¾ Có một hoặc nhiều Grid Service Reference tham khảo đến nó.
3
3
.
.
2
2
.
.
4
4
.
.
2
2
.
.






T
T
i
i
m

m
e
e


M
M
o
o
d
d
e
e
l
l




Do các thành phần tham gia hệ thống Grid có thể nằm trên nhiều vùng thời gian
khác nhau, sử dụng các định dạng biểu diễn thời gian khác nhau, nên cần phải có
mô hình biểu diễn thời gian thống nhất trong toàn bộ hệ thống để đảm bảo đồng bộ

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 67 -
về thời gian. Chuẩn GMT được chọn để sử dụng trong các Grid service, các hosting
environment và client được gợi ý dùng protocol Network Time Protocol (NTP)
hoặc các chức năng tương tự để đồng bộ hoá đồng hồ của mình với thời gian GMT.
Về định dạng biểu diễn thời gian trong các service và thông điệp, OGSI sử dụng
kiểu xsd:dateTime và mở rộng thêm kiểu ExtendedDateTimeType để thay thế
xsd:dateTime trong trường hợp biểu diễn thời gian không xác định.
Định nghĩa ExtendedDateTimeType như
sau:





3
3
.
.
2
2
.
.
4
4
.
.
3
3
.

.






G
G
r
r
i
i
d
d


S
S
e
e
r
r
v
v
i
i
c
c
e

e


N
N
a
a
m
m
i
i
n
n
g
g


Chúng ta đã biết các Web service được định vị bằng các Unified Resource
Indicator (URI). Vì các Grid service cũng là Web service nên chúng cũng được xác
định bởi các URI, tuy nhiên trong OGSA, OGSI, một Grid Service URI được gọi là
Grid Service Handle (GSH). Một Grid service instance có một hoặc nhiều GSH.
GSH chỉ là một tên dưới dạng URI, không mang đủ thông tin để client có thể liên
lạc với service instance. Để có thể liên lạc, GSH cần phải được phân giải thành Grid
Service Reference (GSR).
Mỗi GSH phải duy nhất, toàn cục, vĩnh viễn cho một service instance trong hệ
thống Grid. Không thể có 2 service instance có cùng GSH.
GSR chứa t
ất cả các thông tin cần thiết để client liên lạc với service instance
thông qua một kết hợp của một hoặc nhiều protocol truyền thông mạng (protocol
binding). Cũng giống như URI, GSR có một lược đồ dữ liệu để chứa các thông tin

đặc biệt của mình. Để phân giải GSH thành GSR, client sử dụng cơ chế Handle
Resolver. GSR có thể có nhiều định dạng khác nhau tuỳ vào protocol liên lạc mà
client sử dụng, ví dụ khi sử dụng với RMI/IIOP, GSR có dạng củ
a một IOR, khi sử
dụng với SOAP, GSR là có dạng một tài liệu WSDL. Một service instance cũng có
thể có nhiều GSR tham khảo tới nó, chu trình sống của GSR độc lập với service
…
targetNamespace = />

<simpleType name="ExtendedDateTimeType">
<union memberTypes="ogsi:InfinityType xsd:dateTime"/>
</simpleType>
<simpleType name="InfinityType">
<restriction base="string">
<enumeration value="infinity"/>
</restriction>
</simpleType>








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 68 -
instance, nó có thể trở nên không hợp lệ tại bất kỳ thời điểm nào. Việc kiểm tra xem
một GSR có hợp lệ hay không là trách nhiệm của client. Khi một GSR không hợp
lệ, client phải lấy một GSR mới thông qua GSH.

Dưới đây định nghĩa của GSH và GSR đưới dạng XML:
+ Định nghĩa GSH






+ Định nghĩa GSR





Tài liệu WSDL biểu diễn thông tin GSR chỉ cần chứa các thông tin cần thiết
nhất để có thể liên lạc với một service instance cụ thể, định dạng như sau:








+ Service Locator
targetNamespace =

<xsd:element name="handle" type="ogsi:HandleType"/>

<xsd:simpleType name="HandleType">

<xsd:restriction base="xsd:anyURI"/>
</xsd:simpleType>
targetNamespace =

<xsd:element name="reference" type="ogsi:ReferenceType"/>

<xsd:complexType name="ReferenceType" abstract="true">
<xsd:attribute ref="ogsi:goodFrom" use="optional"/>
<xsd:attribute ref="ogsi:goodUntil" use="optional"/>
</xsd:complexType>
targetNamespace =

<xsd:complexType name="WSDLReferenceType">
<xsd:complexContent>
<xsd:extension base="ogsi:ReferenceType">
<xsd:sequence>
<xsd:any namespace=”
minOccurs="1" maxOccurs="1" processContents="lax"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 69 -
Là một cấu trúc kết hợp không hoặc nhiều GSH, không hoặc nhiều GSR,
không hoặc nhiều interface (portType) QName, dùng để kết hợp GSH, GSR,
interface lại thành một đơn vị cơ bản để dễ sử dụng. Service Locator có thể được sử
dụng trong bất cứ phương thức nào chấp nhận GSH hoặc GSR. Định nghĩa service
locator như sau:








3
3
.
.
2
2
.
.
4
4
.
.
4
4

.
.






I
I
n
n
t
t
e
e
r
r
f
f
a
a
c
c
e
e


OGSI mở rộng khái niệm portType của WSDL để hiện thực hoá khái niệm
interface được đề cập đến trong OGSA. Trong OGSI, wsdl:portType được định

nghĩa lại thành interface của Grid service (gwsdl:portType) như sau:












targetNamespace =

<xsd:element name="locator" type="ogsi:LocatorType"/>

<xsd:complexType name="LocatorType">
<xsd:sequence>
<xsd:element ref="ogsi:handle"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="ogsi:reference"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name=”interface” type=”QName”
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>

</xsd:complexType>
…
targetNamespace=

xmlns:gwsdl=

…
<element name="portType" type="gwsdl:portTypeType"/>
<complexType name="portTypeType">
<complexContent>
<extension base="wsdl:portTypeType">
<sequence>
<any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name=”extends” use=”optional”>
<simpleType>
<list itemType=”QName”/>
</simpleType>
</attribute>
<anyAttribute namespace="##other"/>
</extension>
</complexContent>
</complexType>








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2

- 70 -
Thuộc tính extends trong gwsdl:portType là một danh sách các QName, mỗi
QName là một wsdl:portType hoặc gwsdl:portType. Việc định nghĩa các phương
thức trên interface được kế thừa lại từ wsdl:portTypeType.
Về chi tiết các interface của Grid service định nghĩa bởi OGSI 1.0, xin xem
thêm trong Phụ lục D – “Các interface của một OGSI Service”


3
3
.
.
2
2
.
.
4
4
.
.
5
5
.
.

S
S
e
e
r
r
v
v
i
i
c
c
e
e


d
d
a
a
t
t
a
a


Service data là một tập các thông tin có cấu trúc về Grid service instance nhằm
cung cấp các thông tin trạng thái của nó theo yêu cầu. Grid service được phân loại
và chỉ mục theo các thông tin trong service data. Mỗi instance của Grid service đều
có một tập các service data chứa các thành phần Service Data Element (SDE), các

SDE có thuộc nhiều loại khác nhau, nhưng các SDE cùng loại thì luôn chứa cùng
một loại thông tin.
Ý tưởng biểu diễn các thuộc tính của service instance như là service data được
kế thừa từ ý tưởng của lập trình hướng đối tượng, các service data chỉ được truy vấ
n
và thao tác bởi các phương thức định nghĩa trong interface. Chỉ các thông tin cần
cung cấp cho bên ngoài mới được khai báo như là service data, còn các thông tin
nội bộ của service thì không được khai báo.
Các SDE có thể là tĩnh (khai báo trong khi định nghĩa service interface) hoặc
động (được thêm vào service instance trong thời gian chạy). Client có thể sử dụng
phương thức findServiceData của interface GridService để lấy danh sách các SDE
của service instance.
+ Cấu trúc của một Service Data
Một service data có các thuộc tính cơ bản sau: name, type, minOccurs,
maxOccurs, nillable, mutability, và modifiable. Định nghĩa XML của chúng xin
tham khảo tài liệu [6].












Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 71 -

Tên Kiểu giá trị Tập giá trị
Giá trị
default
Diễn giải
name
NCName and
{target
namespace}

Tên của serviceData
type
QName
Xác định kiểu XML
Schema quy định giá trị
của SDE.
minOccurs
nonNegative
Integer

unbounded
(không giới
hạn)

1 Xác định số giá trị SDE
nhỏ nhất xuất hiện trong
serviceDataValues hoặc
staticServiceDataValues,
nếu là 0 là tuỳ chọn

maxOccurs

nonNegative
Integer

unbounded
1 Xác định số giá trị SDE
lớn nhất xuất hiện trong
serviceDataValues hoặc
staticServiceDataValues

nillable
boolean
true/false
false
Có cho phép SDE có giá
trị nil (là một giá trị có
thuộc tính xsi:nil với
value=“true”).
mutability


“static”,
“constant”,
“extendable”
, “mutable”

“extenda
ble”

Quy định cách thức thay
đổi một SDE.

+ “static” : giá trị của
SDE được xác định trong
thành phần
staticServiceDataValues
và được giữ lại trong bất
cứ instance nào có
portType chứa SDE đó.
+ “constant” : giá trị của
SDE được gán trong lúc
tạo instance và được giữ
không đổi trong suốt thời
gian sống của instance.
+ “extendable” : Cho
phép thêm các thành phần
mới vào SDE trong thời
gian chạy, các thành phần
mới khi đã được thêm vào
sẽ không thể loại bỏ khỏi
SDE được n
ữa.
+ “mutable” : tất cả các
thành phần của SDE có
thể được thêm vào hay

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 72 -
loại bỏ bất cứ lúc nào.
modifiable
boolean
true/false
false
Nếu true, cho phép client
cập nhật trực tiếp giá trị
SDE thông qua phương
thức
setServiceData.
Các thuộc tính khác không có
trong namespace

Bảng 3-2 Các thuộc tính cơ bản của một service data.

+ Mở rộng portType để hỗ trợ Service Data
OGSI định nghĩa thêm một thành phần con của portType có tên là
serviceData, được sử dụng để khai báo các thành phần serviceData (SDE) đi kèm
với portType đó. Các giá trị khởi tạo cho serviceData được xác định bằng thành
phần
staticServiceDataValues của portType. Dưới đây là định nghĩa

Ví dụ dưới đây khai báo một portType với 2 thành phần serviceData với tên là
“Host” và “CPU Architecture” và khởi tạo giá trị Host=“GLOBUSTEST”.Mọi
service instance triển khai portType này phải có thông tin về Host và
CPUArchitecture.









<gwsdl:portType name="NCName"> *
<wsdl:documentation … /> ?
<wsdl:operation name="NCName"> … </wsdl:operation> ?
…………
<sd:serviceData name="NCName" … /> *
<sd:staticServiceDataValues>?
<some element>*
</sd:staticServiceDataValues>
……………
<wsdl:definitions xmlns:tns=”xxx” targetNamespace=”xxx”>

<gwsdl:portType name="ServiceDataExample"> *
<wsdl:operation name=…> … </wsdl:operation>
…
<sd:serviceData name="Host" type=”xsd:String”
mutability=”static”/>
<sd:serviceData name="CPUArchitecture" type=”tns:SomeComplexType”/>

…
<sd:staticServiceDataValues>
<tns:Host>GLOBUSTEST</tns:Host>
</sd:staticServiceDataValues>
</gwsdl:portType>








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 73 -
3
3
.
.
2
2
.
.
4
4
.
.
6
6
.

.






L
L
i
i
f
f
e
e
c
c
y
y
c
c
l
l
e
e


Tất cả các thực thể đều có một chu trình sống của mình, chu trình sống là các
bước chuyển trạng thái từ lúc thực thể được tạo ra đến khi bị huỷ đi. Việc quản lý
chu trình sống của service instance rất quan trọng nhất là khi service cần phải hỗ trợ

khả năng phục hồi hoạt động với các giá trị và trạng thái khi server hoặc container
khởi động lại. Các cơ chế cài đặt c
ụ thể để quản lý chu trình sống của service
instance tùy thuộc vào host environment, OGSI không quy định các cơ chế này, tuy
nhiên OGSI định nghĩa các interface cho phép client thao tác với các sự kiện trong
chu trình sống của service instance một cách tổng quát.
+ Về tạo lập service instance
Client có thể gọi phương thức createService của một service instance có cài
đặt interface Factory để tạo một service instance mới.
+ Về huỷ bỏ service instance
Client có thể yêu cầu huỷ service instance một cách tường minh bằng cách
gọi phương thức destroy của interface GridService mà service instance nào cũng cài
đặt; hay quy định thời gian sống cho service instance (qua các phương thức
requestTerminationBefore/After của interface GridService) , sau thời gian đó mà
service instance không nhận được yêu cầu gia hạn từ các client, thì service instance
sẽ tự huỷ. Service instance được phép quyết định khi nào thì sẽ kéo dài thời gian
sống hoặc khi nào sẽ kết thúc (ví dụ : service instance có thể kết thúc trước thời hạn
do không còn tài nguyên,…)
Bên cạnh đó, các service instance có th
ể cung cấp khả năng thông báo về các
sự kiện liên quan đến các chu trình sống của mình thông qua cơ chế Notification
chuẩn (các phương thức của các interface NotificationSource/Sink/Subscription)
3
3
.
.
2
2
.
.

4
4
.
.
7
7
.
.






N
N
o
o
t
t
i
i
f
f
i
i
c
c
a
a

t
t
i
i
o
o
n
n


Là một cơ chế cho phép nguồn thông báo (notification source) phân phối các
thông điệp đến các nơi yêu cầu (notification sink). Một số khái niệm liên quan:
+ Notification source








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 74 -
Là một service instance có cài đặt interface NotificationSource, và là nơi gửi
thông báo đến các Notification sink
+ Notification sink
Là một service instance nhận các thông báo từ nhiều Notification source
khác nhau. Một sink phải cài đặt interface NotificationSink để nhận được các thông
báo.
+ Notification message

Là một thông điệp XML được gửi từ Notification source đến sink. Kiểu của
thông điệp được xác định bởi Subscription expression.
+ Subscription expression
Là một lược đồ XML mô tả thông điệp nào và khi nào thông điệp được gửi
đi, dựa trên sự thay đổi các giá trị SDE của service instance.
+ Hoạt động
1. Để thiết lập quá trình gửi nhận thông điệp, một yêu cầu cần nhận thông
điệp chứa Subscription expression, vị trí của Notification sink, và khoảng thời gian
trong đó cần nhận thông điệp được gửi đến Notification source.
2. Yêu cầu này có thể dẫn đến việc tạo một service instance, gọi là
Subscription, có cài đặt interface NotificationSource. Và instance này sẽ chịu trách
nhiệm trao đổi các thông báo.

Ghi chú : Để có thể hiểu rõ hơn về Grid service và các cơ chế của nó, xin xem
thêm trong phụ lục C - “Kỹ thuật cài đặt các cơ chế của Grid Service”
3
3
.
.
3
3
.
.


K
K
i
i
ế

ế
n
n


t
t
r
r
ú
ú
c
c


G
G
l
l
o
o
b
b
u
u
s
s


T

T
o
o
o
o
l
l
k
k
i
i
t
t


Bộ Globus Toolkit giải quyết các vấn đề của công nghệ Grid Computing dựa
trên 4 thành phần chính. 3 thành phần Resource Management, Information Service,
Data Management liên kết hoạt động trên nền tảng bảo mật chung, Sercurity
Infrastructure. Ngoài ra, GT còn cung cấp một bộ các hàm API và SDK nhằm giúp
phát triển, xây dựng các ứng dụng Grid.








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 75 -

GT3 được thiết kế lại để hỗ trợ hoàn toàn OGSI. Tuy nhiên, cần phải chú ý rằng
GT3 không chỉ là một bản cài đặt của OGSI. GT3 bao gồm rất nhiều các dịch vụ,
chương trình, công cụ,…. Một số trong chúng được xây dựng trên OGSI và được
gọi là WS (Web Services) components, một số khác không dựa trên OGSI, được gọi
là pre-WS components.
Bộ GT3, tồn tại song song 2 mô hình kiến trúc như trên hình 3-2. Các nhà phát
triển có thể sử dụng một trong hai mô hình để xây dựng các ứng d
ụng và các hệ
thống Grid của mình. Tuy nhiên, mô hình Grid service dựa theo OGSI được khuyến
khích sử dụng.

Hình 3-2 Kiến trúc của bộ Globus Toolkit.
3
3
.
.
3
3
.
.
1
1
.
.




M
M

ô
ô


h
h
ì
ì
n
n
h
h


k
k
i
i
ế
ế
n
n


t
t
r
r
ú
ú

c
c


G
G
T
T
2
2


Trong mô hình kiến trúc GT2, có thể thấy rõ ràng 4 thành phần của bộ GT,
GRAM đảm nhận phần Resource Management, MDS đảm nhận phần Information
Service, GridFTP đảm nhận phần Data management (phần truyền dữ liệu). 3 thành
phần này được xây dựng trên nền tảng bảo mật chung là Grid Sercurity
Infrastructure (GSI). Các thành phần được thiết kế theo module, có thể sử dụng độc
lập hoặc phối hợp với nhau thông qua giao diện riêng của từng thành phần.
Mô hình hệ thống Grid sử dụng GT2 nh
ư sau :








Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 76 -

Hình 3-3 Mô hình các thành phần của một hệ thống sử dụng GT2

3
3
.
.
3
3
.
.
2
2
.
.




M
M
ô
ô


h
h
ì
ì
n

n
h
h


k
k
i
i
ế
ế
n
n


t
t
r
r
ú
ú
c
c


G
G
T
T
3

3


Mô hình GT3 hơi khác biệt hơn mô hình GT2, cũng 4 thành phần đó, nhưng các
thành phần này được thiết kế để trở thành các OGSI Grid service, được truy xuất
thông qua một giao diện chung, điều này giúp việc các ứng dụng sử dụng các
service dễ dàng hơn.
Dưới đây là mô hình tổ chức các thành phần của GT3 :









Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 77 -

Hình 3-4 Mô hình tổ chức các thành phần GT3.
Các khung có nền trắng là các thành phần cung cấp bởi GT3 Core. Chúng là các
khối cơ bản để xây dựng các Grid service. Thành phần OGSI Reference
Implementation cài đặt cho tất cả các interface xác định bởi OGSI cũng như các
hàm API và công cụ để phát triển các OGSI Grid service. Thành phần Security
Infrastructure cung cấp các dịch vụ truyền thông SOAP cũng như thực hiện bảo vệ
các thông điệp, chứng thực hai chiều (mutual authentication), và đăng nhập một lần;
thiết kế lại nền tảng GSI trong GT2 để
hoạt động trong môi trường OGSI. Hai khối
cơ bản này không cung cấp các service thực thi được nhưng như là cơ sở của tất cả

các service khác. Tuy nhiên, GT3 Core cũng có một số service có khả năng thực thi
nền tảng đủ tổng quát để được sử dụng và liên kết với tất cả các Grid service khác.
Những service này được gọi là System-Level Service, được xây dựng trên cơ sở
OGSI Reference Implementation và Security Infrastructure. GT3 cũng cung cấp
một số service cấp cao h
ơn, Base Service, như các service quản lý tài nguyên
(MMJFS) , quản lý dữ liệu (RFT), các service cung cấp thông tin (Index service).
Khái niệm User-Defined Service dùng để chỉ các service cấp cao hơn nữa, không
cung cấp bởi GT3, được xây dựng trên tất cả thành phần của GT3 bao gồm luôn
Base Service.
Tất cả các service và các thành phần cơ bản tương tác với một môi trường thực
thi OGSI ảo, gọi là Grid Service Container. Mục đích của container là làm lớp phân