Áp dụng mẫu thiết kế trong xử lý phân tán - Ngô Thị Lan

Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 73 ÁP DỤNG MẪU THIẾT KẾ TRONG XỬ LÝ PHÂN TÁN Ngô Thị Lan*, Phạm Thị Thương, Lê Thu Trang Trường Đại học Công nghệ thông tin và Truyền thông – ĐH Thái Nguyên TÓM TẮT Hiện nay hầu hết các hệ thống thông tin đều được xây dựng phân tán. Phát triển một hệ thống phân tán là khó khăn do tính phức tạp vốn có của việc giao tiếp phân tán. Mặt khác phần mềm hiện đại ngày càng đòi hỏi tính linh động, mở rộng cao để sẵn sàng đáp ứng được các yêu cầu thường xuyên thay đổi của người sử dụng. Một yêu cầu không thể thiếu đối với phần mềm hiện đại là tính tái sử dụng cao. Mẫu thiết kế được coi là giải pháp hữu hiệu để nâng cao tính tái sử dụng của phần mềm. Trong bài báo này, chúng tôi trình bày kết quả nghiên cứu của mình về việc áp dụng mẫu thiết kế trong tiến trình xây dựng và phát triển hệ thống phân tán sao cho hệ thống có khả năng tái sử dụng và bảo trì cao. Từ khóa: Xử lý phân tán, mẫu thiết kế, hệ thống phân tán, giao tiếp phân tán, chia sẻ tài nguyên ĐẶT VẤN ĐỀ* Phát triển một hệ thống phân tán là khó khăn do tính phức tạp vốn có của việc giao tiếp phân tán. Xây dựng một hệ thống phân tán có khả năng mở rộng, linh động, dễ sửa đổi còn khó hơn. Erich Gamma cùng các đồng sự đã đề xuất 23 mẫu thiết kế, nhằm đáp ứng được nhiều yêu cầu đối với sản phẩm phần mềm: dễ bảo trì, dễ nâng cấp, chất lượng cao và tiết kiệm thời gianTrong đó, đáp ứng được tiêu chí quan trọng là khả năng sử dụng lại các đơn thể, thừa kế được các kinh nghiệm của các chuyên gia trong quá trình phát triển phần mềm [5]. Trong bài báo này chúng tôi nghiên cứu áp dụng mẫu thiết kế vào giải quyết một số vấn đề cơ bản khi thiết kế hệ thống phân tán. Bài báo có cấu trúc như sau: Sau phần đặt vấn đề là phần trình bày về hệ phân tán và các vấn đề của hệ phân tán. Tiếp theo, chúng tôi trình bày tổng quan về mẫu thiết kế. Trong phần kế tiếp, chúng tôi trình bày về cách áp dụng các mẫu thiết kế vào giải quyết một số vấn đề cụ thể của hệ thống phân tán. Cuối cùng là thảo luận và tài liệu tham khảo. CÁC VẤN ĐỀ CƠ BẢN CỦA HỆ PHÂN TÁN Một hệ thống phân tán là một hệ thống máy tính, trong đó một số thành phần hợp tác bằng cách giao tiếp qua mạng. Nói một cách tổng quát hơn thì hệ thống phân tán là một hệ * Tel: 0943 870272, Email: ntlan@ictu.edu.vn thống gồm các thành phần xử lý phân tán, giao tiếp với nhau qua một cơ sở hạ tầng truyền thông chung (www, internet, mạng điện thoại..) [6]. Các vấn đề của hệ phân tán: - Tính chia sẻ tài nguyên: Hệ thống phân tán phải chia sẻ được tài nguyên trong hệ thống. - Tính mở: Hệ thống có thể dễ dàng bổ sung thêm dịch vụ mới mà không ảnh hưởng tới các hoạt động đã có. - Tính tương tranh: Trong hệ phân tán ta cần xử lý được tính tương tranh, tính đồng bộ của hệ thống. - Khả năng thay đổi quy mô. - Khả năng chịu lỗi: Hệ thống phân tán có nguy cơ mất an toàn rất lớn. Vì vậy đòi hỏi hệ thống phải có khả năng chịu lỗi cao. - Tính co dãn: Thể hiện khả năng tương thích của hệ thống. - Tính trong suốt: Ẩn giấu sự rời rạc và những nhược điểm nếu có của hệ phân tán đối với người sử dụng (end-user) và những nhà lập trình ứng dụng. MẪU THIẾT KẾ Định nghĩa về mẫu thiết kế Mẫu thiết kế là cặp bài toán (vấn đề) và giải pháp cho một vấn đề thiết kế thông dụng. Nó không đơn thuần là một bước nào đó trong các giai đoạn phát triển phần mềm và cũng không phải là luật mà là các ý tưởng, sáng kiến kinh nghiệm đã được kiểm tra, đúc kết Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 74 qua thực tế. Nó là lời khuyên cho người thiết kế phần mềm áp dụng vào ngữ cảnh cụ thể. Mỗi mẫu mô tả một vấn đề xảy ra lặp đi lặp lại, và mô tả cốt lõi giải pháp của vấn đề đó, ta có thể sử dụng một mẫu hơn triệu lần mà không bao giờ thực hiện hai lần giống nhau [5]. Sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần giải quyết nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý sao cho phần mềm được xây dựng có tính tái sử dụng cao, tránh bị thoái hóa thiết kế. Các yếu tố xác định mẫu thiết kế Một mẫu thiết kế được xác định qua các yếu tố sau: - Tên mẫu (pattern name): Mỗi mẫu đặc trưng bởi tên của nó. Dựa vào tên mẫu ta có thể hình dung một cách nhanh chóng và hiệu quả về mẫu. - Vấn đề (Problem): Mô tả tình huống áp dụng mẫu. - Giải pháp (Solution): Thể hiện các lớp và đối tượng tham gia giải quyết vấn đề và mối quan hệ, trách nhiệm của các thành phần tham gia vào mẫu. Mẫu cung cấp một mô tả trừu tượng của vấn đề được thiết kế và việc sắp xếp các phần tử cần thiết để giải quyết vấn đề đó. - Kết quả: Cho chúng ta thấy việc áp dụng các giải pháp để giải quyết các vấn đề đặt ra có hiệu quả hay không. Kết quả sẽ đặt ra cho chúng ta các lựa chọn, để từ đó có thể xem xét lựa chọn nào là phù hợp nhất, tốt nhất. Các bước để lựa chọn mẫu thiết kế Để lựa chọn mẫu thiết kế phù hợp với ngữ cảnh cụ thể của hệ thống ta thực hiện các bước sau: [9] - Xác định được cần thiết kế gì, các vấn đề phát sinh trong khi thiết kế, các vấn đề đó thuộc loại nào và tham khảo xem ứng với loại vấn đề đó có thể dùng mẫu nào để giải quyết. - Tham khảo lần lượt từng mẫu được chọn, xem mục đích sử dụng, đối chiếu với các vấn đề thiết kế gặp phải (Design Problems). Bước này giúp ta hiểu rõ hơn về các mẫu và tác dụng thực của mẫu lên vấn đề cần giải quyết. - Tìm hiểu sự tương tác giữa các mẫu thiết kế để xác định được các nhóm mẫu phù hợp với bài toán của mình. - Cố gắng tìm kiếm, khảo sát các nguyên nhân có thể dẫn tới việc thoái hóa thiết kế (redesigning) để cô lập hóa, nhằm tránh các thay đổi không cần thiết. - Xác định các thành phần (module, lớp đối tượng) có thể thay đổi trong tương lai. Từ đó quyết định xem phải làm gì để có thể thay đổi hệ thống mà không cần phải thiết kế lại. ÁP DỤNG MẪU THIẾT KẾ TRONG XỬ LÝ PHÂN TÁN Hệ thống phân tán thông thường được xây dựng trên mô hình client – server và truyền thông với nhau qua giao thức TCP/IP. Server sẽ chịu trách nhiệm trả lời các yêu cầu của client. Khi thiết kế phía server nên thiết kế sao cho độ ghép cặp thấp để dễ mở rộng trong tương lai nhưng phải kết dính chặt với các chức năng sẽ bổ sung. Đồng thời, các thành phần khác nhau phía server nên thiết kế sao cho dễ dàng chuyển giao. Client sẽ cung cấp các yêu cầu dữ liệu đến server, xử lý các phản hồi từ server. Để thực hiện giao tiếp giữa server và client trở nên trong suốt đối với người dùng và tối ưu thời gian xử lý của hệ thống khi client truy xuất các tài nguyên hay yêu cầu các dịch vụ từ server thì chúng ta sử dụng mẫu proxy. Proxy trì hoãn việc khởi tạo đối tượng cho đến khi cần thiết nó sẽ chuyển lời gọi hàm tới đối tượng mà nó đại diện để yêu cầu khởi tạo. Mặt khác khi dùng mẫu proxy ta có thể hạn chế được các nguy cơ mất an toàn đối với server do client truy cập đến. Do proxy có thể thực hiện các chính sách được thiết lập cho hệ thống trước khi thực hiện yêu cầu của Client. Nếu server phát hiện có tấn công phá hoại từ một client nào đó thông qua proxy, thì server chỉ cần xóa bỏ tiến trình của proxy hiện tại để chấm dứt cuộc tấn công [1,3]. - Client Object: yêu cầu một dịch vụ từ server và triệu gọi một phương thức của nó. - Server Object: Cung cấp dịch vụ cho Client Object. - Client-Side Proxy: Đại diện cho đối tượng của client. Nó chịu trách nhiệm truyền đối số cho đối tượng cục bộ từ xa (remote object location). Nó sử dụng đối tượng tham chiếu Reference Manager để chuyển đổi đối tượng tham chiếu gửi tới tên phân tán (distributed Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 75 names) và nhận distributed names từ đối tượng tham chiếu. Nó cũng sử dụng Reference Manager để lấy một một đối tượng Data Interface. Hình 1: Cấu trúc mẫu proxy trong xử lý phân tán - Server-Side Proxy: chịu trách nhiệm hỗ trợ phân tán cho đối tượng Server Object trên server. Nó là điểm truy cập cho yêu cầu từ xa tới server. - Reference Manager: Chịu trách nhiệm kết nối với đối tượng tham chiếu cục bộ và proxy, với distributed names. - Client-Side Communicator và Server- SideCommunicator: Chịu trách nhiệm cài đặt giao tiếp phân tán ở tầng vật lý. Để xử lý các trường hợp nhiều đối tượng liên quan đến nhau mà khi một đối tượng trong số đó thay đổi trạng thái thì các đối tượng còn lại cần biết được và cập nhập theo thì ta sử dụng mẫu Observer. Trong hệ phân tán, ta cần đồng bộ một số đối tượng ở server và client. Các đối tượng trong phần 1 (hình 2) được thiết kế bên server thì các đối tượng trong phần 2 (hình 2) sẽ được thiết kế bên client và ngược lại. Tần suất sử dụng mẫu Observer là cao. Tuy nhiên, trong hệ thống phân tán khi sử dụng mẫu Observer, ta cần chú ý một số vần đề nảy sinh sau: Hình 2: Mẫu Observer trong hệ thống phân tán - Đố tượng Subject và Observer có thể được đặt ở các nút mạng khác nhau. - Giao tiếp giữa 2 bên có tốc độ khác nhau, giao tiếp không đáng tin cậy và khả năng của các bên là giới hạn. Khi đó, để giải quết các vấn đề trên, ta cố gắng giảm số lượng cập nhập, giảm kích thước của các cập nhập, giảm số lượng các đối tượng Observer. Khi các cập nhập quá phức tạp ta có thể kết hợp mẫu Meditor. Sử dụng mẫu Meditor để quản lý các thay đổi cần thực hiện. Hình 3: Mẫu Observer khi chiến lược update phức tạp Mẫu Command đóng gói các yêu cầu vào trong các đối tượng riêng biệt. Trong hệ thống phân tán, ta sử dụng mẫu Command để quản lý các yêu cầu từ phía client gửi đến, quản lý đăng nhập, thực hiện hủy thao tác (undo) ClientObject ReenceInterface> +m() Client-SideProxy +convertArgument() ServerObject DataInterface> +invoke() ReferenceManager Client-SideCommunicator +marshaling() +unMarshaling() +sendMessage() Server-SideProxy +convertArguments() Server-SideCommunication +marshaling() +unMarshaling() +returnMessage() SimpleChangeManager +Register(Subjects, Observer) +unRegister(Subjects, Observer) +notyfy() DAGChangeManager +Register(Subjects, Observer) +unRegister(Subjects, Observer) +notyfy() Subjects +attach(Observer o) +detach(Observer o) +notyfy() ChangeManager -subjectObserverMapping +Register(Subjects, Observer) +unregister(Subjects, Observer) +notyfy() Obsever +update(Subjects) +subject +observer Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 76 hoặc lấy lại thao tác vừa hủy (redo) hoặc khi cần thực hiện chậm các yêu cầu (Command sẽ đưa các yêu cầu vào hàng đợi và thực thi sau). Nhờ mẫu này mà khi muốn mở rộng chương trình thêm các yêu cầu mới vào ta không phải sửa lại chương trình mà chỉ cần thay đổi ở lớp Command. Hình 4: Mẫu Command Đối tượng Client yêu cầu tạo Command trên nút nhận cục bộ (local Receiver node). Đối tượng Receiver phải cung cấp tập các yêu cầu cụ thể (ConcreteCommand), chỉ tạo yêu cầu khi cần truyền đi. Việc tạo và điều phối các yêu cầu được thực hiện tại client. Trong hệ phân tán, client gửi yêu cầu tới server, server gửi kết quả trả về cho client. Yêu cầu gửi server và kết quả trả về có thể hiển thị ở các định dạng khác nhau. Ta sử dụng mẫu Strategy để xác định các thuật toán hiển thị, thực hiện đóng gói đối với từng thuật toán, cho phép client lựa chọn thuật toán cụ thể trong số đó để sử dụng. Hình 5: Mẫu Strateggy Trong những hệ thống phân tán có kết nối tới cơ sở dữ liệu lớn, để hệ thống tối ưu về tốc độ thì thay vì làm việc với nhiều đối tượng cơ sở dữ liệu ta dùng mẫu Sinleton để tạo ra một thể hiện duy nhất của cơ sở dữ liệu. Ta có thể sử dụng mẫu MVC (Model – View – Controller) để tách các thành phần mô hình, trình diễn, điều khiển riêng biệt, giúp hệ thống dễ xây dựng và bảo trì hay mở rộng. Mẫu MVC có 3 thành phần: - Model nắm giữ dữ liệu. - View: (tầng giao diện) hiển thị các dữ liệu trong Model theo Controller. - Controller điều khiển việc tương tác giữa đối tượng giao diện với người sử dụng cũng như những đối tượng khác. Mẫu MVC thường sử dụng mẫu Observer khi nó làm mới lại để hiển thị các lớp dữ liệu thay đổi. Một biến thể cải tiến của MVC là mẫu Hierarchical Model View Controller (HMVC) [7]. Bên phía client, mô hình HMVC sẽ phân tầng client vào cấu trúc phân cấp cha – con (parent-child MVC) cho phép thiết kế hữu hiệu các tầng kiến trúc của client. Hình 6: Mẫu HMVC - View: Là nơi diễn ra tương tác. Trong tương tác, view liên kết với controller để đưa ra một sự kiện. Controller Model View Layer 1 Controller Model View Layer Controller Model View Layer Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 77 - Controller: Có một Parent-child hierarchy. Trong một tầng có một cotroller. Trong tầng trên nhất, đối tượng controller sẽ truyền sự kiện xuống hệ thống phân cấp. Khi sự kiện truyền đến bộ điều khiển cần xử lý nó có thể hoặc không truyền tiếp. - Model: Điều khiển thay đổi mô hình khi nó nhận được một sự kiện yêu cầu cập nhập dữ liệu. Nếu mô hình thay đổi, nó sẽ thay đổi trạng thái và thông báo cho view. Thành phần view lắng nghe sự kiện và thay đổi theo. Bên phía server, có đối tượng điều khiển mức trên riêng. Tất cả các yêu cầu được đưa lên bộ điều khiển cấp cao nhất này. Khi yêu cầu được nhận, dữ liệu được lấy từ chuỗi đầu vào. Để không vượt ra ngoài phạm vi nghiên cứu trong bài báo này, chúng tôi giả sử rằng các máy chủ biết được định dạng dữ liệu được chấp nhận bên phía client. Các dữ liệu cần phải được đưa tới đúng thành phần. Dữ liệu được chuyển thành các sự kiện và truyền xuống các controller dưới trong cây phân cấp của mẫu HMVC. Khi thông tin được chuyển đến đúng thành phần nhận, nó sẽ thực thi hành động của yêu cầu, trả kết quả về cho Controller gốc. Điều khiển của Controller gốc sẽ đưa kết quả ra theo đúng định dạng chấp nhận của client. THẢO LUẬN Chúng tôi đã nghiên cứu, tổng hợp, đưa ra các vấn đề cơ bản trong xử lý phân tán và cách áp dụng mẫu thiết kế vào để thiết kế hệ thống phân tán sao cho hệ thống dễ dàng thay đổi mở rộng. Nghiên cứu của chúng tôi là nền tảng cơ sở ban đầu để xây dụng ứng dụng thực tế. Hiện chúng tôi đã áp dụng để xây dựng hệ thống phân tán: Hệ thống quản lịch cá nhân của giảng viên trường CNTT & TT – Đại học Thái Nguyên. Do chương trình cần thời gian để chạy thử nên chúng tôi xin trình bày kết quả thử nghiệm của mình trong nghiên cứu tiếp theo. TÀI LIỆU THAM KHẢO [1]. Alan H. Karp, Kevin Smathers, Three Design Patterns for Secure Distributed Systems, HP Laboratories Palo Alto, HPL-2003-40, February 25th, 2003 [2]. Ant´onio Rito Silva1, Francisco Assis Rosa2, Teresa Gonc¸alves2 and Miguel Antunes1, Distributed Proxy:A Design Pattern for the Incremental Development of Distributed Applications, 2000 [ =10.1.1.32.7664] [3]. DONG T. B. Thuy and TRAN D. Thu, User Interface Design by Applying Object – Oriented Design Patterns, Addendum Contributions to the 4th IEEE International Conference on Computer Sciences Research, Innovation & Vision for the Future, February 12-16, Hochiminh City, Vietnam, 2006. [4]. Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software, hardcover, 395 pages, Addison-Wesley. ISBN 0- 201-63361-2. [5]. George Coulouris, Jean Dillimore and Tim Kindberg, Distributed Systems: Concepts and Design, Edition 4, Addison Wesley 2005. [6]. HMVC: The layered pattern for developing strong client tiers [ 2000/jw-0721-hmvc.html] [7]. Karli Kirsimäe, Classical Design Patterns in Distributed Computing, Research Paper, University Tartu of mathematic and ìnormatics, 2008. [8]. Nguyễn Quý Minh, Tăng Nguyễn Trung Hiếu, Phạm Anh Vũ, Lê Hải Dương, Phương Lan, Design Patterns. Nhà xuất bản Phương Đông, 2005 [9]. Observer (Java 2 Platform SE v 1.4.2) [ bserver.html] [10]. Trương Đình Huy, Võ Trung Hùng, Ứng dụng mẫu thiết kế trong quá trình phát triển phần mềm, Tạp chí khoa học và công nghệ Đà Nẵng, số 3(38), 2010. Ngô Thị Lan và Đtg Tạp chí KHOA HỌC & CÔNG NGHỆ 99(11): 73 - 78 78 SUMMARY APPLICATION OF DESIGN PATTERNS TO DISTRIBUTED COMPUTING Ngo Thi Lan*, Pham Thi Thuong, Le Thu Trang College of Information and Communication Technology - TNU Nowadays most of information systems are built distributed. Development of a distributed system is difficult due to the inherent complexity of distributed communication. On the other hand modern software increasingly requires highly flexible expansion to be ready to meet the constantly changing requirements of the user. An indispensable requirement for the modern software is highly reusable. Design is considered to be an effective measure to improve the reuse of software. In this paper, we present the results of their research on the application of design patterns in the process of construction and development of distributed systems so that the system has the ability to re-use and high maintenance. Key words: design pattern, distributed computing Ngày nhận bài: 12/11/2012, ngày phản biện: 20/11/2012, ngày duyệt đăng:10/12/2012 * Tel: 0943 870272, Email: ntlan@ictu.edu.vn