Luận văn Bảo mật trong môi trường lưới với tiếp cận hướng tác tử

cho truyền thông điệp, điều này là một thuận lợi lớn khi ta phát triển các ứng dụng trên Internet, bởi vì các tường lửa và proxy trên Internet không làm đảo lộn các truyền 41 thông của HTTP (không giống như CORBA gặp phiền toái với vấn đề tường lửa). Tuy nhiên, dịch vụ web có một số nhược điểm, đó là: - Trước hết, việc truyền toàn bộ dữ liệu bằng XML rõ ràng là không hiệu quả bằng việc sử dụng mã nhị phân. Để có được tính khả chuyển, nó đã phải đánh đổi bằng tính hiệu quả. - Thiếu tính linh động: Hiện tại dịch vụ web là không linh động, khi chúng chỉ cho phép một số dạng triệu gọi dịch vụ cơ bản. CORBA có thể cho phép lập trình viên nhiều cách cung cấp dịch vụ hơn như là dịch vụ vĩnh viễn (persistency), thông báo (notifications), quản lý vòng đời (lifecycle management). Ở phần sau, ta sẽ thấy cách mà dịch vụ lưới bổ sung các nhược điểm trên của dịch vụ web. Tuy nhiên, có một đặc điểm quan trọng để phân biệt dịch vụ web với các công nghệ tính toán phân tán khác. Trong khi các công nghệ như CORBA, EJBs hướng vào các hệ thống tính toán phân tán phụ thuộc chặt (highly-coupled distributed systems), khi mà client và server phải phụ thuộc vào nhau, dịch vụ web lại thích hợp cho các hệ thống phân tán không phụ thuộc (losely- coupled systems), khi mà client có thể không biết gì về dịch vụ web cho tới khi nó triệu gọi các dịch vụ Web. Các hệ thống phân tán phụ thuộc là lý tưởng cho các ứng dụng Intranet, nhưng lại có hiệu suất thấp trên môi trường Internet. Điều này giải thích tại sao dịch vụ web thích hợp hơn đối với các ứng dụng trên Internet nói chung và các ứng dụng trên môi trường lưới nói riêng. 2.1.2.1. Một triệu gọi dịch vụ web điển hình Để hiểu rõ hơn về hoạt động của dịch vụ web, hãy theo dõi các bước để triệu gọi một dịch vụ web. 42 Hình 2.3. Một triệu gọi dịch vụ web điển hình 1. Như đã đề cập trước đó, một client có thể không biết gì về dịch vụ web mà nó định triệu gọi. Bởi vậy, bước đầu tiên là tìm một dịch vụ web đáp ứng các đòi hỏi của nó. Ví dụ, nếu quan tâm tới một dịch vụ web cung cấp thông tin về thời tiết của các thành phố của Mỹ, ta có thể tìm nó qua bộ đăng ký và khai phá dịch vụ UDDI. 2. Bộ đăng ký UDDI sẽ trả lời cho chúng ta biết server nào cung cấp dịch vụ mà ta yêu cầu. 3. Khi đã biết về vị trí của dịch vụ web, nhưng vẫn chưa biết triệu gọi dịch vụ đó như thế nào. Chúng ta phải yêu cầu dịch vụ web mô tả thông tin về chính nó để biết chính xác phương thức nào cần triệu gọi. 4. Dịch vụ web sẽ trả lời bằng một ngôn ngữ gọi là WSDL. 5. Cuối cùng, chúng ta đã biết dịch vụ web nằm ở đâu và triệu gọi nó như thế nào. Quá trình triệu gọi được thực hiện bởi một ngôn ngữ gọi là 43 SOAP. Do đó, trước tiên ta phải gửi một yêu cầu SOAP (SOAP request) để lấy thông tin về thời tiết. 6. Dịch vụ Web sẽ trả lời với một đáp ứng SOAP (SOAP response) chứa thông tin về thời tiết mà ta yêu cầu. Nó có thể là một thông báo lỗi nếu yêu cầu SOAP của chúng ta không đúng. 2.1.2.2. Kiến trúc dịch vụ web: Hình 2.4. Kiến trúc dịch vụ web - Tầng xử lý dịch vụ (Process): tầng này có thể bao gồm nhiều dịch vụ web. Ví dụ. khả năng khám phá dịch vụ (thuộc về tầng này của kiến trúc) cho phép tìm một dịch vụ web cụ thể từ một tập các dịch vụ web. - Tầng mô tả dịch vụ (Description): một trong những đặc điểm thú vị của dịch vụ web là nó có khả năng tự mô tả về mình, về những thao tác mà nó có thể cung cấp, tham số vào ra,… Điều này được thực hiện bằng ngôn ngữ mô tả dịch vụ web (Web Service Description Language – WSDL). - Tầng triệu gọi dịch vụ (Invocation): tầng này chịu trách nhiệm gọi dịch vụ web giữa client và server sau khi đã nắm được vị trí và phương thức triệu gọi. SOAP (Simple Object Access Protocol) sẽ được sử dụng để thông báo cho phía client biết quy cách đưa một yêu cầu đến server và quy cách của kết quả trả về. Khai phá, kết hợp, … WSDL Web Services Description Language Giao thức triệu gọi phổ biến là SOAP nhưng về lý thuyết có thể sử dụng các giao thức khác Giao thức truyền thông phổ biến là HTTP, nhưng về lý thuyết có thể sử dụng các giao thức khác 44 - Tầng vận chuyển (Transport): tầng này trực tiếp gửi các gói tin giữa 2 phía server và client. Giao thức được sử dụng là HTTP (HyperText Transfer Protocol). 2.1.2.3. Địa chỉ của dịch vụ web Các dịch vụ web được xác định bằng các định danh tài nguyên thống nhất URIs (Uniform Resource Identifiers) tương tự như URL (Uniform Resource Locator). Chẳng hạn dịch vụ cung cấp thông tin dự báo thời tiết có địa chỉ URI như sau: Địa chỉ này giống như một trang web. Tuy nhiên, dịch vụ web được sử dụng bởi các phần mềm. Nếu người dùng gõ một địa chỉ dịch vụ web URI vào trong trình duyệt, ta sẽ nhận được một thông báo lỗi. Thực tế, hầu hết các chương trình ta viết sẽ nhận về URI của dịch vụ web như một tham số dòng lệnh. 2.1.2.4. Một ứng dụng dịch vụ web Việc triệu gọi dịch vụ web được thực hiện qua client stub. Vì vậy, trong lược đồ triệu gọi ở phần trước (hình 2.4), client thường không phải thực hiện tất cả các bước trong một triệu gọi đơn. Hơn thế nữa, client stub còn có thể được sinh tự động dựa trên mô tả WSDL của dịch vụ web. Hình 2.5. Client và server stub được sinh ra từ file WSDL 45 Như vậy thứ tự các sự kiện bên phía client liên quan đến sử dụng dịch vụ web là như sau: - Xác định một dịch vụ web đáp ứng các yêu cầu thông qua UDDI. - Thiết lập mô tả WSDL của dịch vụ web. - Phát sinh stubs ngay sau đó, cho chúng vào ứng dụng của chúng ta. - Ứng dụng sẽ sử dụng stubs tại mỗi thời điểm nó triệu gọi dịch vụ web. Mô hình lập trình phía server cũng rất đơn giản, ta không cần phải viết một chương trình server phức tạp, tự động thông dịch các yêu cầu SOAP và đưa ra các đáp ứng SOAP. Chúng ta đơn giản chỉ cài đặt tất cả các chức năng cho dịch vụ web của chúng ta, sau đó sinh ra một server stub (hay còn được gọi là skeleton). Server stub sẽ chịu trách nhiệm thông dịch các yêu cầu, đưa chúng tới cho dịch vụ thực thi. Nó cũng có thể tự động sinh ra mô tả WSDL, hay các ngôn ngữ mô tả khác (IDL trên CORBA). Việc thực thi phía server và server stubs được quản lý thông qua một thành phần gọi là trình chứa dịch vụ web (Web Service container), bảo đảm các yêu cầu HTTP cho dịch vụ web được trực tiếp tới server stub. Giả sử rằng chúng ta đã định vị được dịch vụ web, và phát sinh client stubs từ mô tả WSDL. Ngoài ra, các lập trình viên phía server cũng phải phát sinh server stubs. Các bước liên quan tới triệu gọi một dịch vụ web được mô tả như hình 2.6. Hình 2.6. Chi tiết một triệu gọi dịch vụ web điển hình 46 1. Bất cứ khi nào ứng dụng client cần triệu gọi dịch vụ web, nó sẽ gọi client stub. Client stub sẽ chuyển triệu gọi địa phương ('local invocation') vào trong một yêu cầu SOAP phù hợp. Quá trình này được gọi là marshaling hay serializing. 2. Yêu cầu SOAP được gửi qua mạng thông qua giao thức HTTP. Trình chứa dịch vụ nhận được các yêu cầu SOAP, và chuyển nó tới server stub. Server stub sẽ biến đổi các yêu cầu SOAP thành dạng phù hợp để chương trình thực thi phía server có thể hiểu được (quá trình này được gọi là unmarshaling hay deserializing). 3. Thực thi dịch vụ sẽ nhận các yêu cầu từ service stub, và tiến hành công việc mà nó được yêu cầu. 4. Kết quả của các toán tử được yêu cầu được chuyển tới server stub, và stub sẽ chuyển nó thành các đáp ứng SOAP. 5. Đáp ứng SOAP được gửi qua mạng thông qua giao thức HTTP. Client stub nhận được các đáp ứng SOAP và chuyển nó về dạng phù hợp để các ứng dụng client có thể hiểu được. 6. Cuối cùng, ứng dụng nhận được kết quả của triệu gọi dịch vụ web và sử dụng nó. 2.1.2.5. Dịch vụ web – phía server Cuối cùng chúng ta cùng xem xét kiến trúc phía server của một ứng dụng dịch vụ web. 47 Hình 2.7. Kiến trúc phía server của một ứng dụng dịch vụ web - Dịch vụ web: Như đã đề cập ở trên, dịch vụ web chỉ là một phần mềm nhỏ để thực hiện một chức năng nào đó, nó có thể được viết bằng một ngôn ngữ lập trình nào đó, chẳng hạn Java. Tuy nhiên, dịch vụ web lại không thể hiểu được các thông điệp SOAP và càng không thể tạo ra được các thông điệp SOAP trả lời, do đó ta cần SOAP engine. - SOAP engine đơn giản là một phần mềm để xử lý các yêu cầu SOAP và sinh ra các thông điệp trả lời. Thực tế, người ta thường dùng một SOAP engine thay vì thực sự sinh ra các server stubs cho mỗi dịch vụ web riêng lẻ (chú ý rằng, ta vẫn cần các client stubs cho client). Ví dụ cho một SOAP engine là Apache Axis (thực tế SOAP engin này được sử dụng trong Globus Toolkit). Tuy nhiên, chức năng của SOAP engine thường chỉ giới hạn trong việc thao tác SOAP. Để có một chức năng thực sự như một server có thể nhận các yêu cầu từ các client khác nhau, ta nhúng SOAP engine trong trong Server ứng dụng. 48 - Server ứng dụng (application server) là phần mềm cung cấp "không gian sống" cho các ứng dụng có thể truy nhập từ các client khác nhau. SOAP engine chạy như một ứng dụng trong server ứng dụng này. Ví dụ cho server ứng dụng là Jakarta Tomcat, một trình chứa JSP và Java Servlet thường dùng trong Apache Axis của Globus Toolkit. Nhiều server ứng dụng đã bao gồm các chức năng HTTP, cho nên ta có thể cài đặt và chạy các dịch vụ web bằng cách cài đặt một SOAP engine cùng một server ứng dụng. Tuy nhiên, khi một server ứng dụng thiếu các tính năng HTTP, chúng ta cần có thêm server HTTP. - Server HTTP: thường được gọi là web server. Nó là một phần mềm biết cách để xử lý các thông điệp HTTP. Ví dụ: Apache HTTP Server là một trong những web server thông dụng nhất trên Internet. 2.1.3. WSRF - nền tảng tài nguyên dịch vụ web Như đã đề cập trong phần trước, dịch vụ web là công nghệ được lựa chọn bởi các ứng dụng trên Internet với sự ràng buộc "lỏng lẻo" giữa client và server. Điều này làm cho nó trở thành sự lựa chọn đầu tiên để xây dựng các ứng dụng lưới. Tuy nhiên dịch vụ web lại có một số nhược điểm nhất định. Trên thực tế, dịch vụ web thuần túy (được xây dựng bới W3C) không phù hợp cho việc phát triển các ứng dụng lưới. WSRF, khắc phục các điểm không phù hợp của dịch vụ web, làm cho nó thích hợp với việc phát triển các ứng dụng lưới hơn. 2.1.3.1. WSRF - tất cả đều là trạng thái Các dịch vụ web thuần túy thường là “phi trạng thái”, nghĩa là nó không thể nhớ các kết quả từ một lần triệu gọi từ các lần triệu gọi khác. Điều này được minh họa bằng ví dụ trong hình sau. Trong ví dụ này, kết quả của phép cộng không được lưu lại sau mỗi lần thực hiện. 49 Hình 2.8. Một triệu gọi dịch vụ web phi trạng thái Tuy nhiên, khả năng “nhớ trạng thái” là một tính chất rất quan trọng đối với ứng dụng lưới. Ví dụ sau thể hiện một dịch vụ web “có trạng thái”. Hình 2.9. Một triệu gọi dịch vụ web có trạng thái 50 Giải pháp được đề nghị thực tế lại rất đơn giản: chỉ cần giữ cho dịch vụ web và thông tin về trạng thái của nó riêng rẽ nhau. Thay vì đặt trạng thái vào trong dịch vụ web, ta sẽ lưu nó vào trong một thực thể riêng gọi là tài nguyên, cái mà sẽ lưu giữ tất cả các thông tin về trạng thái. Mỗi tài nguyên sẽ có một khóa duy nhất, do đó bất cứ khi nào ta muốn một tương tác liên quan đến trạng thái với một dịch vụ web, chỉ cần chỉ thị cho dịch vụ web sử dụng tài nguyên cụ thể đó. Ví dụ với dịch vụ web thực hiện phép cộng ở trên. Hình vẽ dưới đây thể hiện dịch vụ web này có thể có 3 tài nguyên khác nhau (A, B, C) để lựa chọn. Nếu ta muốn một giá trị nguyên được “nhớ” từ một lần triệu gọi đến một lần triệu gọi khác, client chỉ cần chỉ ra nó muốn triệu gọi phương thức với tài nguyên nào. Hình 2.10. Cách tiếp cận tài nguyên cho vấn đề trạng thái của dịch vụ web Trong hình 2.10, ta có thể thấy client muốn thực hiện phép toán cộng với tài nguyên C. Khi dịch vụ web nhận được yêu cầu thực hiện phép tóan cộng, nó sẽ đảm bảo việc nhận tài nguyên C để phép cộng được thực hiện thực sự trên tài nguyên đó. Các tài nguyên tự chúng có thể lưu trong bộ nhớ trong, bộ nhớ ngoài hay ngay cả trong CSDL. Ngoài ra, cũng cần chú ý cách mà một 51 dịch vụ web có thể truy nhập nhiều tài nguyên. Tất nhiên là các tài nguyên có thể có kích thước và cấu trúc khác nhau. Một tài nguyên có thể lưu giữ nhiều giá trị (không chỉ là một số nguyên đơn thuần như ví dụ trên). Chẳng hạn, các tài nguyên có thể biểu diễn các file: Hình 2.11. Một dịch vụ web với nhiều tài nguyên, mỗi tài nguyên biểu diễn một file Client chỉ ra chính xác dịch vụ web bằng địa chỉ URI, còn để chỉ ra tài nguyên – cách thường dùng là dùng một kỹ thuật mới gọi là ánh xạ dịch vụ web (một kỹ thuật linh hoạt để chỉ ra địa chỉ của dịch vụ web hơn là địa chỉ URI thông thường). Chú ý rằng, một cặp dịch vụ web với tài nguyên được gọi là dịch vụ web – tài nguyên. Địa chỉ của một dịch vụ web – tài nguyên cụ thể được gọi là một endpoint reference (đây là một thuật ngữ trong ánh xạ dịch vụ web). 52 Hình 2.12. Dịch vụ web – tài nguyên 2.1.3.2. Đặc tả WSRF WSRF là một tập hợp của 4 đặc tả khác nhau liên quan đến quản lý dịch vụ web – tài nguyên: Các thuộc tính của dịch vụ web – tài nguyên (WS- ResourceProperties): Một tài nguyên gồm 0 hoặc nhiều thuộc tính tài nguyên. Ví dụ, trong hình vẽ trên, mỗi tài nguyên có 3 thuộc tính tài nguyên là: Filename, Size và Desriptors. WS - ResourceProperties xác định cách các thuộc tính tài nguyên được định nghĩa và truy nhập. Các thuộc tính nằy được định nghĩa bằng ngôn ngữ mô tả giao diện dịch vụ web WSDL. Vòng đời của dịch vụ web – tài nguyên (WS-ResourceLifetime): Các tài nguyên có vòng đời không tầm thường. Nói cách khác, chúng không phải là những thực thể tĩnh, được khởi tạo khi server khởi động và bị hủy khi server tắt. Các tài nguyên có thể được khởi tạo và hủy tại bất kì thời điểm nào. WS-ResourceLifetime cung cấp các cơ chế cơ bản để quản lý vòng đời tài nguyên. 53 Nhóm dịch vụ web (WS-ServiceGroup): WS-ServiceGroup chỉ ra một cách chính xác cách nhóm các dịch vụ web hoặc dịch vụ web - tài nguyên. Mặc dầu khả năng được cung cấp mới chỉ ở mức cơ bản, tuy nhiên nó là nền tảng cho những dịch vụ mạnh hơn (chẳng hạn IndexService) cho phép nhóm các dịch vụ khác nhau và truy nhập chúng thông qua một “lối vào” duy nhất. Các lỗi cơ bản của dịch vụ web (WS-BaseFaults): đặc tả này cung cấp một cách thức chuẩn để thông báo lỗi khi có vấn đề xảy ra trong quá trình triệu gọi dịch vụ web. 2.1.4. Kiến trúc Globus Toolkit 4 Như đã trình bày, WSRF là cơ sở hạ tầng của GT4. Ngoài triển khai WSRF, GT4 còn bao gồm rất nhiều các thành phần khác mà ta có thể sử dụng để viết các ứng dụng lưới. Như trong hình 2.13, các thành phần này được chia thành 5 loại: bảo mật, quản lý dữ liệu, quản lý việc thực hiện công việc, các dịch vụ thông tin và môi trường chạy ứng dụng. Chú ý rằng, mặc dù GT4 tập trung vào dịch vụ web nhưng nó vẫn chứa các thành phần không được triển khai trên nền dịch vụ web, chẳng hạn GridFTP. Trong hình 2.13, nửa trên thể hiện các thành phần được phát triển dựa trên kiến trúc dịch vụ web; còn nửa dưới là các thành phần không dựa trên kiến trúc dịch vụ web. 54 Hình 2.13. Kiến trúc Globus Toolkit 4 - Thành phần bảo mật (Security): sử dụng các thành phần bảo mật, dựa trên cở sở hạ tầng bảo mật lưới, chúng ta có thể đảm bảo việc truyền thông sẽ được an toàn. - Thành phần quản lý dữ liệu (Data Management): các thành phần này cho phép chúng ta quản trị một tập dữ liệu lớn trong các tổ chức ảo. Các thành phần cốt lõi của Globus Toolkit, sẽ không thay đối trong tương lai Các thành phần tạm thời, có thể sẽ còn thay đổi trong tương lai Các thành phần sẽ được bỏ đi trong tương lai 55 - Thành phần quản lý thực thi (Excution Management): các thành phần quản lý thực hiện công việc phụ trách việc khởi tạo, theo dõi, quản lý, lập lịch và tương tác giữa các chương trình trong lưới. - Thành phần dịch vụ thông tin (Information Services): các dịch vụ thông tin, thường chỉ các dịch vụ khám phá và theo dõi (Monitoring and Discovery Services - MDS) bao gồm một tập các thành phần dùng để tìm và theo dõi tài nguyên trong một tổ chức ảo. Phiên bản non-WS của MDS là MDS2 vẫn được GT4 hỗ trợ, tuy nhiên nó sẽ bị bỏ đi trong các phiên bản sau. - Thành phần Common Runtime: cung cấp tập các thư viện cơ sở và các công cụ để xây dựng các dịch vụ WS lẫn non-WS 2.2. Các thành phần bảo mật trong GT4 Bảo mật là một trong những vấn đề quan trọng nhất được đặt ra trong môi trường lưới vì vậy Globus Toolkit 4 chứa đựng nhiều loại thành phần bảo mật [4]: - Thành phần xác thực và cấp phép dịch vụ web (WS authentication and authorization). Globus Toolkit 4 cho phép bảo mật mức thông điệp và mức giao vận cho các truyền thông SOAP của các dịch vụ Web. Đồng thời, nó cung cấp một cơ cấu cấp phép cho việc cấp phép mức container. - Pre-WS authentication and authorization. Nó bao gồm các API và các công cụ cho việc xác thực, cấp phép và quản lý giấy chứng nhận. - Dịch vụ cấp phép cộng đồng (Community Authorization Service - CAS). CAS cung cấp điều khiển truy xuất tới các tổ chức ảo. Máy chủ CAS cấp các giấy phép theo các tập con tài nguyên cho thành viên của 56 cộng đồng. Việc cấp phép CAS hiện tại chưa có trong các dịch vụ web, tuy nhiên nó hỗ trợ cho GridFTP server. - Dịch vụ ủy quyền (Delegation service). Dịch vụ này cho phép ủy thác giấy ủy quyền giữa các dịch vụ trên một máy. Dịch vụ ủy quyền cho phép một giấy ủy quyền được sử dụng bởi nhiều dịch vụ. Đồng thời, dịch vụ này cũng cung cấp giao diện thay mới giấy ủy quyền và qua đó có thể gia hạn cho các giấy ủy quyền. Hình 2.14. Ví dụ về việc sử dụng một dịch vụ bởi một dịch vụ khác - SimpleCA, đây là một Nhà chứng nhận thẩm quyền đơn giản. Thành phần này có đầy đủ các chức năng của một môi trường khóa công khai. Tuy nhiên, thành phần này chủ yếu được sử dụng với mục đích kiểm thử và minh họa. 57 - MyProxy, thành phần này có nhiệm vụ lưu trữ các giấy ủy quyền X.509, bảo vệ chúng và cung cấp giao diện cho việc lấy lại các giấy ủy quyền. MyProxy thực hiện vai trò của một kho chứa các giấy ủy quyền và nó thường được sử dụng bởi các ứng dụng Web portal. - GSI-OpenSSH, đây là một phiên bản đã được hiệu chỉnh cho máy chủ và máy trạm OpenSSH, với việc thêm vào hỗ trợ cho sự xác thực GSI. GSI-OpenSSH có thể được sử dụng để tạo từ xa một shell trên một hệ thống ở xa để thực thi các kịch bản vỏ (shell script) hoặc để đưa ra các lệnh shell một cách tương tác và nó cũng cho phép truyền các file giữa các hệ thống mà không đòi hỏi về mật khẩu cũng như ID của người dùng. Tuy nhiên, một sự ủy nhiệm hợp lệ phải được tạo bằng cách sử dụng lệnh grid-proxy-init. 2.3. Ví dụ minh họa: cài đặt bảo mật trong GRAM GRAM (Globus Resource Allocation Management) là dịch vụ của GT cho phép client có thể khởi tạo, quản lý, theo dõi một cách an toàn các nhiệm vụ tính toán trên các máy ở xa. Việc tiến hành bảo mật đối với GRAM là một trong những công việc phức tạp nhất bởi vì nó liên quan nhiều đến cả cơ chế bảo mật địa phương và các client từ xa. Phần này sẽ trình bày việc cài đặt bảo mật trong GRAM để minh họa cho việc cài đặt bảo mật cho các dịch vụ. 58 Hình 2.15. Cơ chế thực hiện của GRAM Để có thể thực hiện công việc nhờ GRAM, một client phải mô tả công việc, chỉ rõ những chi tiết về thư mục thực thi, nơi lưu trữ các đầu ra và đầu vào… Những mô tả này được gửi tới tài nguyên và kết quả là một thực thể của dịch vụ quản lý công việc (Managed Job Service - MJS). Một MJS là một dịch vụ của lưới cho phép khởi tạo công việc, điều khiển, theo dõi công việc. MJS được tạo bởi một MJS factory service. Về lý thuyết thì ta sẽ có tương ứng với mỗi tài khoản người dùng một MJS factory service, tuy nhiên trong thực tế để tránh lãng phí, GT thực thi một dịch vụ là Master Managed Job Factory Service (MMJFS). Mỗi MMJFS chạy trên mỗi tài nguyên và triệu gọi Local Managed Job Factory Services (LMJFS) cho mỗi tài khoản người dùng khi cần thiết. Một dịch vụ là Proxy Router dẫn những yêu cầu từ người dùng tới LMJFS nếu có hoặc MMJFS nếu LMJFS của người dùng đó không 59 tồn tại. Với MJS factory thì có thể có một hay nhiều thể hiện của MJS chạy cùng một lúc trên trình chứa. Như minh họa trên hình 2.15, để thực hiện công việc trên GRAM phải trải qua 7 bước: 1. Requestor tạo một bản mô tả công việc và ký lên nó với một giấy ủy nhiệm thích hợp. Yêu cầu này sau đó được gửi tới target resource. 2. Proxy Router service nhận yêu cầu và gửi tới LMJFS nếu có (nhảy tới bước 6) hoặc gửi tới MMJFS (thực hiện tiếp bước 3). 3. MMJFS xác nhận chữ ký trên yêu cầu sau đó xác định tài khoản cục bộ mà job sẽ chạy dựa trên tài khoản đó sử dụng grid-mapfile, một file nằm trên máy cục bộ chứa đựng những thông tin ánh xạ từ GSI vào tài khoản cục bộ. 4. MMJFS triệu gọi quá trình Setuid Starter để khởi tạo LMJFS. Setuid Starter là một chương trình có đặc quyền (ví dụ như setuid-root) mà chức năng duy nhất của nó là khởi tạo một LMJFS đã được cấu hình sẵn cho một người dùng. 5. Khi LMJFS đã được tạo, nó cần nhận được giấy ủy nhiệm và phải tự đăng ký với Proxy Router để nó thể nhận được các yêu cầu khác trong tương lai. LMJFS triệu gọi Grid Resource Identity Mapper (GRIM) để nhận được giấy ủy nhiệm. GRIM là một chương trình có đặc quyền truy cập và sinh ra các giấy ủy nhiệm cho LMJFS. Giấy ủy nhiệm này chứa trong nó định danh người dùng lưới, tên người dùng cục bộ … để giúp cho requestor có thể đảm bảo đây đúng là LMJFS cần thiết. 6. LMJFS nhận được yêu cầu công việc, LMJFS kiểm định chữ ký trên yêu cầu để đảm bảo là nó không bị giả mạo và kiểm tra xem requestor có được quyền truy cập tài khoản người dùng cục bộ mà LMJFS đang 60 chạy. LMJFS khởi tạo một MJS và trả lại tham chiếu dịch vụ đến người dùng. 7. Requestor kết nối tới MJS để bắt đầu công việc. Requestor và MJS kiểm chứng lẫn nhau trước khi tiến hành quá trình giao dịch. MJS kiểm định xem requestor có đủ thẩm quyền để thực thi trong tài khoản cục bộ hay không còn requestor kiểm định xem MJS có giấy ủy nhiệm (GRIM credential) hợp lý từ máy chủ hay không, điều này cho phép client không chỉ xác định được là MJS chạy trên đúng máy chủ mà còn chạy trên đúng tài khoản. 61 Chương 3. Ứng dụng công nghệ tác tử trong tính toán lưới 3.1. Tác tử 3.1.1. Khái niệm tác tử 3.1.1.1. Tác tử Tác tử “là một phần mềm máy tính hoạt động trong một môi trường nào đó, có khả năng linh hoạt, thực hiện các hoạt động tự trị trong môi trường đó để đạt được các mục tiêu thiết kế” [8]. Chi tiết hơn [9], tác tử: - Là thực thể giải quyết vấn đề được xác định một cụ thể với các ranh giới và giao diện được định nghĩa rõ ràng. - Hoạt động trong một môi trường cụ thể, nhận các đầu vào liên quan đến sự thay đổi trạng thái của môi trường thông qua các cảm biến và thực hiện các hành vi phản ứng lại các thay đổi đó. - Được thiết kế để hoàn thành một vai trò cụ thể, có các mục tiêu xác định cần đạt được và các khả năng giải quyết vấn đề nhằm đạt mục tiêu. - Có khả năng tự trị, có thể điều khiển cả trạng thái bên trong lẫn các hành vi bên ngoài. - Hoạt động hướng mục tiêu, có các hành vi linh hoạt để theo đuổi mục tiêu cần đạt được. Có thể là phản ứng lại các tác động hoặc chủ động thực hiện các hành vi. 3.1.1.2. Các đặc trưng của tác tử - Tính tự trị: Một tác tử có thể hoạt động mà không cần sự can thiệp trực tiếp của con người hoặc các thành phần khác. Điều này đòi hỏi trong các phần mềm tác tử phải cài đặt các hoạt động có chu kì để tạo ra khả năng thực thi tự phát, trong đó tác tử phải có khả năng thực hiện các 62 hành động có mức ưu tiên khác nhau và cuối cùng đem lại kết quả mong muốn cho con người. - Khả năng phản ứng: Các tác tử có thể nhận thức được môi trường xung quanh chúng và phản ứng lại sự thay đổi xảy ra trong môi trường đó. Các hành động của chúng được thực hiện như là kết quả của việc kích hoạt các luật hoặc của các hoạt động lặp đi lặp lại, chẳng hạn như cập nhật cơ sở tri thức của tác tử, gửi thông điệp tới các tác tử khác trong môi trường. - Khả năng cộng tác: Mỗi tác tử có thể tương tác với các tác tử khác và/hoặc con người. Đối với hình thức tương tác giữa tác tử và con người, người sử dụng chỉ rõ những hành động nào sẽ được thực hiện và tác tử chỉ rõ nó có thể làm cái gì và cung cấp cho người dùng kết quả như thế nào. Còn sự hợp tác giữa các tác tử là cơ chế mà thông qua đó các tác tử trao đổi tri thức, các kế hoạch cộng tác giữa chúng để giải quyết những vấn đề lớn hơn khả năng của mỗi tác tử. - Khả năng di trú: Các tác tử có thể di chuyển đến các môi trường khác, tìm kiếm thông tin cần thiết và trả lại kết quả mà người dùng mong muốn. 3.1.1.3. Phân loại tác tử Dựa trên các thuộc tính được trình bày ở trên, có thể chia tác tử thành các loại sau: - Tác tử tự trị: Các tác tử loại này thường