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

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 3

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
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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 4

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Ờ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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 5

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ỜI CẢM ƠN

Tôi xin cảm ơn các Thầy, Cô giáo Trường Đại học Công nghệ đã truyền đạt nhiều
kiến thức, bài giảng quý báu cho tôi trong thời gian học tại Trường.
Tôi xin cảm ơn Thầy giáo - TS. Trương Anh Hoàng đã tận tình hướng dẫn và chỉ
bảo tôi rất nhiều trong suốt thời gian làm luận văn.
Tôi cũng xin được cảm ơn Ban Giám hiệu, Khoa CNTT, phòng Đào tạo sau đại
học - Nghiên cứu khoa học, trường Đại học Công nghệ đã tạo điều kiện và giúp đỡ tôi
hoàn thành luận văn và khoá học Thạc sĩ tại trường.
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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 6

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
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

STT Tên Diễn giải
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
5. XML Extensible Markup Language
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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 7

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 8

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 9

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
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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 10

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 11

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









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

Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 12

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
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.

1.1.1. Định nghĩa kiến trúc phần mềm
Kiến trúc phần mềm là thuật ngữ khó định nghĩa. Thực tế là chưa có một định
nghĩa nào về kiến trúc phần mềm được chấp nhận một cách rộng rãi. Để hiểu một cách
đa dạng, nhiều khía cạnh, chúng ta sẽ đi qua một số định nghĩa tiêu biểu được tập hợp
bởi Viện Kỹ nghệ phần mềm (Software Engineering Institute) [
27].

Sau đây là định nghĩa đầu tiên của ANSI/IEEE [
4]: Về mặt thực tế, kiến trúc được
định nghĩa như là tổ chức cơ bản của một hệ thống, được biểu diễn bởi các thành
phần, các quan hệ của chúng với nhau và với môi trường, cùng với các nguyên tắc bao
trùm thiết kế và tiến hoá của nó.

Đị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ế.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 13

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
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].


Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 14

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
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].

1.1.2.5. Các khung nhìn kiến trúc
Các khung nhìn kiến trúc được đưa ra trong mô hình 4+1 khung nhìn của Philippe
Krutchen, năm 1995 [
14]:

Khái ni
ệ
m Vật lý
Khung nhìn lô gic
(Logical View)
Khung nhìn thực thi
(Implementation View)

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.
Người dùng
ối
Chức năng
Lập trình viên
Quản lý phần mềm
Khung nhìn tiến trình
(Process View)
Hiệu năng

Mở rộng
N
g
ười tích h
ợp
h
ệ
thốn
g

Khung nhìn triển khai
(Deployment View)
Khung nhìn ca sử dụng
(Use Case View)
Mô hình hệ thống
Chuyển giao, cài đặt
Truyền thông
Kỹ sư hệ thống
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 15

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 16

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
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.

1.2.1. Vài nét về lịch sử SOA
Khái niệm SOA được tạo ra vào năm 1996 trên một bài báo của nhà phân tích
Gartner Yefim V.Natis[
21]:
- SOA là kiến trúc phần mềm được bắt đầu bởi một định nghĩa giao diện và xây dựng
toàn bộ mô hình ứng dụng như một mô hình các giao diện, các thực thi giao diện và
các lời gọi giao diện.
- 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.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 17

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
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ử:

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

Một kiến trúc chuẩn hoá, mềm dẻo đòi hỏi phải hỗ trợ tốt việc kết nối giữa các ứng
dụng và chia sẻ dữ liệu. SOA là một trong các kiến trúc đó. Trung tâm của SOA đó là
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 18

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
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ỳ.

1.2.3.2. Các dịch vụ (Services)
Dịch vụ là một cấu thành phần mềm thực hiện một số chức năng để đóng gói khái
niệm nghiệp vụ mức cao. Nó bao gồm các thành phần như hình 4, chi tiết như sau :
• Thoả ước (contract): Cung cấp bản đặc tả về mục đích, chức năng, các ràng buộc,
và sử dụng dịch vụ.
• 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.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 19

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

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.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 20

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

• 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ụ
Đáp ứng
Yêu cầu
Yêu cầu
Đáp ứng
Công bố
Tìm
kiếm

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ụ
Yêu cầu dịch vụ
Nối
kết

Kênh dịch vụ
Tìm kiếm và
Lựa chọn
Công bố

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


Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 21

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
Trong đó, có 3 thực thể chính:
• vider): đăng tải các thông tin về dịch vụ mình cung
• dịch vụ để lấy thông tin về
• trữ tập trung các thông tin

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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 22

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
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
• hiệu năng của chú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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 23

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
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.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 24

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 25

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
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ử
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 26

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
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
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 27