Xây dựng một hệ thống khắc phục lỗi bằng ngôn ngữ lập trình Java

ề trên. Bố cục khóa luận gồm 5 chương. Chưong 1: Giới thiệu về hệ thống phân tán và những đặc trưng của nó mà trong đó fault tolerance là một đặc trưng không thể thiếu được. Chương 2: Giới thiệu một số hệ thống có sẵn Chương 3: Giới thiệu về công nghệ JXTA Chương 4: Xây dựng hệ thống Chương 5: Tổng kết và hướng phát triển tiếp theo CHƯƠNG 1: Giới thiệu về Fault tolerance 1.1 Giới thiệu về hệ thống phân tán: Có nhiều định nghĩa khác nhau về hệ thống phân tán (Distributed system) tùy thuộc vào việc xem xét những khía cạnh khác nhau của hệ thống, nhưng về cơ bản là giống nhau: Hệ thống phân tán là một tập hợp các máy tính độc lập được kết nối và giao tiếp với nhau thông qua giao thức truyền thông mạng (communication network), mỗi máy tính có bộ xử lý (CPU), bộ nhớ (memory), và các thiết bị ngoại vi riêng (peripheral). Bộ nhớ CPU Thiết bị ngoại vi Máy tính Bộ nhớ CPU Thiết bị ngoại vi Máy tính Bộ nhớ CPU Thiết bị ngoại vi Máy tính Giao thức truyền thông mạng(TCP/IP, JXTA…) (Communication network) Hình 1.1: Mô hình hệ thống phân tán Theo định nghĩa ở trên, một hệ thống phân tán mà ta có thể dễ dàng bắt gặp đó là mạng Internet. Internet là một mạng toàn cầu, tập hợp rất nhiều máy tính ở những nơi khác nhau lại với nhau. Mỗi máy tính là độc lập và có thể giao tiếp được với nhau. 1.1.1 Đặc trưng cơ bản của Hệ thống phân tán Một hệ thống phân tán mang những đặc trưng sau: 1.1.1.1. Resource sharing Trong hệ thống phân tán, các máy tính độc lập được kết nối và giao tiếp với nhau, do đó tài nguyên trên mỗi máy có thể chia sẻ, trở thành tài nguyên dùng chung. Những máy tính có nhu cầu sử dụng tài nguyên có thể truy cập và sử dụng tài nguyên trên máy tính khác. Những tài nguyên này có thể là phần mềm, phần cứng hay dữ liệu. Như vậy, các tài nguyên sẽ được sử dụng hiệu quả hơn. Đơn giản như: Giả sử máy tính A không có máy in và cần in tài liệu. Máy tính B có máy in rảnh rỗi. Nếu hai máy tính không được kết nối, ta phải mua một máy in mới cho máy tính A. Còn trong hệ thống phân tán, máy tính A có thể sử dụng máy in tại máy tính B để in. Như vậy, chúng ta đã sử dụng máy in ở máy tính B một cách hiệu quả hơn và tiết kiệm được chi phí mua máy in cho máy A. 1.1.1.2. Concurrency Các máy tính trong hệ thống phân tán đều có bộ xử lý và bố nhớ riêng, nhờ vậy chúng có thể xử lý công việc. Một công việc có thể được chia nhỏ và chuyển cho từng máy xử lý đồng thời. Vì vậy tốc độ xử lý tăng lên. Đối với những xử lý nhỏ thì việc xử lý không mất nhiều thời gian nếu được xử lý trên một máy độc lập. Ngược lại, những việc có lượng tính toán lớn (như việc phá mã) đòi hỏi nhiều thời gian, có khi là không khả thi về mặt thời gian. Những công việc như vậy có thể được thực hiện trong hệ thống phân tán bằng cách chia nhỏ công việc, rồi chuyển giao cho từng máy tính thực hiện đồng thời.Kết quả cuối cùng được tổng hợp dựa trên kết quả xử lý ở từng máy. Thời gian xử lý sẽ giảm đi đáng kể. 1.1.1.3. Fault-tolerance Các hệ thống máy tính có thể xảy ra lỗi. Khi bị lỗi, kết quả của quá trình xử lý có thể không đúng hoặc làm ngừng hoạt động của hệ thống. Trong hệ thống phân tán, lỗi là một phần của hệ thống. Điều này có nghĩa là một số thành phần của hệ thống bị lỗi nhưng không ảnh hưởng tới hoạt động của những thành phần khác, đảm bảo cho hệ thống tiếp tục hoạt động. Các phương pháp khắc phục lỗi cho hệ thống được nhà thiết kế xem xét và áp dụng ngay từ khi bắt đầu tiến hành thiết kế và xây dựng hệ thống, đồng thời căn cứ vào đặc điểm và mục đích của mỗi hệ thống sẽ áp dụng các phương pháp khác nhau. Mục đích là đảm bảo cho hệ thống hoạt động ổn định, và duy tri f được hoạt động lâu dài 1.1.1.4. Scalability Là khả năng mở rộng qui mô hệ thống mà không làm ảnh hưởng đến hiệu quả hoạt động của hệ thống. Qui mô của hệ thống được mở rộng khi có các máy tính mới hay các thành phần khác của hệ thống được thêm vào. Hệ thông phân tán được thiết kế để đảm bảo rằng hệ thống vẫn hoạt động bình thường. Ví dụ như khi thêm mới một máy tính vào hệ thống, phải đảm bảo rằng còn địa chỉ IP để cấp cho máy tính mới. Như vậy hệ thống cần có khoảng địa chi IP chưa sử dụng để cấp cho những máy tính thêm mới trong tương lai. 1.1.1.5. Openness Là khả năng mở rộng tài nguyên của hệ thống. Tài nguyên của hệ thống phải được đảm bảo mở rộng một cách dễ dàng, theo nhiều cách. Hệ thống có thể sử dụng các tài nguyên được cung cấp trên các hệ thống khác hoặc thêm mới tài nguyên. Tài nguyên có thể là phần cứng, phần mềm hay dữ liệu và luôn sẵn sàng cho người sử dụng. 1.1.2. Một số mô hình kiến trúc trong các ứng dụng phân tán Phần này giới thiệu một số mô hình phổ biến xây dựng các ứng dụng phân tán. Các mô hình được trình bày theo mức độ trừu tượng từ thấp đến cao: Message Passing, Client-Server, Pear-to-Pear, Distributed object, Mobile agent. level of abstraction Mobile agent Ditributed object Client-Server Message passing Pear-to-pear Hình 1.0: Mức độ trừu tượng của các mô hình phân tán low hight Như vậy fault tolerance là một trong những đặc trưng của hệ thông phân tán. Một hệ thống lớn không thể không có Fault tolerance trong đó. Vì vậy việc xây dựng một hệ thống có Fault tolerance chúng ta cần tìm hiểu về nó. 1.2. Giới thiệu Fault tolerance: 1.2.1 Giới thiệu Fault tolerance là một vấn đề được nghiên cứu nhiều trong nghành khoa học máy tính. Để hiểu được vai trò của nó trong hệ thống phân tán trước hết chúng ta cần nắm rõ từ những khái niệm về hệ thống phân tán cho đến những khái niệm về Fault tolerance. Sự tồn tại của Fault tolerance trong hệ thống phân tán là cần thiết. Một hệ thống Fault tolerance cần có những tính chất sau đây: Tính sẵn sàng(Availability). Tính tin cậy(Reliability). Tính an toàn(Safety). Khả năng không gián đoạn(Maintainability). 1.2.1.1. Availability: Được định nghĩa như là đặc tính chính của hệ thống sẵn sàng sử dụng ngay lập tức. Nói rõ hơn là nó sẵn sàng hoạt động chính xác trong bất kì khoảng thời gian nào và sẵn sàng thực hiện chức năng vì lợi ích sử dụng.Hơn nữa một hệ thống có tính sẵn sàng cao sẽ chờ đợi để làm việc trong mọi thời điểm. 1.2.1.2. Reliability: Tức là hệ thống có thể chạy liên tục mà không mắc lỗi. Một hệ thống có tính tin cậy cao sẽ duy trì công việc không bị gian đoạn trong một khoảng thời gian khá dài. 1.2.1.3. Safety: Có nghĩa là khi hệ thống tạm thời mắc lỗi thì nó đảm bảo rằng không có gì là nghiêm trọng xẩy ra cả. Ví dụ, nhiều quá trình điều khiển như là điều khiển năng lượng điện hay quá trình gửi sóng trong không gian yêu cầu về độ nghiêm ngặt và an toàn cao.Chỉ một lỗi nhỏ cũng có thể gây ra những thiệt hại rất lớn. 1.2.1.4. Maintainability: Tức là làm thế nào để khôi phụ hệ thống lỗi một cách dễ dàng. Một hệ thống có khả năng duy trì là mức cao của tính sẵn sàng, đặc biệt là nó có thể tìm và khắc phục một cách tự động nếu mắc lỗi. Thông thường thì hệ thống mang tính tin cậy yêu cầu cung cấp một mức cao của độ an toàn. Một hệ thống được gọi là Fail khi nó không thể hoàn thành nhiệm vụ của mình. Nếu một hệ thống phân tán được thiểt kế để cung cấp cho chính người sử dụng với một số các dịch vụ,hệ thống sẽ có lỗi khi đó một hoặc nhiều dịch vụ không hoàn thành. Một error là trạng thái của hệ thống có thể làm cho hệ thống không hoạt động. Ví dụ, khi gửi các gói trên mạng, sẽ có một vài gói đã bị phá hủy khi chúng đến nơi nhận. Sự phá hủy trong trường hợp này có nghĩa là bên nhận đã nhận được không đúng giá trị các bit hoặc thậm chí là nó không thể tìm thấy một số thứ mà nó đã nhận. Nguyên nhân của error được gọi là fault. Tức là tìm ra nguyên nhân gây ra lỗi là quan trọng. Ví dụ, đường truyền sai hoặc kém cũng có thể là nguyên nhân gây ra lỗi khi chuyển các gói trên mạng. Trong trường hợp này, hệ thống rất dễ mắc lỗi. Tuy nhiên lỗi đường truyền có thể chỉ do nguyên nhân là ảnh hưởng của thời tiết xấu mà nhất là trong mạng không dây(Wireless network). Xây dựng một hệ thống tin cậy cần có quan hệ chặt chẽ với xử lí các lỗi. Vì mục đích đó của chúng ta, vấn đề quan trọng nhất cần đưa ra là “Fault tolerance” có nghĩa là một hệ thống có thể cung cấp các dịch vụ chính xác và đúng đắn mặc dù hệ thống vẫn có sự hiện diện của lỗi trong đó. Mục đích hay nhiệm vụ của nó chính là: + Ngăn chặn lỗi + Gỡ lỗi + Dự đoán trước được các lỗi Faults thường được phân loại thành các loại sau: + Lỗi tạm thời. + Lỗi không liên tục. + Lỗi lâu dài. Lỗi tạm thời(Transient fault) nó xẩy ra trong một khoảng thời gian sau đó nó lại biến mất, ví dụ như một con chim bay qua chùm của sóng ngắn có thể gây ra lỗi trên. Lỗi không liên tục( intermittent fault) xuất hiện khi mất sự liên kết hay liên kết là không rõ ràng. Lỗi này có thể gây ra hậu quả rất lớn vì nó rất khó chuẩn đoán. Lỗi lâu dài(Permanent fault) tồn tại mãi cho đến khi nó được khắc phục thì thôi. Một số nguyên nhân của lỗi này như là: Cháy chip, rơi đầu từ đĩa, lỗi phầm mềm. 1.2.2. Failure Models: Một hệ thống có lỗi thì nó tất nhiên sẽ không cung cấp được những dịch vụ mà nó muốn. Nếu chúng ta coi hệ thống phân tán như là tập hợp các server liên kết lẫn nhau và với các client, khi đó chỉ cần một trong các server hay cả hai bị lỗi thì rắc rối sẽ xẩy ra cho hệ thống. Trong hệ thống phân tán thì quan hệ phụ thuộc xuất hiện rất nhiều. Một lỗi đĩa có thể làm khó cho sự sống của file server. Nếu file server là một phần của dữ liệu phân tán thì việc này sẽ đưa đến dữ liệu sẽ có thể bị giữ lại và chỉ có thể một phần dữ liệu truyền qua mà thôi.Như vậy lỗi sẽ gây ra hậu quả khá là nghiêm trọng, để tìm ra lỗi một cách chính xác thì chúng ta nên đưa ra phân loại về lỗi: Crash failure Một crash failure xẩy ra khi server ngừng làm việc nhưng nó vẫn làm việc chính xác cho đến khi nó dừng. Một khía cạnh quan trọng của crash failure là mỗi một server tạm nghỉ, không có bất cứ cái gì được nhận từ nó. Một ví dụ đặc trưng của crash failure là hệ điều hành ngừng lại hẳn vaf chỉ có cách là khởi động lại máy tính. Nhiều hệ thống PC chụi đựng crash failure và coi đó như là một lỗi thường xuuyên. Omission failure Một Omission failure xẩy ra khi lỗi server để trả lời yêu cầu. Tất cả mọi thứ là không đúng.Có hại loại Omission failure là receive Omission failure và send Omission failure. Receive Omission failure tức là server chưa bao giờ có yêu cầu trong công việc đầu tiên. Chú ý rằng nó có thể tốt trong hoàn cảnh là liên kết giữa một client và một server đã được thiết lập chính xác nhưng lại không có gì lắng nghe điều đó. Receive Omission failure ảnh hưởng không lớn đến trạng thái hiện tại của server, server không biết có bất kì thông báo nào gửi đến cho nó. Tương tự như vậy, send Omission failure xẩy ra khi server kết thúc công việc của nó. Nhưng vì một lí do nào đó mà lỗi trong khi gửi câu trả lời. Ví dụ:Khi gửi xẩy ra tình trạng bộ nhớ bị tràn trong khi đó thì server lại không chuẩn bị trước điều đó. Chú ý rằng ngược lại với Receive Omission failure server có thể ảnh hưởng đến trạng thái.Server chỉ hoàn thành môt dịch vụ cho client. Kết quả nếu việc gửi gặp lỗi trả lời server cần để chuẩn bị rằng client sẽ gửi lại yêu cầu trước đó một lần nữa. Một loại nữa của Omission failure không liên quan đến kết nối có thể là nguyên nhân do lỗi phần mềm như vòng lặp vô tận hay quản lí bộ nhớ không đúng. Timing failure Đây là một có quan hệ với thời gian. Timing failure xẩy ra khi câu trả lừi có được nằm ngoài khoảng thời gian cho phép. Cung cấp dữ liệu quá sớm có thể đó là nguyên nhân gây ra sự cố cho bên nhận nếu nó không đủ bộ đệm để giữ lại tất cả dữ liệu mà nó vừa được gửi. Response failure Đây là một lỗi quan trọng xẩy ra khi câu trả lời của server hoàn toàn là không đúng đắn. Có hại loại Response failure có thể xẩy ra là: Value failure và State transition.Ví dụ: một công cụ tìm kiếm có hệ thống trả về là một trang Web không có liên quan gì đến những cái mà người sử dụng muốn tìm chúng. State transition failure được biết đến như là một lọai khác của Response failure xẩy ra khi server bất ngờ chống lại yêu cầu. Ví dụ như một server nhận được một thông báo nhưng nó không thể nhận ra được điều đó. Arbitrary failure Được biết đến như là Byzantine failure. Nó có quan hệ chặt chẽ với crash failure. Tóm lại các loại của Failure được cho bởi bảng tổng kết sau đây: Hình 1.3. Bảng tổng kết các loại failure Tóm lại trong hệ thống phân tán thì rất dễ xẩy ra một lỗi nào đấy khi chương trình đang chạy. Vì thế sự ra đời của fault tolerance là rất cần thiết cho hệ thống phân tán, việc nắm bắt được các lỗi và nguyên nhân gây ra lỗi giúp chúng ta có được một hệ thống chạy an toàn, ổn định và không bị ngắt quảng. Đó chính là một yêu cầu cho mọi hệ thống. 1.3. Giới thiệu về Java Migration: Sự tính toán di động là là một kiểu chương trình đầy triển vọng trên mạng - hướng ứng dụng. Có rất nhiều loại ứng dụng được đưa ra như là: Thương mại điện tử, đấu giá trên mạng, tự động tìm kiếm thông tin, hay quản lí công việc tự động…. Khả năng để duy trì trạng thái thực thi trong Migration là một tiêu chí quan trọng của phân loại ngôn ngữ lập trình cho sự tính toán di động. Migration được gọi là trong suốt nếu một ứng dụng di động được tiếp tục lại trang thái (sau khi dừng) một cách chính xác trạng thái trước đó. Transparent Migration thì đặc biệt là quan trọng vì nó cho phép người lập trình viết một ứng dụng di động như là viết một ứng dụng thông thường khác mà không là ứng dụng di động. Hệ thống ngôn ngữ di động đầu tiên được biết đến như là Telescrip và Aglet Tct , chúng đều mang cơ chế của Transparent Migration.Tuy nhiên,Transparent Migration không được bổ sung trong JAVA - hệ thống ngôn ngữ di động cơ bản dù cho JAVA là rất phổ biến cho mọi người quan tâm đến tính toán di động. Và có một khó khăn trong việc sử dụng Transparent Migration trong Java đó là làm sao để giữ được stack trong Migration. Hai phương pháp đã được đưa ra để là được điều đó là: + Sử dụng Java virtual machine. + Thay đổi mã nguồn. Tuy nhiên cả hai phương pháp trên đề có nhứng khó khăn của nó. Phương pháp thứ nhất yêu cầu ứng dụng di động chạy lien tục trên sự thay đổi của máy ảo, đây là mộ thuận lợi vì điều này có mặt khắp nơi trên hầu hết các máy ảo Java. Phương pháp sau nó không thể áp dụng được khi mà mã nguồn không sẵn sàng để dung.Trong thực tế thì mã nguồn Java thường không sẵn có. Như vậy việc chúng ta đưa ra hai phương pháp trên và sự đối chiếu của hai phương pháp, thì phương pháp chúng ta có thể tránh được những điều trở ngại đó, những hạn chế đó. Đó là Bytecode Transformation. Trong phương pháp này Bytecode thay thế cho mã nguồn được thay đổi thông qua khả năng có thể Transparent Migration. Sự biến đổi của bytecode có nhiều thuận lợi hơn so với sự biến đổi của mã nguồn. Đó chính là sức mạnh của ngôn ngữ Java, làm gọn chương trình, nơi mà chỉ sự chuyển đổi của cấu trúc điều khiển mới được phép. Trong hệ thống phân tán thì một client hay một server gặp sự cố đó là điều có thể hoàn toàn xẩy ra. Vì thế khi một client hay server gặp lỗi thì vấn đề mà chúng ta cần phải giải quyết là làm thế mà để chương trình của chúng ta vẫn có thể tiếp tục chạy được trong hệ thống. Để làm điều đó chúng ta sử dụng cơ chế của Transparent Migration. Nhưng vấn đề của chúng ta là làm thế nào để Migration. Điều đó được thực hiện bởi 3 bước : Saving Execution State Transmitting Execution State Restore Execution State Saving Execution State: Khi dự đoán được có thể xẩy ra một lỗi nào đấy trong hệ thống mà cụ thể ở đây là lỗi trên một máy nào đấy trong mạng thì trạng thái máy lúc đó phải được lưu lại và đưa vào trong stack, đưa vào cấu trúc dữ liệu. Transmitting Execution State: Khi các trạng thái thực thi đó được lưu lại bằng cách dùng máy ảo Java, các trạng thái đó sẽ được chuyển đến đích, là nơi có thể tiếp tục chạy tiếp chương trình. Restore Execution State: Khi được chuyển tới đích, ở đây các trạng thái thực thi sẽ được tái tạo lại, và tiếp tục thi hành công việc. Nó sẽ lấy lại các giá trị trong khung stack. Công việc ở đây không phải bắt đầu lại từ đầu, mà nó sẽ bắt đầu từ chỗ mà nó dừng. CHƯƠNG 2: Giới thiệu một số hệ thống hỗ trợ Migration Hiện nay có rất nhiều hệ thống hỗ trợ cơ chế Migration, mỗi hệ thống đều có những mặt mạnh và mặt yếu khác nhau. Sau đây chung ta sẽ giới thiệu một vài hệ thống cơ bản. 2.1. Giới thiệu hệ thống Sumatra: Sumatra là sự mở rộng của môi trường lập trình Java có khả năng thích nghi với chương trình di động. Nền tảng độc lập chính là lí do chung ta chọn Java cho công việc của chúng ta. Trong Sumatra chung ta không thay đổi ngôn ngữ java. Sumatra có thể chạy trên tất cả những gì thuộc về ngôn ngữ java nếu không có sự thay đổi. Thêm tất cả những chức năng được cung cấp bởi lớp thư viên java đưa ra. Thiết kế của chúng ta cho Sumatra cung cấp cơ chế thich ứng với chương trình di động. Nét đặc trưng chính giúp ta phân biệt Sumatra với các hệ thống truớc đó là nó hỗ trợ chương trình ứng dụng cái mà có sự liên kết với tất cả và sự di chuyển diễn ra có sự điều khiển ứng dụng.Tuy nhiên sự kết hợp giữa mục đích phân tán và thread migration cho phép trộn lẫn giữa di chuyển giữ liệu hay di chuyển sự tính toán. Ở trình độ cao của điều khiển ứng dụng cho phép chúng ta dễ dàng khỏa sát những chính sách khác nhau cho sự kiểm tra tài nguyên và làm thích ứng với sự thay đổi của tài nguyên. Sumatra thêm hai khaí niệm chương trình vào java đó là object-groups và execution engines. Môt object-groups tạo nên một nhóm đối tượng động. Đối tượng có thể thềm vào hoặc lấy ra khỏi nhóm đối tượng. Tất cả các đối tượng trong pham vi một nhóm được đối xử như nhau. Điều nay rất giống với ngôn ngữ java vì mỗi cấu trúc giữ liệu là một đối tượng và nó có thể di chuyển trạng thái đối tượng trong khoảng thời gian. Một execution engines là một khái niệm trong môi trường phân tán.Cụ thể là nó phù hợp để trình biên dịch thi hành trên một host. Sumatra cho phép một object-groups di chuyển giữa execution engines. Những thứ chủ yếu cung cấp bởi Sumatra gồm: Object-group migration: object-groups có thể di chuyển giữa các máy trên yêu cầu của ứng dụng. Đầu tiên tất cả các đối tượng trong một object-groups đuợc đối xử như là khởi đầu cho tính lưu động liên quan đến quá trình hoạt động. Đối tượng trong object-groups tự động kiểm soát sử dụng các loại thông tin lưu trong lớp mẫu của chúng . Khi một object-groups được di chuyển tất vị trí tham chiêu đến nó trong nhóm được di chuyển và lưu lại vị trí mới của đối tượng.Tuy nhiên một vài đối tựợng như đối tượng I/O thì không thể di chuyển(Tài nguyên). Remote method invocation: Method invocation trong đối tượng được chuyển qua gọi là remote. Loại thông tin lưu trong lớp mẫu được dùng để hoàn thành chức năng RPC nếu nó không có một trình biên dịch gốc.Sumatra không tự động theo dõi đối tượng di động. Thread Migration:Sumatra cho phép một Thread Migration sử dụng phương thức engine.go() để gửi đi stack và chương trình đếm và di chuyển thread đến máy cần thi hành theo nghĩa của nó.Quá trình hoạt động được khôi phục lại tại nơi chỉ dẫn trứơc sau khi gọi hàm go().Nó tự động đưa vào stack.Trình thông dịc Sumatra duy trì một laọi stack song song với giá trị stack. Nơi giữ của giá trị stack. Khi một thread di chuyển. Sumatra vận chuyển tất cả đối tượng thamm chiếu bởi stack nhưng không thuộc nhóm đối tượng nào. Đối tượng của object-groups di chuyển khi object-groups di chuyển. Sauk hi thread di chuyển đến nơi mới nó sẽ thực hiên nôi dung trong stack ở vị trị mới. Remote execution: Môt thread mới có thể được tạo ra bởi recec’ing trong hàm main() của lớp mẩu trong remote engine.Những đặc trưng của thread mới được sao lại và chuyển đến nơi remote.Không giống với remote method invocation, remote execution không là một khối. Sauk hi hàm main được gọi nó lập tức khôi phục lại thread và gửi đến remote engine.Remote execution khác với Thread Migration là nó tạo ra một thread mới và cahỵ đồng thời với Thread gốc. Remote monitoring:Sumatra cung cấp một tài nguyên giao diện kiêm tra, cái mà có thể được sử dụng bởi ứng dụng để đăng kí nhu cầu kiểm tra. Sígnal handlers:Sumatra cho phép ứng dụng để đăng kí trình xử lí cho hệ lệnh của UNIX. Một ví dụ về Sumatra : filter _object = new Lung_filter(); cancerobject = new Lung_checker(filter_object) myengine = System.rpc.myEngine(); //Createaengineatthexraydatabasesite. remote_engine = new Engine("xrays.gov"); // Sendthelung filter classtotheremoteengine remote_engine.downloadClass("Lung filter"); // Createanewobjectgroup. objgroup = new ObjGroup("lung filter group"); // Addthelung filter objectto theobjectgroup objgroup.checkIn(filter object); // Movetheobjectgrouptothedatabasesite objgroup.moveTo(remote_engine); //aremotemethodcall selectsinterestingxrays size = filter_object.query(db,"DarkLungs"); // Aretheretoomanyimagestobring over? if ( size > too_many_images ) // Migratethread,processimagesandreturn. Remote_engine.go(); result = cancer object.detect cancer(); myengine.go(); else // thereareonlyafew interestingxrays. Fetchthem // andprocesslocally. objgroup.moveTo(myengine); result = cancer object.detect cancer(); // displayresult locally System.display(result); 2.2. Giới thiệu hệ thống TACOMA: Dự án TACOMA:Mô hình tác nhân hiện nay nhận đựợc nhiều sự chú ý. Một tác nhân phổ biến nhất là phần mềm thay thế người dùng. Và con người quan tâm đến làm thế nào để chỉ ra cách đối xử với các tác nhân, và các tác nhân làm thế nào để liên kết với nhau cũng như liên kết với những người khác cao hơn. Trong dự án TACOMA chúng ta chú trọng đến việc hệ điều hành liên kết với tác nhân máy tính. Động cơ của tác nhân máy tính gồm có : Hình 2.1 A client-server interaction. Hình 2.2. Moving the computation close to the data. Hình 2.3: Agent sent to the server location. Hình 2.4: Co-locating communicating agents. Chúng ta bắt đầu dự án TACOMA bằng việc nghiên cứu tỉ mỉ làm thế nào hỗ trợ tác nhân trên internet .Chúng ta quan tâm tới việc fault –tolerance, quản lí chương trình, bảo mật và sự tính toán của tác nhân. Mô hình TACOMA và sự thực hiện cơ bản của nó: Trong mô hình kiểu client – server với tính toán phân tán yêu cầu server phân công rõ các nút. Mô hình đưa ra sự tính toán có thể di chuyển tự do trên mạng. Dự án TACOMA chú trọng đến kiểu agent cho tính toán phân tán.Sau đây là các kiểu của hệ thống tác nhân của chúng ta. 2.2.2.1. Agents- The computation Unit: Đầu tiên chúng ta cần ,ột sự khởi tạo tính toán trong hệ thống của chúng ta. Chúng ta sử dụng khái niệm agent cho mọi sự tính toán. Ở đây chúng ta cần phân biệt rõ client- server – agent. Trong mô hình này chúng ta chú ý đến tất cả các agents. Một số agents không cung cấp bất kì một dịch vụ nào khác, một vài agents cung cấp dịch vụ cho những thứ khác, một vài agent dựa vao những agent khác trong khi nó không làm việc. Một vài agents lại đứng một chỗ trong khi nó có thể dii chuyển quanh. Từ cách nhìn thấp- Một agent chỉ là một quá trình bao gồm code và trạng thái.Một agent đơn giản có thể là một Tcl scrip hay là một chương trình C nhỏ. Tính lưu động là thành phần quan trọng trong agent. Trong chính bản thân nó quyết định khi nào cần di chuyển và di chuyển đến đâu. Đây chính là sự khác biệt so với Migration. 2.2.2.2. Folfders, Briefcases và Cabinets – Duy trì trạng thái. Một agent phải có thể nắm bắt được dữ liệu.Có hai hướng: Nó có thể để lại dữ liệu tại vị trí chính xác và nó phải có thể mang theo dữ liệu khi nó di chuyển. Chúng ta đưa ra khái niệm folders vì mục đích đó. Folder là nơi chứa dũ liệu có thể sử dụng bởi agent.Mỗi folder là một tên ASCII.Mỗi Agent có thể cất hoặc lấy dữ liệu từ folder này. Có nhiều loại folder. CODE folder là nơi chứa mã nguồn của một agent, DATA folder là nơi chứa dữ liệu, cái có thể hỗ trợ cho CODE folder. Tập hợp các folders là một Briefcases. Briefcases di chuyển khi các agent di chuyển. Nhưng folders được sử dụng lâu dài được lưu lại một nơi gọi là File Cabinet. Không giống như Briefcases mà File Cabinet không di chuyển khi agent di chuyển mà nó đứng yên. Cụ thể về Folder, Briefcases và Cabinet có thể được miêu tả bởi hình sau: Hình 2.5: Briefcases(with folder) và file Cabinet(with folder) 2.2.2.3 Meet – the Base Abstraction Một agent có thể Meet . Đây là khái niệm sử dụng cho việc giao tiếp và đồng bộ giữa các agents.Để thi hành nó ta gọi như sau: Meet another_agent Briefcases Agent không giao tiếp bởi sự trao đổi mail.Một meet đơn giản giống như là xác định và thay đổi một Briefcases .Một agent Client có thể yêu cầu một dịch vụ từ agent hệ thống. Agent hệ thống có thể trả lại folder kết quả nếu nó cần. Hình 2.6:Meeting giữa hai agent Nơi để meet Agent phải có khả năng di chuyển,Có nghĩa là nó có khả năng di chuyển tự nhiên từ máy này đến máy khác trên mạng. Chúng ta làm một sự di chuyển trong suốt với người lập trình ứng dụng. Đầu tiên chúng ta cần loại bỏ hết rexec agent. Meet rexec Briefcase Briefcase có một CONTACT folder nơi gặp gỡ với các HOST folder , ví dụ như ag_tcl lấy từ CODE folder và chạy nó Meet ag_tcl Briefcase Sau đó chúng ta cố gắng loại bỏ sự hoat động của HOST folder Hình 2.7: Moving một agent như là một phần của Briefcase 2.2.2. Cài đặt TACOMA và một ví dụ đơn giản: 2.2.3.1. Một ví dụ Agent đơn giản Chúng ta xây dựng và thi hành một vài phiên bản của hệ thống phân tán TACOMA , nơi di chuyển sự tính toán và thực hiện trên môi trường mạng không đồng nhất.Chúng ta sử dụng Tcl để viết một agent đơn giản. GUI agent có thể được tạo thông qua Tcl _ Tk. Tk là bộ công cụ cho X –Windows system. Chúng ta sẽ nhìn vào một ví dụ đơn giản để minh họa cho các đặc trưng của hệ thống TACOMA. Ví dụ chúng ta cần gửi một thông báo” Lunch now – DJ”. Thông báo phải được hiển thị trên dev/console bởi ag_echo. bc_create out_bc folder_store out_bc HOST odin folder_store out_bc DATA “lunch now - DJ” folder_store out_bc OUTPUT /dev/console meet ag_echo out_bc Quá trình thực hiện điều đó chúng ta có thể hình dung bỏi hình vẽ 2.8 như sau: Hình 2.8:Remote echoing example 2.2.3.2 Cài đặt TACOMA Chúng ta có thể lấy TACOMA từ trang web:http và down file có tên tacoma_v1.0.dist.tar.gz. Chúng ta có thể đặt file này vào thư mục gốc hoặc nơi nào đó cho thuận lợi. Vidụ: /users/dag/TACOMA/src/. Chúng ta giải nén nó vào thư mục tacoma chúng ta tạo gunzip tacoma_v1.0.dist.tar.gz tar xf tacoma_v1.0.dist.tar Thư mục chứa 6 thư mục con • bin/ nơi chứa tcltcp và wishtcp. Files chứa đụng phiên bản của Tcl-TCP và Tk- TCP • lib/ nơi chứa ag_echo và ag_tcl, thư mục này chỉ chứa Tacoma.tcl. file này chứa thủ tục Tcl như folder_store, bc_create • man/ chứa trang hướng dẫn • cabinets/, Nơi chứa cabinets. • examples/ Nơi chứa ví dụ về TACOMA agent • sysagents/ Nơi chứa ag_wish. Thư mục Tacoma chỉ chứa hầu hết agents cần cho hệ thống TACOMA • tac_firewall. • tac_exec. • tac_rpc. 2.2.3.3 Chạy TACOMA Để chạy TACOMA đầu tiên chúng ta cần thiíet lập biến môi trừờng cho HOST: setenv HOST hugin Tên host của bạn trong ví dụ này là hugin. Sau đó là biến môi trừờng của TACOMA cần được lập: setenv TACOMAPATH /users/dag/TACOMA/src/tacoma setenv TACOMAPORT 13147 Dấu hiệu khởi động thành công: => [1] 27301 TACOMA v1.0 Agent tac_firewall started at hugin (on port 13147) Date: Wed Mar 1 11:27:22 MET 1995 Path: ‘/users/dag/TACOMA/src/tacoma’ Starting tac_rpc ... done 2.3. Giới thiệu hệ thống Voyager,Aglets: Voyager là một hệ thống được viết bằng ngôn ngữ java hỗ trợ cơ chế Migration trong môi trừơng thực thi và tác tử di động.Nó cũng hỗ trợ cho các mạng không đồng bộ nhưng không hỗ trợ khả năng noncooperation. 2.3.1 Starting và stopping một chương trình Voyager Để khởi động Voyager chúng ta dùng Voyager.startup() Startup() Khởi động Voyager như một client không chấp nhận đến sự kết nối với các chương trình từ xa. startup( String url ) Khởi động Voyager như một server có chấp nhận đến kết nối, mỗi điạc chỉ URL hoặc cổng ngẫu nhiên nêu URL là rỗng (null) startup( Object object, String url ) Có thể tóm lại như sau: Voyager.startup(); // startup as a client Voyager.startup( null ); // startup as a server on a random unassigned port Voyager.startup( "8000" ); // startup as a server on port 8000 Voyager.startup( "//dallas:7000" ); // startup as server on port dallas:7000 Voyager.startup( "//10.2.2.20:7000" ); // startup as server on port 10.2.2.20:7000 Để tắt một Voyager chúng ta dùng Voyager.shutdown(). 2.3.2 Khởi động Voyager server bằng dòng lệnh(command line). Để khởi động Voyager server bằng dòng lệnh chúng ta dùng tiện ích của Voyager.Tiện ích này khởi động một Voyager server chấp nhận sự kết nối và thông báo trên URL nhất định. Để stop accepts connections and messages on a given URL. To stop a Voyager server, press Control-C. Because thi immediately terminates the process, it should not be used on a deployed system unless the application is in an unrecoverable state or can safely be terminated.chúng ta ấn Control – C trên bàn phím. Ví dụ: để khởi động chương trình Voyager nhận cổng kết nối 8000 >voyager 8000 voyager orb professional 4.0, copyright objectspace 1997-2003 2.4. Một số hệ thống khác: Ngoài các hệ thống trên thì còn có rất nhiều hệ thống khác cũng hỗ trợ cơ chế Migration như Telescrips,Emerald, Arachne….Mỗi một hệ thống đều mang một đặc trưng khác nhau. Chúng ta có thể tổng hợp lại quả bảng tổng kết sau đây: Hình 2.9:Bảng tổng kết các hên thống hỗ trợ Migration Hầu hết các hệ thống đều được viết bằng ngôn ngữ java ngoài một số hệ thống như TeleScript, Emerald, Arachne, được viết bằng chính ngôn ngữ của nó hay được viết bằng ngôn ngữ C, C++. CHƯƠNG 3: Giới thiệu về JXTA 3.1.Giới thiệu về JXTA. 3.1.1. Sự ra đời của JXTA: Do sự hạn chế của mạng peer to peer là tính không tương thích giữa các mạng peer to peer và mỗi mạng chỉ giải quyết được 1 phần khả năng thực tế của công nghệ P2P nhất là chưa có một chuẩn công nghệ chung cho P2P. Trong khi đó Microsoft đang nghiên cứu và phát triển các công nghệ cho P2P thông qua dự án .NET. Vì thế hãng Sun Microsystem thành lập nhóm nghiên cứu do Bill Joy và Mike Clary chỉ đạo với mong muốn thiết kế một giải pháp phục vụ cho tất cả các ứng dụng P2P, lấy tên là dự án JXTA 3.1.2.Khái niệm JXTA: JXTA là tập các giao thức, thủ tục làm nền tảng cho việc xây dựng các ứng dụng P2P. JXTA cũng bao gồm các tiêu chuẩn về cách các thiết bị trong mạng P2P làm việc với nhau. JXTA cho phép bất kì các thiết bị có kết nối với nhau trên mạng(connected device) giao tiếp và cộng tác với nhau. Hình 3.1 3.1.3.Tầm nhìn của dự án JXTA: Đẩy mạnh việc truyền thông (không cô lập) giữa các ứng dụng đồng thời phát triển các lệnh quản lí cho peer, nhóm peers thông qua Shell.Không những thế JXTA hỗ trợ đa nền tảng, đa ngôn ngữ, từ các thiết bị nhỏ như mobile phone, PDA cho tới các hệ thống Server lớn, giữ cho thành phần cốt lõi (Core) nhỏ và đơn giản và tạo sự khác nhau về kiến trúc giữa cơ chế cốt lõi và các chính sách tùy chọn. Đặc biệt JXTA chú trọng bảo mật ngay từ đầu. Tóm lại JXTA là một lựa chọn đúng đắn cho mạng ngang hàng với những ưu điểm của nó như là: Cho phép sử dụng nhiều loại dịch vụ, thiết bị va giao vận. JXTA sử dụng XML vì thế khuôn dạng dữ liệu chuẩn, dễ hỗ trợ, dễ thích nghi. Nhưng bên cạnh những ưu điểm đó thì JXTA cũng có những hạn chế nhất định như: Không chỉ ra cách thức gọi dịch vụ không cốt lõi, nó có thể sử dụng bất kì cơ chế nào Có thể không phù hợp cho ứng dụng đơn riêng biệt do các thông báo XML thường có kích thước lớn. Khái quát hóa giao vận là không cần thiết, TCPlà giao thức phổ biến hiện nay tại sao ta không chọn luôn giao thức TCP 3.1.4. JXTA trong sự phát triển của tính toán phân tán: Client-Server: Sử dụng giao thức TCP/IP Web-based: Sử dụng giao thức HTTP Peer-to-Peer: Sử dụng các giao thức JXTA Hình 3.2 3.1.4. Tổng quan về mô hình mạng JXTA Hình 3.3 Các đặc tính của JXTA + Khả năng phối hợp hoạt động (Interoperability):Đây là một đặc tính quan trọng của JXTA, tức là các peer dễ dàng định vị lẫn nhau và dễ dàng trao đổi thông tin với nhau cũng như các peer dễ dàng tham gia vào các hệ thống P2P khác nhau. Do vậy các hệ thống P2P khác nhau có thể dễ dàng phối hợp hoạt động với nhau. Ví dụ: - có thể phối hợp hệ thống P2P chia sẻ file nói chung (Gnuttela) và chia sẻ nhạc (Napster) + Không phụ thuộc vào platform (Platform independence ) Tức là nó không phụ thuộc vào ngôn ngữ lập trình, không phụ thuộc vào hệ điều hành và không phụ thuộc vào thủ tục mạng, giao thức mạng (TCP/IP, Bluetooth…) Tóm lại JXTA có thể chạy trên nhiều ngôn ngữ lập trình, nhiều giao thức và hệ điều hành khác nhau +Tính phổ biến (Ubiquity):Tức là JXTA có thể hoạt động trên tất cả các thiết bị có tính toán số (digital device) - Thiết bị điện tử dân dụng - Sensor - PDA - Mobile phone - PC Kiến trúc JXTA: Hình 3.4 + Lớp lõi( JXTA core): Phụ trách việc tạo peer, xóa peer, quảng bá peer …Đồng thời lớp này cũng có nhiệm vụ quản lí truyền thông giữa các peer với nhau trong mạng - Định tuyến (routing) - Thăm dò (plumbing) Hình 3.5 + Lớp dịch vụ (JXTA Services):Cung cấp dịch vụ cho các ứng dụng P2P - Tìm kiếm (Search) - Chỉ mục (Indexing) - Chia sẻ file (file sharing) - Discovery - Membership Hình 3.6 + Lớp ứng dụng (JXTA Applications):Quản lí các ứng dụng P2P do người dùng xây dựng và tích hợp các ứng dụng P2P, có thể phối hợp các ứng dụng P2P khác nhau Hình 3.7 Giao thức JXTA: Trong JXTA có rất nhiều giao thức đó là : + Giao thức phát hiện peer (Peer discovery protocol): Cho phép một peer tìm thấy thông báo quảng bá (advertisement) trên các peer khác hoặcbdùng để tìm bất cứ peer, nhóm peer hay thông báo quảng bá nào. + Giao thức phân tích địa chỉ peer(Peer resolver protocol): Cho phép một peer gửi và nhận các truy vấn (queries) để tìm (find, search) peer, nhóm peer, ống và các thông tin khác. + Giao thức thông tin peer (Peer information protocol): Cho phép một peer tìm hiểu được khả năng và trạng thái của peer khác. - VD: lệnh ping + Giao thức hội nhóm (Rendezvous Protocol): Cho phép một Peer phát tán thông điệp trong phạm vi của một nhóm peer. + Giao thức nối ống (Pipe Binding protocol): Cho phép các peer thiết lập kênh truyền thông ảo như một đường ống (pipe) giữa chúng và các peer khác. Các peer gửi thông điệp qua ống. +Giao thức định tuyến điểm cuối (Endpoint routing protocol): Cho phép một peer hỏi một peer định tuyến về các đường chuyển thông điệp tới một peer đích. Peer định tuyến (router peer): là peer thực hiện các thủ tục định tuyến điểm cuối (Endpoint routing protocol). Như vậy chúng ta có thể phân cấp cho các gaio thức JXTA như hình vẽ sau: Hình 3.8 Công nghệ trong JXTA: + XML: JXTA sử dụng XML để mã hóa thông điệp và có thể chuyển đổi dễ dàng nếu không dùng XML nữa + An ninh: - Mã hóa MD5, RC4, RSA - Cơ chế kiểm sóat đăng nhập(authentication) PAM). - Quản lí thâm nhập (access control) dựa vào nhóm peer. - Truyền tải SSL,TLS. - Tương tác giao diện dòng lệnh JXTA Shells. Các phiên bản JXTA: JXTA 1.0 (2001) - Chỉ hỗ trợ J2ME - Hỗ trợ ngôn ngữ C, Java JXTA 2.0 (2004) - Hỗ trợ cho J2SE, J2ME - JXTA cho PersonalJava: - Hỗ trợ các ngôn ngữ Java, C, Perl, Python, Ruby Tương lai JXTA: Cộng đồng phát triển mở: - JXTA là dự án mã nguồn mở - Xây dựng bởi rất nhiều chuyên gia trên thế giới - Môi trường cộng tác phát triển trên nền web (jxta.org) - Được sự hỗ trợ rất lớn của cộng đồng các nhà phát triển P2P Ứng dụng ngày càng rộng rãi: - Truyền thông không dây: JXTA for J2ME - Chính phủ: Video conference, e-Government - Giải trí: Game online, Music sharing - Các ứng dụng truyền thông và cộng tác : File sharing, IM, Document Sharing… 3.2. Java JXTA: Nền tảng của Java JXTA là tập hợp các lớp và các ứng dụng có khả năng quản lý và truyền các ứng dụng và điều khiển dữ liệu giữa các nền tảng JXTA tương ứng. Các dịch vụ nhân được dùng để tạo ra các ứng dụng P2P. Ban đầu JXTA không được xây dựng như một Java API, lúc đầu JXTA được xây dựng như một tập các cách thức và thông điệp. Các thông điệp được định nghĩa như tài liệu XML với ngôn ngữ và hệ điều hành độc lập. Phiên bản JXTA cho Java chỉ là một phần của giao thức JXTA. Chúng bao gồm các giao thức được viết trên Java, C, Perl, ... API có thể làm ẩn đi nhiều chi tiết của giao thức. Sự khác biệt giữa API JXTA cho Java và giao thức JXTA là sự chi tiết của các thao tác. Ví dụ khi thực hiện việc định tuyến, các cách thức định tuyến được ẩn đi nhờ các ứng dụng và ta không cần quan tâm đến chúng. Mục tiêu của JXTA không phải là chạy trên mọi nền tảng như Java, nhưng phải cần kết nối P2P ở mọi nơi. Bản bổ sung cho Java của JXTA cũng tương thích với các phiên bản khác hay các ngôn ngữ khác như C, Perl, ... Peer JXTA và Java Peer là một nút của mạng JXTA. Mỗi peer thuộc một hoặc nhiều nhóm và thực thi đầy đủ các dịch vụ như cho phép các peer khác tương tác với nó, hay tương tác qua nó. Trong phần lớn các ứng dụng ban đầu, peer đồng nghĩa với người dùng mặc dù điều đó không phải là đúng đắn lắm. Mỗi peer JXTA được kết nối đầy đủ với một máy ảo Java (JVM). Thông thường mỗi thiết bị - như PC - chẳng hạn là một peer, bạn cũng có thể khởi động nhiều JVM để tạo ra nhiểu peer cho mỗi PC, nhưng làm thế không tốt lắm khi debug và thử nghiệm. Nếu bạn muốn chạy nhiều bản của một ứng dụng JXTA, bạn cần làm nó trên các thư mục riêng biệt và sử dụng các cổng liên kết khác nhau để tránh tranh chấp giữa các ứng dụng. Tổng quan về giao thức JXTA trong Java API Giao thức JXTA được xây dựng từ các message XML, mỗi message là một tài liệu XML, tài liệu XML được định nghĩa như một phần của liên kết (communication) và dữ liệu của liên kết. Các message XML được truyền giữa các peer để chuyển thông tin hoặc trao đổi như một phần của liên kết với các querry và các response. JXTA cho Java giữ nguyên những mặt mạnh của JXTA và mở rộng khả năng quản lý, điều khiển bằng cách thêm vào các đặc tính hướng đối tượng của Java. Sơ lược về API Để thực thi hệ thống P2P chúng ta cần một số dịch vụ cơ bản bao gồm discovery, membership và communication. Giao thức JXTA chia communication làm 3 loại pipe binding, endpoint và các giao thức phân tích. Ngoải ra còn có giao thức thông tin giữa các peer khác, nó chỉ đơn giản như lệnh ping trong mạng, chỉ khác nó còn mang thêm những thông tin khác của peer. Modul Peer Group, Dịch vụ và ứng dụng Mỗi peer group có một lớp dịch vụ riêng. Có một dịch vụ nhân thường được cài đặt để hỗ trợ giao thức JXTA. Mỗi dịch vụ là một modul, đơn giản như một file nhỏ có thể tự chạy. Ứng dụng cũng có thể trở thành một kiểu modul. Hình dưới thể hiện giao diện, quan hệ và giao thức hỗ trợ chúng: Modul (net.jxta.platform) +init(group: PeerGroup, asignID: ID, ImplAdv: Advertisement): void +startApp(args: String[]):int +stopApp():void Service (net.jxta.service) +getImplAdvertisement(): Advertisement +getInterface(): Service Application (net.jxta.platform) Hinh 3.9 Những dịch vụ nhân được hỗ trợ bằng cách tham chiếu những dịch vụ nhân tương ứng từ platform. Hình dưới mô tả việc hỗ trợ đó (chú ý MembershipService là lớp trừu tượng và không có giao diện): Service (net.jxta.service) Module (net.jxta.platform) RendezvousService (net.jxta.rendezvous) EndpointService (net.jxta.endpoint) PipeService (net.jxta.pipe) DiscoveryService (net.jxta.discovery) ResolveService (net.jxta.resolve) PeerInfoService (net.jxta.peer) MembershipService (net.jxta.membership) Hình 3.10 Sơ lược về Java API dành cho giao thức JXTA Giao thức JXTA được dùng để giúp các peer tìm kiếm, tương tác với nhau và quản lý các ứng dụng P2P. Bản thân các giao thức này không phải là ứng dụng và chúng cần nhiều dòng lệnh hơn những gì chúng thực sự làm được. API ẩn đi nhiều chi tiết của mạng P2P, và nó làm cho việc viết ứng dụng JXTA đơn giản hơn.Sau đây là một số loại API: API tìm kiếm peer Tìm kiếm peer là việc tìm địa chỉ máy với cache cục bộ và khả năng chuyển tiếp yêu cầu. Gốc của API tìm kiếm là lớp DiscoveryService, lớp này có thể hiểu như một phần của lớp PeerGroup vì bản thân việc tìm kiếm chỉ được giới hạn trong group chứa nó. API phân tích peer API phân tích được sử dụng bới các API khác cần request hay respond định dạng. API này được truy cập qua giao diện của lớp ResolverService. Nó được hiểu như một query trong mạng rộng, nó sẽ truy vấn nhóm của peer thay vì truy vấn peer cụ thể. API thông tin peer API thông tin peer là một cách request thông tin trạng thái của peer, nó được truy cập thông qua PeerInfoService. Giao thức chứng thực peer API chứng thực peer giống như API tìm kiếm, chỉ có thể dùng trong peer group. Nó bao gồm hai phần Chứng thực và Xác nhận peer. Phần xác nhận peer được sử dụng trong phần lớn tin nhắn, để xác nhận peer đó đúng là thành viên của nhóm. Giao thức chứng thực peer được truy cập qua lớp trừu tượng MembershipService. Có thể giao diện của lớp này sẽ được thay đổi trong các phiên bản tới của JXTA Java API. Pipe binding API Đây là một trong những API động, lý do là vì nó sử dụng nhiều dạng khác nhau của pipe, nó được truy cập thông qua lớp PipeService. Nên nhớ rằng dịch vụ pipe sử dụng đến các dịch vụ phân tích và endpoint. Modul EnpointRounter sẽ định hương pipe. Lớp PipeService không định nghĩa các pipe, nó chỉ tạo ra và quản lý các pipe, các pipe được định nghĩa đầy đủ trong giao diện các lớp InputPipe và OutputPipe. Peer endpoint API API này thường được ẩn đi với các nhà phát triển ứng dụng JXTA bởi vì nó thực ra chỉ là sự hỗ trợ cho rounter. Có vô số rounter được dùng trong các tập đoàn và trên mạng Internet, chúng thực sự vô hình với những người viết trình duyệt hay các phần mềm mạng khác. Tuy nhiên API này có thể được sử dụng để định hướng bởi các ứng dụng có khả năng tạo ra những ứng dụng mạnh hơn. Nó còn nắm chìa khóa để truy cập vào các khả năng vận chuyển đến các dịnh vụ khác, như các pipe và dịch vụ phân tích. Sự khác biệt giữa router vả endpoint router là router là được thực hiện trên peer thay vì các phần đặc biệt của phần cứng và phần mềm. Trong tương lai có thể sẽ xuất hiện router JXTA chuyên dụng nhưng có thuận lợi lớn là bạn có thể sẽ tự mình định tuyến. API này chắc chắn là có hiệu quả thấp hơn so với router chuyên dụng, nhưng endpoint router được xây dựng để định tuyến trong những điều kiện xấu nhất của mạng LAN, firewall, proxy server, ... Router dùng dịch vụ phân tích để truy vấn đến các peer khác thuộc quyền quản lý của ronter đó. Giao thức endpoint, như TCP và HTTP, cũng được định nghĩa và quản lý ở đây. API endpoint được truy cập thông qua giao diện của lớp EndpointService. Peer ID Peer ID được khởi tạo trong lúc cấu hình ban đầu của JXTA platform. Lớp Configurator tạo ra một đối tượng PeerAdvertisement và gọi phương thức setPeerID của đối tượng này với ID được lấy từ gói IDFactory. Đoạn code sau mô tả IDFactory hoạt động như thế nào, bạn có thể thấy ID của group World được dùng trong lời gọi hàm, nó đăng ký ID như là một thành viên của group World: IDFactory.newPeerID(PeerGroupID.worldPeerGroupID) Nhớ rằng khi một peer là thành viên của một group, nó có thể được định vị thông qua dịch vụ tìm kiếm bởi các peer khác trong group đó. Tất cả các peer đểu là thành viên của group World nên chúng đều có thể nhìn thấy các peer khác bằng dịch vụ tìm kiếm peer của group World. Lý do là ID của peer được dùng kết hợp với ID của group. Các lớp Peer Các peer được mô tả bằng các thông báo peer trong lớp PeerAdvertisement của Java JXTA API. Trong phiên bản của JXTA cho Java, phần lớn các giao thức hỗ trợ luôn luôn tách rời vào 2 package riêng biệt. Trong trường hợp này, lớp PeerAdvertisement có những phương thức để đồng bộ hóa các đặc tả XML của thông báo peer. Lớp PeerAdv có thêm những tính năng được dùng hoàn toàn cho bản bổ sung cho Java. Hình dưới là các lớp peer được sử dụng trong ứng dụng JXTA và quan hệ giữa chúng. PeerAdvertisement (net.jxta.protocol) +clone(): Object +getAdvertisementType(): String +getDebugLevel(): String +getID(): ID +getName(): String +getPeerGroupID(): PeerGroupID +getPeerID(): PeerID +getServiceParam(key: ID): StructureDocument +getServiceParams(): Hashtable +putServiceParam(key: ID, param: Element): void +removeServiceparam(key: ID): StructureDocument +setDebugLevel(debugLevel: String): void +setDescription(description: String): void +setName(name: String): void +setPeerGroupID(gid: PeerGroupID): void +setPeerID(pid: PeerID): void +setServiceparams(params: Hashtable): void PeerAdv (net.jxta.impl.protocol) +getDocument(encodeAs: MimeMediaType): Document +initialize(root: Element): void +PeerAdv(root: Element): void +PeerAdv() PeerID (net.jxta.impl.id.UUID) +clone(): Object +equals(target: Object): Boolean +getIDFormat(): String +getPeerGroupID(): ID +getUniqueValue(): URL +getURL(): URL +hashCode(): int +PeerID(groupUUID: UUID, peerUUID: UUID) +PeerID(id: ID) +PeerID() +PeerID(groupID: PeerGroupID) PeerID (net.jxta.peer) +getPeerGroupID(): ID Hình 3.11 Chú ý : Có 2 kiểu package khác nhau trong ứng dụng JXTA. Đó là API và các bổ sung. API hầu hết là các lớp trừu tượng hay các giao diện. Các package là bổ sung (implementation) có code nền tảng tường minh. Bởi vì API còn rất mới nên không phải tất cả các implementation đều được ánh xạ trong API, nên một số implementation cần có cách truy cập riêng. Thực tế không cần sử dụng các lớp implementation trừ khi nó là phần mở rộng thực sự của API. Tóm lại JXTA là một công nghệ mới giúp chung ta có thể xây dựng hệ thống. Nó chỉ ra cách mà các thiết bị trong hệ thống liên lạc với nhau như thế nào. JXTA là phổ biến cho mọi ngôn ngữ. CHƯƠNG 4. Xây dựng hệ thống hỗ trợ Fault tolerance bằng ngôn ngữ java 4.1. Mô tả hệ thống: Hệ thống xây dựng nhằm mục đích khắc phục lỗi trong hệ thống phân tán, Tức là khi một ứng dụng đang chạy trên một máy tính bất kì trong hệ thống phân tán.Vì một lí do nao đó mà máy tính đó không thể tiếp tục chạu chương trình đó nữa thì nó sẽ tự động ngừng chương trình và chuyển chương trình đó đên một máy tính bất kì khác trong hệ thống. Tại đây các trạng thái chương trình lúc nó dừng sẽ được khôi phục lại và nó không phải chạy lại chương trình đó từ đầu mà chương trình sẽ được chạy từ chỗ mà nó bị dừng.Quá trình trên đựơc thực hiện là trong suốt với người dùng, có nghĩa là người dùng không cần quan tâm đến hệ thống làm việc đó như thế nào mà người dùng chỉ cần quan tâm đến kết quả của công việc đó. Mô hình hệ thống có thể được hình dung bởi hình vẽ sau đây: Người dùng GETWAY Chương trình vào Kết quả Hệ thống chúng ta Hình 4.1: Mô hình hệ thống Khi một ứng dụng của người dùng được đưa vào thông qua một cổng giao tiếp giữa người dùng và hệ thống. Tại đây nó sẽ xét xem ở đâu có thể chạy được ứng dụng đó, nếu ứng dụng đang chạy mà gặp phải một lí do nào đó mà nó không thể chạy tiếp (Máy hỏng,lỗi phần mềm…) nó sẽ tự động chuyển sang một nơi khác chạy tiếp. Khi ưng dụng được hoàn thành , nó sẽ đưa kết quả ra cổng giao tiếp và trả lại kết quả cho người dùng. 4.2. Thiết kế hệ thống Hệ thống có thể chạy trên nền Linux hoặc SunOS 5.5.1 Linux: JDK 1.1.3, gcc 2.7.2.3 JDK 1.1.7, egcs 1.0.3 JDK 1.1.8v3, gcc 3.3.2 20031022 SunOS 5.5.1 JDK 1.1.5, gcc 2.6.3 Để tạo một di chuyển chúng ta sử dụng lớp MobaThread thay thế cho lớp Thread thông thường Để có thể di chuyển từ một máy này sang một máy khác chúng ta sử dụng phương thức: MobaThread.goto(destination) Giao diện khi chạy hệ thống Hình 4.2: Giao diện chương trình Tổ chức hệ thống: User Application Introspection Object Mashaling Thread Externalization Thread Migration Java Virtual Machine MOBA Hình 4.3 Tổ chức của công việc Thread Migration Introspection là thư viện cung cấp các hàm giống như là thư viện chuẩn của java. Object Marshaling nó cũng cung cấp các hàm sẵn có. Thread Externalization chuyển các trạng thái của thread đang chạy thành dòng byte và nó được sử dụng bởi Thread Migration để di chuyển Thread giữa các máy ảo Java. Để minh họa cho họat động của hệ thống chúng ta một vài ví dụ trên hệ thống như chương trình in ra các số nguyên từ 1 đến 1000 hay chương trình in ra các số trong dãy Fibonaci. Ta đưa chương trình vào hệ thống và Start hệ thống.Khi muốn dừng chương trình chúng ta Stop hệ thống và chuyển sang một máy khác và Start lại hệ thống. CHƯƠNG 5. Tổng kết và hướng phát triển tiếp theo Nhìn chung khóa luận đã đáp ứng được mục tiêu đề ra ban đầu nghiên cứu về vấn đề khắc phục lỗi trong hệ thống phân tán và xây dựng được hệ thống hỗ trợ Fault tolerance bằng ngôn ngữ lập trình java. Hệ thống của chúng ta cho phép chạy một ứng dụng khi có lỗi nó sẽ chuyển đến một nơi khác và tiếp tục chạy từ chỗ nó bị dừng. Hệ thống xây dựng trong khóa luận này mặc dù đã đáp ứng được yêu cầu của fault tolerance nhưng có sự hạn chế nó là hệ thống chỉ có thể chạy trên Linux., mặc dù bảo mật tốt nhưng nó lại không phổ biến như Windows. Hướng tiếp theo của chúng ta là xây tiếp tục xây dựng làm sao cho hệ thống có thể chạy trên hệ điều hành Windows. Điều đó là quan trọng vì hầu hết các máy tính trên thế giới hiên nay đều cài hệ điều hành Windows. Tài liệu tham khảo: [1] Fault tolerance.pdf [2] Voyager_User_Guide.pdf [3] “An Introduction to the TACOMA Distributed System Version 1.0” Dag Johansen, Robbert van Renesse, Fred B. Schneider [4] “Execution context Migration with in a standard java virtual machine environment”---Andrew Dorman Supervisor: DR. CASPAR RYAN [5] “Network-aware Mobile Programs.” Ranganathan, AnuragAcharya,ShamikD. Sharmaand JoelSaltz [6] “Transparent FaultTolerance for Grid Applications” Pawel Garbacki , Bartosz Biskupski , and Henri Bal [7] “Sumatra: A Language for Resource-aware Mobile Programs” Anurag Acharya, M. Ranganathan, Joel Saltz [8] “JXTA: Java™ P2P Programming” By Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, Juan Carlos Soto Publisher: Sams Publishing Pub Date: March 22, 2002 [9] “Bytecode Transformation for Portable Thread Migration in Java” TakahiroSakamoto,TatsurouSekiguchi,andAkinoriYonezawa Department of Information Science, Faculty of Science, UniversityofTokyo [10] D.LangeandM.Oshima.ProgrammingMobileAgentsinJava. In progress, 1996. Danh sách các website tham khảo: /products/Voyager/.