Tiểu Luận Hệ Phân Tán Dựa Trên Nền Tảng Web

Nguyên tắc của việc cung cấp và sử dụng một dịch vụ Web khá đơn giản và được minh họa trong hình 1.3: các ứng dụng Client có thể gọi các dịch vụ được cung cấp bởi ứng dụng server.. Mỗi h

Tr-ờng đại học CÔNG NGHệ hà nội

HỆ PHÂN TÁN DỰA TRấN NỀN TẢNG

WEB

Tiểu luận môn học

Môn học: Hệ phõn tỏn

Học viên thực hiện : nguyễn thị ngọc anh

: NGUYỄN THỊ KIỀU ANH

Lớp : Cao học K17

Hà Nội – 1/2011

Mục lục

I HỆ PHÂN TÁN DỰA TRÊN NỀN TẢNG WEB 4

1.1 Kiểu kiến trúc 4

1.2 Các tiến trình 7

1.3 Liên lạc 11

1.4 Naming 12

1.5 Đồng bộ 14

1.6 Nhất quán và bản sao 15

1.7 Fault Tolerance (Khả năng chịu lỗi) 20

II XÂY DỰNG WEBSERVICE TRẮC NGHIỆM 21

2.1 Giới thiệu ứng dụng trắc nghiệm: 21

2.2 Cơ sở dữ liệu: SQL server 2008 21

2.3 Mô hình: 22

2.4 Hình ảnh webservice 22

2.5 Sử dụng webservice TracNghiem 2

Hệ phân tán dựa trên web(Distributed web-based systems)

WWW được xem như một hệ thống phân tán lớn gồm hàng triệu khách hàng và máy chủ để truy cập đến các tài liệu liên kết Các server duy trì tập hợp các tài liệu, trong khi các Client cung cấp giao diện dễ sử dụng cho người sử dụng để trình diễn và truy cập vào các tài liệu

- Tài liệu thường được biểu diễn bằng văn bản (plain text, HTML, XML)

- Các loại khác: ảnh, âm thanh, video, các ứng dụng (PDF, PS)

- Tài liệu có thể chứa mã script được thực thi bởi phần mềm hướng Client

I Hệ phân tán dựa trên nền tảng Web

Client tương tác với các Web server qua trình duyệt (brower) Trình duyệt chịu trách nhiệm hiển thị đúng cách một tài liệu Và trình duyệt cũng chấp nhận cho phép người dùng chọn một tham chiếu tới một tài liệu khác, rồi sau đó nó tìm và hiển thị Giao tiếp giữa trình duyệt và Web server theo một giao thức chuẩn HTTP (HyperText Transfer Protocol - giao thức truyền siêu văn bản)

Mô hình tổ chức của hệ thống:

Hình 1.1 Mô hình tổng thể của Web site truyền thống

Cơ chế hoạt động của hệ thống:

(1): Server nhận yêu cầu lấy một tài liệu (HTTP) từ Client

(2): Tiến trình ở Server thực hiện truy cập và lấy tài liệu từ cơ sở dữ liệu

(3): Server sau khi xử lý sẽ trả lại thông tin cho Client: có thể là thông tin báo không tìm được hoặc nội dung tài liệu

1.1.2 Kiến trúc đa tầng

Web không dừng lại ở kiến trúc hai tầng đơn giản Client – Server, bây giờ nó đã được mở rộng thêm nhiều thành phần để hỗ trợ tốt các kiểu dữ liệu khác nhau mà chúng ta đã mô tả

Một trong những cải tiến đầu tiên của kiến trúc cơ bản để hỗ trợ sự tương tác với người sử dụng bằng việc sử dụng CGI ( Common Gateway Interface - Hệ giao tiếp cổng vào chung) Thông qua giao diện này, người sử dụng điền vào biểu mẫu HTML

và các thông tin này sẽ được gửi đến server

Cơ chế của quá trình này được thể hiện ở hình 1.2:

Hình 1.2 Các nguyên tắc sử dụng chương trình CGI phía server

(1): Người dùng nhập thông tin cần thiết vào form Thông tin về chương trình và thông số của nó được Client gửi tới Server

(2): Server khởi tạo chương trình CGI để nạp tài liệu

(3): Chương trình tương tác với cơ sở dữ liệu, xử lý và tạo ra các văn bản HTML Văn bản này được trả về cho Server

(4): Server thực hiện trả lại văn bản cho phía Client

1.1.3 Các dịch vụ Web

Dịch vụ Web giống như các dịch vụ truyền thống khác (ví dụ, dịch vụ định danh, dịch

vụ báo cáo thời tiết,…) đã có sẵn trên Internet Nhưng dịch vụ Web có điểm đặc biệt:

nó tuân thủ theo tập các tiêu chuẩn mà cho phép nó phát hiện và truy cập trên Internet bằng các ứng dụng Client

Nguyên tắc của việc cung cấp và sử dụng một dịch vụ Web khá đơn giản (và được minh họa trong hình 1.3): các ứng dụng Client có thể gọi các dịch vụ được cung cấp bởi ứng dụng server Quá trình này được thực hiện dựa trên sự chuẩn hóa

Hình 1.3.Mô hình dịch vụ Web

- UDDI (Universal Description, Discovery and Integration standard) là một thư mục chứa các mô tả dịch vụ cần thiết Nó là một cơ sở dữ liệu giúp cho các Client có thể truy cập tìm kiếm các dịch vụ phù hợp

- Các dịch vụ được mô tả thông qua ngôn ngữ WSDL (Web Services Definition Language) Ngôn ngữ này tương tự ngôn ngữ định nghĩa giao diện được hỗ trợ trong liên lạc RPC Ngôn ngữ WSDL mô tả các định nghĩa chính xác của giao diện được hỗ trợ bởi dịch vụ, đó là: các đặc tả thủ tục, các kiểu dữ liệu, vị trí các dịch vụ,…

- Liên lạc giữa Client và Server thông qua giao thức SOAP (Simple Object Access Protocol)

đó hiển thị chúng trên màn hình của người dùng Trình duyệt cung cấp một giao diện

mà các siêu liên kết được hiển thị theo cách mà người dùng có thể dễ dàng chọn thông qua một cú nhấp chuột

Trước đây, trình duyệt Web gồm những chương trình đơn giản Chúng bao gồm các thành phần được thể hiện trong hình 1.4

Hình 1.4 Các thành phần logic của một trình duyệt Web

- Rendering engine: chịu trách nhiệm hiển thị các văn bản HTML (hoặc XML) lên màn hình Nó yêu cầu phân tích HTML hoặc XML, có thể cũng yêu cầu giải thích kịch bản

- Browser engine: cung cấp các kỹ thuật cho người dùng cuối cách đi đến tài liệu, chọn các phần của nó và kích hoạt siêu liên kết,…

1.2.2 The Apache Web Server

Tính đến nay, Web server phổ biến nhất là Apache, được ước tính sử dụng để lưu trữ khoảng 70% tất cả các trang Web

Tổ chức cơ chế hoạt động của Apache được trình bày trong hình 1.5 Cơ bản của tổ chức này là khái niệm về hook, nó chỉ một nhóm chức năng đặc biệt Các lõi Apache giả định rằng yêu cầu được xử lý trong một số giai đoạn, mỗi giai đoạn bao gồm một vài hook Mỗi hook đại diện cho một nhóm các hành động tương tự nhau cần được thực thi như một phần của việc xử lý một yêu cầu

Hình 1.5 Tổ chức chung của Apache Web Server

Ví dụ, có một hook để dịch một URL thành tên file địa phương Như vậy việc dịch chắc chắn cần thực hiện trước khi xử lý một yêu cầu Tương tự như vậy, có một hook cho việc ghi thông tin tới một bản ghi, một hook cho việc kiểm tra xác minh Client, một hook cho kiểm tra quyền truy cập và một hook cho kiểm tra yêu cầu định dạng MIME liên quan đến (ví dụ, để đảm bảo yêu cầu có thể được xử lý đúng cách) Như hình 1.5, các hook được xử lý theo một thứ tự định trước

Các hàm liên kết với một hook được cung cấp bởi các module riêng biệt Mỗi hook chứa một bộ các hàm mà phù hợp với một mẫu hàm cụ thể (ví dụ, danh sách các thông

số và kiểu trả về) Một nhà phát triển module sẽ viết các hàm cho các hook cụ thể Khi biên dịch Apache, nhà phát triển chỉ rõ hàm nên được thêm vào hook Hình 1.5 là các liên kết khác nhau giữa các hàm và hook

Vì có thể có hàng chục module, mỗi hook có một vài hàm Thông thường, các module được coi là độc lập với nhau, vì vậy các hàm trong cùng hook sẽ thực thi theo thứ tự tùy ý Tuy nhiên, Apache cũng có thể xử lý module phụ thuộc bằng cách cho phép nhà phát triển định thứ tự mà các hàm từ các module khác nhau được xử lý Vì vậy, kết quả của Web Server cực kỳ linh hoạt

1.2.3 Web Server Clusters

Một vấn đề quan trọng liên quan đến bản chất Client – Server của Web là Web server

dễ dàng bị quá tải Một giải pháp thực tế được thực hiện trong nhiều thiết kế chỉ đơn giản là sao chép một máy chủ trên một cụm máy chủ và sử dụng kỹ thuật riêng biệt, chẳng hạn font-end, để chuyển tiếp các yêu cầu của Client tới một trong các bản sao Nguyên tắc này được thể hiện trong hình 1.6 và đây cũng là một ví dụ của phân tán theo chiều ngang

Hình 1.6 Nguyên tắc sử dụng một server cluster kết hợp với front-end để thực thi

một dịch vụ Web

Một khía cạnh quan trọng của cách tổ chức này là thiết kế front – end Vì nó có thể trở thành một nút cổ chai hiệu suất nghiêm trọng mà tất cả các lưu lượng truy cập sẽ đi qua

- Transport-layer Switching: Cứ khi nào Client có một yêu cầu HTTP, nó thiết lập một kết nối TCP tới server Transport-layer switch đơn giản là chuyển các dữ liệu được gửi theo kết nối TCP tới một trong các server, phụ thuộc vào độ đo tải của server Hồi đáp

từ server được trả lại cho switch, và sau đó được chuyển tới Client đang yêu cầu Hạn chế chính của Transport-layer Switch là switch không thể đưa vào account nội dung của yêu cầu HTTP mà chỉ gửi cùng với kết nối TCP

- Content-aware Distribution: đầu tiên front-end kiểm tra yêu cầu HTTP đến, và quyết định server nào cần chuyển tiếp yêu cầu Cách tiếp cận này có một số lợi thế Ví dụ,

nếu front-end luôn chuyển yêu cầu cho cùng tài liệu tới cùng máy chủ, các server có thể cache tài liệu hiệu quả dẫn đến thời gian đáp ứng cao hơn Ngoài ra, nó có thể thực thi việc phân tán các tài liệu giữa các server thay vì phải sao lặp mỗi tài liệu trên mỗi server Cách tiếp cận này làm việc sử dụng dung lượng lưu trữ có sẵn hiệu quả hơn và cho phép sử dụng các server riêng biệt cho xử lý văn bản đặc biệt như âm thanh hoặc video

Content-aware Distribution có hạn chế: font-end cần làm nhiều công việc Lý tưởng nhất, người ta muốn có TCP handoff hiệu quả và các hàm của Content-aware Distribution Kết hợp với TCP handoff, front –end có 2 nhiệm vụ:

- Đầu tiên, khi một yêu cầu ban đầu đến, nó phải quyết định server nào sẽ xử lý phần còn lại của liên lạc với Client

- Thứ hai, front-end nên chuyển các thông điệp TCP của Client kết hợp với kết nối handed-off TCP

Hình 1.7 Content-aware mở rộng của Web server

Hai nhiệm vụ có thể được phân phối như hình 1.7 Dispatcher chịu trách nhiệm quyết định kết nối TCP server nào nên được handed-off; người phân phối giám sát lưu lượng TCP đến cho kết nối handed-off Switch được dùng để chuyển tiếp các thông điệp TCP tới người phân phối Đầu tiên khi Client liên hệ với dịch vụ Web, thông điệp thiết lập kết nối TCP được chuyển tiếp tới người phân phối, và lần lượt liên hệ với dispatcher để nó quyết định kết nối server nào nên được handed-off Vào thời điểm đó, switch được thông báo rằng nó nên gửi tất cả các thông điệp TCP cho kết nối tới server đã chọn

Hiện có nhiều lựa chọn thay thế khác và cải tiến hơn cho việc thiết lập Web server Cluster Ví dụ, thay vì sử dụng bất kỳ loại front-end nào, nó có thể sử dụng round-

robin DNS mà một tên miền được gán với nhiều địa chỉ IP Trong trường hợp đó, khi phân giải host name của một trang Web, trình duyệt Client sẽ nhận một danh sách nhiều địa chỉ, mỗi địa chỉ tương ứng với một trong các Web server Thông thường, trình duyệt chọn địa chỉ đầu tiên trong danh sách

1.3 Liên lạc

1.3.1 Hypertext Transfer Protocol (HTTP)

Tất cả liên lạc giữa Client và Server trong Web dựa trên giao thức truyền tải siêu văn bản (HTTP) HTTP là giao thức Client-Server khá đơn giản Một Client có thể yêu cầu gửi hoặc nhận một tài liệu nào đó thông qua các thông điệp yêu cầu khác nhau

HTTP được thiết kế như một giao thức Client-Server hướng tới chuyển tài liệu theo cả

2 chiều Một Client có thể yêu cầu mỗi thao tác này được thực hiện tại server bằng cách gửi một thông điệp yêu cầu chứa thao tác mong muốn tới server Dưới đây là danh sách các thông điệp yêu cầu sử dụng phổ biến nhất:

HTTP cho rằng mỗi tài liệu có thể kết hợp với siêu dữ liệu được lưu trữ trong header riêng mà gửi cùng với một yêu cầu hoặc hồi đáp Thao tác header được gửi đến server khi Client không muốn tài liệu thực mà chỉ liên quan đến siêu dữ liệu (metadata) Ví

dụ, sử dụng thao tác head sẽ trả về thời gian tài liệu được sửa đổi Thao tác này có thể được sử dụng để chứng minh tính hợp lệ của tài liệu, kiểm tra tài liệu có tồn tại không

mà không cần phải thực sự chuyển giao tài liệu

- Thao tác quan trọng nhất là get Nó được dùng để thực sự lấy tài liệu từ server

và chuyển lại cho Client đang yêu cầu

- Thao tác put: một Client có thể yêu cầu server lưu trữ tài liệu dưới một tên đã cho (được gửi cùng với yêu cầu) Server sẽ chỉ chấp nhận yêu cầu đó của Client

ủy quyền

- Thao tác post: có phần tương tự như lưu trữ tài liệu, ngoại trừ Client sẽ yêu cầu

dữ liệu được thêm vào tài liệu hoặc thu thập tài liệu Một ví dụ điển hình là việc đăng một bài báo cho một nhóm tin tức Đặc tính phân biệt so với thao tác put

là thao tác post nói nhóm tài liệu nào mà bài báo được thêm vào Bài báo được gửi cùng yêu cầu Ngược lại, một thao tác put mang tài liệu và tên tới server được yêu cầu lưu trữ tài liệu

- Thao tác delete: được dùng để yêu cầu server xóa tài liệu mà tên được gửi cùng thông điệp tới server

1.3.2 Simple Object Access Protocol (SOAP )

SOAP là chuẩn cho liên lạc với các dịch vụ Web SOAP có 2 kiểu tương tác:

- Conversational exchange style: hai bên cơ bản trao đổi tài liệu có cấu trúc Ví

dụ, như một tài liệu có đơn đặt hàng hoàn chỉnh là cái điền vào khi đặt vé máy bay điện tử Các hồi đáp tới đơn đặt hàng có thể là tài liệu xác nhận có chứa số thứ tự, thông tin chuyến bay, chỗ ngồi và có lẽ cả mã vạch để quét khi lên máy bay

- RPC-style exchange: dùng để triệu gọi dịch vụ Web Trong trường hợp này, thông điệp SOAP sẽ xác định rõ các thủ tục được gọi và cung cấp danh sách các giá trị tham số đầu vào để gọi Vì vậy, hồi đáp sẽ là thông điệp chính thức có chứa hồi đáp cho lời gọi

Cách thức truy cập tài liệu thường được thể hiện qua tên của lược đồ mà là một phần của URL như: http, ftp hoặc telnet Vị trí tài liệu được nhúng vào trong URL bằng tên DNS của server mà yêu cầu truy cập được gửi đến, mặc dù một địa chỉ IP cũng có thể được sử dụng Số cổng mà server sẽ nghe yêu cầu cũng là một phần của URL Cấu trúc của một URL:

Hình 1.8 Cấu trúc thường sử dụng của URL (a) sử dụng chỉ tên DNS (b) Kết hợp tên DNS với số cổng (c) Kết hợp địa chỉ IP với số cổng

Việc phân giải URL trong hình 1.8 khá đơn giản Nếu server được tham chiếu bằng tên DNS, tên sẽ cần được phân giải tới địa chỉ IP của server Sử dụng số cổng chứa trong URL, Client có thể liên lạc với server sử dụng giao thức có tên của lược đồ, và chuyển cho nó tên tài liệu được định dạng là phần cuối cùng của URL

- Uniform Resource Name (URN): là một cơ chế định danh chung cho toàn thế giới, độc lập vị trí và liên tục tham chiếu tới tài liệu

Data:text/plain;charset=iso-8859-7,%e1%e2%e3

- Web được xem như hệ thống chủ yếu là đọc Cập nhật chỉ làm bởi một người hoặc một tổ chức nên không có sự xung đột

Tuy nhiên, mọi thứ đang thay đổi Ví dụ, có một nhu cầu ngày càng tăng về cung cấp

hỗ trợ cho các tác giả cộng tác của các tài liệu Web Nói cách khác, Web sẽ cung cấp

hỗ trợ cho các bản cập nhật đồng thời của tài liệu bởi một nhóm người dùng hoặc tiến trình cộng tác Tương tự như vậy, với giới thiệu của các dịch vụ Web, chúng ta thấy một nhu cầu phải đồng bộ

Quản lý phân tán của tài liệu Web thực hiện thông qua giao thức riêng WebDAV (Web Distributed Authoring and Versioning ) WebDAV cung cấp các cách thức để khóa tài liệu đã chia sẻ, và tạo, xóa, copy và di chuyển tài liệu từ các Web server từ xa

Để đồng bộ truy cập đồng thời tới tài liệu chia sẻ, WebDAV hỗ trợ kỹ thuật khóa đơn giản Có 2 cơ chế ghi khóa:

- Khóa ghi riêng được gán tới Client đơn và sẽ ngăn chặn bất kỳ Client nào muốn sửa đổi các tài liệu chia sẻ trong khi nó đang bị khóa

- Khóa ghi chia sẻ: cho phép các Client đồng thời cập nhật tài liệu Vì khóa diễn

ra ở độ chi tiết của toàn bộ tài liệu, khóa ghi chia sẻ thuận tiện khi các Client cập nhật các phần khác nhau của cùng tài liệu Tuy nhiên, các Client cần chú ý tới xung đột xảy ra

Đăng ký khóa được thực hiện thông qua việc chuyển quyền lấy khóa (Key token) tới Client đang yêu cầu Server ghi vào Client hiện tại đang có quyền lấy khóa Khi Client muốn chỉnh sửa tài liệu, Client gửi một yêu cầu HTTP post tới server với yêu cầu lấy