Kiến trúc và chuẩn phần mềm trên nền Web, ứng dụng xây dựng hệ thống thi trắc nghiệm

Nhận thấy đây là một lĩnh vực mới, thiết thực và có nhiều ý nghĩa đối với ngành Công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, tôi đã lựa chọn đề tài “Kiến trúc và chuẩn

MỤC LỤC

LỜI CAM ĐOAN 5

LỜI CẢM ƠN 6

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT 7

DANH MỤC CÁC BẢNG 8

DANH MỤC CÁC HÌNH 9

MỞ ĐẦU 11 U PHẦN 1 - KIẾN TRÚC VÀ CHUẨN PHẦN MỀM TRÊN NỀN WEB 12

CHƯƠNG 1 - KIẾN TRÚC PHẦN MỀM 13

1.1 Kiến trúc phần mềm 13

1.1.1 Định nghĩa kiến trúc phần mềm 13

1.1.2 Các đặc tính cơ bản của kiến trúc phần mềm 14

1.1.3 Tại sao kiến trúc phần mềm quan trọng 16

1.1.4 Kết luận về kiến trúc phần mềm 16

1.2 Kiến trúc hướng dịch vụ (SOA) 16

1.2.1 Vài nét về lịch sử SOA 17

1.2.2 SOA là gì? 17

1.2.3 Các phần tử của SOA 19

1.2.4 Mô hình khái niệm SOA 21

1.2.5 Kênh dịch vụ doanh nghiệp (ESB - Enterprise Service Bus) 22

1.2.6 Các nguyên tắc SOA 24

1.2.7 SOA và Dịch vụ Web 25

1.2.8 Tương lai cho SOA 25

1.3 Dịch vụ web (web service) 26

1.3.1 Khái niệm dịch vụ web 26

1.3.2 Các đặc tính của dịch vụ web 27

1.3.3 Vai trò của dịch vụ web 27

1.3.4 Kiến trúc của dịch vụ web 28

1.3.5 Đặc tả công nghệ dịch vụ web 29

1.3.6 An ninh dịch vụ web 31

1.3.7 Kết luận về dịch vụ web 32

1.4 REST 33

1.4.1 Tại sao gọi REpresentational State Transfer 33

1.4.2 Các chuẩn sử dụng trong REST 33

1.4.3 Các nguyên tắc REST 34

1.4.4 Các phần tử kiến trúc REST 34

1.4.5 Thiết kế và thực thi REST 35

1.5 So sánh và đánh giá dịch vụ web 37

CHƯƠNG 2 - CHUẨN PHẦN MỀM TRÊN NỀN WEB 40

2.1 Các chuẩn web là gì? 40

2.2 Tại sao sử dụng chuẩn web 41

2.3 Cách thức kiểm tra web là chuẩn 42

2.4 Công cụ cải thiện chất lượng web 45

2.5 Kết luận chuẩn web 45

PHẦN 2: ỨNG DỤNG XÂY DỰNG HỆ THỐNG THI TRẮC NGHIỆM 46

CHƯƠNG 3 - XÂY DỰNG HỆ THỐNG THI TRẮC NGHIỆM 47

3.1 Mô tả bài toán thi trắc nghiệm 47

3.2 Kiến trúc phần mềm 49

3.2.1 Giới thiệu chung 49

3.2.2 Biểu diễn kiến trúc 50

3.2.3 Mục tiêu và các ràng buộc kiến trúc 50

3.2.4 Khung nhìn ca sử dụng 51

3.2.5 Khung nhìn logic 53

3.2.6 Khung nhìn tiến trình 57

3.2.7 Khung nhìn triển khai 59

3.2.8 Khung nhìn thực thi 60

3.3 Thực hiện hệ thống 60

3.3.1 Lựa chọn công nghệ 60

3.3.2 Thiết kế chương trình 65

3.3.3 Thiết kế cơ sở dữ liệu 72

3.3.4 Thiết kế lời gọi REST 72

3.3.5 Một số hình ảnh chương trình 74

PHẦN 3: THẢO LUẬN VÀ KẾT LUẬN 77

TÀI LIỆU THAM KHẢO 80

PHỤ LỤC 01: MỘT SỐ ĐẶC TẢ CHUẨN DỊCH VỤ WEB 82

PHỤ LỤC 02: XÂY DỰNG DỊCH VỤ WEB KIỂU SOAP 97

PHỤ LỤC 03: MỘT SỐ CHUẨN WEB THÔNG DỤNG 103

LỜI CAM ĐOAN

Với mục đích học tập, nghiên cứu để nâng cao kiến thức và trình độ chuyên môn, tôi làm luận văn này một cách nghiêm túc và trung thực

Trong luận văn, tôi có sử dụng một số tài liệu tham khảo của một số tác giả Các nội dung viết có sử dụng tài liệu tham khảo đều được chỉ rõ nguồn trong ngoặc vuông Danh sách các tài liệu tham khảo được liệt kê tại mục “Tài liệu tham khảo”

Toàn bộ mã nguồn để xây dựng chương trình là do tôi tự viết Chương trình có dùng một số thư viện, công cụ để tạo lập môi trường hoặc mang tính chất tiện ích Tôi xin cam đoan và chịu trách nhiệm về sự trung thực trong luận văn tốt nghiệp Thạc sĩ của mình

Hà Nội, ngày 21 tháng 10 năm 2008

Học viên

Đỗ Đức Thảo

Trong quá trình học tập và làm luận văn, tôi cũng đã nhận được sự giúp đỡ không nhỏ từ phía gia đình, bạn bè và đồng nghiệp Tôi xin cảm ơn tất cả mọi người

Hà Nội, ngày 21 tháng 10 năm 2008

Đỗ Đức Thảo

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

1 SOA Service Oriented Architecture

Kiến trúc hướng dịch vụ

2 WSDL Web Services Description Language

Ngôn ngữ mô tả các dịch vụ web

3 SOAP Simple Object Access Protocol

Giao thức truy cập đối tượng đơn giản

4 UDDI Universal Description, Discovery and Integration

Tích hợp, khám phá, mô tả chung

Ngôn ngữ đánh dấu mở rộng

6 REST REpresentational State Transfer

Chuyển giao trạng thái biểu diễn (một kiểu kiến trúc trên web)

7 HTTP Hypertext Transfer Protocol

Giao thức truyền siêu văn bản

8 WOA Web Oriented Architecture

Kiến trúc hướng web

9 RFC Request for Comment

Dạng chuẩn của Internet Engineering Task Force

10 STD Internet standard

Chuẩn internet của Internet Engineering Task Force

11 XHTML Extensible Hypertext Markup Language

Ngôn ngữ đánh dấu siêu văn bản mở rộng

12 SVG Scalable Vector Graphics

Các đồ hoạ vec tơ có thể co dãn

13 CSS Cascading Style Sheets

Các bảng định kiểu thác nước (thường dùng cho HTML, XHTML)

14 CNTT Công nghệ thông tin

DANH MỤC CÁC BẢNG

Bảng 1 - Các phần tử kiến trúc REST 34

Bảng 2 - So sánh dịch vụ web SOAP và REST 38

Bảng 3 - Bảng danh sách các định nghĩa kiểu tài liệu web 43

Bảng 4 - Bảng cấu trúc các project Hệ thống thi trắc nghiệm 65

Bảng 5 - Bảng thiết kế lời gọi REST 74

Bảng 6 - Bảng tổng hợp ánh xạ từ UDDI/WSDL 92

DANH MỤC CÁC HÌNH

Hình 1 - Mô hình 4+1 khung nhìn 15

Hình 2 - Sơ đồ khối định nghĩa SOA 18

Hình 3 - Ví dụ một hệ thống SOA 18

Hình 4 - Mô tả dịch vụ 20

Hình 5 - Mô hình khái niệm cơ bản SOA 21

Hình 6 - Mô hình đầy đủ SOA, thể hiện vai trò của kênh dịch vụ 21

Hình 7 - Bên trong ESB 24

Hình 8 - Giải pháp SOA cơ sở 28

Hình 9 - Sơ đồ kiến trúc tổng thể dịch vụ web 29

Hình 10 - Sơ đồ đặc tả dịch vụ web 30

Hình 11 - Kiến trúc WS-Security 31

Hình 12 - Mô hình WS-Security 31

Hình 13 - Thiết kế kiến trúc mức cao REST 36

Hình 14 - Phân giải URL tới các chức năng 36

Hình 15 - So sánh và đánh giá SOA 38

Hình 16 - Hình ảnh kiểm tra web site IBM 44

Hình 17 - Hình ảnh kiểm tra web site EVN 44

Hình 18 - Tổng quan về Hệ thống thi trắc nghiệm 50

Hình 19 - Khung nhìn ca sử dụng 51

Hình 20 - Kiến trúc tổng thể 53

Hình 21 - Lớp trình diễn 54

Hình 22 - Lớp trình diễn - Ngân hàng câu hỏi 54

Hình 23 - Lớp trình diễn - Lập đề thi 54

Hình 24 - Lớp trình diễn - Quản lý thí sinh 55

Hình 25 - Lớp trình diễn - Làm bài thi 55

Hình 26 - Lớp ứng dụng 55

Hình 27 - Lớp dịch vụ - Ngân hàng câu hỏi 56

Hình 28 - Lớp dịch vụ - Quản lý thi 57

Hình 29 - Mô hình hoạt động tổng thể của hệ thống thi trắc nghiệm 58

Hình 30 - Mô hình triển khai hệ thống thi trắc nghiệm 59

Hình 31 - Mô hình mạng áp dụng thực tế tại một Đơn vị 59

Hình 32 - Khung nhìn thực thi 60

Hình 33 - Kiến trúc DotNetNuke 62

Hình 34 - Mô hình DataProvider 62

Hình 35 - Mô hình CBO Hydrator để Fill Object/Collection 63

Hình 36 - Mô hình hoạt động mô đun 63

Hình 37 - Màn hình DotNetNuke khi xem 64

Hình 38 - Màn hình DotNetNuke khi thiết kế 64

Hình 39 - Giao diện chính quản lý ngân hàng câu hỏi 74

Hình 40 - Giao diện thêm/sửa nhóm 75

Hình 41 - Giao diện thêm/sửa câu hỏi 75

Hình 42 - Giao diện tự kiểm tra trắc nghiệm 76

Hình 43 - Màn hình dịch vụ web nhận được yêu cầu kiểu REST 76

Hình 44 - Cấu trúc ngữ nghĩa của WSDL 1.1 85

Hình 45 - Mô hình cấu trúc biểu diễn quan hệ giữa các phần tử, theo 85

Hình 46 - Cấu trúc ngữ nghĩa của WSDL 2.0 89

Hình 47 - Cấu trúc message SOAP 94

Hình 48 - Mô hình kiến trúc dịch vụ web StockTrader 97

Hình 49 - UML class diagram cho StockTraderTypes definition assembly 99

MỞ ĐẦU

Cùng với sự phát triển mạnh mẽ của CNTT, có rất nhiều các công nghệ mới ra đời làm thay đổi thế giới Một trong số đó là các công nghệ về web với kiến trúc hướng dịch vụ (SOA) Rất nhiều bài báo, Công ty lớn trên thế giới đã viết và tham tra trực tiếp vào lĩnh vực này Nhận thấy đây là một lĩnh vực mới, thiết thực và có nhiều ý nghĩa đối với ngành Công nghệ thông tin nói chung và công nghệ phần mềm nói riêng,

tôi đã lựa chọn đề tài “Kiến trúc và chuẩn phần mềm trên nền web, ứng dụng xây dựng

Hệ thống thi trắc nghiệm” làm đề tài luận văn Thạc sĩ

Nội dung của luận văn gồm các phần:

• Phần 1: Kiến trúc và chuẩn phần mềm trên nền web Gồm các chương:

- Chương 1: Kiến trúc phần mềm Đề cập về lý thuyết kiến trúc phần mềm, kiến

trúc hướng dịch vụ và dịch vụ web, kiểu kiến trúc REST

- Chương 2: Chuẩn phần mềm trên nền web Trình bày khái niệm về chuẩn web,

lý do cần chuẩn web, cùng các nguyên tắc để kiểm tra chuẩn web

• Phần 2: Ứng dụng xây dựng hệ thống thi trắc nghiệm Gồm:

- Chương 3: Xây dựng hệ thống thi trắc nghiệm Đề cập ứng dụng thực tế trên cơ

sở lý thuyết để xây dựng hệ thống thi trắc nghiệm Hệ thống thi trắc nghiệm là

hệ thống phần mềm truyền thống, đã có rất nhiều ứng dụng thương mại lẫn mã nguồn mở (open source) Tuy nhiên, tôi muốn tiếp cận xây dựng hệ thống theo hướng mới dựa trên nền tảng SOA Qua đó, sẽ có nhiều ý tưởng và lợi ích mới

mẻ được khám phá dựa trên sức mạnh của SOA

• Phần 3: Thảo luận và Kết luận Kết luận về kết quả đã đạt được

Hà Nội, ngày 21 tháng 10 năm 2008

Đỗ Đức Thảo

PHẦN 1 - KIẾN TRÚC VÀ CHUẨN PHẦN MỀM TRÊN NỀN WEB

CHƯƠNG 1 - KIẾN TRÚC PHẦN MỀM 1.1 Kiến trúc phần mềm

Hệ thống phần mềm ngày một lớn và phức tạp Điều này trở nên nhiều khó khăn đối với các nhà phát triển phần mềm trong việc đảm bảo chất lượng, kiểm soát các thay đổi, bảo trì phần mềm Để giải quyết hiệu quả vấn đề này, hệ thống phần mềm cần có một kiến trúc tốt, đủ để cho phần mềm có thể đứng vững trước các thay đổi, bổ sung liên tục mà vẫn giảm thiểu được các chi phí Đây là mục đầu tiên, mang tính chất khái niệm, trước khi đi vào một số kiến trúc cụ thể như SOA, REST trong các mục sau Trong mục này cũng sẽ trình bày một số vấn đề về kiến trúc phần mềm, giúp người phát triển phần mềm hoặc kiến trúc sư phần mềm có thể hiểu rõ và áp dụng cho công việc của mình

Định nghĩa thứ hai của L Bass, P Clements, R Kazman [2]: Kiến trúc phần mềm của một chương trình hoăc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống, nó bao gồm các phần tử phần mềm, các thuộc tính nhìn thấy bên ngoài của các phần tử đó, và các mối quan hệ giữa chúng Định nghĩa này có phần gần giống như

định nghĩa của ANSI/IEEE

Định nghĩa thứ ba của D Garlan, M Shaw [6]: Kiến trúc phần mềm vượt ra ngoài các giải thuật và các cấu trúc dữ liệu tính toán; việc thiết kế và xác định ra cấu trúc toàn bộ hệ thống trở nên như một dạng vấn đề mới Các đề xuất cấu trúc bao gồm tổ chức toàn bộ và cấu trúc điều khiển toàn cục; các giao thức truyền thông, đồng bộ hoá, và truy nhập dữ liệu; gán chức năng cho các phần tử thiết kế; phân tán về vật lý;

sự kết hợp của các phần tử thiết kế; mở rộng và hiệu năng; và sự lựa chọn giữa các cách thiết kế

Phân tích các định nghĩa, chúng ta có thể rút ra được một số đặc tính cơ bản của các kiến trúc phần mềm Trong phần tiếp theo sẽ mô tả một số cách tiếp cận chính để hiểu rõ hơn về kiến trúc phần mềm

1.1.2 Các đặc tính cơ bản của kiến trúc phần mềm

Từ các định nghĩa về kiến trúc, chúng ta sẽ rút ra một số đặc tính cốt lõi của kiến trúc phần mềm như sau:

1.1.2.1 Kiến trúc định nghĩa cấu trúc

Đa số các nhà kiến trúc sư đều đầu tư nhiều thời gian và công sức vào việc phân rã

hệ thống ứng dụng thành các thành phần có quan hệ, các mô đun, ứng dụng Trong khi

đó, một hệ thống ứng dụng có rất nhiều các yêu cầu và ràng buộc cần đáp ứng Vì vậy, kiến trúc phần mềm đầu tiên là đưa ra được cấu trúc của hệ thống gồm các thành phần nào để đáp ứng được tất cả các yêu cầu và ràng buộc đó một cách tốt nhất Trong quá trình phân rã một ứng dụng, kiến trúc sư gán các trách nhiệm cho mỗi thành phần Các tránh nhiệm này định nghĩa tác vụ mà thành phần đó đảm nhận trong ứng dụng [7]

1.1.2.2 Kiến trúc xác định truyền thông giữa các thành phần

Hệ thống phần mềm được phân rã thành các thành phần Việc liên kết giữa các thành phần tạo nên những hoạt động của hệ thống Vì vậy, kiến trúc cần xác định truyền thông giữa các thành phần này thông qua việc trao đổi dữ liệu, các thông tin điều khiển Các thành phần này có thể được thực hiện trong cùng một không gian địa chỉ, trên các luồng hoặc tiến trình khác nhau Hoặc nhiều thành phần có thể đồng thời được báo hiệu khi có một sự kiện nào đó xẩy ra [7]

1.1.2.3 Kiến trúc đề cập các yêu cầu phi chức năng

Các yêu cầu phi chức năng không xuất hiện trong các ca sử dụng (Use-case) Nó được phân loại thành các dạng:

• Các ràng buộc kỹ thuật: chúng ràng buộc các lựa chọn thiết kế hoặc công nghệ cần phải sử dụng Ví dụ, “chúng ta chỉ có các lập trình viên Java, vì vậy chúng ta phải phát triển trên Java”

• Các ràng buộc nghiệp vụ: là các ràng buộc phi kỹ thuật, gắn với các công tác nghiệp vụ

• Các thuộc tính chất lượng: định nghĩa các ràng buộc ứng dụng về tính mềm dẻo, dễ

mở rộng, dễ thay đổi, tái sử dụng, hiệu năng, vân vân

Các yêu cầu này này cần phải được đề cập một cách rõ ràng trong thiết kế Ngoài các yêu cầu chức năng, các nhà kiến trúc sư thì cũng đều phải tính tới tất cả các yêu cầu phi chức năng [7]

1.1.2.4 Kiến trúc là sự trừu tượng hoá

Bằng cách tạo dựng lên các thành phần, quan hệ giữa các thành phần, bản thân kiến trúc chính là sự trừu tượng hoá cho ứng dụng sẽ xây dựng Nó là phương tiện dễ đọc,

dễ hiểu và dễ trao đổi nhất giữa đội dự án, với cả các nhà tài trợ dự án [7]

Hình 1 - Mô hình 4+1 khung nhìn

Bao gồm:

• Khung nhìn logic (Logical View): mô tả các phần tử kiến trúc quan trọng và mối

quan hệ giữa chúng Nó đưa ra cấu trúc ứng dụng bằng các sơ đồ dạng Class Diagram hoặc tương đương

• Khung nhìn tiến trình (Process View): Tập trung mô tả các phần tử truyền thông

và tương tranh của một kiến trúc

• Khung nhìn vật lý/triển khai (Physical View/Deployment View): nó mô tả làm

thế nào các tiến trình và thành phần được ánh xạ với hệ thống phần cứng Ví dụ như các cơ sở dữ liệu, máy chủ web được đưa vào một số các máy chủ

• Khung nhìn phát triển/thực thi (Development View/Implementation View): nó

tập trung vào tổ chức bên trong của các thành phần phần mềm, thông thường là chúng sẽ được đưa vào môi trường phát triển hoặc công cụ quản lý cấu hình

Mô hình hệ thống Chuyển giao, cài đặt

Truyền thông

Kỹ sư hệ thống

Các khung nhìn này được gắn với một khung nhìn trung tâm là khung nhìn ca sử

dụng (Use-case View) Đây là khung nhìn biểu diễn các chức năng của hệ thống

1.1.3 Tại sao kiến trúc phần mềm quan trọng

Các lý do khiến cho kiến trúc phần mềm trở nên quan trọng [2]:

• Trao đổi với các nhà tài trợ: kiến trúc phần mềm biểu diễn sự trừu tượng hoá

chung của hệ thống Trong khi đó, đa số các nhà tài trợ không phải tất cả đều có chung một cơ sở để có thể hiểu nhau, thương lượng, quyết tâm

• Các quyết định thiết kế sớm: kiến trúc phần mềm biểu thị các quyết định sớm về

thiết kế hệ thống Nó là bức tranh toàn cảnh về hệ thống cần xây dựng mà các bước tiếp theo cần cụ thể hoá và chi tiết các phần này

• Trừu tượng hoá của một hệ thống có thể chuyển giao: Kiến trúc phần mềm tạo

ra mô hình dễ hiểu, có tri thức, đủ nhỏ để làm thế nào một hệ thống được cấu trúc

và làm thế nào các phần tử của nó làm việc cùng với nhau Đặc biệt, nó có thể được

áp dụng sang các hệ thống khác có thuộc tính chất lượng, yêu cầu chức năng tương

tự và có thể đẩy lên tái sử dụng quy mô lớn

1.1.4 Kết luận về kiến trúc phần mềm

Kiến trúc phần mềm là một trong các yếu tố quan trọng, quyết định lớn tới toàn bộ quá trình phát triển phần mềm Qua các định nghĩa, chúng ta hiểu về tầm quan trọng của kiến trúc phần mềm Chúng hướng tới giải quyết các yêu cầu phi chức năng như khả năng sẵn sàng, dễ thay đổi, hiệu năng, an ninh, khả năng kiểm thử, khả năng sử dụng

Các mục tiếp theo sẽ trình bày về một dạng kiến trúc phần mềm tiên tiến hiện nay

và thu hút được sự quan tâm của nhiều người - Kiến trúc hướng dịch vụ, đặc biệt là trong môi trường dựa trên web và các công nghệ thực hiện

1.2 Kiến trúc hướng dịch vụ (SOA)

Kiến trúc hướng dịch vụ (SOA – Service Oriented Architecture) là một kiểu kiến trúc mà tất cả các khía cạnh của việc tạo và sử dụng các tiến trình nghiệp vụ được đóng gói như các dịch vụ Trong suốt chu trình sống của nó, cũng như việc định nghĩa

và cung cấp cơ sở hạ tầng CNTT, SOA cho phép các ứng dụng khác nhau trao đổi dữ liệu và kết nối các tiến trình nghiệp vụ một cách lỏng lẻo, không phân biệt hệ điều hành và các ngôn ngữ lập trình bên dưới các ứng dụng đó SOA biểu diễn một mô hình

mà các chức năng của nó được phân rã vào trong các đơn vị nhỏ, khác nhau, có thể được phân tán qua mạng và có thể được kết hợp lại với nhau hoặc tái sử dụng để tạo ra các ứng dụng nghiệp vụ mới Các dịch vụ này truyền thông với nhau thông qua việc truyền dữ liệu từ dịch vụ này tới dịch vụ khác, hoặc kết hợp các hoạt động bởi hai hoặc

nhiều dịch vụ Khái niệm SOA thường được xây dựng và là bước phát triển hơn của các khái niệm cũ như tính toán phân tán và lập trình mô đun

- SOA nên được đặt là ‘kiến trúc hướng giao diện’ thì đúng hơn

Trước đó cũng đã có nhiều khái niệm kiến trúc phần mềm như khách - chủ (Client – Server), gọi thủ tục từ xa (RPC), đến CORBA (Common Object Request Broker - 1991) Kiến trúc RPC hay CORBA cũng đã được hiện thực hoá bởi các công nghệ/chuẩn của Sun với RMI (trong phiên bản JDK 1.1 – 1997)/RMI-IIOP (trong phiên bản J2SE 1.3 – 2000) trên ngôn ngữ Java, hay của Microsoft với DCOM (năm 1996) Các công nghệ/chuẩn này nhìn chung còn khá phức tạp, không liên thông giữa các ngôn ngữ lập trình khác nhau

Mặc dù xuất hiện sớm, nhưng SOA thực sự được quan tâm sau đó vài năm, vào khoảng năm 2002/2003 Lúc này, công nghệ dịch vụ web (web service) đã xuất hiện

Nó cung cấp một ngôn ngữ định nghĩa giao diện mới là WSDL, rất thích hợp cho việc

sử dụng trong SOA Dịch vụ web được chấp nhận rộng rãi do có nhiều ưu điểm mạnh Một điều cần lưu ý, SOA là một kiểu kiến trúc, không phải sản phẩm và công nghệ dịch vụ web thích hợp cho SOA

1.2.2 SOA là gì?

SOA (Service Oriented Architecture) - Kiến trúc hướng Dịch vụ, theo định

nghĩa của DotNetGuru [25], là khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ

Định nghĩa khác của IBM [19]: SOA là một cách tiếp cận để xây dựng các hệ thống phân tán và thực hiện tích hợp doanh nghiệp bằng cách chuyển giao chức năng ứng dụng như các dịch vụ tới các ứng dụng người dùng cuối hoặc các dịch vụ khác

Một định nghĩa nữa có phần rõ ràng hơn về SOA [13]: Kiến trúc hướng dịch vụ (SOA) là một kiến trúc phần mềm dựa trên các khái niệm cốt lõi của đầu cuối ứng dụng (application frontend), dịch vụ (service), kho chứa dịch vụ (service repository),

và kênh dịch vụ (service bus) Một dịch vụ bao gồm một thoả ước, một hoặc nhiều giao diện, và một thực thi

Kiến trúc hướng dịch vụ (SOA)

Đầu cuối ứng dụng

(Application frontend) Dịch vụ (Service)

Kho chứa dịch vụ (Service Repository)

Kênh dịch vụ (Service Bus)

Thoả ước

(Contract)

Thực thi (Implementation)

Giao diện (Interface)

Lôgic nghiêp vụ

(Business Logic)

Dữ liệu (Data)

Hình 2 - Sơ đồ khối định nghĩa SOA

SOA biểu diễn một mô hình tiến hoá mới để xây dựng các ứng dụng phân tán Các dịch vụ là các thành phần phân tán cung cấp các giao diện được định nghĩa tốt và trao đổi thông tin bằng các thông điệp XML Cách tiếp cận dựa trên dịch vụ rất có ý nghĩa trong việc xây dựng các giải pháp vượt qua cả đường biên ranh giới công ty, phòng ban, tổ chức Một nghiệp vụ cùng với nhiều hệ thống và ứng dụng trên các nền tảng khác nhau có thể sử dụng SOA để xây dựng giải pháp tích hợp kết nối lỏng lẻo và thực hiện các luồng công việc đồng nhất

Một hình ảnh ví dụ về hệ thống sử dụng kiến trúc SOA: web site bán hàng sử dụng thương mại điện tử:

các dịch vụ Dịch vụ được hiểu một cách đơn giản như là các mô đun phần mềm để thực hiện một số chức năng nào đó, có khả năng làm việc độc lập và cung cấp các giao diện để giao tiếp với môi trường bên ngoài Trong SOA, dịch vụ được nâng lên một tầng cao hơn của một dịch vụ thông thường Đó là mỗi dịch vụ có một bản mô tả đầy

đủ về nó để các đối tượng khác có thể hiểu và sử dụng được, không phân biệt nền tảng thực thi Hệ thống được xây dựng bằng kiến trúc SOA cung cấp một tập hợp các dịch

vụ Sự phối kết của các dịch vụ sẽ tạo ra các ứng dụng mới đáp ứng cho tiến trình xử

lý nghiệp vụ Như vậy, bản thân dịch vụ trong SOA còn có ý nghĩa nữa đó là khả năng tái sử dụng

1.2.3 Các phần tử của SOA

Trong mục này sẽ định nghĩa cụ thể các phần tử của SOA [13] và mô hình để kết nối các phần tử theo các cách khác nhau của SOA (thời gian phát triển hay thời gian chạy)

1.2.3.1 Các đầu cuối ứng dụng (Application Frontends)

Các đầu cuối ứng dụng là những thành phần tích cực trong SOA Chúng khởi động

và điều khiển tất cả các hoạt động của hệ thống Có nhiều kiểu khác nhau của đầu cuối ứng dụng Nó có thể là một chương trình ứng dụng có giao diện đồ hoạ để giao tiếp trực tiếp với người dùng cuối Hoặc cũng có thể là các chương trình tự chạy mà không

có giao diện người dùng cuối nhưng gọi các chức năng định kỳ

• Giao diện (interface): Chức năng dịch vụ được bộc lộ ra bên ngoài cho các trình

khách (client) thông qua giao diện Thực thi vật lý của giao diện gồm các gốc dịch

vụ (service stub) được kết hợp vào trong các trình khách sử dụng dịch vụ

• Thực thi (imlementation): thực thi dịch vụ cung cấp một cách vật lý của dữ liệu và

lôgic nghiệp vụ Nó là một hiện thực hoá kỹ thuật để hoàn thành thoả ước dịch vụ Kết quả thực tế là các chương trình, dữ liệu cấu hình và cơ sở dữ liệu

Hình 4 - Mô tả dịch vụ

1.2.3.3 Kho chứa dịch vụ (Service Repository)

Kho chứa dịch vụ cung cấp các phương tiện để tìm kiếm dịch vụ và thu thập các thông tin sử dụng dịch vụ Đặc biệt là các dịch vụ này có thể được khám phá bên ngoài phạm vi thời gian và chức năng của dự án tạo ra chúng Mặc dù đa số thông tin đã nằm trong bản thoả ước dịch vụ, kho chứa dịch vụ còn cung cấp thêm một số thông tin về

vị trí vật lý, người cung cấp, người liên hệ, phí sử dụng, các ràng buộc kỹ thuật, các đề xuất về an ninh, các mức dịch vụ sẵn sàng

Kho chứa là phần tử hữu ích trong SOA Nhưng ta có thể xây dựng SOA với nhiều lợi ích mà không cần kho chứa SOA Một kiến trúc có thể không cần kho chứa nếu phạm vi dịch vụ chỉ cho một dự án Nhưng nếu có nhiều dự án, nhiều dịch vụ, nhiều nhóm với sự thay đổi nhân sự không biết trước thì kho chứa dịch vụ là yếu tố cần chú

ý xem xét Việc thực hiện kho chứa dịch vụ cũng có nhiều hình thức Nhưng cách tốt nhất vẫn là lưu chúng trong một cơ sở dữ liệu có định dạng cấu trúc

1.2.3.4 Kênh dịch vụ (Service bus)

Kênh dịch vụ được dùng để kết nối các thành viên là các dịch vụ và đầu cuối ứng dụng lại với nhau Các đặc tính của kênh dịch vụ:

• Tính kết nối (Connectivity): Mục đích chính của kênh dịch vụ là kết nối các thành

viên của SOA Nó cung cấp phương tiện để các thành viên của đầu cuối ứng dụng

và dịch vụ gọi chức năng của các dịch vụ

• Không đồng nhất công nghệ: kênh dịch vụ có thể mang nhiều công nghệ khác

nhau Kênh dịch vụ có thể kết nối các thành viên trên các ngôn ngữ lập trình, hệ điều hành, môi trường chạy khác nhau

• Không đồng nhất của các khái niệm truyền thông: tương tự không đồng nhất công

nghệ, kênh dịch vụ cũng mang nhiều khái niệm truyền thông khác nhau Ví dụ tối thiểu là phải có phương tiện truyền thông đồng bộ và không đồng bộ

• Các dịch vụ kỹ thuật: thông qua mục đích của kênh dịch vụ là truyền thông, nó

cũng phải cung cấp các dịch vụ kỹ thuật như ghi nhật ký, kiểm toán, an ninh, truyền thông điệp, hoặc các giao dịch

Trong phần Kênh dịch vụ doanh nghiệp (ESB – Enterprise Service Bus) sẽ thảo

luận kỹ về việc này

1.2.4 Mô hình khái niệm SOA

Mô hình kiến trúc SOA cơ bản [11] được biểu diễn bằng hình sau:

Sử dụng

dịch vụ

Cung cấp dịch vụ #1

Cung cấp dịch vụ #2

Kho chứa dịch vụ

Hình 5 - Mô hình khái niệm cơ bản SOA

Một mô hình khác thể hiện sự tham gia đầy đủ của các thành phần trong SOA [24]:

Cung cấp dịch vụ

Sử dụng dịch vụ

Kho chứa dịch vụ

Công bố

Hình 6 - Mô hình đầy đủ SOA, thể hiện vai trò của kênh dịch vụ

Trong đó, có 3 thực thể chính:

• vider): đăng tải các thông tin về dịch vụ mình cung

Lưu ý rằng, một cung cấp dịch vụ (service provider) cũng có thể trở thành một sử dụn

ể được biến đổi để đưa kênh dịc

.2.5 Kênh dịch vụ doanh nghiệp (ESB - Enterprise Service Bus)

, gắn với phầ

.2.5.1 ESB là gì?

nghĩa hình thức nào về ESB Nó thường được nhiều nhà bán hàn

.2.5.2 Cơ sở của ESB

truyền thông cho các dịch vụ trong kiến trúc hướng dịch vụ

Cung cấp dịch vụ (Service Pro

cấp lên kho chứa dịch vụ và xử lý các yêu cầu dịch vụ

Sử dụng dịch vụ (Service Consumer): truy cập thư mục

các dịch vụ cung cấp, gửi yêu cầu đến Service Provider

Kho chứa dịch vụ (Service Repository/Directories): lưu

về dịch vụ cung cấp

g dịch vụ (service consumer) để gọi tới các cung cấp dịch vụ (service provider) khác (như đối tượng cung cấp dịch vụ #1 trên hình vẽ 6)

Trường hợp sử dụng kênh dịch vụ, mô hình SOA có th

h vụ vào trung tâm truyền thông giữa các thành phần Để làm rõ hơn trường hợp sử

dụng kênh dịch vụ, thể hiện trong phần tiếp theo về Kênh dịch vụ doanh nghiệp (ESB – Enterprise Service Bus)

1

Khái niệm kênh (bus) khá quen thuộc với những người làm về máy tính

n cứng Nó được xem như là một kênh truyền tín hiệu từ bộ phận này đến bộ phận khác trong máy tính Tương tự như vậy, chúng ta cũng sẽ hiểu về ESB trong phần mềm

1

Chưa có một định

g chiếm lĩnh và định nghĩa lại để phù hợp cho bộ sản phẩm của họ Đây cũng là một khái niệm nhiều tranh cãi, cho rằng ESB là một kiểu kiến trúc, một sản phẩm phần mềm hoặc nhóm các sản phẩm phần mềm Khái niệm ESB thường liên quan đến một kiến trúc xác định, nó được sử dụng nhiều nhất để biểu diễn một cơ sở hạ tầng mà cho phép như một kiến trúc Nói một cách khác, ESB cung cấp một cơ sở hạ tầng truyền

thông phía dưới cho các thành phần phần mềm Chữ “Enterprise” trong ESB nhấn

mạnh rằng sản phẩm có các tính năng như an ninh, giao dịch, và thích hợp cho sử dụng trong doanh nghiệp phát triển lớn [26, 21].

1

ESB là trung tâm đầu não

Trong đó, ESB được thiết kế để đóng vai trò trung gian giữa các thành phần SOA, dịch vụ hạ tầng, và các tiến trình nghiệp vụ ESB có tính chất đa năng Nó có thể kết nối các kiểu phần mềm trung gian, kho chứa các định nghĩa siêu dữ liệu (như làm thế nào bạn định nghĩa một số hiệu khách hàng), sổ đăng ký (làm thế nào định vị thông

tin), và các giao diện của mỗi loại Chúng ta có thể nghĩ rằng ESB như một đường ống

để các thành phần cắm vào Trên thực tế, nó đúng hơn là một tập hợp các thành phần phần mềm

Có nhiều sản phẩm về ESB và chúng có các khả năng khác nhau Nhưng tất cả chú

khả năng của chúng mở rộn

.2.5.3 Chi tiết về ESB

ư một hộp đen - không cần biết nó làm việc như thế nào Ch

ểu thông

• vụ giao diện (interface services): có thể kiểm tra các thông điệp đối

ng đều cung cấp một “lớp trừu tường hoá” với trách nhiệm quản lý thông điệp – cho phép các thành phần phần mềm kết nối và gửi các thông điệp với nhau một cách nhất quán và hiệu quả Một vài ESB có nhiều tính năng cao hơn và làm việc cùng với nhiều loại truyền thông dữ liệu, từ e-mail đến các thông điệp SOAP Một vài cái khác thực thi việc mã hoã và cung cấp an ninh toàn diện Phát triển của ESB thêm vào nhiều khả năng, nên chúng ta có thể sử dụng trong nhiều ngữ cảnh khác nhau Chúng ta có thể tạo ra các ESB để quản lý truyền thông giữa các cơ sở dữ liệu, và các ESB để quản

lý truyền dữ liệu tới đa số các ứng dụng mà cần phải được kết nối tới vô số các nguồn

dữ liệu Trong mỗi ngữ cảnh, ESB là một trung gian đa tính năng để tạo ra nhiều kết nối giữa các tiến trình, góp phần làm việc một cách hiệu quả

Các ESB được phát triển một cách độc lập với SOA Các

g để gộp tính năng kết nối các thành phần dịch vụ web và các loại thành phần khác

Vì vậy, ta có thể có ESB mà không có SOA Nhưng ta có thể bắt đầu SOA bằng cách thực thi một ESB Cùng với các sản phẩm ESB, điều này là một khởi đầu tốt Tuy nhiên, cũng có thể xây dựng SOA mà không cần ESB, lúc này ta phải có kênh mà tất

cả các kết nối giữa các thành phần SOA thông qua các máy chủ Nên nó làm việc tốt trên quy mô nhỏ và thực thi được sớm SOA Nhưng nếu hệ thống tăng trưởng và trở nên nhiều phức tạp, thì lúc này cần có thực thi một ESB

1

ESB có thể được xem nh

úng ta nắm các dịch vụ nghiệp vụ và liên kết chúng trong kênh ESB có sự thông minh để kết nối các dịch vụ theo cách đúng đắn Thực tế, ESB thực thi một loạt các nhiệm vụ cơ sở hạ tầng thay vì phải viết trong mã của ứng dụng Để hiểu rõ về ESB, chúng ta đi vào các thành phần bộ phận của ESB ESB bao gồm các dịch vụ:

• Các dịch vụ thông điệp (messaging services): hỗ trợ đa dạng các ki

điệp, cung cấp định đường thông minh dựa trên nội dung và bảo đảm phân phối các thông điệp Chúng có thể tách và gộp các thông điệp

Các dịch vụ quản lý (managing services): có thể giám sát

trợ giúp nâng cao các thoả thuận mức dịch vụ bằng cách ghi lại và trả lời tới các trễ thông điệp Chúng có thể thực hiện các thư tự ưu tiên thông điệp và gắn các luật nghiệp vụ toàn cục thông qua tất cả các ứng dụng hoặc thành phần chúng kết nối

Các dịch

với các định nghĩa lược đồ (nơi chúng được giữ trong phiên bản của chúng của

registry) Chúng hỗ trợ các chuẩn dịch vụ web và cung cấp các bộ thích ứng (adapter) cho một vài kiểu dịch vụ hoặc giao diện không phải web

• Các dịch vụ gián tiếp (mediation services): chuyển đổi các thông điệp giữa các định dạng được dùng bởi các ứng dụng gửi nhận

• Các dịch vụ siêu dữ liệu (metadata services): các dịch vụ này có thể biến đổi dữ liệu từ định dạng này tới định dạng khác bởi sử dụng các định nghĩa siêu dữ liệu lưu giữ trong phiên bản của chúng tại kho chứa

• Các dịch vụ an ninh (security services): mã hoá các thông điệp khi cần và gộp

mô hình an ninh chuẩn hoá để định danh, chứng thực, và kiểm toán tất cả các hoạt động ESB

Tất cả các thành phần của một ESB chuẩn được biểu diễn trong hình sau [12]

Chương

trình A

Chương trình B

Các dịch vụ quản lý

Các dịch

vụ giao diện

Các dịch

vụ thông điệp

Các dịch

vụ gián tiếp

Các dịch vụ siêu dữ liệu

Các dịch vụ

an ninh Kênh dịch vụ doanh nghiệp (ESB)

Hình 7 - Bên trong ESB

Trong đó ESB có thể liên kết 2 chương trình độc lập với nhau

1.2.6 Các nguyên tắc SOA

Các nguyên tắc cơ bản của thiết kế SOA được Thomas Erl [3] đưa ra như sau:

1 Thoả ước dịch vụ (service contract): các dịch vụ gắn chặt với thoả thuận truyền

thông bằng cách định nghĩa một hoặc nhiều tài liệu mô tả về dịch vụ

2 Kết nối lỏng lẻo (losse coupling): các dịch vụ duy trì một quan hệ mà tối thiểu hoá

các phụ thuộc với các phần khác

3 Trừu tượng hoá (abstraction): chỉ một phần của dịch vụ được nhìn thấy bởi thế

giới bên ngoài thông qua giao ước dịch vụ Phần còn lại bên trong là các lôgic nghiệp vụ và dữ liệu là không nhìn thấy được

4 Tự trị (autonomy): Dịch vụ tự điều khiển bên trong đường biên ranh giới của nó

mà không phụ thuộc vào các dịch vụ khác để thực hiện quyền của nó

5 Tái sử dụng (reusability): hệ thống được phân chia thành các dịch vụ với ý định

tái sử dụng khi cần

6 Phức hợp (composability): Tập hợp các dịch vụ có thể được kết hợp và lắp ráp lại

với nhau thành các dịch vụ phức hợp

7 Phi trạng thái (statelessness): Dịch vụ có thể không cần quản lý thông tin trạng

thái vì nó cản trở khả năng kết nối lỏng lẻo đồng thời cũng làm tăng lượng tài nguyên sử dụng

8 Khám phá (Discoverability): Dịch vụ nên cho phép các mô tả của chúng được

khám phá và hiểu bởi con người và các trình yêu cầu dịch vụ cần sử dụng chúng Trong 8 nguyên tắc này, các nguyên tắc về tự trị, kết nối lỏng lẻo, trừu tượng hoá, thoả ước dịch vụ được xem là các nguyên tắc cốt lõi nền tảng của SOA Bốn nguyên tắc này hỗ trợ hiện thực hoá các nguyên tắc khác

1.2.7 SOA và Dịch vụ Web

Dịch vụ web được biết đến nhiều trong thời gian gần đây Mục đích chính của dịch

vụ web là tạo ra các chức năng để có thể truy cập thông qua các chuẩn Internet, độc lập với nền tảng và ngôn ngữ lập trình Vì vậy, dịch vụ web chính là công nghệ để thực thi SOA

Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery and Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn

Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý

thiết kế phần mềm Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng

SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và

không phải tất cả dịch vụ web đều có kiến trúc SOA) Tuy vậy, SOA và dịch vụ web

có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công

1.2.8 Tương lai cho SOA

SOA được nhiều hãng phần mềm lớn trên thế giới quan tâm và phát triển IBM đã khai trương 4 trung tâm nghiên cứu và triển khai SOA tại Austin (Mỹ), Beijing (Trung

Quốc), Delhi (Ấn độ) và Hursley (Anh) Các trung tâm này sẽ hỗ trợ cho công việc của IBM Global Services SOA Centers of Excellence Phiên bản hệ điều hành Windows thế hệ kế tiếp, tên mã Longhorn, sẽ hỗ trợ đầy đủ SOA với công nghệ tích hợp Indigo

Và SOA còn được sự ủng hộ của nhiều hãng tên tuổi khác như Sun, Oracle

Hiện nay, rất nhiều các phần mềm đưa ra cũng đều đã theo kiến trúc SOA Đồng thời, trên thị trường hiện này cũng đã có nhiều các sản phẩm, công cụ nền tảng cho SOA của các hãng phần mềm tên tuổi như Microsoft, IBM SOA được xem là có triển vọng và đầy tiềm năng cho tương lai của các hệ thống phần mềm

Trong phần tiếp theo sẽ trình bày những thể hiện cụ thể, đáng chú ý của SOA qua dịch

vụ web (web service), REST

1.3 Dịch vụ web (web service)

1.3.1 Khái niệm dịch vụ web

Dịch vụ web là công nghệ phổ biến hiện nay để thực thi một cách dễ dàng kiến trúc SOA Trước hết, chúng ta cùng tìm hiểu định nghĩa của dịch vụ web

W3C [28] định nghĩa: Dịch vụ web là hệ thống phần mềm được thiết kế để hỗ trợ liên thao tác giữa máy với máy thông qua mạng Nó có một giao diện được mô tả bởi định dạng có thể xử lý được bằng máy (đặc biệt WSDL) Các hệ thống khác tương tác cùng với dịch vụ web bằng cách tuân theo mô tả của nó sử dụng thông điệp SOAP, thông thường được chuyển đi bằng HTTP cùng với tuần tự XML kết hợp cùng với các chuẩn web liên quan khác

Như vậy, có thế nói trung tâm của dịch vụ web chính là dịch vụ (service) Vậy dịch

vụ là gì? các định nghĩa sau sẽ làm rõ vấn đề này:

• Các dịch vụ là các cấu thành tự trị mà xử lý các thông điệp được định nghĩa tốt

• Các dịch vụ cung cấp một giao diện được định nghĩa tốt bằng cách được mô tả bởi một tài liệu dựa trên XML, được gọi là ngôn ngữ mô tả dịch vụ web (Web Services Description Language – WSDL), một cách khác được hiểu như là thoả ước WSDL (WSDL contract) Tài liệu này mô tả các phương thức mà dịch vụ

hỗ trợ, bao gồm thông tin kiểu dữ liệu và thông tin nối kết để định vị và truyền thông cùng với các phương thức dịch vụ web

• Các dịch vụ cung cấp các điểm kết thúc mà các bên sử dụng và các dịch vụ khác có thể nối kết tới, dựa trên địa chỉ cổng của dịch vụ (thường là một URL)

• Các dịch vụ cũng gần như đối tượng trong kiến trúc hướng đối tượng truyền thống, là các thành phần dựa trên kiểu trong đó chúng cung cấp một giao diện được định nghĩa và thực hiện một hoặc nhiều thao tác (phương thức) Tuy nhiên, có sự khác nhau chính, đó là các trình sử dụng dịch vụ (consumer) có thể nối kết một cách mềm dẻo tới một dịch vụ, trong khi các trình sử dụng thành phần hướng đối tượng phải thiết lập tham chiếu một cách chặt chẽ Trình sử

dụng dịch vụ có thể đáp ứng một cách mềm dẻo tới các thay đổi trong giao diện của bên cung cấp dịch vụ (provider), bởi vì nó dễ dàng sinh lại một lớp đại diện (proxy) để cập nhật tài liệu WSDL Tuy nhiên, nếu một cấu thành truyền thống

mà thay đổi giao diện của nó, bản thân trình sử dụng phải biên dịch lại theo thứ

tự để tránh các lỗi tương thích Với dịch vụ, trình sử dụng dịch vụ sẽ không cần biên dịch lại nếu dịch vụ mà chúng tham chiếu tới thay đổi Thay vào đó, chúng chỉ cần kết nối để cập nhật lại tài liệu WSDL Điều này được biết như tính chất

kết nối lỏng lẻo (loose coupling, hay loosely couple services)

1.3.2 Các đặc tính của dịch vụ web

Dịch vụ web có nhiều đặc tính nổi trội Trong đó phải kể đến một số điểm như sau:

- Dịch vụ web cho phép khách và chủ tương tác được với nhau, mặc dù trong những môi trường khác nhau

- Dịch vụ web có dạng mở và dựa vào các tiêu chuẩn XML và HTTP là nền tảng kỹ thuật cho dịch vụ web

- Dịch vụ web rất linh động: Vì với UDDI và WSDL, thì việc mô tả và phát triển dịch vụ web có thể được tự động hóa

- Dịch vụ web được xây dựng trên nền tảng những công nghệ được chấp nhận

- Dịch vụ web có thể công bố (publish) và gọi thực hiện qua mạng

Ngày nay dịch vụ web được sử dụng rất nhiều trong những lĩnh vực khác nhau của cuộc sống, như :

- Dịch vụ chọn lọc và phân loại tin tức: là những hệ thống thư viện kết nối đến các web portal để tìm kiếm các thông tin từ các nhà xuất bản có chứa những từ khóa muốn tìm

- Dịch vụ hiển thị danh sách đĩa nhạc dành cho các công ty thu thanh

- Ứng dụng đại lý du lịch có nhiều giá vé đi du lịch khác nhau do có chọn lựa phục

vụ của nhiều hãng hàng không

- Bảng tính toán chính sách bảo hiểm dùng công nghệ Excel/COM với giao diện web

- Thông tin thương mại bao gồm nhiều nội dung, nhiều mục tin như: dự báo thời tiết, thông tin sức khoẻ, lịch bay, tỷ giá cổ phiếu,…

- Những giao dịch trực tuyến cho cả B2B và B2C như: đặt vé máy bay, làm giao kèo thuê xe

- Hệ thống thông tin dùng Java để tính toán tỷ giá chuyển đổi giữa các loại tiền tệ

Hệ thống này sẽ được các ứng dụng khác dùng như một dịch vụ web

- …

1.3.3 Vai trò của dịch vụ web

Dịch vụ web ra đời đã mở ra một hướng mới cho việc phát triển các ứng dụng trên Internet Công nghệ dịch vụ web là một cuộc cách mạng hóa cách thức hoạt động của

các dịch vụ B2B và B2C Dịch vụ web kết hợp sử dụng nhiều công nghệ khác nhau cho phép hai ứng dụng cùng ngôn ngữ, độc lập hệ điều hành trao đổi được với nhau thông qua môi trường mạng (Internet, Intranet, ) Tuy nhiên những công nghệ sử dụng ở đây không nhất thiết phải là những công nghệ mới Đây là điểm khác biệt của dịch vụ web so với các công nghệ khác, đó chính là khả năng kết hợp các công nghệ

đã có như là XML, SOAP, WSDL, UDDI để tạo ra các dịch vụ, đặc điểm này làm nổi bật vai trò của dịch vụ web

1.3.4 Kiến trúc của dịch vụ web

Các nhà phát triển phần mềm đều đã quen thuộc với kiến trúc n-tier Trong đó các thành phần của ứng dụng được phân thành các lớp khác nhau Tối thiểu gồm 3 lớp là: giao diện người dùng, nghiệp vụ, dữ liệu Tương tự, một giải pháp dịch vụ web cơ sở [11] theo kiến trúc SOA gồm các lớp như sau:

Dịch vụ web – khách, các dịch vụ khác

Các giao diện dịch vụ Giao

diện

người

dùng Các thành

phần nghiệp vụ

Các luồng công việc nghiệp vụ

Nguồn dữ liệu

Hình 8 - Giải pháp SOA cơ sở

- Hỗ trợ các yêu cầu an ninh mà dịch vụ đặc tả

- Hỗ trợ các phương thức (thao tác) mà dịch vụ đặc tả trong thoả ước WSDL

• Khối “Các thành phần nghiệp vụ” (Business Components), và “Các luồng công việc nghiệp vụ” (Business Workflows): tương tư như tầng nghiệp vụ của kiến trúc n-tier

• Khối “Nguồn dữ liệu” (Data source): tầng làm việc với cơ sở dữ liêu

Xét về tổng thể, tương ứng với kiến trúc SOA, kiến trúc dịch vụ web (H Voormann, [26]) có thể được biểu diễn bằng sơ đồ sau:

Môi giới dịch vụ

Cung cấp dịch vụ Yêu cầu dịch vụ

Hình 9 - Sơ đồ kiến trúc tổng thể dịch vụ web

Đây là sơ đồ khá đặc trưng của dịch vụ web, thể hiện 3 chuẩn cốt lõi của dịch vụ web là SOAP, WSDL, UDDI Trong đó:

- Môi giới dịch vụ (Service Broker): Cung cấp các thông tin về dịch vụ theo chuẩn UDDI

- Yêu cầu dịch vụ (Service Requester): truy cập tới trình môi giới dịch vụ bằng WSDL và gọi đối tượng Cung cấp dịch vụ bằng SOAP

- Cung cấp dịch vụ (Service Provider): công bố thông tin lên trình Môi giới dịch vụ, cung cấp lời gọi ra bên ngoài cho các đối tượng Yêu cầu dịch vụ qua SOAP

1.3.5 Đặc tả công nghệ dịch vụ web

Sự khác nhau giữa công nghệ dịch vụ web hiện nay với SOA là mức độ sẵn sàng của cơ sở hạ tầng hỗ trợ Cơ sở hạ tầng trong ngữ cảnh này nói đến các công nghệ hỗ trợ và lắp ráp để thực thi một giải pháp SOA Dịch vụ web độc lập yêu cầu rất ít các

hỗ trợ cơ sở hạ tầng thêm vào Tuy nhiên, chúng ta đã thấy tổng quan mức khái niệm, SOA yêu cầu nhiều hỗ trợ hạ tầng, bao gồm lựa chọn giao vận, hạ tầng an ninh, hỗ trợ cho thông điệp xác thực, Các công ty khác nhau, gồm cả Microsoft và IBM đã làm việc với nhau để thiết lập các đặc tả chuẩn mà bao phủ được dải đầy đủ của các công nghệ đang hỗ trợ cho hạ tầng SOA Tổ chức phi lợi nhuận như OASIS cũng đã đứng ra

để tạo diễn đàn cho các công ty cộng tác phát triển các đặc tả chuẩn

Hình sau [11] biểu diễn nhóm mức cao của các đặc tả dịch vụ web mà đã được công

bố bởi Microsoft, IBM, và các công ty khác

- Nhóm mô tả (Description): Nhóm này định nghĩa các đặc tả mà cho phép một dịch

vụ web có thể mô tả bản thân nó Đặc tả lõi là WSDL (cho service contract), và XSD (cho định nghĩa lược đồ kiểu dữ liệu) Nó cung gồm cả đặc tả WS-Policy mô

tả chính sách mà một dịch vụ web tăng cường khi nó truyền thông cùng một client (ví dụ như các luật tuân theo để thực hiện thành công một yêu cầu dịch vụ) Cuối cùng là UDDI đặc tả cho khám phá và mô tả các dịch vụ web

- Bảo đảm dịch vụ (Service Assurances): dịch vụ web không thể trao chuyển đơn giản các thông điệp XML Chúng phải cung cấp cho trình khách (client) một vài bảo đảm rằng các thông điệp được phát đi trong cách an toàn Nhóm đặc tả này gồm WS-Security (cung cấp cơ chế chứng thực), WS-Reliable Messaging (bảo đảm phân phối trong mạng không tin cậy), và một vài đặc tả liên quan giao dịch

- Hợp thành dịch vụ (Service Composition): cho phép người phát triển lựa chọn các đặc tả, gộp chúng lại và ghi chúng trong tài liệu WSDL

Chi tiết các đặc tả này trong WS-I Basic Profile và WS – Specifications của Phụ lục 01 Hướng dẫn cách thức xây dựng dịch vụ web được trình bày trong Phụ lục 02

định của security tokens mà hỗ trợ các cơ sở hạ tầng an ninh Hiện tại, WS-Security có

5 kiểu security tokens:

• User token (<wsse:UsernameToken>): định danh và mật khẩu

• X.509 certificate (wsse:BinarySecurityToken): sử dụng khoá công khai, được chứng thực bởi bên thứ ba có uỷ quyền

• Kerberos ticket (<wsse:BinarySecurityToken>): sở hữu khoá phiên, được chứng nhận đủ quyền tạo yêu cầu tới các dịch vụ xác định

• Security Assertion Markup Language (SAML): sử dụng cú pháp ngôn ngữ SAML để biểu diễn các xác nhận liên quan an ninh, như định danh, thuộc tính, được quyền

• Rights Expression Language (REL): giấy phép biểu diễn các quyền ISO/IEC 2100-5

1.3.7 Kết luận về dịch vụ web

Để tạo một dịch vụ web, chúng ta cần xây dựng các tầng cần thiết trong kiến trúc dịch vụ web hay nói cách khác là xây dựng và thiết lập các thành phần trong các tầng

đó, cụ thể là các thành phần SOAP, WSDL, UDDI, XML, trong đó:

- SOAP là giao thức nằm giữa tầng vận chuyển và tầng mô tả thông tin về dịch

vụ, SOAP cho phép người dùng triệu gọi một dịch vụ từ xa thông qua một thông điệp XML

- WSDL là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Dịch vụ web

sử dụng ngôn ngữ WSDL để truyền các tham số và các loại dữ liệu cho các thao tác, các chức năng mà dịch vụ web cung cấp

- UDDI dùng cho cả người dùng và SOAP chủ (server), nó cho phép đăng ký dịch vụ để người dùng có thể gọi thực thi các hàm, các chức năng của dịch vụ web hay nói cách khác một dịch vụ cần phải được đăng ký để cho phép các khách có thể gọi thực hiện

- Bên cạnh đó chúng ta cũng phải quan tâm đến việc làm sao để cho các dịch vụ

có tính an toàn, toàn vẹn và bảo mật thông tin, nhất là các dịch vụ liên quan đến giao dịch thương mại và tài chính Chuẩn WS-Security là một trong những chuẩn quan trọng đáp ứng yêu cầu này

1.4 REST

REST là tên viết tắt của REpresentational State Transfer (tạm dịch: Chuyển trạng thái biểu diễn), là một kiểu kiến trúc phần mềm cho các hệ thống đa phương tiện phân tán như World Wide Web REST được giới thiệu trong một luận văn tiến sĩ của Roy Thomas Fielding [5], năm 2000, trường đại học Califonia, một trong các tác giả của Hypertext Transfer Protocol (HTTP)

REST liên quan chặt chẽ tới một tập hợp của các nguyên tắc kiến trúc mạng, phác thảo ra làm thế nào các tài nguyên được định nghĩa và truy cập Khái niệm này mô tả bất kỳ giao diện đơn giản nào mà chuyển phát dữ liệu thông qua HTTP không cần lớp thông điệp thêm vào như SOAP hoặc kiểm soát phiên thông qua HTTP cookies

Các hệ thống đi theo các nguyên tắc REST của Fielding thường gọi là RESTful

1.4.1 Tại sao gọi REpresentational State Transfer

Web bao gồm nhiều tài nguyên Mỗi tài nguyên là bất kỳ thông tin nào người dùng mong đợi Ví dụ, hãng Boeing Aircraft Corp có thể định nghĩa một tài nguyên 747 Máy trạm truy cập tài nguyên này bằng địa chỉ:

http://www.boeing.com/aircraft/747Tài nguyên được trả về và biểu diễn tại máy trạm (ví dụ: Boeing747.html) Kết quả của việc máy trạm duyệt địa chỉ liên kết Boeing747.html là chuyển từ biểu diễn tài nguyên này sang biểu diễn tài nguyên khác Biểu diễn tài nguyên mới đặt ứng dụng máy trạm vào trong một trạng thái khác Do vậy, ứng dụng máy trạm đổi trạng thái biểu diễn cho mỗi tài nguyên nên được gọi là chuyển trạng thái biểu diễn

Diễn tả của Roy Thomas Fielding [5] về “REpresentational State Transfer”:

Chuyển trạng thái biểu diễn muốn nói về hình ảnh làm thế nào một ứng dụng web được thiết kế để hoạt động tốt: một mạng của các trang web (máy trạng thái ảo), nơi người dùng duyệt các trang web thông qua ứng dụng bằng cách chọn các đường liên kết (chuyển trạng thái), kết quả là trang tiếp theo (biểu diễn trạng thái tiếp theo của ứng dụng) được chuyển tới người dùng và thể hiện sự sử dụng chúng

1.4.2 Các chuẩn sử dụng trong REST

Có thể thấy, REST là một kiểu thiết kế (tương tự như SOA) Chúng ta chỉ có thể hiểu và thiết kế hệ thống theo kiểu đó (tương tự kiểu kiến trúc khách-chủ) REST sử dụng các chuẩn:

• HTTP

• URL

• XML/HTML/GIF/JPEG/vân vân (các biểu diễn tài nguyên)

• text/xml, text/html, image/gif, image/jpeg,vân vân (các kiểu MIME)

1.4.3 Các nguyên tắc REST

Các nguyên tắc thiết kế chính của REST:

• Trạng thái và chức năng của ứng dụng được phân chia thành các tài nguyên

• Mỗi tài nguyên được địa chỉ hoá một cách duy nhất, sử dụng cú pháp toàn cục bằng các liên kết đa phương tiện

• Tất cả các tài nguyên chia sẻ một giao diện đồng nhất cho chuyển trạng thái giữa máy trạm và tài nguyên, bao gồm:

- Một tập ràng buộc của các thao tác được định nghĩa tốt

- Một tập ràng buộc của các kiểu nội dung, lựa chọn hỗ trợ mã theo yêu cầu (code on demand)

1.4.4 Các phần tử kiến trúc REST

Các phần tử kiến trúc được mô tả trong luận văn của Fielding được xem là những khía cạnh chính của REST Bảng sau tổng hợp các phần tử dữ liệu của REST [5]:

Phần tử dữ liệu Các ví dụ web hiện đại

Tài nguyên (resource) Đích nhận mong đợi của một tham chiếu siêu

văn bản

Định danh tài nguyên

(resource identifier)

URL, URN

Biểu diễn (representation) Tài liệu HTML, ảnh JPEG

Siêu dữ liệu trình diễn

(representation metadata)

Kiểu phương tiện, thời điểm thay đổi gần nhất

Siêu dữ liệu tài nguyên

(resource metadata)

Liên kết nguồn gốc, các thay thế, biến đổi

Dữ liệu điều khiển (control

1.4.4.1 Tài nguyên và các định danh tài nguyên

Trừu tượng hoá thông tin chính trong REST là tài nguyên Bất kỳ thông tin gì mà

có thể được đặt tên thì đều có thể là tài nguyên: tài liệu, hình ảnh hoặc một dịch vụ nhiệt độ Theo một định nghĩa khác, bất kỳ đích của các tham chiếu siêu văn bản đều đưa đến định nghĩa của tài nguyên Một tài nguyên là một ánh xạ khái niệm tới tập các thực thể

REST sử dụng định danh tài nguyên để định danh tài nguyên riêng biệt gộp trong

Một biểu diễn là chuỗi các byte, cộng với siêu dữ liệu biểu diễn để mô tả các byte

đó Biểu diễn bao gồm dữ liệu, siêu dữ liệu mô tả dữ liệu, và đôi lúc cả siêu dữ liệu để

mô tả siêu dữ liệu (thường dùng với mục đích kiểm tra tính toàn vẹn của thông điệp)

Các thông điệp phản hồi có thể bao gồm siêu dữ liệu biểu diễn và siêu dữ liệu tài nguyên: thông tin về tài nguyên mà không phải chỉ cho mỗi tài nguyên cung cấp

Dữ liệu điều khiển định nghĩa mục đích của thông điệp giữa các thành phần như hành

động được yêu cầu hoặc ý nghĩa của phản hồi

Phụ thuộc vào dữ liệu điều khiển, một biểu diễn đưa ra có thể chỉ dẫn trạng thái hiện tại của tài nguyên yêu cầu, trạng thái mong muốn cho tài nguyên yêu cầu, hoặc giá trị của một vài tài nguyên khác, như biểu diễn của dữ liệu đầu vào trong một biểu mẫu (form) truy vấn dữ liệu tại trình khách

1.4.5 Thiết kế và thực thi REST

Trong phần này sẽ trình bày về cách thức thiết kế và thực thi hệ thống web theo mô hình REST Mô hình mức cao thiết kế REST [8]:

Hình 13 - Thiết kế kiến trúc mức cao REST

Trong đó, bộ xử lý URL Processor được thực hiện theo cách:

Hình 14 - Phân giải URL tới các chức năng

Đầu vào của bộ xử lý URL là các URL và đầu ra là gọi chức năng tương ứng với URL đó Khi thực thi bộ xử lý URL, có nhiều công nghệ có thể sử dụng Nhìn chung

có 2 cách sau:

• Tìm cách kết hợp một URL cơ sở cùng với trình điều khiển (handler) xác định Ví

dụ, như /services sẽ dựa trên cơ sở tất cả các dịch vụ web Máy chủ cần hỗ trợ tính năng bất kỳ khi nào URL bắt đầu cùng với /services thì trình điều khiển xác định được gọi

• Nếu không thể kết hợp bằng trình điều khiển với một URL cơ sở, cần viết bộ lọc (filter) HTTP Sự khác nhau giữa bộ lọc HTTP và trình điều khiển HTTP đó là bộ lọc được gọi trước trình điều khiển Ý tưởng về bộ lọc HTTP cho phép mã hoá người dùng để thực hiện các bước chung trên tất cả các yêu cầu Ví dụ thông thường là chứng thực Sử dụng bộ lọc HTTP, bạn có khả năng định nghĩa trình điều khiển nào được gọi Trong ngữ cảnh bộ xử lý REST URL, bộ xử lý nên được

nhúng như bước cuối cùng sau tất cả các bộ lọc khác đã thực hiện Nó là bước cuối cùng bởi vì bạn muốn chứng thực thực hiện trên URL yêu cầu, và không thực hiện chuyển hướng URL Khi thực thi bộ xử lý REST URL, cần nhớ rằng chỉ URL xác định chức năng nào được gọi

1.5 So sánh và đánh giá dịch vụ web

Kiến trúc SOA trở nên mạnh mẽ và ứng dụng hiệu quả, dễ dàng nhờ công nghệ dịch vụ web Ban đầu, dịch vụ web được hiểu như một dạng công nghệ gắn với các chuẩn WSDL, SOAP, UDDI Ngay cả W3C khi định nghĩa dịch vụ web, dường như cũng nhấn mạnh tới khái niệm SOAP Song song quá trình phát triển của dịch vụ web,

có sự xuất hiện của REST Ban đầu, REST chưa thể đưa được vào ngay như dịch vụ web - SOAP bởi thiếu vắng các công cụ lập trình hỗ trợ REST Nhưng trong một vài năm gần đây, REST đã được nhiều người chú ý bởi tính đơn giản nhưng hiệu quả Các hãng phần mềm lớn như Microsoft, SUN cũng đã hỗ trợ công cụ phát triển REST (trong khoảng năm từ 2007) Từ phiên bản DotNetFramework 3.0 của Micrsoft đã hỗ trợ REST Bộ JAX-RS (Java API for RESTfull Web Service, JSR-311) dành riêng hỗ trợ REST

Có thể nói, đến nay, dịch vụ web được phân thành hai loại là SOAP và REST Giữa hai loại này đều có những đặc điểm, thế mạnh riêng mà tuỳ thuộc vào người phát triển

tự lựa chọn:

• SOAP là dạng chuẩn công nghiệp, có thể chạy được trên nhiều giao thức khác như FTP, SMTP, Message Queue Điểm yếu là chỉ sử dụng phương thức POST với các thông tin đóng gói bên trong thông điệp Người quản trị không thể hiểu băng thông mạng đang dùng gì khi không nhìn vào bên trong thông điệp Đồng thời, các thông điệp SOAP cũng khó đóng gói hơn là thông điệp REST

• REST đơn thuần sử dụng HTTP với các phương thức GET, POST, PUT, DELETE Người quản trị có thể xem thông điệp (như GET thoitiet/Hanoi) và hiểu

nó làm gì Các yêu cầu có thể được đánh dấu và đáp ứng có thể được cất giữ (cache) để cải thiện hiệu năng Dễ dàng tạo ra các yêu cầu như GET chỉ bằng URI

Từ URI, có thể dễ dàng áp dụng các biện pháp an ninh, lọc, ghi nhật ký, truy vết, REST thân thiện vì tính đơn giản và hiệu quả Điểm hạn chế của REST đó là gắn chặt với giao thức web http

Bảng sau tập hợp và so sánh giữa hai kiểu dịch vụ web SOAP và REST:

Dịch vụ web –

SOAP

• Chuẩn công nghiệp, với nhiều đặc tả (SOAP, WSDL, WS-*, )

• Hỗ trợ nhiều giao thức

• Chỉ có phương thức POST (tất cả đóng gói trong thông điệp)

• Khó theo dõi băng thông

Ưu điểm Nhược điểm

(HTTP, FTP, SMTP, Message Queue)

mạng đang làm gì nếu không mở thông điệp

• Đặc tả khá phức tạp

Dịch vụ web –

REST

• Có phương thức GET, POST, PUT, DELETE

• Dễ áp dụng các phương pháp cải thiện hiệu năng bằng các phương pháp cất giữ (cache), lần vết, an ninh, thông qua URI

• Dễ theo dõi băng thông mạng qua các URI

• Thân thiện và đơn giản

• Chỉ hỗ trợ HTTP

Bảng 2 - So sánh dịch vụ web SOAP và REST

Hiện nay, tại các website dịch vụ nổi tiếng, nhiều người truy cập như amazon, google, yahoo, cũng vẫn hỗ trợ cả SOAP và REST Web Service

Gần đây, sự xuất hiện của REST cũng như tính ứng dụng dễ dàng của nó cũng kéo theo một dạng kiến trúc mới xuất hiện WOA (Web Oriented Architecture) Chưa có định nghĩa thực sự về WOA Cũng có câu hỏi đặt ra là WOA có phải là tương lai của SOA Có định nghĩa cho rằng:

WOA= SOA + WWW + REST

Trên blog ZDNet của Dion Hinchcliffe [http://blogs.zdnet.com/Hinchcliffe/?p=27] đưa ra hình ảnh so sánh khá trực quan giữa SOA, WOA, REST, cùng các chuẩn SOAP, WSDL,

Lõi SOA cùng với sự trải rộng:

Kiến trúc hướng web (WOA)

Thế giới đang có phần nghiêng nhiều về WOA với REST là trung tâm Lý do bởi WOA được phát triển từ web đi lên, đã rất thân thiện, có tính trong sáng và dễ hiểu Chỉ cần biết về http, POX (plain old XML) cùng các công cụ hỗ trợ là viết được REST Vấn đề an ninh trong REST có thể dùng ngay https thay vì phải biết về WS-Security phức tạp

CHƯƠNG 2 - CHUẨN PHẦN MỀM TRÊN NỀN WEB

Như chúng ta đã biết, web là lĩnh vực rộng lớn và phát triển nhanh và mạnh Có rất nhiều các sản phẩm về web cùng với nhiều nhà sản xuất khác nhau, chạy trên nhiều nền tảng khác nhau.Ví dụ:

• Các trình duyệt web: trên nền tảng Windows, UNIX, Linux, MAC Với rất nhiều sản phẩm (IE, Firefox, )

• Các máy chủ web (web server): Internet Information Service của Microsoft trên nền tảng Windows, Apache trên nhiều nền tảng,

• Các công cụ phát triển web: Visual Studio của Micrsoft, Java,

Sự phát triển đa dạng của web đã đặt ra một số vấn đề về chuẩn hoá để các nhà sản xuất, nhà phát triển, có thể có chung một cơ sở, một tiếng nói cho những sản phẩm web của mình Chương này sẽ làm rõ các nội dung về chuẩn web, tại sao cần chuẩn web, cùng với các cách thức kiểm tra và đảm bảo web là chuẩn

2.1 Các chuẩn web là gì?

Các chuẩn web là khái niệm chung chỉ các chuẩn hình thức hoặc các đặc tả kỹ thuật để định nghĩa và mô tả những khía cạnh của Word Wide Web Trong một vài năm gần đây, khái niệm này đã trở nên quen thuộc hơn cùng với khuynh hướng tán thành xây dựng các web site và triết lý thiết kế, phát triển web bằng các phương pháp chuẩn hoá

Cũng có nhiều chuẩn và đặc tả phụ thuộc lẫn nhau, một trong số đó liên quan các khía cạnh internet, không phải Word Wide Web, nhưng có ảnh hưởng trực tiếp hoặc gián tiếp đến phát triển và quản trị các web site và dịch vụ web Những chuẩn này đều

có thể tiến tới các chuẩn mức cao hơn mà có ảnh hưởng một cách trực tiếp tới khả năng truy cập (accessbility) và khả năng sử dụng (usability) của web site Theo nghĩa rộng, các chuẩn web bao gồm [26]:

• Các khuyến nghị được công bố bởi Word Wide Web Consortium (W3C) Gồm rất nhiều khuyến nghị như HTML, XHTML,

• Các tài liệu chuẩn Internet (Internet Standard – STD) được công bố bởi Internet Engineering Task Force (IETF) STD là dạng đặc biệt của RFC hoặc tập RFC Ví

dụ như STD 1 là RFC 5000, công bố tháng 5/2008 cho các chuẩn giao thức chính thức Internet

• Các tài liệu RFC (Request For Comments) được công bố bởi IETF Ví dụ RFC

2616 cho HTTP v1.1, RFC 114 cho FTP, RFC 793 cho TCP,

• Các chuẩn được công bố bởi International Organization for Standardization (ISO)

Ví dụ ISO 8879:1986 cho Standard Generalized Markup Language (SGML)

• Các chuẩn được công bố bởi ECMA International (thường gọi ECMA) Ví dụ điển hình là ECMAScript, dạng chuẩn đặc tả trong ECMA-662

• Chuẩn Unicode và nhiều báo cáo kỹ thuật Unicode được công bố bởi Unicode Consortium Ví dụ UTF8

• Tên và các đăng ký số được duy trì bởi Internet Assigned Numbers Authority (IANA) Đây là một tổ chức giám sát toàn cầu về cấp phát địa chỉ IP, quản lý vùng gốc DNS, các kiểu phương tiện (ví dụ như Multipurpose Internet Mail Extensions

- MIME) và các giao thức Internet khác

Khi các vị trí hoặc trang web được mô tả là thích ứng với các chuẩn web, nó thường hàm ý rằng vị trí hoặc trang web đó là hợp lệ hoặc gần hợp lệ với HTML, CSS

và JavaScript Khi nói đến các chuẩn web, các công bố sau thường được xem là cơ bản nhất:

• Các khuyến nghị cho ngôn ngữ đánh dấu (markup language): HTML, XHTML, SVG và XForms từ W3C

• Các khuyến nghị cho các bảng định kiểu (stylesheets): đặc biệt là CSS từ W3C

• Các chuẩn cho ECMAScript: đa số là JavaScript từ ECMA

• Các khuyến nghị cho Document Object Model (DOM) từ W3C

Mô tả các dạng chuẩn web thông dụng trên đây được trinh bày trong phần Phụ lục

03

2.2 Tại sao sử dụng chuẩn web

Các nhà phát triển và thiết kế web thường không chú ý tới các chuẩn web Lý do chung là nó quá khó, nó làm việc thế nào cũng được và do phụ thuộc vào các công cụ

sử dụng sinh mã Tuy nhiên, nếu xem về mặt lôgic, sẽ thấy có nhiều lợi ích khi học và

sử dụng các chuẩn web Sau đây là một số ví dụ:

• Phát triển và bảo trì đơn giản hơn: sử dụng HTML được cấu trúc và nhiều ngữ

nghĩa làm nó dễ và nhanh hiểu mã hơn bởi bất kỳ ai

• Khả năng tương thích cùng với các trình duyệt web: khi sử dụng các chuẩn đã

được định nghĩa và mã hợp lệ, các tài liệu được giảm thiểu rủi ro cho các trình duyệt web tương lai mà không thể hiểu mã đã sử dụng

• Tải và thể hiện các trang web nhanh hơn: kích thước file nhỏ hơn nên tải nhanh

hơn Các trình duyệt web hiện đại thể hiện các trang nhanh hơn khi chúng trong chế độ chuẩn

• Khả năng truy nhập tốt hơn: HTML ngữ nghĩa, nơi cấu trúc được phân tách với

trình diễn, làm nó dễ dàng hơn cho các trình đọc màn hình và thiết bị duyệt thay đổi nhau để phiên dịch nội dung (như sử dụng CSS)

• Xếp hạng máy tìm kiếm tốt hơn: phân tách nội dụng và trình diễn làm nội dung

biểu diễn trong phần lớn của toàn bộ kích thước file Được kết hợp cùng với đánh dấu ngữ nghĩa này sẽ cải thiện xếp hạng trong cỗ máy tìm kiếm

• Thích ứng đơn giản hơn: đánh dấu tài liệu một cách có ngữ nghĩa có thể được

thích ứng dễ dàng hơn với các thiết bị duyệt thay đổi nhau và in, giống như máy tính cầm tay và điện thoại tế bào, được liên kết tới các file CSS khác nhau Bạn có thể làm các thay đổi toàn site cho biểu diễn bằng cách soạn thảo một file đơn Các chuẩn web có thể tiết kiệm thời gian và tiền bạc cho các người tạo website và cung cấp kinh nghiệm tốt hơn với người duyệt website

2.3 Cách thức kiểm tra web là chuẩn

Phần này thảo luận một số cách thức để kiểm tra web có tuân thủ các chuẩn công

bố (thường là HTML, XHTML, CSS) của W3C [29]

Kiểm tra HTML:

Đầu tiên một tài liệu web được xem là chuẩn cần có khai báo thẻ DOCTYPE Tài liệu web có thể là một file html, hoặc một đầu ra của yêu cầu tài nguyên từ trình khách tới máy chủ web của một ứng dụng web như jsp, asp.net, Thẻ DOCTYPE báo cho trình xử lý tài liệu (như trình duyệt web) biết tài liệu này là dạng tài liệu chuẩn gì Trường hợp tài liệu web không định nghĩa DOCTYPE, trình xử lý tài liệu sẽ xem như dạng chuẩn ngầm định (thông thường là HTML 4.01 Transitional) Ví dụ bảng sau liệt

kê các định nghĩa kiểu tài liệu web do W3C đưa ra:

Phiên bản Danh sách DTD Khai báo DOCTYPE trong tài liệu

2.0//EN">

HTML 3.2 Final//EN">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Strict,

Transitional, Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"

"http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 Strict,

Transitional, Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

strict.dtd">