Nghiên cứu công nghệ SOA và bảo mật xác thực Xauth áp dụng xây dựng giải pháp quản lý sự cố mạng viễn thông

1

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ









BÙI ĐỨC HIẾU


NGHIÊN CỨU CÔNG NGHỆ SOA VÀ BẢO MẬT XÁC THỰC XAUTH
ÁP DỤNG XÂY DỰNG GIẢI PHÁP QUẢN LÝ SỰ CỐ MẠNG VIỄN THÔNG

LUẬN VĂN THẠC SỸ

Hà Nội - 2014
2

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ









BÙI ĐỨC HIẾU


NGHIÊN CỨU CÔNG NGHỆ SOA VÀ BẢO MẬT XÁC THỰC XAUTH
ÁP DỤNG XÂY DỰNG GIẢI PHÁP QUẢN LÝ MẠNG VIỄN THÔNG
Ngành: Công nghệ thông tin

Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10


LUẬN VĂN THẠC SỸ
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG NINH THUẬN
NGƯỜI ĐỒNG HƯỚNG DẪN: TS. TRỊNH THANH BÌNH










Hà Nội - 2014
3

Lời mở đầu
Với những dòng chữ tiên này, tôi xin dành để gửi lời cảm ơn chân thành và sâu sắc
nhất tới thầy giáo, tiến sỹ Trương Ninh Thuận, tiến sỹ Trịnh Thanh Bình - người đã tận
tình hướng dẫn, chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ khi bắt đầu cho tới
khi hoàn thành luận văn của mình.
Đồng thời, xin trân trọng gửi lời cảm ơn tới tập thể các thầy giáo - Bộ môn Công
Nghệ Phần Mềm - trường Đại học Công nghệ - Đại học Quốc gia Hà Nội đã tạo cho tôi
một môi trường làm việc đầy đủ và thuận tiện.
Xin cảm ơn tất cả những người thân yêu trong gia đình tôi cùng toàn thể bạn bè,
những người đã luôn mỉm cười và động viên tôi mỗi khi vấp phải những khó khăn, bế

tắc.
Cuối cùng, xin chân thành cảm ơn ông Shakti (công ty Katjaksys), anh Nguyễn Minh
Quân (công ty điện toán VDC), những người đã đem đến cho tôi những lời khuyên vô
cùng bổ ích để giúp tháo gỡ những khó khăn, vướng mắc trong quá trình làm luận văn.
4

Mục lục
Lời mở đầu 3
Mục lục 4
Danh sách hình vẽ 6
Bảng từ viết tắt 8
Mở đầu 9
CHƯƠNG 1: TỔNG QUAN CÁC CÔNG NGHỆ PHÂN TÁN 11
1.1. Hoàn cảnh ra đời 11
1.2. Một số mô hình trong hệ thống phân tán 11
1.2.1. CORBA - Common Object Request Broker Architecture 12
1.2.2. DCOM – Distributed Component Object Model 13
1.2.3. EJB – Enterprise Java Bean 13
1.3. Kết luận chương 1 14
CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ WCF 16
2.1. Giới thiệu kiến trúc hướng dich vụ SOA 16
2.1.1. Tổng quan 16
2.1.2. Các nguyên tắc chính của hệ thống SOA 17
2.1.3. Các tính chất của hệ thống SOA 18
2.1.4. Lợi ích của SOA 22
2.1.5. Kiến trúc phân tầng chi tiết của SOA 23
2.1.6. Một số mô hình triển khai SOA 26
2.1.7. Các phương pháp xây dựng hệ thống SOA 26
2.1.8. Chu trình phát triển của SOA: 26
2.2. Tổng quan công nghệ WCF 28

2.2.1. Giới thiệu 28
2.2.2. Ưu điểm của WCF 29
2.2.3. Kiến trúc WCF 30
2.3. Kết luận chương 2 30
CHƯƠNG 3 NGHIÊN CỨU XÂY DỰNG GIẢI PHÁP CHO BÀI TOÁN
QUẢN LÝ SỰ CỐ BTS 32
3.1. Xây dựng giải pháp 32
3.1.1. Khảo sát bài toán 32
5

3.1.2. Phân tích bài toán 34
3.1.3. Xây dựng giải pháp 37
3.2.1. Xây dựng cơ sở dữ liệu lưu trữ 40
3.3. Kết quả xây dựng và thử nghiệm phần mềm 42
3.3.1. Một số hình ảnh hoạt động của phần mềm: 42
3.4. Kết luận chương 3 44
CHƯƠNG 4 NGHIÊN CỨU XÂY DỰNG GIẢI PHÁP XÁC THỰC BẢO
MẬT DỊCH VỤ WEB VỚI OAUTH và XAUTH 46
4.1. Tổng quan 46
4.2. Các vấn đề gặp phải 46
4.3. Dịch vụ chia sẻ định danh mở OpenID 47
4.4. Dịch vụ xác thực ủy quyền chia sẻ tài nguyên Oauth 48
4.5. Cơ chế xác thực Oauth đề xuất cho bài toán 51
4.6. Những vấn đề phát sinh của Oauth trên môi trường thiết bị di động52
4.7. Giải pháp XAuth và Service Authorization manager 53
4.8. Xây dựng xử lý xác thực 54
4.9. Kết luận chương 4 57
KẾT LUẬN 58
Tài liệu tham khảo 59

6

Danh sách hình vẽ
Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc CORBA [1] 12
Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc DCOM 13
Hình 3: Mô hình kiến trúc EJB 14
Hình 4: Sơ đồ cộng tác trong SOA hiện nay 16
Hình 5: Cơ chế dò tìm dịch vụ động 20
Hình 6: Cơ chế phát hiện một dịch vụ khi dịch vụ đó Online 21
Hình 7: Kiến trúc phân tầng của SOA 24
Hình 8: Chu trình phát triển SOA 27
Hình 9: Mô hình hoạt động của WCF tương tác với các thành phần client
(Nguồn: Microsoft) 29
Hình 10: Kiến trúc của WCF (Nguồn: Microsoft) 30
Hình 11:Mô hình hệ thống các phần mềm hỗ trợ điều hành mạng viễn thông 32
Hình 12: Mô hình chức năng của hệ thống 34
Hình 13: Sơ đồ quy trình nghiệp vụ tổng thể 35
Hình 14: Sơ đồ quy trình nghiệp vụ quy trình quản lý danh sách BTS bị sự cố 36
Hình 15: Sơ đồ quy trình quản lý sự cố 36
Hình 16: Mô hình ứng dụng 37
Hình 17: Mô hình triển khai hệ thống 38
Hình 18: Mô hình cơ sở dữ liệu phân hệ Hệ thống 40
Hình 19: Mô hình cơ sở dữ liệu phân hệ Quản lý sự cố BTS 41
Hình 20: Quy trình xử lý xác thực định danh OpenId 47
Hình 21: Quy trình xử lý xác thực, ủy quyền khai thác tài nguyên dịch vụ
(Nguồn: Oauth.net) 49
Hình 22: Quy trình xử lý xác thực, ủy quyền truy xuất tài nguyên đề xuất với bài
toán hiện tại 51
Hình 23: Xử lý xác thực theo cơ chế XAuth [4] 54
Hình 24:Cơ chế làm việc của AuthorizationManager [4] 54

Hình 25: Khai báo AuthorizationManager 55
Hình 26: Đăng ký MyServiceAuthorizationManager với Web server 56
Hình 27: Trạng thái đã xác thực thành công 56
Hình 28: Trạng thái xác thực thất bại 57
7

8

Bảng từ viết tắt
Từ viết tắt
Giải nghĩa
SOA
Service-oriented architecture
WCF
Windows Communication Foundation
OAuth
Open standard for authorization
BTS
Base transceiver station
RESTful
Representational State Transfer
SOAP
Simple Object Access Protocol
JAXM
Java API for XML Messaging
CORBA
Common Object Request Broker Architecture
XSLT
Extensible Stylesheet Language Transformations
OAUTH

Open standard for Authorization
DCOM
Distributed Component Object Model
EJB
Enterprise JavaBeans
ORB
Object Request Broker
WSDL
Web Services Description Language
PDA
Personal Digital Assistant
BVT
Ban Viễn Thông


9

Mở đầu
Hiện nay, trên thế giới nói chung và Việt Nam nói riêng, việc ứng dụng các sản
phẩm phần mềm vào quản lý doanh nghiệp, xử lý các nghiệp vụ của doanh nghiệp là
nhu cầu tất yếu. Từ các ứng dụng đơn lẻ như: quản lý nhân sự tiền lương, quản lý
công nợ, quản lý tài chính, quản lý và chăm sóc khách hàng, vv… đến một giải pháp
tổng thể như HRM (Human Resource Management) hay ERP (Enterprise Resource
Planning), tất cả đã và đang mang lại cho doanh nghiệp nhiều lợi ích thiết thực.
Tập đoàn bưu chính viễn thông Việt Nam - VNPT là một tập đoàn lớn với nhiều
tổng công ty, công ty thành viên, hoạt động triên nhiễu lĩnh vực khác nhau trong đó có
công ty Viễn thông Vinaphone. Với đặc thù hoạt động của mình, công ty phải sử dụng
hệ thống phần mềm hỗ trợ quản lý điều hành viễn thông để phục vụ công tác quản lý
điều hành công ty.
Quá trình hoạt động và phát triển của công ty đòi hỏi thường xuyên phải nâng cấp

hệ thống phần mềm cũ đồng thời xây dựng các hệ thống phần mềm mới nhằm đáp ứng
được yêu cầu ngày càng cao trong công tác quản lý, báo cáo, giám sát hoạt động của
công ty trong thời kỳ mới.
Hệ thống phần mềm hỗ trợ quản lý và điều hành viễn thông là một hệ thống bao
gồm nhiều module như Phát triển thuê bao, Quản lý mạng cáp ngoại vi, Giao tiếp với
các thiết bị tổng đài, Quản lý sự cố, Quản lý đánh số, … đa phần được xây dựng trên
nền tảng cũ (mô hình Client Server, ngôn ngữ lập trình Visual basic và CSDL Oracle,
…) vì vậy độ phức tạp lớn dẫn đến chi phí phát triển và bảo trì cao. Bên cạnh đó, hệ
thống còn phải đối mặt với các khó khăn trong xu thế mới như vấn đề an ninh bảo mật,
vấn đề tái sử dụng và mở rộng các hệ thống sẵn có, vấn đề về sự không tương thích
giữa hệ thống BVT với các hệ thống phần mềm chạy trên các nền tảng khác của các
đơn vị được phối hợp triển khai như kết nối với Hệ thống tính cước của các đơn vị
Viễn thông tỉnh thành, Hệ thống xác thực Visa của công ty Điện toán và Truyền số
liệu (VDC), Hệ thống MyTV Portal của công ty Phần mềm và truyền thông VASC,
…
Để khắc phục các nhược điểm trên, các thành viên trong đội ngũ phát triển TOS
cũng như cá nhân tôi luôn trăn trở tìm kiếm các giải pháp mới để áp dụng. Hiện nay,
10

một giải pháp mới đang được cộng đồng công nghệ thông tin rất quan tâm, đó là “Kiến
trúc hướng dịch vụ” (Service-oriented Architecture - SOA). Giải pháp này được kỳ
vọng là chìa khóa giải quyết được các vấn đề phức tạp và sẽ là “xu thế trong tương
lai”.
Ngoài phần giới thiệu, kết luận và phụ lục. Luận văn được chia thành 4 chương trình:
Chương 1 – Tổng quan các công nghệ phân tán. Chương này giới thiệu một cách
tổng quan những công nghệ chính được sử dụng để phát triển các hệ thống phân tán, so
sánh ưu và nhược điểm của các công nghệ cũng như tiền đề để lựa chọn giải pháp cho
bài toán đang nghiên cứu tìm hiểu.
Chương 2 – Kiến trúc hướng dịch vu (SOA) và công nghệ WCF. Chương này đi
tìm hiểu về kiến trúc SOA như một giải pháp cho hệ thống phân tán, cơ chế hoạt động,

các tính chất đặc điểm của kiến trúc SOA. Tìm hiểu công nghệ dịch vụ Web WCF của
Microsoft để lý giải cho việc lựa chọn công nghệ này là giải pháp cho bài toán đã đặt ra.
Chương 3 – Nghiên cứu và xây dựng giải pháp cho bài toán quản lý sự cố trạm
BTS. Ở chương này, ta tiến hành khảo sát và phân tích bài toán Quản lý sự cố BTS –
một trong 9 bài toán của hệ thống phần mềm quản lý mạng viễn thông. Từ đó áp dụng
kiến trúc và công nghệ đã nghiên cứu ở các chương trước cho bài toán.
Chương 4 – Nghiên cứu xây dựng giải pháp xác thực bảo mật dịch vụ web với
Oauth và Xauth. Ở chương này luận văn tìm hiểu một số giải pháp xác thực bảo mật
từ đó đề xuất xây dựng giải pháp bảo mật xác thực, ủy quyền truy xuất tài nguyên Oauth,
đồng thời cải tiến phương pháp xác thực Xauth phục vụ việc xác thực tài khoản người
dùng với phần mềm trên các môi trường thiết bị di động.
11

CHƯƠNG 1: TỔNG QUAN CÁC CÔNG NGHỆ PHÂN TÁN
1.1. Hoàn cảnh ra đời
Tập đoàn bưu chính viễn thông Việt Nam (VNPT) là một tập đoàn viễn thông lớn với
nhiều tổng công ty, công ty thành viên hoạt động trên nhiều lĩnh vực khác nhau: Bưu
chính, viễn thông, kỹ thuật, dịch vụ, thiết bị, vv
Trong thời gian gần đây, tập đoàn có nhiều sự thay đổi trong quy trình quản lý, điều
hành các công ty thành viên, cùng với yêu cầu ngày càng cao trong công tác giám sát
điều hành
Hiện tại trong nội bộ các công ty trực thuộc tập đoàn đang sử dụng rất nhiều phần mềm
hỗ trợ các công tác quản lý. Các phần mềm này có tính chất phức tạp và không đồng
nhất về nền tảng công nghệ. Việc xây dựng hệ thống quản lý điều hành viễn thông mới
phải thực hiện song song với việc tái sử dụng lại các thành phần của hệ thống cũ. Điều
này nảy sinh khó khăn trong việc giao tiếp giữa các hệ thống khác nhau chưa được đáp
ứng.
Bên cạnh đó, việc phát triển quy mô của các doanh nghiệp, triển khai với nhiều chi
nhánh cũng gặp nhiều khó khăn do các phần mềm chưa đáp ứng được yêu cầu bảo mật
khi trao đổi thông tin qua môi trường Internet.

Với đặc thù các chi nhánh áp dụng phần mềm quản lý phân bố rải rác trong cả nước dẫn
đến chi phí phát sinh khi triển khai, nâng cấp và bảo trì hệ thống tốn kém thời gian và
công sức.
Hiện trạng của hệ thống hệ thống cũ đòi hỏi việc xây dựng được giải pháp cho hệ thống
mới nhằm khắc phục những khó khăn và hạn chế đang tồn tại. Việc lựa chọn công nghệ
phù hợp và đánh giá chất lượng của hệ thống là rất quan trọng cho tập đoàn trong việc
quản lý và điều hành doanh nghiệp.
Do vậy các tiêu chí được đặt ra đối với công nghệ sử dụng cho hệ thống mới:
- Tối ưu hóa việc tái sử dụng lại các hệ thống hiện có mà chưa thể thay thế được
- Tạo môi trường đồng nhất cho nhu cầu chia sẻ, tương tác trao đổi của các hệ thống
hiện có
- Đảm bảo an toàn, bảo mật thông tin giữa các hệ thống trên Internet.
- Giảm thiểu chi phí cài đặt, nâng cấp, bảo trì hệ thống tại các chi nhánh
Dựa trên các tiêu chí đã đặt ra có thể thấy kiến trúc phù hợp với yêu cầu hệ thống mới
là kiến trúc phân tán. Ta sẽ tìm hiểu các công nghệ hỗ trợ kiến trúc này và tìm giải pháp
công nghệ phù hợp nhất cho bài toán.
1.2. Một số mô hình trong hệ thống phân tán
Ba kiến trúc phân tán phổ biến nhất hiện nay là DCOM, CORBA và EJB.
Các kiến trúc này là sự mở rộng của hệ thống hướng đối tượng bằng cách cho phép
phân tán các đối tượng trên mạng. Đối tượng đó có thể không nằm trong vùng không
12

gian ứng dụng, hoặc nằm trên một máy khác không chứa ứng dụng nhưng vẫn được
tham chiếu sử dụng như một phần ứng dụng.
1.2.1. CORBA - Common Object Request Broker Architecture
CORBA là một tiêu chuẩn được định nghĩa bởi Object Managerment Group (OMG).
Nó thiết kế nhằm mục đích để tạo thuận lợi cho việc giao tiếp giữa các hệ thống được
triển khai trên các nền tảng khác nhau [1].
Đây là một kiểu kiến trúc phân tán mang đặc tính: mở, độc lập với nền tảng và không
phụ thuộc vào ngôn ngữ lập trình.

Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc CORBA [1]
CORBA cho phép các ứng dụng giao tiếp nhau mà không cần biết vị trí và ai đã tạo
ra.
ORB là thành phần trung gian phục vụ việc trao đổi giữa Client/ Server thông qua
các Object. Với ORB, client có thể triệu gọi một phương thức trên object server một
cách thông suốt mà object đó có thể nằm trên cùng một máy hay mạng máy tính. ORB
có trách nhiệm tìm kiếm object mà có thể hiện thực các yêu cầu, truyền thông số, gọi
phương thức của nó và trả về kết quả. Client không cần phải biết vị trí của object, ngôn
ngữ lập trình, hệ điều hành hay bất kỳ khía mà nó không phải là thành phần của giao
diện object.
Trong mô hình client/server, những nhà phát triển có thể sửa dụng những phương
pháp thiết kế hay những chuẩn riêng của mình để phát triển các ứng dụng. Với ORB,
13

giao thức được định nghĩa với những giao diện ứng dụng thông qua việc đặc tả không
phụ thuộc ngôn ngữ mô tả, IDL.
Ưu điểm của CORBA: có thể thoả mãn mọi ngôn ngữ, nền tảng phần cứng, giao thức
mạng và công nghệ để phát triển CORBA.
Nhược điểm: là ngôn ngữ lập trình cấp thấp, khó học và cần đội ngũ phát triển có
kinh nghiệm. Các đối tượng CORBA khó có thể tái sử dụng.

1.2.2. DCOM – Distributed Component Object Model
Kiến trúc DCOM được phát triển xoay quanh mục tiêu thúc đẩy khả năng tương tác
giữa các phần mềm. Kiến trúc này hỗ trợ một dạng “Software Bus”, ở đó các thành phần
của phần mềm có thể được tái sử dụng và được hợp nhất với các thành phần khác tương
đồng [2].

Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc DCOM
Ưu điểm:

- Kiến trúc DCOM mang tính ổn định, hoạt động không phụ thuộc vào vị trí địa lý,
quản lý kết nối hiệu quả và dễ dàng mở rộng.
- Kiến trúc này phù hợp với các doanh nghiệp sử dụng các ứng dụng cùng chạy trên
nền Windows.
Nhược điểm: Các công nghệ trong kiến trúc DCOM chỉ chạy được trên nền windows.
1.2.3. EJB – Enterprise Java Bean
14

Kiến trúc Java Bean định nghĩa một thành phần Java ở server-side và một giao diện
lập trình cho các ứng dụng server. Các nhà phát triển sẽ xây dựng các thành phần, được
gọi là enterprise beans, thành phần này chứa lớp Bussiness Logic của doanh nghiệp.
Enterprise beans chạy trên server EJB để cung cấp các dịch vụ giao dịch và bảo mật cho
beans. Các nhà phát triển sẽ không phải lo lắng về việc phải lập trình cấp thấp hay các
dịch vụ phức tạp mà chỉ cần tập trung vào giải quyết các vấn đề ở tầng cao hơn.[3]
EJB bao gồm 3 tầng: tầng trình diễn, tầng xử lý nghiệp vụ, tầng thứ 3 là các tài nguyên
như cơ sở dữ liệu máy chủ.
Do EJB là một kiến trúc độc lập nền tảng nên nó phù hợp với những hệ thống đòi hỏi
khả năng tích hợp từ nhiều ứng dụng. Tuy nhiên, EJB không phải là một chuẩn mở dẫn
đến kiến trúc này hạn chế trong khả năng giao tiếp với các chuẩn khác.


Hình 3: Mô hình kiến trúc EJB

1.3. Kết luận chương 1
Tóm lại, các kiến trúc trên đều hướng đến vấn đề xây dựng kiến trúc hướng dịch vụ
nhưng chúng còn gặp phải một số vấn đề như:
- Tight coupling (tính ăn khớp): kiến trúc triển khai cài đặt phía nhà cung cấp và phía
sử dụng dịch vụ phải giống nhau.
- Những chuẩn trên đa phần là những chuẩn đóng. Ví dụ: đối tượng Java trong mô hình
EJB chỉ trao đổi được với các đối tượng cùng mô hình và không thể trao đổi được với

các đối tượng DCOM.
15

- Lượng thông tin trong mỗi lần giao dịch là ít, được thực hiện nhiều lần vì vậy dẫn
đến chiếm dụng băng thông sử dụng và thời gian đáp trả dữ liệu nhanh.
- Một vấn đề đặt ra là làm thế nào để các hệ thống phân tán phát triển trên các công
nghệ khác nhau có thể giao tiếp được với nhau? Cách tiếp cận mới này đáp ứng được
yêu cầu đó. Đó là cách tiếp cận theo kiểu “kiến trúc hướng dịch vụ.”


16

CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ WCF

2.1. Giới thiệu kiến trúc hướng dich vụ SOA
2.1.1. Tổng quan
Hơn 40 năm qua hệ thống CNTT đã phát triển theo cấp số nhân, trong quá trình phát
triển đó, các công ty phần mềm đã tạo ra nhiều kiến trúc xử lý phức tạp. Khả năng xử
lý của các kiến trúc truyền thống đã đạt tới giới hạn của mình, trong khi nhu cầu về năng
lực xử lý ngày càng tăng cao. Đòi hỏi công nghệ phần mềm phải đưa ra được kiến trúc
có thể đáp ứng những nhu cầu đó từ phía doanh nghiệp. Ngoài ra các kiến trúc này phải
thỏa mãn những yêu cầu về giảm chi phí, tăng khả năng tích hợp với các hệ thống của
đối tác và khách hàng [4].
Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một phương pháp thiết kế
và tích hợp các phần mềm, chức năng hệ thống theo dạng module, trong đó mỗi module
đóng vai trò là một “dịch vụ có tính loose coupling” và có khả năng truy cập thông qua
môi trường mạng. Một cách đơn giản thì một hệ thống SOA là tập hợp các dịch vụ được
chuẩn hoá trên mạng, trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ.
SOA có ba đối tượng chính minh hoạ trong hình sau:
Hình 4: Sơ đồ cộng tác trong SOA hiện nay

 Service Provider: Cung cấp stateless service phục vụ cho một nhu cầu nào đó.
User (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần
sử dụng đang hoạt động.
 Serive Consumer: User sử dụng service được cung cấp bởi Service Provider.
http://hostname/service.
wsdll
SOAP
UDD
Service
Consume
r
Service
Registry
Service
Provider
W
S
D
L
<xml> data </xml>
find
publish
17

 Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider
khác nhau, Service Consumer dựa trên những thông tin này để tìm kiếm và lựa
chọn Service Provider phù hợp.
SOA cung cấp các giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện
nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triến khai theo mô
hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là điều kiện cơ sở, nền tảng

để tích hợp, tái sử dụng những tài nguyên hiện có.
Tư tưởng về một kiến trúc phần mềm hướng dịch vụ đã có từ các mô hình CORBA,
DCOM (mô hình của Microsoft), EJB (mô hình của java) tuy nhiên những cách tiếp cận
này còn gặp nhiều hạn chế (như luận văn đã phân tích ở trên). Kiến trúc SOA không chỉ
cải tiến đáng kể mà còn đem đến nhiều ưu điểm nổi trội hơn các mô hình cũ.
2.1.2. Các nguyên tắc chính của hệ thống SOA
Một hệ thống SOA phải đảm bảo đủ 4 nguyên tắc chính sau:
- Sự phân định rạch ròi giữa các dịch vụ
Do có sự tách biệt giữa thành phần giao tiếp và thành phần thực hiện dịch vụ trong
kiến trúc hướng dịch vụ.
Các dịch vụ này sẽ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao
tiếp. Thành phần này sẽ quy định những dạng thông điệp trong quá trình trao đổi: thông
điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý. Và đây chính là
cách duy nhất để các đối tượng bên ngoài có thể truy cập vào thông tin và chức năng
của dịch vụ. ta chỉ cần gửi thông điệp được định dạng đến trước để yêu cầu dịch vụ mà
không cần biết thông điệp đó sẽ được xử lý như thế nào.
- Các dịch vụ tự hoạt động
Các dịch vụ cần được triển khai và hoạt động như một thực thể độc lập mà không phụ
thuộc vào các dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó không bị
sụp đổ khi có sự cố.
Để thực hiện điều này, các dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình
hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp dịch vụ cộng tác của
nó bị hỏng, đồng thời sử dụng các biện pháp bảo mật để tránh các cuộc tấn công ồ ạt từ
bên ngoài vào như gửi thông điệp lỗi hoặc thông điệp ồ ạt.
- Các dịch vụ chia sẻ lược đồ
18

Các dịch vụ nên cung cấp thành phần giao tiếp (Interface) của nó ra bên ngoài và hỗ
trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu
(Schema) chuẩn. Như thế hệ thống sẽ có tính dễ liên kết và dễ dàng mở rộng

- Tính tương thích của các dịch vụ dựa trên chính sách
Một dịch vụ muốn tương tác với các dịch vụ khác thì phải thoả mãn các chính
sách (Policy), các yêu cầu (Requirements) của dịch vụ đó như: mã hoá, bảo mật. Mỗi
dịch vụ phải cung cấp công khai các chính sách và các yêu cầu bảo mật của mình.
2.1.3. Các tính chất của hệ thống SOA
- Loose coupling
Có 2 dạng đặc tính mô tả mối kết hợp giữa các modul trong kiến trúc phần mềm:
loose (rời) và tigh (chặt). Trong đó các mối kết hợp mang đặc tính loose có các ràng
buộc được mô tả một cách rõ ràng. Ngược lại, với đặc tính tigh, các ràng buộc của mối
kết hợp không được mô tả trước. Các ứng dụng hiện nay đều hướng tới đặc tính loose
coupling nhằm tăng tính tường minh và khả năng kết nối giữa các thành phần.
SOA thể hiện tính loose coupling thông qua việc sử dụng Contract and Binding (Hợp
đồng và ràng buộc). Khi bắt đầu sử dụng dịch vụ, người dùng sẽ gửi yêu cầu tới đối
tượng Registry để yêu cầu các thông tin của dịch vụ. Lúc này Registry trả lại thông tin
của các dịch vụ thỏa mãn tìm kiếm. Bên sử dụng dịch vụ sẽ lựa chọn dịch vụ cần sử
dụng và tiến hành thực thi các nhiệm vụ theo mô tả của dịch vụ đó. Việc sử dụng dịch
vụ trong SOA không phụ thuộc vào tập tin cài đặt mà dựa vào hợp đồng và các ràng
buộc sử dụng dịch vụ.
Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống đầu
cuối. Mỗi hệ thống có thể tự quản lý độc lập làm tăng hiệu suất, khả năng mở rộng và
khả năng đáp ứng cao. Loose coupling làm tách biệt giữa bên cung cấp và bên sử dụng,
nhưng nó đòi hỏi các interface phải theo một chuẩn và cần một thành phần trung gian
quản lý để trung chuyển yêu cầu giữa các hệ thống đầu cuối
- Tái sử dụng dịch vụ
Do SOA chạy trên môi trường mạng, các dịch vụ được đăng ký trên Internet giúp
việc tìm kiếm, chia sẻ và tài sử dụng được thực hiện dễ dàng.
Một số dịch vụ trong hệ thống SOA không cần tái sử dụng, những dịch vụ này sẽ
không cần Interface mô tả.
Việc tái sử dụng trong SOA còn được thực hiện bằng cách kết hợp nhiều dịch vụ để
thực hiện các nhiệm vụ khác nhau.

19

Tái sử dụng trong SOA còn giúp loại bỏ bớt các thành phần trùng lặp trong hệ thống,
tối giản hóa việc cài đặt và đơn giản hóa quản trị hệ thống. Những dịch vụ dùng chung
bởi tất cả các ứng dụng của hệ thống SOA gọi là những shared infrastructure service
- Sử dụng dịch vụ bất đồng bộ
Trong kiến trúc SOA, phương thức triệu gọi bất đồng bộ hoạt động theo cơ chế sau:
Ban đầu, bên yêu cầu sẽ gửi một thông điệp với đầy đủ ngữ cảnh tới bên nhận. Bên
tiếp nhận yêu cầu sẽ thiết lập một “kênh thông điệp” để trả kết quả sau khi đã xử lý.
Trong quá trình xử lý của bên nhận yêu cầu, bên gửi yêu cầu không phải chờ yêu cầu
được xử lý xong, các yêu cầu tiếp theo sẽ được đưa vào 1 queue để xử lý lần lượt. Do
bên gọi không phải chờ đợi cho đến khi yêu cầu được xử lý xong và trả về nên không bị
ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết
một hệ thống SOA có thể hổ trợ gửi và nhận cả thông điệp đồngbộ và bất đồng bộ
- Quản lý các Policy (chính sách)
Mỗi một nhà cung cấp dịch vụ trên Internet đối với các dịch vụ cung cấp cho khách
hàng sẽ có một luật kết hợp riêng gọi là các Policy. Các Policy tạo ra sự thống nhất trong
việc tái sử dụng dịch vụ vì các Policy được thiết kế tách biệt và tuỳ vào mỗi ứng dụng
nên giảm tối đa các thay đổi phần mềm đồng thời có thể chia các nhóm làm việc mà
không cần phụ thuộc vào nhau (nhóm phát triển phần mềm và nhóm điều hành,nhóm hỗ
trợ).
- Khả năng cộng tác
Một trong những đặc tính nổi bật và quan trọng nhất trong kiến trúc SOA là khả năng
cộng tác (interoperability), khả năng này giúp cho các ứng dụng được phát triển trên các
nền tảng và ngôn ngữ khác nhau có thể giao tiếp được với nhau. Để làm được điều này,
mỗi dịch vụ phải đưa ra một giao diện tích hợp (Interface) có thể triệu gọi tới thông qua
một kết nối. Kết nối này được gọi là interoperable. Interoperable chứa một dạng giao
thức và cấu trúc sao cho các client kết nối tới nó đều có thể hiểu được. Do vậy,
interoperability hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và client.
Các định dạng dữ liệu này có thể được ánh xạ thông qua một ngôn ngữ đặc tả trung gian.

Đặc tả này sẽ chịu trách nhiệm ánh xạ giữa định dạng dữ liệu khả kết (interoperable)
đến định dạng của dữ liệu tuỳ thuộc vào hệ thống. Ví dụ Wrb Service là một đặc tả trung
gian cho giao tiếp giữa các hệ thống JAX-RPC, JAXM chuyển các đối tượng dạng Java
thành SOAP.
- Tự động dò tìm và ràng buộc động
20

SOA hỗ trợ cơ chế dò tìm dịch vụ (Service discovery). Khi một client cần sử dụng
một dịch vụ nào đó, SOA có thể tìm kiếm dịch vụ theo những tiêu chuẩn khi cần. Client
chỉ cần đơn giản hỏi một Registry về dịch vụ thoả mãn yêu cầu.


Hình 5: Cơ chế dò tìm dịch vụ động

Khi một khách hàng (hoặc đôi khi là một dịch vụ hoặc những người cần gọi dịch vụ
khác) cần phải kết nối với một dịch vụ đích , nó trước hết sẽ yêu cầu dịch vụ phát hiện
thông qua "Probe " kèm theo các tiêu chí của dịch vụ. Thông thường các tiêu chí này
chứa tên loại hợp đồng dịch vụ đích . Sau đó, các dịch vụ dò tìm sẽ tìm kiếm trong kho
lưu trữ của mình theo các tiêu chí . Kho lưu trữ có thể là một cơ sở dữ liệu , một bộ nhớ
cache phân phối hoặc một tập tin XML. Nếu nó phù hợp, dịch vụ phát hiện sẽ lấy các
thông tin của Endpoint (người dùng đầu cuối), nó được gọi là siêu dữ liệu Endpoint và
gửi lại . Và điều này được gọi là "Probe" (thăm dò). Cuối cùng là client nhận được các
siêu dữ liệu phát hiện Endpoint và sẽ sử dụng các Endpoint này để kết nối với dịch vụ
đích .
Bên cạnh đó thăm dò , dịch vụ phát hiện nên chịu trách nhiệm cho biết có một dịch
vụ mới có sẵn khi nó trực tuyến , cũng như dừng lại khi nó đi offline .Tính năng này
21

được đặt tên là "Announcement" (thông báo). Khi một dịch vụ bắt đầu và dừng lại, nó
sẽ thông báo cho các dịch vụ dò tìm.

Hình 6: Cơ chế phát hiện một dịch vụ khi dịch vụ đó Online
- Đặc tính Self – healing (tự hồi phục)
Đặc tính này cho phép một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không
cần đến sự can thiệp của con người. Đây là một yếu tố quan trọng trong các ứng dụng
hệ thống phân tán.
Trong SOA, có thể có nhiều dịch vụ được tích hợp với nhau để thực hiện một công
việc, mỗi dịch vụ trong hệ thống đó luôn tiềm ẩn nguy cơ ngừng bất cứ lúc nào, nhất là
những ứng dụng tổ hợp của nhiều dịch vụ được phát triển bởi nhiều nhà cung cấp khác
nhau. Điều này làm cho độ tin cậy của hệ thống giảm sút, điều này đòi hỏi các dịch vụ
phải có khả năng phục hồi của sau khi gặp lỗi. Hạ tầng mạng phải cho phép các kết nối
động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một kiến trúc hỗ trợ kết
nối và thực thi động như thế sẽ có khả năng tự phục hồi cao hơn kiến trúc không hỗ trợ
tính năng này.
Một tính chất cơ bản khác của hệ thống hướng dịch vụ là: có sự tách biệt giữa interface
và cài đặt, nên có thể có nhiều cài đặt khác nhau cho một interface. Nếu một thể hiện
dịch vụ nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho
22

khách hàng mà không bị ảnh hưởng gì. Khả năng này có được nghĩa là client chỉ tương
tác với interface của dịch vụ chứ không tương tác trực tiếp tới cài đặt của dịch vụ.
2.1.4. Lợi ích của SOA
SOA hiện nay được các doanh nghiệp lựa chọn là một giải pháp hiệu quả, tiết
kiệm chi phí và phù hợp với nền tảng công nghệ hiện tại vì SOA có những ưu điểm sau:
- SOA cho phép sử dụng lại những thành phần có sẵn
Đây là một trong những ưu điểm nổi bật và quan trong nhất của SOA, đặc điểm này
giúp các doanh nghiệp có thể sử dụng lại được những tài nguyên có sẵn, từ đó giúp giảm
chi phí cho phần kiến trúc và tích hợp. Ngoài ra nó còn giúp giảm chi phí trong việc
phải mua hoặc phát triển phần mềm mới khi nâng cấp, thay đổi công nghệ.

Việc tái sử dụng các thành phần này đem lại rất nhiều lợi ích, thứ nhất là giảm tính
dư thừa, thứ hai là sử dụng lại được những thành phần sẵn có để thiết kế phần mềm mới,
giảm chi phí phát triển cho từng phần độc lập của mỗi tính năng mới chưa có. Với SOA,
thay vì phải “đập bỏ làm lại”, chúng ta chỉ cần tạo các cầu nối tích hợp giữa các ứng
dụng và hệ thống trên môi trường khác nhau.
- SOA mang đến giải pháp ứng dụng tổ hợp cho doanh nghiệp
SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới bằng cách kết hợp chức
năng từ các hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết. Tức là
một số tiến trình cũ có khả năng được kết hợp với nhau bên trong một cổng thông tin
(portal) giúp cho người dùng có thể truy cập một lần mà vẫn có thể có hàng loạt thông
tin về các sản phẩm của các doanh nghiệp. Với SOA, một ứng dụng tổng hợp có thể
được tổng hợp dễ dàng bất kể sự khác nhau về địa lý hoặc công nghệ phát triển dịch vụ
đó. Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí và tăng
hiệu quả kinh doanh.
- SOA cho phép tăng tính linh hoạt khi triển khai cài đặt
Với đặc tính loose coupling của SOA, phía triệu gọi dịch vụ không cần quan tâm đến
địa chỉ hay công nghệ cài đặt dịch vụ. Việc triệu gọi dịch vụ thông qua một giao diện
chuẩn nên giúp cho các lập trình viên tránh được việc phải lặp lại các công việc tạo mới
các service có khả năng hiểu được mọi công nghệ sử dụng trong cùng một hệ thống.
Một ưu điểm nữa, đó là với một hệ thống SOA, các doanh nghiệp dễ dàng cung cấp
các dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng. Đối tác đó không cần biết cách
thức cài đặt và công nghệ của dịch vụ như thế nào. Tương tự, nếu đối tác đó cũng cài
đặt hệ thống SOA thì việc tích hợp và sử dụng các dịch vụ cũng dễ dàng hơn nhiều.
23

Cuối cùng, tính loose coupling tăng khả năng triển khai. Chỉ cần bọc những thành
phần sử dụng interface ứng dụng lại thành một dịch vụ, ta đã có một thành phần dịch vụ
độc lập trong hệ thống SOA như những dịch vụ khác.
- SOA cho phép xây dựng hệ thống thích ứng với những thay đổi trong tương lai
Với những hệ thống phần mềm lớn như hệ thống viễn thông, ngân hàng, vv… Việc

phải thay đổi, cập nhật các nghiệp vụ, yêu cầu diễn ra một cách thường xuyên. Bên cạnh
đó là việc mở rộng phạm vi của hệ thống đòi hỏi sự linh hoạt và mềm dẻo trong kiến
trúc phần mềm. Để đáp ứng được những yêu cầu này, SOA là sự lựa chọn có tính khả
thi nhất cho các doanh nghiệp.
- Hỗ trợ đa thiết bị và đa nền tảng
SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới. Điều này cho
phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau như các Browser, thiết bị di động như
điện thoại, pager, PDA… sử dụng cùng một chức năng mà vẫn có thông tin trả về tuỳ
theo dạng thiết bị. Tính chất độc lập về công nghệ này của SOA tiết kiệm rất nhiều cho
các công ty về mặt chi phí, đặc biệt là giai đoạn các công nghệ phát triển đa dạng như
hiện nay.
- Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp
Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách thêm
nhiều thể hiện (instance) của một service. Công nghệ chia tải (load - balancing) tự động
tìm và định tuyến yêu cầu đến thể hiện service thích hợp. Tương tự, SOA có thể chuyển
tiếp các yêu cầu đến một thể hiện khác khi cần, nhờ đó tăng khả năng sẵn sàng phục vụ
2.1.5. Kiến trúc phân tầng chi tiết của SOA
Hiện nay, SOA đang được nhiều bên tham gia nghiên cứu, phát triển. Mỗi bên đều
đưa ra mô hình kiến trúc theo quan điểm của mình. Do vậy vẫn chưa có một mô hình
chính thức nào cho kiến trúc SOA mà chỉ dừng ở dạng một phương pháp luận giúp
chúng ta tận dụng sức mạnh của các nguồn lực, tài nguyên khác nhau trong hệ thống để
tạo thành một thể thống nhất. Trong khuôn khổ luận văn, chúng ta sẽ đi xem xét mô
hình SOA với những đặc điểm chung nhất:

24


Hình 7: Kiến trúc phân tầng của SOA
- Connectivity Layer (Tầng kết nối)
Tầng kết nối cho phép kết nối các ứng dụng, dịch vụ và các tài nguyên ở bên dưới

thành các dịch vụ. Tầng kết nối có nhiệm vụ giao tiếp với nhà cung cấp, nó hoạt động
như một bộ chuyển đổi (adapter) giữa các ứng dụng phi dịch vụ và mạng các dịch vụ
khác. Các bộ chuyển đổi sẽ được lựa chọn tùy vào từng ứng dụng.
Tầng kết nối thường được sử dụng để kết nối tới CSDL. Nó cung cấp các tập hàm
API cho phép truy cập đến hầu hết các hệ CSDL thông dụng từ các ngôn ngữ lập trình
hiện đại. Với các ứng dụng enterprise thì mỗi nhà cung cấp cung cấp tập hàm API khác
nhau.
- Orchestration Layer (Tầng hòa phối)
Tầng này bao gồm những thành phần vừa đóng vai trò sử dụng dịch vụ, vừa cung cấp
dịch vụ. Những dịch vụ này sử dụng dịch vụ của tầng kết nối và các dịch vụ orchestration
khác để kết hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp
cao hơn, có hành vi gần với chức năng nghiệp vụ thực hơn. Trong tầng Orchestration
bao gồm 3 thành phần chính:
 Simple Composite Service (dịch vụ kết hợp đơn giản)
Đây là các dịch vụ kết hợp đơn giản có nhiệm vụ kết hợp các lời triệu gọi tới các dịch
vụ ở phía dưới. Chúng giúp việc tương tác với các dịch vụ cấp thấp trở lên đơn giản hơn
và che dấu đi tính phức tạp với những người sử dụng dịch vụ ở tầng cao.
 Process Service (dịch vụ tiến trình)
Đây là những dịch vụ định ra một tiến trình kết nối các dịch vụ ở cấp thấp hơn. Nó
hỗ trợ việc thiết kế các dịch vụ kết nối đến nhiều hệ thống enterprise bên dưới sau đó
thực thi như một tiến trình.
25

Process service có rất nhiều đặc tính phù hợp quy trình nghiệp vụ của doanh nghiệp
nên có rất nhiều nỗ lực để chuẩn hoá cách thức định nghĩa ra chúng. Tổ chức OASIS đã
đưa ra chuẩn WS – BPEL (Web Service Business Process Execution Language) cho
process service
 Data Service (dịch vụ dữ liệu)
Đây là những dịch vụ cung cấp dữ liệu thu thập được từ nhiều nguồn dữ liệu khác
nhau. Những dữ liệu này có thể cùng tồn tại trên nhiều CSDL và ứng dụng khác nhau.

Data service thường không chỉ được xem như một dịch vụ ở tầng orchestration mà nó
còn chịu trách nhiệm tương tác trực tiếp với CSDL bên dưới thông qua những phương
thức truy cập phi dịch vụ (non – service oriented access). Chúng cung cấp dữ liệu từ
những ứng dụng độc lập và kết hợp dữ liệu từ nhiều nguồn khác nhau.
Data service thường sử dụng một số ngôn ngữ truy vấn và cơ chế mô tả khác để xác
định quan hệ giữa những lược đồ dữ liệu (data schema). Các công nghệ phổ biến hiện
nay là SQL, XSLT và Xquery trong đó XSLT và Xquery là hai công nghệ thuần về việc
truy vấn dữ liệu trong bối cảnh Web service vì chúng xử lý và kết xuất dữ liệu dạng
XML
- Composite Application Layer (tầng ứng dụng tổng hợp)
Trong quá trình xử lý, thông tin được truyền qua lại giữa nhiều dịch vụ trong hệ thống
kết quả cuối cùng được hiện thị tại các giao diện người dùng. Tầng ứng dụng tổng hợp
được xem là tầng cuối cùng tích hợp các dịch vụ để đưa thông tin đến giao diện người
sử dụng.
Tầng này đơn thuần chỉ sử dụng các dịch vụ và cung cấp các giao diện ứng dụng cho
người dùng đầu cuối. Dựa vào tính linh hoạt của SOA và đặc tính của các dịch vụ được
tổng hợp từ tầng orchestration, các ứng dụng có khả năng biểu diễn mọi loại thông tin
từ mọi nguồn thông tin, thậm chí cho phép người sử dụng gửi thông tin tổng hợp mà
thông tin đó sẽ được phân phối lại cho các hệ thống bên dưới.
Tầng ứng dụng tổng hợp chia làm hai tầng nhỏ hơn là portal và portlet. Một Portlet
được định nghĩa như một ứng dụng chạy trong một cửa sổ thành phần trong một ngữ
cảnh với sự tách biệt rõ ràng giữa Portlet và ngữ cảnh của nó. Portlet là thành phần cung
cấp và sử dụng dịch vụ. Có điều là chúng cung cấp một dạng dịch vụ giao diện đặc biệt
được thiết kế đặc biệt để sử dụng bởi một bộ UI Framework consumer (một Portal). Mỗi
Portlet sử dụng một số dịch vụ liên quan của tầng orchestration bên dưới và cho phép
người sử dụng gửi thông tin bổ sung. Công nghệ web hiện nay như Java Server Faces
(JSF) và ASP.NET đều hỗ trợ xây dựng portlet. Portal là một bộ khung tích hợp sử dụng