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
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (3.67 MB, 111 trang )
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..............
CHƯƠNG 2 - CHUẨN PHẦN MỀM TRÊN NỀN WEB
2.1.Các chuẩn web là gì? ................................
2.2.Tại sao sử dụng chuẩn web ......................
2.3.Cách thức kiểm tra web là chuẩn.............
2.4.Công cụ cải thiện chất lượng web ............
2.5.Kết luận chuẩn web ..................................
PHẦN 2: ỨNG DỤNG XÂY DỰNG HỆ THỐNG THI TRẮC NGHIỆM...........
CHƯƠNG 3 - XÂY DỰNG HỆ THỐNG THI TRẮC NGHIỆM
3.1.Mô tả bài toán thi trắc nghiệm ................
3.2.Kiến trúc phần mềm..................................
3.2.1.
Giới thiệu
3.2.2. Biểu diễn kiến trúc ..................................................................................
3.2.3. Mục tiêu và các ràng buộc kiến trúc .......................................................
3.2.4. Khung nhìn ca sử dụng............................................................................
3.2.5.
Khung nh
3.2.6. Khung nhìn tiến trình ..............................................................................
3.2.7. Khung nhìn triển khai..............................................................................
3.2.8. Khung nhìn thực thi.................................................................................
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.Thực hiện hệ thống ...................................
Lựa chọn công nghệ ................................................................................
Thiết kế chương trình ..............................................................................
Thiết kế cơ sở dữ liệu ..............................................................................
Thiết kế lời gọi REST .............................................................................
Một số hình ảnh chương trình .................................................................
PHẦN 3: THẢO LUẬN VÀ KẾT LUẬN..................................................................
TÀI LIỆU THAM KHẢO...........................................................................................
PHỤ LỤC 01: MỘT SỐ ĐẶC TẢ CHUẨN DỊCH VỤ WEB
PHỤ LỤC 02: XÂY DỰNG DỊCH VỤ WEB KIỂU SOAP
PHỤ LỤC 03: MỘT SỐ CHUẨN WEB THÔNG DỤNG
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
1.
SOA
2.
WSDL
3.
SOAP
4.
UDDI
5.
XML
6.
REST
7.
HTTP
8.
WOA
9.
RFC
10.
STD
11.
XHTML
12.
SVG
13.
CSS
14.
CNTT
Luận văn Thạc sĩ - Đỗ Đức Thảo
Tên
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]:
Khung nhìn lô gic
(Logical View)
Người dùng
Chức năng
Khung nhìn tiến trình
(Process View)
Người tích hợp hệ thống
Hiệu năng
Mở rộng
Khái niệm
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.
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)
Thoả ước
(Contract)
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ụ
Tìm
Công bố
kiếm
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]:
Nối
kết
Cung cấp
dịch vụ
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:
•Cung cấp dịch vụ (Service Provider): đăng tải các thông tin về dịch vụ mình cung
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 dịch vụ để lấy thông tin về
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 trữ tập trung các thông tin
về dịch vụ cung cấp.
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ụng 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ể được biến đổi để đưa kênh
dịch 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.2.5. Kênh dịch vụ doanh nghiệp (ESB - Enterprise Service Bus)
Khái niệm kênh (bus) khá quen thuộc với những người làm về máy tính, gắn với
phầ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.2.5.1. ESB là gì?
Chưa có một định nghĩa hình thức nào về ESB. Nó thường được nhiều nhà bán
hàng 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.2.5.2. Cơ sở của ESB
ESB là trung tâm đầu não truyền thông cho các dịch vụ trong kiến trúc hướng dịch
vụ. 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ú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 khả năng của chúng mở
rộng để 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.2.5.3. Chi tiết về ESB
ESB có thể được xem như một hộp đen - không cần biết nó làm việc như thế nào.
Chú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ểu thông
đ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 hiệu năng của
chúng, 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ụ giao diện (interface services): có thể kiểm tra các thông điệp
đối 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].
Kênh dịch vụ doanh nghiệp (ESB)
Chương
trình A
Các dịch vụ quản lý
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
