Tiểu Luận Hệ Phân Tán Dựa Trên Nền Tảng Web
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1020.86 KB, 25 trang )
Distributed web-based systems
Tr-ờng đại học CÔNG NGHệ hà nội
H PHN TN DA TRấN NN TNG
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
: NGUYN TH KIU ANH
Lớp
: Cao học K17
Hà Nội 1/2011
1/24/2011
2
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
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
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.
1/24/2011
4
I. Hệ phân tán dựa trên nền tảng Web
1.1. Kiểu kiến trúc
Về cơ bản, kiến trúc của các hệ phân tán dựa trên Web không khác nhiều so với
các hệ phân tán khác.
1.1.1. Kiến trúc truyền thống
Nhiều hệ thống dựa trên Web vẫn được tổ chức tương tự như các kiểu kiến trúc
client-server đơn giản. Lõi của Web site được định dạng bởi một tiến trình có quyền
truy cập tới một hệ thống file địa phương lưu trữ các tài liệu. Cách đơn giản nhất để
tham chiếu tới một tài liệu là URL (Uniform Resource Locator). URL vừa chứa thông
tin vị trí tài liệu vừa chứa thông tin về giao thức tầng ứng dụng sử dụng để truyền tài
liệu trên mạng.
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.
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
(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/24/2011
6
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ụ,…
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
-
Liên lạc giữa Client và Server thông qua giao thức SOAP (Simple Object
Access Protocol).
1.2. Các tiến trình
Tại phần này, ta đi nghiên cứu các tiến trình trong hệ phân tán dựa trên Web.
1.2.1. Client
Web Client quan trọng nhất là một phần của phần mềm gọi là Web Browser cho phép
người dùng điều hướng các trang Web bằng cách lấy các trang Web từ server và sau
đó 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
1/24/2011
8
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.
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
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ụ,
1/24/2011
10
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 roundNguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
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:
Thao tác
Mô tả
Head
Yêu cầu trả về header của tài liệu
Get
Yêu cầu trả về tài liệu tới Client
Put
Yêu cầu lưu trữ tài liệu
Post
Cung cấp dữ liệu được thêm vào tài liệu
Delete
Yêu cầu xóa tài liệu
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.
1/24/2011
12
-
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.
1.4. Naming
Web sử dụng một hệ thống đặt tên duy nhất để tham chiếu tới các tài liệu. Tên sử dụng
được gọi là Uniform Resource Identifier hay đơn giản chỉ là URIs. URI có 2 dạng:
-
Uniform Resource Locator (URL): là một URI nhận dạng một tài liệu bằng
cách bao gồm thông tin về cách thức và nơi truy cập tài liệu. Nói cách khác,
URL là một tham chiếu phụ thuộc vào vị trí tới tài liệu.
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:
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
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.
Name
User for
Example
http
HTTP
:80/globe
mailto
mailto:
ftp
FTP
/>
file
Local file
file:/edu/book/work/chp/11/11
data
Inline data
Data:text/plain;charset=iso-88597,%e1%e2%e3
telnet
Remote login
telnet://flits.cs.vu.nl
tel
Telephone
Tel:+31201234567
modem
Modem
Modem:+31201234567;type=v32
1/24/2011
14
Hình 1.9. Ví dụ về URL
URI http được sử dụng để chuyển tài liệu bằng cách dùng HTTP, URI ftp sử
dụng để chuyển tệp tin bằng cách dùng FTP.
1.5. Đồng bộ
Đối với hệ thống Web truyền thống, đồng bộ không phải là vấn đề đáng quan tâm vì 2
nguyên nhân sau:
-
Cơ chế tổ chức Client-Server trong đó các server không bao giờ trao đổi thông
tin với các server khác (hoặc giữa các Client với các Client khác) nên không
cần đồng bộ.
-
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
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
khóa. Quyền mà chỉ ra Client được truy cập ghi tới tài liệu là lý do server thực hiện
yêu cầu.
Vấn đề thiết kế quan trọng là không cần thiết phải duy trì kết nối giữa Client và Server
trong khi giữ khóa. Các Client có thể chỉ đơn giản ngắt kết nối tới server sau khi có
khóa và kết nối với server khi gửi một yêu cầu HTTP.
Chú ý là khi một Client nắm giữ khóa gặp sự cố, server sẽ cách này hoặc cách khác để
phục hồi lại. WebDAV không chỉ định cách thức server xử lý tình huống tương tự
nhưng được mở ra cho các bổ sung đặc biệt.
1.6. Nhất quán và bản sao
Có lẽ một trong các vấn đề quan trọng của hệ phân tán dựa trên Web là đảm bảo truy
cập tới tài liệu Web có hiệu năng và tính sẵn sàng. Các yêu cầu này dẫn đến nhiều đề
xuất cho cache và sao lặp nội dung Web.
1.6.1. Web proxy catching
Việc caching Client-Server thường diễn ra ở 2 nơi:
-
Nơi đầu tiên, hầu hết các trình duyệt được trang bị bộ nhớ đệm đơn giản. Khi
một tài liệu được lấy, nó được lưu trữ trong bộ nhớ cache của trình duyệt từ nơi
nó được tải trong lần tới. Client có thể cấu hình cache bằng cách chỉ ra nơi kiểm
tra tính nhất quán nên diễn ra.
-
Trang web của Client chạy một Web proxy. Web proxy chấp nhận các yêu cầu
từ Client địa phương và chuyển tới Web server. Khi một hồi đáp đến, kết quả
được chuyển tới Client. Lợi thế của cách tiếp cận này là proxy có thể cache kết
quả và trả kết quả tới cho Client khác nếu cần thiết. Nói cách khác, Web proxy
có thể thực thi cache chia sẻ.
1/24/2011
16
Hình 1.10. Nguyên tắc của caching có tính cộng tác
Trong caching cộng tác hoặc caching phân tán, khi nào một cache xảy ra tại Web
proxy, đầu tiên proxy kiểm tra số proxy lân cận để xem trong số đó có chứa tài liệu
được yêu cầu không. Nếu không, các proxy chuểyn tiếp yêu cầu tới Web server chịu
trách nhiệm về tài liệu.
Các giao thức nhất quán cache khác nhau đã được triển khai trong Web. Để đảm bảo
rằng một tài liệu được lấy về từ cache là nhất quán, đầu tiên các Web proxy gửi yêu
cầu HTTP get có điều kiện với phần thêm vào yêu cầu If-Modifier-Since, quy định cụ
thể thời gian sửa đổi cuối cùng được gán với tài liệu lưu trữ. Chỉ khi tài liệu được thay
đổi từ thời điểm trước, server sẽ trả lại toàn bộ tài liệu. Nếu không, Web proxy có thể
trả về phiên bản cache tới Client địa phương đang yêu cầu.
1.6.2. Bản sao cho Web Hosting Systems
Vì tầm quan trọng của Web trong việc trực tiếp tương tác với người dùng cuối, chúng
ta thấy có sự thay đổi giữa việc duy trì nội dung trang Web và đảm bảo trang Web
được truy cập dễ dàng và liên tục. Điều này dẫn đến mạng cung cấp nội dung (Content
delivery networks – CDNs). Ý tưởng là các CDN hoạt động nhưu một dịch vụ lưu trữ
Web, cung cấp một cơ sở hạ tầng để phân tán và nhân bản tài liệu Web của nhiều trang
Web trên Internet.
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
Hình 1.11. Tổ chức chung của một CDN như hệ thống kiểm soát phản hồi
Có 3 kiểu khía cạnh khác nhau liên quan tới nhân bản trong Web hosting system:
-
ước lượng độ đo: Một khía cạnh thú vị của CONs là chúng cần thực hiện sự
thỏa hiệp giữa các khía cạnh khi nói đến lưu trữ nội dung nhân bản. Ví dụ, truy
cập nhiều lần tới một tài liệu có thể được tối ưu nếu một tài liệu được nhân
rộng, nhưng đồng thời phải gánh chịu chi phí tài chính cũng như chi phí về
băng thông sử dụng để phổ biến thông tin cập nhật. Nhìn chung, có nhiều đề
nghị cho ước lượng cách thức tốt để CON thực thi. Các đề nghị này được nhóm
thành một vài lớp:
+ Latency metrics (số liệu độ trễ): thời gian được đo cho một hành
động, ví dụ: lấy tài liệu. Ước lượng độ trễ trở nên khó khăn, ví dụ
một tiến trình quyết định trên vị trí của các bản sao cần biết độ trễ
giữa Client và server từ xa. Vì vậy thuật toán các nút định vị toàn cầu
được triển khai.
+ Spactial metrics (độ đo không gian).
+ Network usage metrics (Độ đo sử dụng mạng)
-
Điều chỉnh hệ thống: một mô hình đơn giản là định kỳ ước lượng độ đo rồi sau
đó điều chỉnh khi cần thiết. Phương pháp này thường được sử dụng trong thực
tế. Nhược điểm của điều chỉnh định kỳ là sự thay đổi đột ngột có thể bị bỏ qua:
flash crowd (sự tăng vọt yêu cầu một tài nguyên nào đó). Vì vậy cần sử dụng
thuật toán dự đoán sự cố để có những lựa chọn điều chỉnh hệ thống thích hợp.
1/24/2011
18
-
Biện pháp điều chỉnh: chỉ có 3 biện pháp dẫn đến sự thay đổi cách cư xử của
Web hosting service:
+ Thay đổi nơi đặt bản sao.
+ Thay đổi thực thi nhất quán.
+ Quyết định cách thức và thời điểm chuyển các yêu cầu Client.
Xem xét cách giải quyết tính nhất quán và nhân bản trong thực tế qua Akamai.
Ý tưởng cơ bản là mỗi tài liệu Web bao gồm một trang HTML (hoặc XML) chính
trong đó một số tài liệu như hình ảnh, video và âm thanh được nhúng. Để hiển thị toàn
bộ tài liệu, cần thiết trình duyệt của người dùng phải lấy được tài liệu nhúng. Giả thiết
là các tài liệu nhúng hiếm khi thay đổi.
Mỗi tài liệu nhúng thường được tham chiếu thông qua URL. Tuy nhiên, trong CON
của Akamai, URL được sửa đổi như nó đề cập tới virtual ghost, là tham chiếu tới
server thực tế trong CON này.
Hình 1.12. Nguyên tắc hoạt động trong CDN Akamai
Tên của các virtual ghost bao gồm tên ONS như ghosting.com mà được phân giải bởi
hệ thông tên ONS tới một server CON DNS (kết quả của bước 3). Mỗi server ONS
như vậy theo dõi các server gần với Client. Trong thực tế, các server CON OST
chuyển hướng các Client tới server bản sao tốt nhất cho Client (bước 4) mà có thể là
gần nhất hoặc tải ít nhất hoặc sự kết hợp của một vài độ đo như vậy.
Cuối cùng, Client chuyển tiếp yêu cầu tài liệu nhúng tới máy chủ CDN đã chọn. Nếu
server chưa có tài liệu, nó sẽ lấy từ dịch vụ Web gốc (bước 6), cache địa phương và
sau đó chuyển tới Client. Nếu tài liệu đã có trong bộ nhớ cache của CDN, nó có thể
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
được trả lại ngay lập tức. Lưu ý rằng để lấy các tài liệu được nhúng, các server bản sao
phải gửi yêu cầu đến server gốc, đó là lý do tên host có trong URL của các tài liệu
nhúng.
Rõ ràng, bất cứ khi nào một tài liệu chính thay đổi, Client sẽ luôn có thể lấy nó từ
server gốc. Một URL cho tài liệu nhúng không chỉ đề cập đến tên server lưu trữ mà
dẫn đến một server CDN DNS mà còn chứa một định danh duy nhất thay đổi tên của
tài liệu nhúng. Trong thực tế, định danh này thay đổi tên các tài liệu nhúng. Hệ quả,
khi Client chuyển đến một server CDN cụ thể, server không tìm thấy tài liệu có tên
trong cache và do đó nó phải lấy từ server gốc. Các tài liệu cũ cuối cùng sẽ bị xóa khỏi
cache.
1.6.3. Bản sao cho Web Application
Đến thời điểm này, chúng ta mới chỉ tập trung vào caching và nhân bản cho nội dung
Web tĩnh. Thực tế, trang Web ngày càng nhiều nội dung động và mở rộng về hướng
cung cấp dịch vụ có thể gọi bởi ứng dụng từ xa.
Hình 1.13. Thay thế khác cho caching và nhân bản ứng dụng Web
Khi xem xét cải thiện hiệu suất của ứng dụng Web qua caching và nhân bản, có thể
triển khai một số giải pháp. Xem xét hình 1.13. Trong trường hợp này, giả định một
CDN mà mỗi trang host có server gốc hoạt động như trang có thẩm quyền cho tất cả
các thao tác đọc và ghi. Một Edge-server được dùng để xử lý các yêu cầu của Client
và có khả năng lưu trữ một phần thông cungx được giữ tại origin server.
Trong kiến trúc edge-server, các Client Web yêu cầu dữ liệu qua edge-server, trong đó,
lần lượt nhận thông tin từ server gốc có liên quan với các trang Web cụ thể được gọi
1/24/2011
20
của Client. Trong hình 1.13, giả sử rằng origin-server bao gồm cơ sở dữ liệu để từ đó
các hồi đáp được tự động tạo ra.
Các cách giải quyết khác:
- Full replication (nhân bản đầy đủ): tỷ lệ đọc/ghi cao, thường cùng với các truy
vấn phức tạp
- Partial Replication (nhân bản một phần): tỷ lệ đọc/ghi cao, nhưng cùng với các
truy vấn đơn giản.
- Content-aware caching: kiểm tra các truy vấn tại cơ sở dữ liệu địa phương và
làm việc với các truy vấn vùng và truy vấn phức tạp.
- Content-blind caching: đơn giản chỉ cần cache kết quả của các truy vấn trước.
Làm việc với các truy vấn đơn giản mà định địa chỉ các kết quả duy nhất.
1.7. Fault Tolerance (Khả năng chịu lỗi)
Khả năng chịu lỗi của hệ phân tán dựa trên Web cũng chủ yếu đạt được qua caching
client – server và nhân bản server. Không có phương thức đặc biệt được kết hợp, ví dụ,
HTTP để hỗ trợ khả năng chịu lỗi hoặc phục hồi. Trong hệ thống dựa trên Web truyền
thống, việc chịu lỗi khá dễ dàng đạt được bằng cách xem xét thiết kế không trạng thái
của server cùng với tính chất tĩnh của nội dung cung cấp.
Các vấn đề cần được xử lý:
-
Các Client của dịch vụ BFT (Byzantine Fault Tolerance) có thể nhìn dịch vụ
như dịch vụ Web khác. Điều này nghĩa là sự sao chép nội bộ của dịch vụ phải
được ẩn với Client, cùng với sự xử lý thích hợp cho các hồi đáp.
-
Một dịch vụ phải đảm bảo tính nhất quán khi hoạt động như một Client.
-
Giao thức chống lỗi phải coi dịch vụ được cung cấp như một thực thể.
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
II. Xây dựng Webservice phục vụ cho việc làm các ứng dụng trắc nghiệm
2.1. Giới thiệu ứng dụng trắc nghiệm:
Nhóm chúng tôi đã áp dụng các kiến thức về Webservice để xây dựng một
Webservice ứng dụng để xây dựng việc làm các bài trắc nghiệm và chấm kết
quả.
2.2. Cơ sở dữ liệu: SQL server 2008
ChuDe
KetQua
Column Name
Data Type
Column Name
Allow Nulls
Data Type
Id
numeric(18, 0)
Id
numeric(18, 0)
Ma
nvarchar(100)
Ma
nvarchar(100)
ThuTu
int
IdCha
numeric(18, 0)
Ten
nvarchar(200)
Ten
nvarchar(200)
NoiDung
ntext
NoiDung
ntext
IdCauHoi
numeric(18, 0)
ThoiGian
nvarchar(50)
TrangThai
bit
IdCauTraLoi
numeric(18, 0)
MucDiemCaoNhat
numeric(18, 2)
MucDiemThapNhat
numeric(18, 2)
Allow Nulls
CacKetQua
Column Name
Data Type
Allow Nulls
CauHoi
Id
numeric(18, 0)
Ma
nvarchar(100)
Id
numeric(18, 0)
ThuTu
int
Ma
nvarchar(100)
TenNguoiTraLoi
nvarchar(200)
ThuTu
int
IdCauHoi
numeric(18, 0)
Ten
nvarchar(200)
IdKetQua
numeric(18, 0)
NoiDung
ntext
Ngay
datetime
IdChuDe
numeric(18, 0)
Column Name
CauTraLoi
Column Name
Data Type
Id
numeric(18, 0)
Ma
nvarchar(100)
ThuTu
int
Ten
nvarchar(200)
NoiDung
ntext
SoDiem
numeric(18, 2)
IdCauHoi
numeric(18, 0)
TrangThai
bit
1/24/2011
Allow Nulls
Data Type
Allow Nulls
22
2.3 Mô hình:
Các Client:
- Tự nhập danh sách câu hỏi, trả
lời
- Cho phép người dùng làm bài
trắc nghiệm.
- Hiển thị kết quả bài trắc
nghiệm
Webservice:TracNghiem
Nhiệm vụ:
- Nhận Request từ các Client
- Gửi Requet đến CSDL
- Nhận kết quả trả về từ CSDL
- Trả kết quả cho các Client
2.4. Hình ảnh webservice
Dưới đây là hình ảnh Webservice trắc nghiệm đã xây dựng:
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Cơ sở dữ liệu:
- Kho câu hỏi và đáp án trắc
nghiệm
- Lưu trữ dữ liệu.
- Trả kết quả truy vấn cho
Service
- Nhận các lệnh truy xuất, tìm
kiếm, sửa đổi của Service
Distributed web-based systems
Các API đã xây dựng:
a. Nhóm API cơ bản:
Nhóm này bao gồm các API sử dụng để gọi các thao tác cơ bản đến cơ sở
dữ liệu bao gồm các API : Thêm, sửa, xóa,tìm kiếm tương ứng với 5 bảng
dữ liệu:
-
KetQuaBaiTracNghiem
-
SuaCacKetQua
-
SuaCauHoi
-
SuaCauTraLoi
-
SuaChuDe
-
SuaKetQua
-
ThemCacKetQua
-
ThemCauHoi
-
ThemCauTraLoi
-
ThemChuDe
-
ThemKetQua
-
TimKiemCacKetQua
-
TimKiemCauHoi
-
TimKiemCauTraLoi
-
TimKiemChuDe
-
TimKiemKetQua
-
TongDiem
-
XoaCacKetQua
-
XoaCauHoi
-
XoaCauTraLoi
-
XoaChuDe
-
XoaKetQua
b. Nhóm các API xử lý:
Bao gồm các hàm xử lý việc trả điểm và chấm kết quả bài trắc nghiệm:
o TinhDiem(int intCauHoi): hàm này tính tổng điểm cho toàn bài trắc
nghiệm mà người dùng đã làm được.
o DanhGia(int intCauHoi, double dbDiem): hàm này trả về kết quả đánh
giá mỗi bài trắc nghiệm thông qua tổng số điểm đạt được.
1/24/2011
2
2.5. Sử dụng webservice TracNghiem
B1. Từ project Client (có thể là ứng dụng winform hoặc webform) gọi đến
service:
B2. Khai báo Webservice trong chương trình
Nguyễn Thị Kiều Anh - Nguyễn Thị Ngọc Anh Lớp K17
Distributed web-based systems
B3. Gọi đối tượng SoapClient và gọi API cần dùng:
TracNghiemSoapClient tracnghiem = new TracNghiemSoapClient();
dgrData.DataSource = tracnghiem.TimKiemChuDe();
Hình ảnh ví dụ về việc hiển thị trên giao diện của ứng dụng Client sử dụng API
TimKiemChuDe() để hiện thị tất cả các chủ đề trắc nghiệm có trong cơ sở dữ liệu
1/24/2011
