Luận văn Nghiên cứu mô hình phân tải server sử dụng proxy động

cứu mô hình phân tải Server sử dụng Proxy động 8 2.1.2. FIPA (Foundation for Intelligent, Physical Agents) Phần này sẽ giới thiệu một cách tổng quát về lịch sử phát triển và nội dung chính của các đặc tả FIPA. Tập hợp đầy đủ các đặc tả của FIPA có thể được tìm thấy trên trang web chính thức của FIPA [17]. Jade là sự thi hành của các đặc tả FIPA vì thế nó phụ thuộc lớn vào các ý tưởng được đưa ra trong các đặc tả và được mở rộng dựa trên chính các văn bản đi kèm. Tuy nhiên các đặc tả FIPA không được thể hiện hoàn toàn ở trong Jade vì Jade có mở rộng thêm ở một số khu vực so với các đặc tả. 2.1.2.1. Lịch sử phát triển FIPA được thành lập năm 1996 như là một tổ chức phi lợi nhuận quốc tế với mục tiêu phát triển tập hợp các chuẩn liên quan đến công nghệ phần mềm Agent. Các thành viên ban đầu, tập hợp của các tổ thức nghiên cứu và công nghiệp, đưa ra một tập hợp các quy chế hướng dẫn sản xuất cho một tập hợp các đặc tả chuẩn de jure [2] dành cho công nghệ phần mềm Agent. Ở thời điểm này, các phần mềm Agent đã được biết đến rộng rãi trong giới khoa học nhưng nhận được rất ít sự quan tâm của các tổ chức thương mại. Những người đứng đầu đã đồng ý cho sản xuất các chuẩn có thể tạo ra một nền tảng cứng của một kỹ thuật mới bằng cách sử dụng chéo một lượng lớn các ứng dụng. Cốt lỗi của FIPA sẽ theo tập hợp các nguyên lý: - Các Công nghệ Agent cho phép một mô hình mới để giải quyết các vấn đề cũ và mới. - Các công nghệ Agent sẽ tiến đến cấp độ trưởng thành lớn. - Để sử dụng được, các công nghệ Agent cần phải có đặc tả. - Đặc tả của công nghệ tiến hoá được đưa ra để hỗ cung cấp các kết quả thu được bởi đặc tả fora. - Đặc tả của cơ chế bên trong các Agent không phải mối quan tâm chính, mà là cơ sở hạ tầng và ngôn ngữ yêu cầu cho khả năng phối hợp mở. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 9 2.1.2.2. Các khái niệm cốt lõi Trong suốt quá trình phát triển của FIPA, rát nhiều các ý tưởng liên quan đến Agent đã được đưa ra. Nhiều ý tưởng đã tiến tới việc thực hiện sau khi được đưa ra thành các chuẩn, một vài ý tưởng vẫn đang được phát triển nhưng chưa hoàn thành, và có những cái khác đã thật bại vì một hoặc nhiều lý do. Trong tất cả các ý tưởng đó, những phần quan trọng nhất là truyền thông Agent, quản lý Agent và kiến trúc Agent. Phần này sẽ giới thiệu về hai trong số ba phần quan trọng nhất đó. 2.1.2.2.1. Truyền thông Agent (agent communication) Agent về cơ bản là hình thái của quá trình phân phối mã nguồn và do đó tuân theo khái niệm cổ điển của mô hình phân phối tính toán theo hai phần: các thành phần và các kết nối. Các thành phần là những khách hàng, những nhà sản xuất và những người điều hành của các thông điệp truyền thông thông qua các kết nối. Phần thân của các chuẩn đầu tiên như là ISO hay IETF lựa chọn một cách tiếp cận hướng mạng trong việc phát triển các cụm các giao thức được phân lớp dựa phần lớn trên truyền thông máy tính chúng ta đã biết – mô hình OSI và mô hình TCP/IP. Cả hai đều được tận dụng thông qua giao tiếp giữa các phần mềm ứng dụng giao thức. 2.1.2.2.2. Quản lý Agent (Agent management) Để bổ sung cho truyền thông, khía cạnh cơ bản thứ hai của các hệ thống Agent được tạo ra bởi các đặc tả ban đầu của FIPA là quản lý Agent: một nền tảng chuẩn trong đó các chuẩn FIPA cho Agent có thể tồn tại, tổ chức và quản lý. Nó thành lập cá mô hình lôgíc tham chiếu cho việc khởi tạo, đăng ký, xác định vị trí, di trú và tổ chức các Agent. Mô hình tham chiếu quản lý Agent bao gồm các thành phần được miêu tả như hình 2.1. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 10 Hình 2.1: Quản lý Agent 2.2. Nền tảng JADE Phần này sẽ đưa ra cái nhìn tổng quan cơ bản về nền tảng JADE (Java Agent Development framework) và các thành phần chính trong kiến trúc phân phối của nó. 2.2.1. Lịch sử phát triển Phầm mềm phát triển đầu tiên, về sau sẽ trở thành nền tảng JADE, được bắt đầu bởi Telecom Italia (được gọi tắt là CSELT) vào cuối năm 1998, được thúc đẩy bởi nhu cầu cần kiểm chứng các đặc tả đầu tiên của FIPA. JADE được trở thành mã nguồn mở trong năm 2000 và được phân phối bới Telecom Italia dưới giấy phép LGPL ( Library Gnu Public Licence). Giấy phép này đảm bảo tất cả các quyền cơ bản để thuận tiện cho việc sử dụng phần mềm bao gồm trong các sản phẩm thương mại: quyền được sao chép phần mềm và phân phối bản sao chép, quyền được sử dụng mã nguồn của phần mềm, và quyền thay đổi mã nguồn và cải tiến nó. Không giống như giấy phép GPL, giấy phép LPGL không đưa bất kỳ sự hạn chế nào và phần mềm sử dụng JADE, và nó cho phép các phần mềm độc quyền được trộn vẫn với phần mềm đăng ký giấy phép LGPL. Mặt khác, giấy phép này yêu cầu mọi công việc bắt nguồn từ JADE, Nghiên cứu mô hình phân tải Server sử dụng Proxy động 11 hoặc bất kỳ công việc nào dựa trên nó đều phải được đưa ra cộng đồng với cùng giấy phép. Website chính thức của JADE [16] cung cấp tất cả các phần mềm, tài liệu, mã nguồn ví dụ và các thông tin về sử dụng JADE. 2.2.2. Jade và mô hình các Agent JADE là một phần mềm nền tảng cung cấp các chức năng phần mềm lớp giữa cơ bản, nó không phụ thuộc vào ứng dụng riêng biệt nào và làm đơn giản hoá việc phân phối các ứng dụng khai thác phần mềm ảo hoá Agent [10]. Một trong những giá trị đầy ý nghĩa của JADE là nó thực hiện trừu tượng hóa dựa trên sự hiểu biết về hướng đối tượng, Java, cung cấp API đơn giản và thân thiện. Các lựa chọn thiết kế đơn giản về sau chịu ảnh hưởng từ việc trừu tượng hoá Agent. 2.2.3. Kiến trúc Jade Hình 2.2 miêu tả các nhân tố kiến trúc chính của nền tảng JADE. Một nền tảng JADE bao gồm các vùng chứa Agent (container) có thể được phân phối qua mạng. Các Agent sống trong các vùng chứa là các quá trình Java, nó cung cấp quá trình thực thi của JADE và tất cả các dịch vụ cần thiết cho lưu trữ và thực thi Agent. Một vùng chứa đặc biệt, được gọi là vùng chưa chính (Main-container), là nơi khởi động của nền tảng: nó là vùng chưa đầu tiên được thực thi và tất cả các vùng chưa khác phải được liên kết đến vùng chưa chính bằng cách đăng ký với nó. Biểu đồ UML trong hình 2.3 miêu tả mối quan hệ giữa các thành phần kiến trúc chính của JADE. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 12 Hình 2.2: Mối quan hệ giữa các thành phần trong kiến trúc chính Hình 2.3: UML mối quan hệ giữa các thành phần trong kiến trúc chính Nghiên cứu mô hình phân tải Server sử dụng Proxy động 13 2.2.4. Biên dịch và chạy nền tảng Jade Tất cả các phần mềm liên quan đến JADE đều có thể tải về từ trang web chính thức của JADE. Các phần mềm liên quan đến JADE có thể chia thành hai loại: bản phân phối chính và các bản phụ trợ. Các bản phụ trợ trong mỗi bản riêng biệt đều có chứa các đơn vị (module) thực thi các phần mở rộng riêng biệt như các mã hoá cho ngôn ngữ. Trong nhiều trường hợp, các bản này không được phát triển trực tiếp bởi đội ngũ phát triển của JADE mà là các thành viên của cộng đồng nguồn mở, những người quyết định đưa các thành quả nghiên cứu của mình lên cho cộng đồng cùng xem. Bản phân phối chính bao gồm năm file đã được nén là: - jadeBin.zip chứa một file jar là nền tảng JADE đã được biên dịch và sử dụng được ngay - jadeDoc.zip chứa các tài liệu bao gồm: Hướng dẫn cho người quản trị (Administrator Guide), Hướng dẫn cho người lập trình (Programmer Guide). Các tài liệu này cũng có thể tải về từ trang web chính thức của JADE - jadeExamples.zip chứa các mã nguồn của rất nhiều ví dụ - jadeSrc.zip chứa tất cả các mã nguồn của JADE - jadeAll.zip chứa tất cả 4 file nói trên Nếu tất cả các file trên được tải xuống và giải nén thì cấu trúc thư mục sẽ giống như miêu tả ở hình 2.4. Thư mục jade/lib chứa tất cả các file jar cần phải được khai báo vào java CLASSPATH để chạy JADE. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 14 Hình 2.4: Cấu trúc thư mục JADE Ví dụ, khi đã tải về ổ C trong hệ điều hành Windows, để chạy được JADE, trước hết cần khai bao CLASSPATH cho java như sau: prompt> set JADE_HOME=c:\jade prompt> set CLASSPATH=%JADE_HOME%\lib\jade.jar; %JADE_HOME%\lib\jadeTools.jar; %JADE_HOME%\lib\http.jar; %JADE_HOME%\lib\iiop.jar; %JADE_HOME%\lib\commons-codec\commons-codec- 1.3.jar;%JADE_HOME%\classes Sau đó có thể khởi động JADE với đồ hoạ bằng cách sử dụng lệnh: prompt> java jade.Boot –gui Sau khi khởi động thành công, màn hình dòng lệnh sẽ hiển thị thông báo giống như hình 2.5 và đồ hoạ của JADE sẽ hiện ra giống như hình 2.6. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 15 Hình 2.5: Kết quả khi khời động thành công Hình 2.6: Giao diện nền tảng JADE Nghiên cứu mô hình phân tải Server sử dụng Proxy động 16 2.2.5. Agent di động (Mobile Agent) Agent di động [9] là mô hình được xuất phát từ hai quy tắc khác nhau [4], đầu tiên là trí thông tinh nhân tạo, thứ tạo ra khái niệm agent, thứ hai là hệ thống phân tán, thứ định nghĩa khái niệm về dịch chuyển mã [6]. Dựa theo định nghĩa chuẩn, Agent di động là một một agent giống như tất cả các agent không di động khác (tự quản, phản ứng hành động, thực hiện tiên phong, có tính xã hội), nhưng thêm vào đó, nó có khả năng di chuyển; nó có khả năng di trú giữa các nền tảng theo yêu cầu để thực hiện các công việc được giao. Theo cách nhìn từ hệ thống phân tán, một Agent di dộng là một chương trình với định danh duy nhất có thể dịch chuyển mã, dữ liệu và trạng thái giữa các máy được nối mạng. Để thực hiện được điều đó, một Agent phải có khả năng dừng công việc của nó ở bất kỳ thời điểm nào, và tiếp tục hoạt động khi đã cư trú ở nơi khác. Chúng ta có thể đặt Agent di động trong mối quan hệ với các mô hình truyền thống như sau: - Client –Server: Mô hình phổ biến nhất, ở đó các dịch vụ được Server đưa ra và được sử dụng bởi một hoặc nhiều Client. - Thực thi từ xa: Một thành phần gửi mã đến thành phần khác để thực thi từ xa, kết quả đưa ra hoặc từ quyết định của chính nó, hoặc một yêu cầu từ phía thành phần ở xa, hoặc có thể như một phần của giao kèo trước đó. Sau khi thực thi, thành phần thực thi sẽ gửi trả kết quả về cho thành phần gốc. - Agent di động: Một thành phần gửi bản thân nó ( hoặc đối tượng khác nếu được phép) đến một nơi lưu trữ ở xa để thực thi. Thành phần chuyển đi với mã, dữ liệu và có thể cả trạng thái. Sự dịch chuyển có thể tương tự như trường hợp trước, nhưng thông thường nhất kết quả từ thành phần đó ( ví dụ là Agent di động) quyết định cho bản thân nó có nhu cầu di chuyển địa điểm xem kẽ. Một Agent di động như miêu tả trong hình 2.7 gồm có 3 phần: mã, trạng thái và dữ liệu. Mã là dạng của Agent sẽ được thực thi khi di trú đến một nền tảng. Trong trường hợp đơn giản nhất thì nó là mã đơn. Trạng thái là môi trường thực thi dữ liệu của Agent, bao gồm chương trình đếm và ngăn xếp thực thi. Phần này chỉ tìm thấy trong Agent sử Nghiên cứu mô hình phân tải Server sử dụng Proxy động 17 dụng cư trú mạnh. Dữ liệu bao gồm các giá trị được sử dụng bởi Agent, như là tri thức, các file xác định v.v. Hình 2.7: Cấu trúc đơn giản của Agent di dộng Có khá nhiều cuộc tranh luận về ưu điểm và nhược điểm của Agent di dộng, thường thì nó được so sánh với các Agent không di động. Một số ưu điểm là: - Không đồng bộ và xử lý không phụ thuộc: Một khi nó đã được di trú vào một nền tảng mới, các Agent không cần phải liên hệ với chủ của nó để thông báo về công việc. Nó có thể chỉ cần gửi lại kết quả. Việc này đặc biệt hữu dụng khi sử dụng với các thiết bị di động với giới hạn về tài nguyên; một agent có thể di trú đến một máy khác để thực hiện các công việc phức tạp và trả lại kết quả theo chu kỳ. - Chịu lỗi: Nó có thể đánh dấu và sửa lỗi với các điều kiện lỗi bằng việc chuyển đến các nền tẳng chéo khi vấn đề được phát hiện. Công bằng nếu một điểm di trú bị sập, một điểm trung gian có thể được chọn để đóng vai trò dự trữ. Nó phù hợp với môi trường thân thiện và dễ đổ vỡ - Biển các ứng dụng: Agent di động rất phù hợp với các ứng dụng cần xử lý một lượng lớn các dữ liệu từ xa. Agent di động có thể dịch chuyển dữ liệu, trong nhiều trường hợp nó có hiệu quả hơn so với cách làm truyền thống. Nhưng Agent di động cũng có những khuyết điểm: Nghiên cứu mô hình phân tải Server sử dụng Proxy động 18 - Khả năng mở rộng và hiệu năng: Mặc dù Agent di động giảm tải cho mạng, nhưng nó lại làm tăng tải cho việc thực thi. Điều này là bởi vì nó thường được lập trình với các ngôn ngữ thông dịch và thường cần phải được theo dõi chặt chẽ việc tương kết theo chuẩn, nó có thể gây ra quá tải việc xử lý dữ liệu. - Khả năng di chuyển và chuẩn hoá: Agent không thể tương kết nếu nó không tuân theo chuẩn truyền thông thông thường. Sự chấp nhận các chuẩn này, như là OMG MASIF (Mobile Agent System Interoperability Facility) hoặc FIPA thường rất quan trọng, đặc biệt trong sự dịch chuyển trong một nền tảng. - An ninh: Sử dụng Agent di động sẽ mang theo một số vấn đề về an ninh. Bất kỳ mã di động nào đều có một mối đe doạ tiềm tàng và cần phải được chứng thực cẩn thận trước khi thực thi. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 19 Chương 3 Mô hình Proxy động Chương này sẽ trình bày chi tiết về bài toán đặt ra và ý tưởng để giải quyết bài toán đó. Sau đó sẽ đi vào chi tiết về các giải pháp cho các yêu cầu bài toán đặt ra. Cuối cùng là mô hình chi tiết dựa trên các giải pháp đưa ra để giải quyết bài toán. 3.1. Mô tả bài toán Như đã nói ở chương đầu tiên về thực trạng hiện nay, một yêu cầu đặt ra để có thể vận dụng và triển khai tốt nhất xu hướng phát triển tiếp theo của Internet và công nghệ chúng ta cần phải có được một mô hình đáp ứng được yêu cầu giảm tải trên đường truyền Internet và giảm tải cho Server. Mô hình Client – Proxy – Server là một sự lựa chọn để đáp ứng được yêu cầu này. Hình 3.1: Mô hình Client – Proxy – Server Tuy nhiên, khác với các mô hình đã có trước đây, Proxy ở được sử dụng ở đây sẽ có thể thực hiện một phần công việc tính toán thay cho Server. Điều này có nghĩa là ngoài chức năng truyền thông tin giữa Client và Server như truyền thống, Proxy này còn phải có khả năng yêu cầu và nhận các tính toán từ Server, sau đó nó sẽ thay cho Server thực hiện các phần tính toán này khi có yêu cầu từ phía Client. Trong mô hình này, Server ngoài Nghiên cứu mô hình phân tải Server sử dụng Proxy động 20 công việc tính toán và trả kết quả thông thường, nó còn phải có thêm chức năng nhận yêu cầu và gửi các công việc về cho Proxy. Như vậy bài toán đặt ra ở đây là phải thiết kế được một mô hình cho phép các tính toán từ trên Server có thể được gửi xuống cho Proxy và có thể thực thi trực tiếp trên Proxy. Proxy có khả năng nhận và thực thi tính toán như trên được gọi là Proxy động. Nói một cách khác, yêu cầu của bài toán là xây dựng mô hình phân tải cho Server sử dụng Proxy động. 3.2. Mô hình đề xuất Phần này sẽ trình bày ý tưởng để đưa ra được mô hình phân tải cho Server sử dụng Proxy động. Sau đó sẽ trình bày chi tiết về các giải pháp đưa ra trong việc xây dựng mô hình. Cuối cùng sẽ trình bầy và giải thich về mô hình đưa ra cho bài toán đã nêu. 3.2.1. Ý tưởng Trong bài toán đã đưa ra ở trên, phần đóng gói tính toán và gửi nó đi giữa các Server là phần quan trọng nhất, phần này quyết định tính chất động của Proxy. Các tính toán cần phải được đóng gói theo một cách nào đó để nó có thể lưu giữ được cách thực thi, các dữ liệu liên quan và trạng thái của nó. Các đóng gói này cũng phải hỗ trợ cho việc chuyển dịch các tính toán đến nơi lưu trữ mới, cho phép các tính toán có thể thực thi ngay trên nơi trữ mới. Ý tưởng đưa ra ở đây là sử dụng Agent cho việc đóng và dịch chuyển các tính toán từ Server về Proxy. Mỗi tính toán riêng biệt và đặc thù sẽ được đóng gói thành một Agent và được lưu trữ trên Server. Thông qua giao tiếp giữa Agent với môi trường hoặc giữa các Agent với nhau, Agent sẽ thực thi các yêu cầu tới nó và trả kết quả cho bên yêu cầu. Các Agent ngoài việc thực thi và trả kết quả, nó còn có thể dịch chuyển nơi cư trú sang một môi trường khác hoặc một Server khác và thực thi ngay tại đó. Đây chính là yếu tố tạo nên khả năng tính toán động cho Proxy, thực thi tính toán ngay tại chỗ thay cho việc yêu cầu Server và nhận kết quả trả về. Ở đây, các chức tính toán và thực thi yêu cầu của Proxy không được thiết lập trước, nó có thể thay đổi tuỳ theo yêu cầu của Client và khả năng thực thi tính toán của Server. Như vậy, ý tưởng chính để đưa ra được mô hình sử dụng Proxy động để phân tải cho Server là sử dụng Agent đóng gói và chuyển các tính toán từ Server về Proxy. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 21 3.2.2. Giải pháp Dựa trên ý tưởng đã đưa ra, chúng ta sẽ đưa ra giải pháp cho Server và Proxy để có thể đáp ứng yêu cầu của bài toán. 3.2.2.1. Giải pháp cho Server Giải pháp cho việc đóng gói và dịch chuyển chuyển các tính toán là sử dụng Agent. Các tính toán sẽ được đóng gói thành các Agent, mỗi Agent sẽ phụ trách một công việc tính toán nhất định. Sử dụng Agent để đóng gói và dịch chuyển các tính toán giữa các Server vì theo các chuẩn về Agent đã được công bố và chấp nhận rộng rãi thì các Agent có thể đóng gói mã nguồn thực thi của nó, các dữ liệu phục vụ cho nó và cả trạng thái hoạt động, tất cả đều được có thể được truyền đi nguyên vẹn sang một Server khác và có thể thực thi tại Server đó mà không cần phải sửa đổi hay can thiệp vào Agent. Các yêu cầu khi được chuyển đến sẽ được phân loại thành các yêu cầu chuyển Agent và các yêu cầu khác. Để có thể thực hiện được việc phân loại yêu cầu được gửi đến, lọc ra các yêu cầu thông thường và các yêu cầu về việc đưa tính toán về Proxy, chúng ta sẽ đưa ra một mẫu yêu cầu được sử dụng chung cho tất cả các yêu cầu được gửi đến cho Server. Với các tính toán yêu cầu chuyển Agent, Server sẽ tìm Agent tương ứng trong các Agent nó đang chứa. Nếu Agent được tìm ra, Server sẽ tạo ra bản sao của Agent rồi gửi bản sao này cho phía yêu cầu. Nếu Agent không được tìm ra, hay không có Agent tương ứng với yêu cầu đưa ra, Server sẽ gửi thông báo đến cho phía yêu cầu rằng không có Agent tương ứng. Với các yêu cầu khác, Server sẽ thực hiện tính toán trực tiếp rồi gửi trả kết quả cho phía yêu cầu. Việc tính toán này hoàn toàn có thể bao gồm cả việc gọi Agent ra để tính toán và lấy kết quả do Agent trả về. 3.2.2.2. Giải pháp cho Proxy Proxy nhận yêu cầu từ Client, phân tích yêu cầu dựa trên khuôn dạng chuẩn đã được quy định trước để phân loại các yêu cầu có sử dụng Agent và các yêu cầu không sử dụng Agent. Khi có nhiều yêu cầu về sử dụng cùng một Agent, Proxy sẽ gửi yêu cầu đến Server để tải Agent tính toán về, sau đó mọi tính toán của phần này sẽ được thực hiện ngay trên Proxy. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 22 Các yêu cầu về Agent sau khi được phân loại sẽ được xử lý theo cách thức riêng. Đầu tiên Proxy sẽ kiểm tra xem có Agent nào nó đang lưu trữ phù hợp yêu cầu hay không. Nếu có, nó sẽ cho Agent đấy thực thi và lấy kết quả trả về, nếu không có, nó sẽ gửi yêu cầu về Agent tương ứng tới Server. Sau khi nhận được Agent tương ứng từ Server, nó sẽ cho thực thi Agent đó và lấy kết quả trả về. Các yêu cầu không liên quan đến Agent cũng sẽ được xử lý riêng. Phần này cho phép Proxy trong mô hình đề ra có thể kết hợp với các Proxy truyền thống khác như dùng để chặn các trang web hay sử dụng cache. Nếu không có sự kết hợp với ứng dụng nào, các yêu không sử dụng Agent sẽ được gửi thẳng đi cho Server và lấy kết quả trả về. Kết quả trả về từ các tính toán trên Agent sẽ được kết hợp với kết quả được trả về từ Server trước khi được chuyển về cho Client. 3.2.3. Mô hình Dựa trên các giải pháp đã đưa ra, chúng ta sẽ xây dựng một mô hình có thể giải quyết được bài toán đặt ra. Mô hình này không những có thể đáp ứng yêu cầu của bài toán mà còn phải có khả năng ứng dụng được vào thực tế. 3.2.3.1. Mô hình chung Dựa trên các giải pháp đã đưa ra ở phần trên, mô hình tổng thể sẽ như hình 3.2. Theo như hình 3.2, Client sẽ gửi yêu cầu đến cho Proxy và sẽ nhận kết quả trả về từ Proxy. Phía Proxy, sau khi phân loại yêu cầu được gửi đến từ Client sẽ thực hiện xử lý yêu cầu và gửi yêu cầu đến cho Server. Proxy có thể gửi đi một trong hai loại yêu cầu là yêu cầu Agent hoặc yêu cầu thông thường khác. Nếu yêu cầu thông thường được gửi đến Server thì Server sẽ tính toán và chỉ trả kết quả về cho Proxy. Nếu yêu cầu là yêu cầu Agent, Server sẽ tìm kiếm Agent tương ứng và gửi Agent về cho Proxy. Trong Proxy và Server đều có một vùng chứa Agent gọi là Agent Container. Các Agent được chứa trong vùng này đều có thể thực thi và trả ra kết quả. Việc chuyển một Agent từ Server sang Proxy sẽ được thực hiện hoàn toàn trên vùng chứa này. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 23 Hình 3.2: Mô hình hệ thống 3.2.3.2. Mô hình của Server Hình 3.3 là cấu trúc các thành phần bên trong Server chính và chức năng của mỗi thành phần: - Giao tiếp với Client/Proxy: Phần này làm nhiệm vụ lắng nghe và kết nối tới Client hoặc Proxy. Khi có một yêu cầu được gửi đến, phần này sẽ thực hiện việc gửi yêu cầu xuống phần xử lý và duy trì kết nối để đợi kết quả từ phần xử lý. Khi kết quả được phần xử lý gửi đến, nó sẽ chuyển tiếp kết quả này sang cho phía yêu cầu và đóng kết nối. - Xử lý yêu cầu: Phần này sẽ thực hiện việc xử lý các yêu cầu được đưa xuống từ phần giao tiếp và gửi trả kết quả cho phần giao tiếp. Phần này gồm có 3 thành phần nhỏ: o Phân loại yêu cầu: Dựa trên các mẫu yêu cầu được gửi đến, thành phần này sẽ phân loại các yêu cầu thành hai loại là yêu cầu Agent và yêu các khác. Các yêu cầu Agent sẽ được gửi xuống cho thành phần Xử lý yêu cầu Agent thực hiện, các yêu cầu khác được gửi xuống cho Xử lý các yêu cầu khác thực hiện. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 24 Hình 3.3: Cấu trúc Server o Xử lý yêu cầu Agent: Khi một yêu cầu về Agent được gửi đến, phần này sẽ lấy thông tin về Agent đó tìm Agent tương ứng trong Agent Container. Nếu trong Agent Container không có Agent này thì phần này sẽ gửi trả về cho phần giao tiếp thông báo là không có Agent tương ứng. Nếu Agent tương ứng tồn tại, phần này sẽ yêu cầu Agent Container tạo ra bảo sao của Agent và gửi bản sao này sang cho Agent Container của Proxy. o Xử lý yêu cầu khác: Các yêu cầu không phải gửi Agent sẽ được xử lý trong phần này. Các tính toán theo yêu cầu sẽ được thực thi và kết quả sẽ được trả về cho phần giao tiếp. Việc tính toán này hoàn toàn có thể bao gồm việc gọi đến các Agent và lấy kết quả trả về từ Agent. - Agent Container: Đây là vùng chứa các Agent của Server. Các Agent được chứa trong vùng này đều có thể được thực thi và trả ra kết quả. Việc tạo ra bản sao và chuyển các Agent đến nơi khác cũng được thi ngay tại vùng này. Để giúp cho việc phân loại các yêu cầu gửi đến một cách nhanh chóng và tiện lợi, chúng ta sẽ đưa ra mẫu yêu cầu mà Proxy sẽ gửi đến cho Server như trong hình 3.4. Mẫu này sẽ gồm hai phần chính là phần Header và phần Content. Trong phần Header sẽ chứa Nghiên cứu mô hình phân tải Server sử dụng Proxy động 25 thông tin của nơi gửi yêu cầu đến, và loại yêu cầu. Có hai loại yêu cầu là yêu cầu Agent (tức là yêu cầu gửi tính toán) và yêu cầu thông thường ( tức là yêu cầu Server thực thi một số tính toán rồi gửi trả kết quả). Server dựa vào Header để xác định loại yêu cầu và nơi gửi thông tin, sau đó dựa theo loại yêu cầu để lấy thông tin cần thiết trong phần Content .’ Hình 3.4: Mẫu yêu cầu gửi cho Server 3.2.3.3. Mô hình của Proxy Hình 3.5 là các thành phần bên trong Proxy Server và chức năng tương ứng với mỗi thành phần đó: - Giao tiếp với Client: Phần này cung cấp một giao diện để lắng nghe yêu cầu từ phía Client và gửi trả kết quả về cho Client. Khi một yêu cầu từ Client được gửi đến, phần giao tiếp này sẽ gửi yêu cầu đó xuống phần xử lý và duy trì kết nối với Client trong khi chờ kết quả được trả ra. Khi kết quả được trả ra từ phần xử lý, giao tiếp này sẽ đưa kết quả đó cho phía Client và kết thúc kết nối. - Giao tiếp với Server: Phần này sẽ thực hiện việc kết nối tới Server để chuyển đi các yêu cầu và nhận về các kết quả. Khi có một yêu cầu được đưa ra từ phần xử lý yêu cầu, giao tiếp này sẽ kết nối tới Server đích gửi đi yêu cầu đi và chờ đợi kết quả được gửi về từ phía Server. Khi kết quả được gửi về, giao tiếp này sẽ đưa kết quả xuống cho phần xử lý và kết thúc kết nối tới Server. HEADER CONTENT (Nội dung) Thông tin nơi gửi Loại yêu cầu (Agent/thông thường) Hình 3.4: Mẫu yêu cầu gửi cho Server Nghiên cứu mô hình phân tải Server sử dụng Proxy động 26 Hình 3.5: Cấu trúc Proxy Server - Xử lý yêu cầu: Phần này sẽ thực hiện việc xử lý các yêu cầu được đưa xuống từ giao tiếp với Client. Trong giai đoạn xử lý sẽ có những yêu cầu được đưa ra và gửi đến Server thông qua thành phần Giao tiếp với Server, có những yêu cầu được tính toán bởi các Agent đã có trong Proxy. Kết quả trả về từ phía Server sẽ được tổng hợp với kết quả thu được từ các Agent có trong Proxy, sau đó sẽ được đưa sang thành phần giao tiếp với Client để gửi đi cho Client. Trong phần xử lý này gồm bốn thành phần nhỏ: o Phân loại yêu cầu: Các yêu cầu được gửi đến từ Client sẽ được phân loại thành các yêu cầu về Agent và các yêu cầu khác. Các yêu cầu về Agent là các yêu cầu đòi hỏi sử dụng Agent để tính toán và trả ra kết quả. Các yêu cầu khác là các yêu cầu không đòi hỏi việc sử dụng Agent để tính toán. Các yêu cầu về Agent sẽ được chuyển sang cho phần Xử lý yêu cầu về Agent xử lý, còn các yêu cầu về tính toán khác sẽ được chuyển sang cho phần xử lý các yêu cầu khác. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 27 o Xử lý yêu cầu về Agent: Khi có yêu cầu về việc sử dụng Agent để tính toán, phần này sẽ kiểm tra trong Agent Container xem có Agent tương ứng với yêu cầu hay không. Nếu có Agent này sẽ được cho thực thi và trả lại két quả của việc thực thi đó. Nếu không có, phần này sẽ gửi yêu cầu sang cho Server thông qua Giao tiếp với Server để yêu cầu gửi Agent tương ứng sang. Khi Agent tương ứng đã được gửi, Agent này sẽ được cho thực thi luôn và lấy kết quả trả về. Kết quả của phần xử lý này sẽ được đưa xuống cho phần tổng hợp kết quả . o Xử lý các yêu cầu khác: Phần này sẽ phụ trách việc xử lý các yêu cầu khác. Đây là nơi có thể dùng kết hợp các Proxy truyền thống vào mô hình này. Ví dụ như việc tìm kiếm thông tin trên cache có thể được áp dụng trong phần này. Nếu không có sự tích hợp nào xẩy ra, các yêu cầu sẽ gửi cho phần Giao tiếp với Server để lấy kết quả trả về. Kết quả trả về từ Server sẽ được đưa xuống phần Tổng hợp kết quả. o Tổng hợp kết quả: Các kết quả được gửi đến từ phần Xử lý yêu cầu về Agent và Xử lý yêu cầu khác sẽ được tổng hợp lại tạo thành một câu trả lời hoàn chỉnh và đầy đủ trước khi được gửi cho Client. Kết quả của việc tổng hợp sẽ được đưa cho phần Giao tiếp với Client để chuỷên sang cho Client. - Agent Container: Đây là vùng chứa các Agent của Proxy. Việc tiếp nhận các Agent được gửi đến và thực thi các Agent đó cũng được thực hiện ngay trong phần này. Kết quả trả ra của việc thực thi Agent sẽ được gửi cho phần Xử lý yêu cầu về Agent. Để tránh tình trạng các Agent dư thừa gây lãng phí, tức là sau một thời gian Agent không còn được sử dụng đến nữa nhưng nó vẫn được lưu trữ trong Proxy, Agent Container sẽ có thêm nhiệm vụ theo dõi tình trạng hoạt động của các Agent. Khi một Agent không được sử dụng đến trong một khoảng thời gian nhất đinh, nó sẽ bị xoá khỏi vùng chứa. Các thông điệp hay yêu cầu được gửi từ Client sang cho Proxy cũng cần phải được quy định theo khuôn dạng chuẩn đề giúp cho việc phân loại các yêu cầu cần sử dụng Agent và không cần sử dụng Agent được nhanh chóng và tiện lợi. Khuôn dạng yêu cầu chuẩn của Client gửi cho Proxy được mô tả như trong hình 3.6. Trong khuôn dạng này phần Header sẽ chỉ chứa thông tin của nơi gửi đến và Server đích cần đến, mọi thông tin Nghiên cứu mô hình phân tải Server sử dụng Proxy động 28 khác đều được ghi trong phần Content. Trong phần content này, nếu có yêu cầu về việc sử dụng Agent để tính toán thì những yêu cầu về Agent cần phải được đưa vào phần đầu của Content, sau đó mới đến các thông tin khác. HEADER CONTENT Các thông tin còn lại Thông tin nơi gửi Thông tin nơi đến Thông tin về các Agent được yêu cầu Hình 3.6: Mẫu yêu cầu gửi cho Proxy Nghiên cứu mô hình phân tải Server sử dụng Proxy động 29 Chương 4 Thực nghiệm Để chứng minh tính khả thi của mô hình đề xuất trong chương 3, chúng tôi đã xây dựng một thực nghiệm phân tải cho Server sử dụng Proxy động. 4.1. Phân tích thiết kế Phần này sẽ mô tả các yêu cầu của bài toán đặt ra và các thiết kế chương trình để giải bài toán đó. 4.1.1. Mô tả chương trình Chương trình thực nghiệm được xây dựng trên một tính toán đơn giản nhưng đang được sử dụng rộng rãi hiện nay, đó là kiểm chứng người dùng bằng hình ảnh hay còn gọi là CAPTCHA [15]. Một CAPTCHA là một loại kiểm thử dạng hỏi đáp được dùng trong máy tính để xác định xem người dùng có phải là con người hay không. "CAPTCHA" là một dạng viết tắt chữ đầu của "Completely Automated Public Turing test to tell Computers and Humans Apart" (Phép thử Turing công cộng hoàn toàn tự động để phân biệt máy tính với người), được trường Đại học Carnegie Mellon cố gắng đăng kí thương hiệu nhưng đã bị bác bỏ. Đây là một quá trình một máy tính (máy chủ) yêu cầu một người dùng hoàn tất một kiểm tra đơn giản mà máy tính có thể dễ dàng tạo ra và đánh giá, nhưng không thể tự giải nó được. Vì máy tính không thể giải quyết CAPTCHA, bất kỳ người dùng nào nhập vào lời giải đúng sẽ được xem là con người. Một loại CAPTCHA phổ biến yêu cầu người dùng phải nhập các chữ cái trong một tấm hình méo mó, đôi khi cùng với một dãy số hoặc chữ lờ mờ xuất hiện trên màn hình. Thông thường, Server sẽ tạo ra ảnh và hiển thị nó trên trình duyệt, sau đó người dùng sẽ nhập các chữ hoặc số trên ảnh vào và gửi cho Server kiểm tra. Nếu kiểm tra đúng thì Server sẽ xác nhận người dùng là hợp lệ. Trong thực nghiệm này, việc sinh ra ảnh và kiểm tra ảnh sẽ được đóng gói thành một Agent. Khi có Client yêu cầu ảnh để kiểm chứng, Proxy sẽ yêu cầu Server gửi cho mình Agent này. Agent sau khi được gửi sang cho Proxy sẽ được thực thi ngay trên Proxy. Kể từ đó, mọi yêu cầu về sinh ảnh và kiểm chứng từ Client sẽ được thực hiện trên Proxy. Khi kiểm chứng sai, Proxy sẽ gửi lại ảnh khác và yêu cầu Client nhập lại. Nếu đúng, Proxy sẽ thông báo cho Server là xác nhận người dùng thành công Nghiên cứu mô hình phân tải Server sử dụng Proxy động 30 4.1.2. Yêu cầu kỹ thuật Để có thể đưa ra một mô hình như đã miêu tả ở trên, Proxy và Server cần phải đáp ứng được một số yêu cầu về kỹ thuật. 4.1.2.1. Yêu cầu kỹ thuật cho Server Server là một máy tính có cấu hình mạnh, có cài đặt các phần mềm cho phép các máy tính khác truy cập để sử dụng các dịch vụ hoặc tài nguyên. Về cơ bản, Server có khả năng tiếp nhận, xử lý yêu cầu, và trả lời yêu cầu. Server trong mô hình đưa ra trước hết cũng cần phải có những tính năng cơ bản như thế, nó cho phép các máy khác có thể truy cập vào nó thông qua địa chỉ IP hoặc Host, các yêu cầu được gửi đến sẽ được xử lý dựa trên các phần mềm cung cấp dịch vụ đã được cài đặt trong Server, cuối cùng các kết quả sau khi xử lý sẽ được Server trả về cho các máy yêu cầu. Trong mô hình đưa ra, Server ngoài các chức năng cơ bản, còn phải có chức năng gửi tính toán đến cho bên yêu cầu. Điều này có nghĩa là các tính toán cần phải được đóng gói theo một cách nào đó để nó có thể được thực thi và trả kết quả trực tiếp ngay tại Server, đồng thời nó phải có khả năng tạo ra các bản sao của chính nó, và có thể di chuyển đến Server khác khi có yêu cầu. Như vậy cần phải có một phần mềm thực hiện chức năng đóng gói các tính toán sao cho các tính toán đó có thể được thực thi hoặc được chuyển đi nơi khác khi có yêu cầu 4.1.2.2. Yêu cầu kỹ thuật cho Proxy Proxy Server là Server làm nhiệm vụ trung chuyển thông tin giữa Client và các Server khác. Proxy Server thường được đặt giữa Client và Internet, đóng vai trò làm cổng ra Internet cho hệ thống mạng phía sau nó. Proxy Server trong mô hình đề ra cũng cần phải có được tính năng này. Như vậy Proxy trong mô hình đề ra sẽ lắng nghe các yêu cầu được gửi đến từ Client, sau đó nó sẽ lựa chọn các Server đích và truyền thông tin yêu cầu của Client cho Server đó. Kết quả trả về từ phía Server ngoài sẽ được gửi về cho Proxy Server, sau đó Proxy sẽ tìm Client nào đã gửi yêu cầu này và trả kết quả về cho Client đó. Ngoài tính năng cơ bản là chuyển thông tin, Proxy Server theo mô hình mới cần phải có khả năng yêu cầu, tiếp nhận công việc tính toán từ server và thực thi nó ngay trên Proxy. Đây là yêu cầu quan trọng để đạt được mục tiêu giảm tải cho Server và giảm lượng truyền tin trên Internet. Với yêu cầu này, Proxy cần một phần mềm có thể gửi yêu cầu cho Nghiên cứu mô hình phân tải Server sử dụng Proxy động 31 Server, yêu cầu gửi những tính toán cần thiết về cho Proxy, sau đó, những tính toán này cần được tiếp nhận và lưu trên Proxy để có thể thực thi trực tiếp trên Proxy. Để có thể gửi các yêu cầu về tính toán cho Server, Proxy cần có chức năng phân tích yêu cầu (request) của client để phân loại các yêu cầu có thể đưa việc tính toán về proxy và các tính toán cần server phải trực tiếp thực hiện. Sau khi phân loại các yêu cầu, Proxy sẽ yêu cầu Server gửi cho mình những tính toán cần phải lấy về để thực thi ngay trên Proxy, thông tin trả về của Server lúc này sẽ là những tính toán cần thiết đã được đóng gói, thông tin trả về này sẽ được lưu trữ tại Proxy chứ không được chuyển về cho Client. Khi các tính toán cần thiết đã được chuyển về cho Proxy, từ lúc này, mọi yêu cầu về tính toán này sẽ được thực hiện ngay tại Proxy, không phải kết nối tới Server nữa. Tuy nhiên không phải tất cả các tính toán đều có thể gửi về cho Proxy thực hiện, do vậy, vẫn có những tính toán cần phải được yêu cầu phía Server trực tiếp thực hiện. Như vậy với những yêu cầu bao gồm cả tính toán có thể thực hiện trên Proxy và những tính toán phải được thực hiện trên Server, thông tin trả về từ hai nguồn này cần được tổng hợp lại trước khi được đưa về cho Client. 4.1.3. Các giai đoạn phát triển Giai đoạn 1: Kết hợp WebServer và Jade platform trên cùng 1 máy. Việc tạo ra ảnh và kiểm chứng ảnh được đưa thành một agent chuyên trách. Khi có yêu cầu về tạo ảnh hoặc kiểm chứng, WebServer sẽ gọi đến Agent này Giai đoạn 2: Tạo ra ProxyServer kết hợp với Jade. Proxy có khả năng phân tích request yêu cầu từ phía Client, những yêu cầu về sử dụng agent sẽ được đặt riêng, những yêu cầu không liên quan đến agent sẽ được truyền tới Server. Với các yêu cầu về tính toán sử dụng Agent, Proxy sẽ tìm cho thực hiện các Agent tương ứng. Kết quả trả về của Server và các agent sẽ được tổng hợp để tạo thành thông tin gửi về cho Client. Giai đoạn 3: Kết hợp Proxy và WebServer. Khi có yêu cầu về tính toán sử dụng Agent, Proxy sẽ kiểm tra trong hệ thống về Agent đó, nếu có sẽ cho thực hiện Agent, nếu chưa có Proxy sẽ gửi yêu cầu đến Server, yêu cầu đưa Agent cần thiết sang cho Proxy. Server tiếp nhận yêu cầu từ Proxy, phân tích các yêu cầu về Agent và không phải Agent. Các yêu cầu không phải Agent sẽ được tính toán bình thường, và gửi trả kết quả về cho Nghiên cứu mô hình phân tải Server sử dụng Proxy động 32 Proxy. Các yêu cầu về Agent sẽ được nhận diện và các Agent tương ứng sẽ được copy và chuyển sang cho Proxy. 4.1.4. Thiết kế chương trình Chương trình kiểm chứng người dùng bằng hình ảnh sẽ hoạt động theo luồng tiến trình như hình 4.1 Hình 4.1: Biểu đồ tuần tự của hệ thống Khi bắt đầu, Client sẽ gửi yêu cầu trang đăng nhập đến cho Server thông qua Proxy. Do đây là yêu cầu không cần dùng đến Agent nên Proxy sẽ chuyển thẳng nó sang cho Server. Server sẽ trả lời lại yêu cầu này bằng cách gửi lại form đăng nhập cho Proxy để chuyển sang cho phía Client. Sau khi nhận được form đăng nhập, Client sẽ tự động gửi yêu cầu về ảnh kiểm chứng cho Proxy. Do đây là yêu cầu có sử dụng Agent nên Proxy sẽ không chuyển nó cho Server mà tìm kiếm Agent tương ứng trong Agent Container của mình. Trong chương Nghiên cứu mô hình phân tải Server sử dụng Proxy động 33 trình này, Agent dùng để sinh ảnh và kiểm chứng ảnh được gọi là captchaAgent. Nếu captchaAgent chưa có trong Agent container của Proxy, nó sẽ gửi thông báo cho Server yêu cầu gửi captchaAgent cho nó. Server nhận được yêu cầu sẽ phân tích yêu cầu để lấy thông tin về đích đến, rồi yêu cầu Agent Container của nó gửi captchaAgent sang cho Agent Container bên phía Proxy. Sau khi việc chuyển Agent kết thúc, Server sẽ gửi thông báo cho Proxy biết đã hoàn thành việc chuyển Agent. Sau khi đã nhận được captchaAgent, Proxy sẽ gửi thông điệp yêu cầu Agent này sinh ra một ảnh captcha và trả lại định danh ảnh cho Proxy. Cuối cùng Proxy sẽ gửi đường dẫn đến bức ảnh cho Client cùng với định danh của bức ảnh. Sau khi điền đầy đủ thông tin theo form đã nhận được, Client sẽ gửi các thông tin này đi cho Proxy. Các thông tin được gửi đến cho Proxy sẽ bao gồm username, password, ký tự tương ứng với ảnh captcha đã được gửi đến và định danh của ảnh captcha. Proxy sau khi tiếp nhận các thông tin này sẽ tiến hành kiểm tra ký tự của ảnh captcha trước. Định danh của ảnh captcha và ký tự xác nhận sẽ được gửi cho captchaAgent và yêu cầu Agent này kiểm tra. Nếu kết quả kiểm tra cho thấy ký tự được gửi đến và ảnh đã gửi đi không khớp với nhau, captchaAgent sẽ gửi thông báo lại cho Proxy đi kèm với ảnh mới sinh và định danh của ảnh đó. Proxy nhận được thông tin này sẽ thông báo lại ngay cho phía Client biết xác nhận ảnh sai và yêu cầu làm lại với ảnh mới được gửi đến. Phần username và password đã được gửi đến cho Proxy sẽ bị bỏ qua mà không được chuyển sang cho Server kiểm chứng. Nếu captchaAgent xác nhận ký tự gửi đến và ảnh đã gửi đi trùng khớp với nhau thì Proxy mới gửi thông tin về username và password đến cho Server tiếp tục kiểm chứng. Kết quả kiểm chứng username và pasword sẽ được Server gửi trả về cho Proxy. Nếu kết quả là sai, Server sẽ yêu cầu phải nhập lại tất cả các thông tin, khi đó Proxy sẽ sinh ra ảnh captcha mới và gửi yêu cầu Client nhập lại tất cả. Nếu kết quả kỉêm chứng username và password đúng, Server sẽ gửi trang chào mừng cho Proxy, Proxy sẽ chuyển trang này sang cho Client. 4.2. Cài đặt và thực nghiệm Trên cơ sở phân tích thiết kế chương trình ở phần trước, chúng tôi đã thực hiện cài đặt chương trình trên hai máy tính khác nhau, một máy làm Server một máy làm Proxy. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 34 Một số máy khác được sử dụng như các Client kết nối với Proxy để tiến thành chạy thử hệ thống. 4.2.1. Cài đặt Server Để tạo ra một Server với chức năng cơ bản là nhận yêu cầu, xử lý thông tin và trả lời cho phía yêu cầu, có thể sử dụng rất nhiều ngôn ngữ lập trình để tạo ra các Server như vậy, ví dụ như để tạo ra một WebServer có thể sử dụng Java hoặc PHP. Tuy nhiên nên sử dụng Java để tạo ra Server vì hiện nay các nền tảng đã được viết để hỗ trợ cho việc phát triển các hệ thống Agent chủ yếu được viết bằng Java như JADE, Aglet, Grasshoper v.v. Thêm vào đó việc sử dụng Java để đóng gói và truyền dữ liệu qua mạng đơn giản hơn so với các ngôn ngữ lập trình khác, do đó Java được lựa chọn là ngôn ngữ được dùng để tạo ra WebServer. Hiện nay nền tảng phát triển JADE được coi là đầy đủ và hợp lý cho các hệ thống sử dụng nhiều Agent vì tính dễ dùng, dễ phát triển, và tuân theo chủân FIPA của nó. Do đó ta sẽ chọn JADE làm nền tảng để phát triển các Agent. Do cùng được viết trên nàng tảng Java nên việc kết hợp Jade và WebServer là đơn giản. 4.2.2. Cài đặt Proxy Proxy Server là một cổng thông tin giữa các máy trong mạng và ngoài Internet. Có thể dễ dàng tạo ra một Proxy đơn giản sử dụng các ngôn ngữ lập trình hỗ trợ lập trình mạng như Java hay C++, C#. Tuy nhiên, do yêu cầu về sử dụng Agent để hỗ trợ cho việc tính toán và di chuyển tính toán, nên ngôn ngữ lập trình Java là lựa chọn hiệu quả nhất. Một nền tảng phát triển Agent cũng được sử dụng trên Proxy server để có thể chứa các Agent được chuyển đến và thực thi chúng. Điều quan trọng là nền tảng trên Server và trên Proxy cần phải giống nhau để tạo ra sự dễ dàng và tiện lợi trong việc liên kết và chuyển tải Agent. Lựa chọn JADE cho việc lưu trữ và thực thi Agent trên Proxy sẽ là một lựa chọn hợp lý. Việc kết hợp JADE và Proxy Server là đơn giản do cả hai dùng được viết trên nền tảng Java. 4.2.3. Thực nghiệm Kết quả thực nghiệm thu được sau khi cài đặt thành công hai máy Server, Proxy và sử dụng một số máy tính làm Client như sau: - Cấu hình máy Server: Core 2 dual 2.5GHz, RAM 2G, hệ điều hành Window Vista - Cấu hình máy Proxy: Dual 2 core 1.8GHz, RAM 1G, hệ điều hành Window XP Nghiên cứu mô hình phân tải Server sử dụng Proxy động 35 - Các máy Client sử dụng trình duyệt Mozilla Firefox 3.0 Bảng số liệu thực nghiệm Số lượng Client Số yêu cầu đến Proxy (dung lượng Byte) Số yêu cầu đến Server (dung lượng Byte) Ghi chú 1 5 (2589 B) 4 (1987 B) Client yêu cầu login.jsp 1 7 (3767 B) 6 (3070 B) Client yêu cầu login.jsp rồi submit thành công 3 21 (11301 B) 16 (8515 B) Mỗi Client yêu cầu một login.jsp rồi submit thành công 5 35 (18853 B) 26 (13865) Mỗi Client yêu cầu một login.jsp rồi submit thành công 5 45 (24313 B) 26 (13865) Mỗi Client yêu cầu login.jsp 1 lần, thay đổi ảnh 1 lần , submit thành công 5 65 (35200 B) 41 (21005 B) Mỗi Client yêu cầu login.jsp 1 lần, submit lần 1 sai ảnh, lần 2 thành công 5 65 (35200 B) 42 (21525 B) Mỗi Client yêu cầu login.jsp 1 lần, submit lần 1 sai thông tin cá nhân, lần 2 thành công 5 135 (73453 B) 26 (13865) Mỗi Client yêu cầu login.jsp 1 lần, và thay ảnh 10 lần, submit thành công Nghiên cứu mô hình phân tải Server sử dụng Proxy động 36 Từ bảng số liệu trên ta có thể thấy số lượng yêu cầu mà Server phải xử lý đã đã giảm đi đáng kể. Số lượng yêu cầu từ phía Client càng tăng lên thì tỷ lệ số lượng yêu cầu Proxy phải xử lý với số lượng yêu cầu Server phải xử lý cũng tăng lên. Đặc biệt khi số lượng yêu cầu về xử lý đòi hỏi sử dụng Agent nhiều thì tỷ lệ này càng lớn. Như vậy việc giảm tải cho Server đã được thực hiện tương đối tốt, đạt được mục đích do mô hình đề ra. Thêm vào đó, nếu ta bố trí Server ở ngoài Internet, các máy Client được đặt trong cùng một mạng với Proxy thì đường truyền Internet cũng giảm hiệu suất hoạt động đi đáng kể. Kết quả của thực nghiệm đã chứng minh được tính đúng đắn và khả thi của mô hình đề ra. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 37 Chương 5 Kết luận Sau thời gian nghiên cứu và xây dựng mô hình với mục đích phân tải cho Server sử dụng Proxy động, chúng tôi đã tiếp cận được những kiến thức cơ bản về các hệ thống mạng, cách triển khai nó và các lý thuyết cũng như thực hành về khái niệm Agent, ứng dụng của Agent trong các hệ thống tính toán, từ đó đưa ra được mô hình Proxy động dựa trên mô hình Client – Proxy – Server truyền thống. Mô hình đưa ra này có thể ứng dụng được vào thực tế để giải quyết được bài toán đặt ra là giảm tải cho các Server đồng thời giảm được lượng thông tin truyền trên Internet. Mô hình đưa ra này hoàn toàn có thể trở thành giải pháp quan trọng cho việc triển khai các mô hình tính toán tập trung trên Internet trong tương lai không xa. Những kết quả chính mà chúng tôi đã đạt được và chưa đạt được, hướng phát triển tiếp theo có thể được tổng kết lại như dưới đây: 5.1. Kết quả thu được Đưa ra được mô hình Proxy động có khả năng ứng dụng được vào thực tế. Mô hình này được xây dựng dựa trên khái niệm về Agent và các ứng dụng liên quan đến nó. Mô hình bao gồm hai thành phần chính là Proxy và Server. Proxy làm nhiệm vụ cầu nối trung gian giữa Client và Server, có chức năng cơ bản là truyền tải yêu cầu từ phía Client đến cho Server và đưa thông tin trả lời từ Server về cho Client. Để có thể đạt được mục tiêu giảm tải cho Server, trong mô hình này Proxy còn có thêm chức năng tiếp nhận tính toán đã được đóng gói từ Server và thực thi nó ngay trên Proxy khi có yêu cầu từ phía Client. Với mô hình nay, việc giảm tải cho Server được thực hiện hiệu quả, đặc biệt là trong các hệ thống lớn với lượng người dùng đông, yêu cầu xử lý lớn và các yêu cầu về tính toán giống nhau được lặp lại nhiều lần. Ngoài ra, mô hình đưa ra con giúp giảm lượng thông tin được truyền trên Internet, góp phần tăng hiệu quả sử dụng đường truyền Internet, đặc biệt là với những nước có cơ sở hạ tầng mạng còn yếu như Việt Nam. Đã xây dựng được một thực nghiệm chứng minh tinh thực tế của mô hình đề ra. Thực nghiệm này dựa trên một ứng dụng đơn giản nhưng đang được sử dụng khá phổ biến hiện nay là kiểm chứng người dùng bằng hình ảnh. Các bức ảnh được sinh ra dựa trên các ký tự bất kỳ và được áp dụng một số biện pháp xử lý để các chương trình nhận dạng ảnh thông thường không thể dễ dàng phát hiện ra. Trong thực nghiệm này, việc sinh Nghiên cứu mô hình phân tải Server sử dụng Proxy động 38 ảnh và kiểm chứng ảnh được Server đóng gói và chuyển về cho Proxy thực hiện. Từ đó, mỗi khi có yêu cầu sinh ảnh và kiểm chứng ảnh từ phía Client, Proxy sẽ thay Server thực hiện nhiệm vụ này. Mô hình đưa ra và thực nghiệm đã chứng minh tính khả thi của mô hình này trong việc áp dụng vào thực tế, tạo tiền đề cho các bước nghiên cứu và phát triển tiếp theo để có thể đưa ra được một mô hình hoàn thiện hơn và những thực nghiệm về sau sẽ chứng minh được những ưu điểm của mô hình này. 5.2. Hướng phát triển tiếp theo Trong quá trình nghiên cứu này, mặc dù đã đưa ra được thực nghiệm để chứng tỏ tính khả thi của mô hình đã đưa ra, nhưng do thời gian có hạn nên thực nghiệm này vẫn còn một số hạn chế để có thể chứng minh được những ưu điểm của mô hình này. Lý do là thực nghiệm đưa ra là một tính toán đơn giản, không đòi hỏi nhiều khả năng xử lý của Server, thêm vào đó, việc kiểm tra kết quả của thực nghiệm chỉ được thực hiện trong một phạm vi nhỏ với số lượng máy tham gia là rất ít, trong khi đó những ưu điểm của mô hình đưa ra chỉ có thể được thể hiện rõ khi nó được áp dụng vào mô hình tính toán lớn, đòi hỏi khả năng xử lý lớn ở Server, đồng thời số lượng máy tham gia nhiều và phải thường xuyên có yêu cầu tính toán trên Server. Mục tiêu tiếp theo của quá trình nghiên cứu sắp tới là thực hiện được một thực nghiệm có quy mô lớn để có thể kiểm chứng được những ưu điểm của mô hình đã đưa ra, đồng thời tìm hiểu những khuyết điểm của mô hình khi được áp dụng vào thực tế để có những sự sửa chữa và bổ sung cho phù hợp với thực tế. Mục tiêu lâu dài của quá trình nghiên cứu này là đưa ra mô hình cụm Proxy phân tải cho cụm Server. Theo đó, một cụm Proxy là một tập hợp rất nhiều Proxy kết nối đến nhau và được đặt giữa một mạng cục bộ lớn và một cụm các Server. Mô hình này sẽ được kế thừa từ mô hình đã đưa ra trong luận văn này do đó nó vẫn giữ được khả năng giảm tải cho Server và tăng hiệu quả sử dụng đường truyền Internet. Tuy nhiên mô hình mới với cụm Proxy đặt giữa Client và cụm Server sẽ tăng khả năng chịu lỗi của hệ thống khi có sự cố xẩy ra. Với cách bố trí một Proxy nằm giữa Client và Server, khi Proxy bị lỗi và không thể hoạt động bình thường, toàn bộ Client phía sau Proxy sẽ không thể liên kết ra ngoài Internet và các công việc liên quan cũng sẽ phải tạm dừng, gây tổn thất lớn về kinh tế. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 39 Nhưng khi các Proxy được bố trí để liên kết với nhau, một Proxy hỏng có thể được tạm thời thay thế bằng cách hướng đường truyền của các Client phía sau nó sang cho Proxy khác. Việc áp dụng mô hình đã đưa ra ở luận văn này sẽ giúp cho Server có thể đưa tính toán của nó về các Proxy khác nhau vào các thời điểm khác nhau, cho nên khả năng giảm tải cho phía Server là không đổi. Như vậy mô hình mới ngoài khả năng giảm tải cho Server, nó còn có thêm khả năng chịu lỗi trong chính các Proxy, giảm thiểu đáng kể rủi ro do khi một Proxy gặp sự cố gây ra. Nghiên cứu mô hình phân tải Server sử dụng Proxy động 40 Tài liệu tham khảo [1] Bellifemine, F and Caire, G and Greenwood, PA. Developing Multi-Agent Systems with JADE. John Wiley & Sons Ltd, 2007. [2] Blatt, R. “De Jure” standards. MIT, 1999 [3] Brooks R. Intelligence without Representation. Artificial Intelligence, 1991, trang 139–159. [4] Brown, P. and Rossak, W. Mobile Agents. Morgan Kaufmann Publishers and dpunkt.verlag, 2005. [5] Genesereth and Ketchpel, SP. Software Agents. Communications of the ACM, 1994, trang 48-53. [6] Picco, GP. Understanding Code Mobility (Tutorial Session). In ICSE ’00: Proceedings of the 22nd International Conference on Software Engineering, 2000, trang 834. [7] Rao AS and Georgeff M. BDI Agents: from Theory to Practice. In Proceedings of the 1st International Conference on Multi-Agent Systems, 1995, trang 312–319. [8] Russell, SJ and Norvig, P. Artificial Intelligence: a Modern Approach, 2nd edn. Prentice Hall, 2003. [9] White, JE. Telescript Technology: Mobile Agents. In Bradshaw Jeffrey, (ed), Software Agents, AAAI Press/MIT Press, 1996. [10] Wooldridge, MJ and Jennings, NR. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 1995, trang. 115–152. [11] [12] [13] [14] [15] [16] Nghiên cứu mô hình phân tải Server sử dụng Proxy động 41 [17] [18]