Sử dụng giải pháp Soa middleware vào tích hợp hệ thống corebanking incas (LV thạc sĩ)

HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

LÊ THANH HẢI

SỬ DỤNG GIẢI PHÁP SOA MIDDLEWARE VÀO TÍCH HỢP HỆ
THỐNG COREBANKING INCAS

LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hƣớng ứng dụng)

HÀ NỘI – 2017


HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

LÊ THANH HẢI

SỬ DỤNG GIẢI PHÁP SOA MIDDLEWARE VÀO TÍCH HỢP HỆ
THỐNG COREBANKING INCAS

CHUYÊN NGÀNH :
MÃ SỐ:

HỆ THỐNG THÔNG TIN
60.48.01.04

LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hƣớng ứng dụng)

NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS.TS. HÀ HẢI NAM

HÀ NỘI – 2017


i

LỜI CAM ĐOAN
Luận văn này là thành quả của quá trình học tập nghiên cứu của tôi cùng sự
giúp đỡ, tạo điều kiện của các quý thầy cô sau 2 năm tôi theo học chƣơng trình đào
tạo Thạc sĩ, chuyên ngành Hệ thống Thông tin của trƣờng Học viện Công nghệ Bƣu
chính Viễn thông.
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi. Nội dung của luận
văn có tham khảo và sử dụng một số thông tin, tài liệu từ các nguồn sách, tạp chí
đƣợc liệt kê trong danh mục các tài liệu tham khảo và đƣợc trích dẫn hợp pháp.

TÁC GIẢ

Lê Thanh Hải


ii

LỜI CẢM ƠN
Em xin đƣợc bày tỏ lòng kính trọng và biết ơn sâu sắc đến PGS.TS. Hà Hải
Nam đã trực tiếp hƣớng dẫn và tận tình chỉ bảo em trong suốt thời gian làm luận
văn tốt nghiệp.
Em xin chân thành cảm ơn toàn thể các thầy giáo, cô giáo Học viện Công
nghệ Bƣu chính Viễn thông đã tận tình chỉ bảo em trong suốt thời gian học tập tại
trƣờng.

Cuối cùng, em xin gửi lời cảm ơn tới gia đình, bạn bè, đồng nghiệp đã luôn
giúp đỡ và tạo điều kiện để em có thể hoàn thành tốt luận văn này.
Hà Nội, tháng 05 năm 2017
Học viên

Lê Thanh Hải


iii

MỤC LỤC
DANH MỤC KÝ HIỆU VIẾT TẮT .................................................................................. v
DANH SÁCH CÁC BẢNG .............................................................................................. vi
DANH SÁCH HÌNH VẼ .................................................................................................vii
MỞ ĐẦU ............................................................................................................................ 1
1. Tính cấp thiết của đề tài ................................................................................................. 1
2. Tổng quan vấn đề nghiên cứu ........................................................................................ 1
3. Mục đích nghiên cứu ...................................................................................................... 4
4. Đối tƣợng và phạm vi nghiên cứu .................................................................................. 5
5. Phƣơng pháp nghiên cứu ................................................................................................ 5
6. Cấu trúc luận văn ........................................................................................................... 6
CHƢƠNG I. TỔNG QUAN GIẢI PHÁP TÍCH HỢP HỆ THỐNG SOA
MIDDLEWARE ................................................................................................................ 7
1.

Kiến trúc SOA: ........................................................................................................... 7
Giới thiệu Kiến trúc hướng dịch vụ......................................................................... 7

1.1.
1.1.1.

Khái niệm ............................................................................................................ 7

1.1.2.

Các đặc điểm chính của dịch vụ .......................................................................... 8

1.1.3.

Các nguyên lý của SOA ...................................................................................... 9

1.1.4.

Tính chất của SOA ............................................................................................ 10

1.1.5.

Các ƣu điểm của SOA ....................................................................................... 11

1.2.

Xây dựng hệ thống theo kiến trúc SOA ................................................................. 11

1.2.1.

Mô hình tổng thể SOA ...................................................................................... 11

1.2.2.

Mô hình giao tiếp bằng thông điệp (message) trong SOA ................................ 13

1.2.3.

Mô hình kiến trúc triển khai của SOA............................................................... 14

1.2.3.1.

Kiến trúc triển khai của SOA và các thành phần ........................................... 14

1.2.3.2.

Phƣơng pháp luận cho việc triển khai kiến trúc SOA.................................... 16

2.

Các thành phần cấu thành hệ thống SOA Middeware .............................................. 19

2.1.

EMS và vai trò ....................................................................................................... 19

2.1.1.

Giới thiệu: .......................................................................................................... 19

2.1.2.

Vai trò ................................................................................................................ 20

2.1.3.

Các tính năng chính ........................................................................................... 20


iv

2.1.4.
2.2.

Các sản phẩm messaging ................................................................................... 21
ESB và vai trò........................................................................................................ 21

2.2.1.

Giới thiệu ........................................................................................................... 21

2.2.2.

Vai trò ................................................................................................................ 21

2.2.3.

Các tính năng chính ........................................................................................... 22

3.

Kết luận chƣơng I ..................................................................................................... 22

CHƢƠNG II. GIẢI PHÁP TÍCH HỢP CÁC DỊCH VỤ CỦA HỆ THỐNG
COREBANKING INCAS ................................................................................................ 23

1. Giải pháp xây dựng hệ thống Middleware tích hợp hệ thống Backend sử dụng các
sản phẩm của TIBCO ....................................................................................................... 24
2.

Mô tả corebanking INCAS và các dịch vụ liên quan: .............................................. 25

2.1.

Vấn tin số dư tài khoản CA (Current Account): .................................................... 26

2.2.

Vấn tin lịch sử giao dịch tài khoản CA ................................................................. 26

2.3.

Chuyển khoản giữa 2 tài khoản CA-CA ................................................................ 27

3.

Phân tích cấu trúc bản tin giao tiếp ABCS và Mbase ............................................... 28

3.1.

Bản tin MBase ....................................................................................................... 28

3.2.

Bản tin ABCS......................................................................................................... 35

4.

Kết luận chƣơng II .................................................................................................... 38

CHƢƠNG III. XÂY DỰNG HỆ THỐNG THỬ NGHIỆM ............................................ 39
1.

Các điều kiện đảm bảo triển khai thử nghiệm: ......................................................... 39

2.

Xây dựng giả lập hệ thống giao dịch ngân hàng ....................................................... 40

3.

Xây dựng luồng xử lý giao tiếp giữa hệ thống Middleware với Corebanking ......... 42

4.

Xây dựng hệ thống giả lập Corebanking .................................................................. 46

5.

Kết luận chƣơng III ................................................................................................... 46

KẾT LUẬN ...................................................................................................................... 47
TÀI LIỆU THAM KHẢO ................................................................................................ 48


v

DANH MỤC KÝ HIỆU VIẾT TẮT
Viết tắt
SOA
EAI
ESB
EMS
CNTT
CA
TPS

Tiếng Anh
Service Oriented Achitecture
Enterprise Application Integration
Enterprise Service Bus
Enterprise Message System
Current account
Transaction per second

Tiếng Việt
Kiến trúc hƣớng dịch vụ
Tích hợp ứng dụng doanh nghiệp
Trục dịch vụ doanh nghiệp
Hệ thống thông điệp doanh nghiệp
Công nghệ Thông tin
Tài khoản hiện tại
Giao dịch trên một giây


vi

DANH SÁCH CÁC BẢNG
Bảng 2.1: Quy trình vấn tin số dƣ [3] .......................................................................26
Bảng 2.2: Quy trình vấn tin lịch sử giao dịch [3] .....................................................26
Bảng 2.3: Quy trình chuyển khoản [3] ......................................................................27
Bảng 2.4: Bản tin MBase [5].....................................................................................28
Bảng 2.5: MBase Socket Header [5] .........................................................................28
Bảng 2.6: MBase DSP Header [5] ...........................................................................29
Bảng 2.7: MBase Header [5] ....................................................................................31
Bảng 2.8: ABCS Socket Header [5] ..........................................................................35
Bảng 2.9: ABCS DSP Header [5] .............................................................................36
Bảng 2.10: ABCS Message Header [5] ..................................................................38


vii

DANH SÁCH HÌNH VẼ
Hình 1.1: Sơ đồ tổng quan liên kết các hệ thống của ngân hàng hiện tại [5] .............2
Hình 1.2: Tích hợp ứng dụng ......................................................................................3
Hình 1.3: Kiến trúc khi áp dụng hệ thống SOA Middleware [4] ................................4
Hình 1.4: Mô hình SOA [11] ....................................................................................12
Hình 1.5: Kiến trúc SOA và các quy trình [11] ........................................................13
Hình 1.6: Giao tiếp bằng message.............................................................................13
Hình 1.7: Kiến trúc triển khai SOA [4] .....................................................................14
Hình 1.8: Kiến trúc tổng quan xây dựng ESB [4] .....................................................17
Hình 1.9: Các giai đoạn triển khai [4] .......................................................................17
Hình 1.10: Các thành phần tham gia xây dựng tích hợp [4] .....................................18
Hình 1.11: EMS [11] .................................................................................................19
Hình 1.12: ESB .........................................................................................................21
Hình 2.1: TIBCO ESB [5].........................................................................................24

Hình 2.2: Luồng tích hợp với Corebanking INCAS [4] ...........................................25
Hình 3.1: Server triển khai phần mềm TIBCO .........................................................39
Hình 3.2: Mô hình triển khai .....................................................................................40
Hình 3.3: Đăng nhập .................................................................................................40
Hình 3.4: Các dịch vụ................................................................................................41
Hình 3.5: Tra cứu số dƣ tài khoản .............................................................................41
Hình 3.6: Lịch sử giao dịch CA ................................................................................42
Hình 3.7: Chuyển khoản CA-CA ..............................................................................42
Hình 3.8: TIBCO-luồng tra cứu số dƣ ......................................................................43
Hình 3.9: TIBCO – luồng tra cứu lịch sử giao dịch ..................................................43
Hình 3.10: TIBCO – luồng chuyển khoản CACA ....................................................44
Hình 3.11: TIBCO – luồng xử lý bản tin truy vấn số dƣ ..........................................44
Hình 3.12: TIBCo – luồng xử lý bản tin lịch sử giao dịch .......................................45
Hình 3.13: TIBCO – luồng xử lý bản tin chuyển khoản CACA ...............................45
Hình 3.14: Hệ thống giả lập Corebanking ................................................................46


1

MỞ ĐẦU
1. Tính cấp thiết của đề tài
Hiện nay, các hệ thống Corebanking của ngân hàng đã đi vào hoạt động cho
đến bây giờ bình quân từ 10 đến 13 năm. Về mặt tổng thể, các hệ thống đã hỗ trợ
hiệu quả các hoạt động kinh doanh của Ngân hàng với sự tăng trƣởng đáng kể của
ngành và khối lƣợng giao dịch. Tuy nhiên, do các hệ thống giao dịch và các hệ
thống lõi của ngân hàng kết nối trực tiếp với Corebanking nên với nhu cầu tăng
trƣởng nhanh, khi triển khai các dịch vụ mới liên tục thì mô hình hệ thống hiện tại
gặp phải nhiều khó khăn và trở ngại:
 Nền tảng hệ thống không đồng nhất, thiếu các tiêu chuẩn, thiếu sự quản
lý tích hợp và tập trung.

 Các thông tin khách hàng không đƣợc quản lý tập trung, ví dụ, giữa hệ
thống ATM và INCAS.
 Kênh ngân hàng nhƣ nhân viên giao dịch chi nhánh, ATM, Internet
Banking, Phone Banking, vv… là hoàn toàn bị ngắt kết nối.
 Do thiếu các giải pháp theo chuẩn và phụ thuộc trực tiếp vào nền tảng của
các hệ thống cũ, cơ sở hạ tầng tổng thể khiến cho giải pháp thiếu linh
hoạt, khó mở rộng, dẫn đến nhiều vấn đề trong việc đáp ứng nhu cầu kinh
doanh.
Do đó, ngân hàng đã quyết định triển khai xây dựng hệ thống lớp giữa mềm
dẻo để đồng nhất tích hợp toàn bộ các hệ thống cơ sở hạ tầng CNTT.

2. Tổng quan vấn đề nghiên cứu
Cơ sở hạ tầng hiện tại của Ngân hàng nhƣ Hình 1 cho thấy Các dịch vụ corebanking đƣợc cung cấp bởi hệ thống Silverlake (INCAS). Các kênh front-end và
các hệ thống back-office tích hợp với INCAS trực tiếp hoặc thông qua một ESB tự
phát triển (sử dụng nền tảng Java).


2

Hình 1.1: Sơ đồ tổng quan liên kết các hệ thống của ngân hàng hiện tại [5]

Do thiếu các giải pháp theo chuẩn và phụ thuộc trực tiếp vào nền tảng của
các hệ thống cũ, cơ sở hạ tầng khiến cho mô hình hiện tại thiếu linh hoạt, khó mở
rộng, dẫn đến nhiều vấn đề trong việc đáp ứng nhu cầu kinh doanh:
 Tính mềm dẻo: hạn chế của các ứng dụng hiện tại đƣợc xây dựng trên các hệ
thống cũ hay các nền tảng độc quyền.
 Các quy trình thực hiện thủ công với rất ít hoặc không có ứng dụng tự động
hóa dẫn đến lỗi và mất mát dữ liệu.
 Các vấn đề về bảo mật dữ liệu.
 Dƣ thừa các ứng dụng với chức năng tƣơng tự nhau.

Hàng chục năm qua, nhiều kiến trúc phần mềm đã đƣợc xây dựng và triển
khai nhằm giải quyết các vấn đề này. Thế nhƣng độ phức tạp phần mềm vẫn cứ tiếp
tục tăng và dƣờng nhƣ đã trở nên vƣợt quá khả năng xử lý của các kiến trúc truyền
thống. Tốc độ và tải giao dịch tăng lên nhiều lần cũng đ i hỏi giao dịch giữa các
ứng dụng có kiến trúc mới ph hợp.
Vì vậy từ những năm đầu 2000 công nghệ thế giới đã chuyển biến theo
hƣớng xây dựng Enterprise Architecture xoay quanh trục thông tin bằng thông điệp


3

để tích hợp các hệ thống phần mềm với nhau đó là “tích hợp ứng dụng doanh
nghiệp” (Enterprise Application Integration - EAI).

Hình 1.2: Tích hợp ứng dụng

Nhƣng EAI vẫn còn tồn tại nhiều vấn đề khó khăn mà doanh nghiệp nào
cũng phải đối mặt:
 Phức tạp khi triển khai, vận hành.
 Các hệ thống trên các hạ tầng khác nhau khó có thể chia sẻ thông tin dẫn đến
tắc nghẽn.
 Chi phí cao do phụ thuộc vào bên thứ 3 cung cấp giải pháp.
Với các vấn đề trên ngân hàng cần một cách tiếp cận mới để giải quyết vấn
đề môi trƣờng không đồng nhất và tốc độ chóng mặt của sự thay đổi, nhu cầu phát
triển các dịch vụ mới và tích hợp các hệ thống khác với Corebanking mà không phải
thay đổi hoàn toàn hệ thống. Một hƣớng tiếp cận mới để giải quyết vấn đề môi
trƣờng không đồng nhất và tốc độ chóng mặt của nhu cầu liên kết các hệ thống,
cách tiếp cận đó gọi là “Kiến trúc hƣớng dịch vụ” Service Oriented Architecture
(SOA). Với kế hoạch phát triển, lãnh đạo ngân hàng đã quyết định xây dựng một hệ
thống Middleware với kiến trúc SOA (SOA - Kiến trúc hƣớng dịch vụ) với mục

đích nâng cao năng lực quản trị bằng cách tích hợp các hệ thống không đồng nhất
trên cơ sở các tiêu chuẩn mở, tăng cƣờng an ninh, giám sát và chất lƣợng dịch vụ
cải thiện.
Hệ thống SOA Middleware đóng vai tr xƣơng sống cho doanh nghiệp trong
việc đem lại tính mềm dẻo và hiệu quả trong kinh doanh bằng cách:
 Tách các kênh dịch vụ front-end khỏi sự phụ thuộc vào các nền tảng
back-end.


4

 Cung cấp một nền tảng Kiểm soát quy trình nghiệp vụ để xây dựng các
chức năng cốt lõi của ngân hàng.
 Cho phép một cơ sở hạ tầng tích hợp hƣớng dịch vụ, mạnh mẽ và chuẩn
hóa kết nối tới các ứng dụng back-end và các hệ thống.

Hình 1.3: Kiến trúc khi áp dụng hệ thống SOA Middleware [4]

Với hệ thống SOA Middleware, nhiều ngân hàng lớn trên thế giới đã áp dụng
thành công phục vụ cho việc tái sử dụng các dịch vụ có sẵn của Corebanking mà
không tác động thay đổi nền tảng Backend. Đơn cử nhƣ ngân hàng OCBC của
Singapore đã ứng dụng đƣợc cho 50% trên tổng 400 dịch vụ của hệ thống
Corebanking INCAS.
Luận văn này đƣợc thực hiện với mục đích áp dụng triển khai giải pháp
hệ thống Middleware với kiến trúc SOA, tích hợp các hệ thống phục vụ giao
dịch của ngân hàng với hệ thống Corebanking INCAS tại Việt Nam thành một
kiến trúc thống nhất về mặt dịch vụ và quản lý.

3. Mục đích nghiên cứu
 Áp dụng giải pháp SOA Middleware cho ngân hàng.

5

 Tích hợp các hệ thống phục vụ giao dịch với hệ thống Corebanking
INCAS theo chuẩn kiến trúc SOA.

4. Đối tƣợng và phạm vi nghiên cứu
4.1 Đối tƣợng nghiên cứu:
 Kiến trúc SOA, hệ thống SOA Middleware.
 Phƣơng thức giao tiếp với hệ thống Corebanking INCAS.

4.2 Phạm vi nghiên cứu:
 Các thành phần cấu thành hệ thống SOA Middleware.
 Đóng gói các luồng nghiệp vụ giao dịch của ngân hàng liên quan đến
Corebanking INCAS thành các dịch vụ có thể sử dụng lại.

5. Phƣơng pháp nghiên cứu
5.1 Phƣơng pháp nghiên cứu lý thuyết:
 Nghiên cứu lý thuyết và ứng dụng kiến trúc SOA trong các hệ thống
Công nghệ thông tin.
 Nghiên cứu dựa trên các kiến trúc tiêu chuẩn của OpenGroup và các nhà
cung cấp liên quan đến kiến trúc SOA
 Nghiên cứu lý thuyết về bản tin giao tiếp với hệ thống Corebanking.
 Tìm hiểu về luồng nghiệp vụ ngân hàng liên quan đến Corebanking
INCAS.

5.2 Phƣơng pháp thực nghiệm:
 Xây dựng bài toán áp dụng giải pháp kiến trúc SOA và hệ thống
Middleware vào hệ thống ngân hàng.

 Xây dựng các hệ thống ngân hàng giả lập: Corebanking INCAS.
 Xây dựng hệ thống Middleware tích hợp với các hệ thống giả lập và thực
hiện các nghiệp vụ ngân hàng.


6

6. Cấu trúc luận văn
Với mục tiêu đặt ra nhƣ vậy, nội dung và kết quả của luận văn đƣợc trình bày
qua 3 chƣơng nhƣ sau:
CHƢƠNG I. TỔNG QUAN GIẢI PHÁP TÍCH HỢP HỆ THỐNG SOA
MIDDLEWARE
Chƣơng này giới thiệu khái niệm về SOA, các thành phần cơ bản của một hệ thống
Middleware và kiến trúc khi xây dựng tích hợp với các hệ thống Backend.
CHƢƠNG II. GIẢI PHÁP TÍCH HỢP CÁC DỊCH VỤ CỦA HỆ THỐNG
COREBANKING INCAS
Trong phạm vi luận văn này sẽ tập trung tích hợp thành công, chuẩn hóa,
đóng gói các dịch vụ liên quan đến Corebanking INCAS thành các dịch vụ chuẩn có
thể sử dụng lại, xây dựng một khung kiến trúc để đảm bảo cho việc triển khai trên
quy mô lớn sau này.
Việc tích hợp này đƣợc thực hiện bằng cách xây dựng một trục tích hợp ứng
dụng ESB sử dụng các sản phẩm công cụ của TIBCO BusinessWorks, Adapters và
cơ chế truyền thông điệp - TIBCO Enterprise Message Service.
CHƢƠNG III. XÂY DỰNG HỆ THỐNG THỬ NGHIỆM
Trong phần xây dựng hệ thống thử nghiệm này sẽ sử dụng các sản phẩm của
TIBCO để xây dựng hệ thống SOA Middleware đóng vai tr trục xƣơng sống để
dẫn dắt và điều phối các dịch vụ giữa hệ thống giao dịch và hệ thống Corebanking
của ngân hàng mà không tác động trực tiếp vào cơ sở hạ tầng Backend.
Xây dựng hệ thống giả lập Corebanking INCAS với các dịch vụ đang có bao
gồm: Vấn tin tài khoản, Vấn tin lịch sử giao dịch,...Sau đó tiến hành xây dựng,

chuẩn hóa các dịch vụ theo chuẩn kiến trúc SOA, điểm mấu chốt để nghiên cứu
thành công là các dịch vụ đƣợc đóng gói một lần và có thể tái sử dụng cho các lần
triển khai các dịch vụ mới sau này mà không phát sinh chi phí phát triển quá lớn,
cung cấp dịch vụ mới cho khách hàng nhanh chóng.


7

CHƢƠNG I. TỔNG QUAN GIẢI PHÁP TÍCH HỢP HỆ THỐNG SOA
MIDDLEWARE
1. Kiến trúc SOA:
1.1. Giới thiệu Kiến trúc hướng dịch vụ
Kiến trúc SOA là kiến trúc dựa trên nền tảng tích hợp các dịch vụ, mỗi dịch vụ ở
đây đóng vai tr là một hay nhiều nghiệp vụ xuyên suốt trong hệ thống, không còn
khái niệm về việc kết nối point 2 point giữa các hệ thống riêng rẽ nhƣ trƣớc đây,
kiến trúc SOA điều hƣớng và quản lý mọi giao tiếp kết nối từ Front-end channels (
ví dụ chuyển tiền, nhận tiền, các nghiệp vụ khác) đến tới các hệ thống back-end (
core banking, card system) thông qua một trục tích hợp ESB duy nhất. Một dịch vụ
có thể cung cấp một hay nhiều nghiệp vụ của một hệ thống, đại diện cho hệ thống
đó hoặc một tổ hợp hệ thống tùy theo nghiệp vụ. Mọi thành phần tham gia trong
một nghiệp vụ đều trong suốt với ngƣời dùng cuối.
Kiến trúc SOA cũng có những khác biệt và lợi thế đối với từng nhà cung cấp,
tuy nhiên kiến trúc lớp giữa về căn bản cần có các thành phần sau:
Công cụ để tích hợp các hệ thống từ back-end, các hệ thống nối vào lớp giữa –
hay gọi là ESB, và thông qua lớp giữa giao tiếp với nhau. Kèm theo là các sản phẩm
tích hợp đã xây dựng sau khi triển khai trục tích hợp.
Công cụ để phát triển các dịch vụ chuẩn, công cụ để ghép nối các dịch vụ chuẩn
thành một service để có thể tái sử dụng liên tục trên toàn hệ thống hay trong một
phạm vi nhất định. Kèm theo là các dịch vụ cơ sở và dịch vụ SOA đã phát triển cho
từng giai đoạn theo yêu cầu nghiệp vụ

Công cụ để quản trị các phiên bản dịch vụ, giám sát và bảo mật.

1.1.1. Khái niệm
SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là
một cách tiếp cận hay một phƣơng pháp luận để thiết kế và tích hợp các thành phần
khác nhau, bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ thống
hoàn chỉnh. Kiến trúc SOA rất giống với cấu trúc của các phần mềm hƣớng đối
tƣợng gồm nhiều module. Tuy nhiên khái niệm module trong SOA không đơn thuần


8

là một gói phần mềm, hay một bộ thƣ viện nào đó. Thay vào đó, mỗi module trong
một ứng dụng SOA là một dịch vụ đƣợc cung cấp rải rác ở nhiều nơi khác nhau và
có thể truy cập thông qua môi trƣờng mạng. Nói một cách ngắn gọn, một hệ thống
SOA là một tập hợp nhiều dịch vụ đƣợc cung cấp trên mạng, đƣợc tích hợp lại với
nhau để cùng cộng tác thực hiện các tác vụ nào đó theo yêu cầu của khác hàng.
Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công
nghệ. Mặc dù SOA hoạt động đƣợc là nhờ công nghệ, nhƣng khách hàng cần phải
chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh các
phƣơng pháp thực hiện dự án, chính sách bảo trì và thay đổi để đạt đƣợc các lợi ích
về khả năng trƣởng thành và đáp ứng.
Dịch vụ (service) là vừa là khái niệm, vừa là thực thể quan trọng nhất, đóng
vai trò trung tâm trong mô hình SOA. Có nhiều quan điểm về khái niệm dịch vụ tùy
thuộc vào từng ngữ cảnh cụ thể. Trong mô hình SOA, dịch vụ đƣợc xác định cách
đơn giản là một mô đun phần mềm hay một chƣơng trình hoàn chỉnh đƣợc cấu trúc
để có thể liên kết với nhau một cách dễ dàng thông qua hình thức trao đổi thông
điệp. Đặc điểm chính của dịch vụ trong mô hình SOA thể hiện ở việc sử dụng dịch
vụ này sẽ đƣợc diễn ra liên tục và có tính lặp đi lặp lại. Đối tƣợng sử dụng dịch vụ
gồm nhiều thành phần khác nhau, có thể từ kiến trúc sƣ, nhà phát triển, nhà phân

tích thiết kế phần mềm, đến các khách hàng, đối tác hay chính những thành viên của
cơ quan, tổ chức. Kèm với việc xây dựng các dịch vụ, một mô hình dịch vụ cần
đƣợc thiết kế nhằm đảm bảo tính chất sử dụng lại, tƣơng tác liên thông và tích hợp
của toàn bộ qui trình nghiệp vụ cũng nhƣ giữa các hạ tầng công nghệ khác nhau của
hệ thống.

1.1.2. Các đặc điểm chính của dịch vụ
Có ranh giới rõ ràng (Boundaries Are Explicit): Mỗi service đƣợc xây
dựng dựa trên các giao chuẩn hóa đã đƣợc sử dụng rộng rãi. Chi tiết hiện thực của
mỗi service sẽ không đƣợc thể hiện ra bên ngoài. Mỗi service chỉ công bố một số
các giao của nó cho ngƣời sử dụng có thể d ng để gởi các yêu cầu và nhận kết quả
trả về.


9

Tính tự trị (Autonomous): Về mặt lý thuyết, mỗi service có tính độc lập
cao, có thể đƣợc xây dựng và đƣa vào sử dụng mà không phụ thuộc vào các service
khác.
Chia sẻ các đặc tả (Share the Schema and Contract, Not the Class): Về
mặt trao đổi dữ liệu, các service không truyền các class và type. Thay vào đó, các
class và type sẽ đƣợc đặc tả hình thức (data đƣợc đặc tả trong schema, behavior
đƣợc đặc tả thành các contract).
Tính tương thích dựa trên chính sách (Service Compatibility Is Based
on Policy): Sự tƣơng thích giữa các service đƣợc căn cứ vào các policy (chính
sách). Tƣơng thích về mặt cấu trúc dựa trên các đặc tả hình thức bao gồm contract
(dựa trên Web Service Description Language (WSDL) hoặc Business Process
Execution Language for Web Services (BPEL4WS)) và schema (XSD). Sự tƣơng
thích dựa trên policy cung cấp khả năng phân tích cũng nhƣ đảm bảo sự tƣơng thích
giữa các service.

1.1.3. Các nguyên lý của SOA
-

SOA tìm cách giải quyết một số vấn đề theo cách nhìn lấy ứng dụng làm
trung tâm. Có thể tóm gọn những phát biểu đó theo các nguyên lý nhƣ sau:

-

Ứng dụng phải mở ra khả năng cho phép các ứng dụng mới hoặc ứng dụng
đang tồn tại có thể sử dụng đƣợc. Nó cũng phải có khả năng kết nối tới các
dịch vụ đƣợc đƣa ra bởi các ứng dụng khác để tạo thành các dịch vụ cao cấp
hơn hay c n gọi là ứng dụng tổ hợp.

-

Sự khác biệt về công nghệ không thành vấn đề và khả năng tƣơng tác trở
thành mục tiêu then chốt.

-

Các chuẩn mở phải đƣợc thông qua để cho phép tích hợp giữa các doanh
nghiệp. Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp, nhiều đối tác
thậm chí có thể với cả khách hàng.

-

Phải chú ý tới việc quản lý và và đảm bảo khả năng có thể quản trị của hệ
thống để đảm bảo tính linh hoạt do ba nguyên tắc đầu tiên không bị xáo trộn
và xung đột với nhau.

10

Nói cách khác, SOA nhấn mạnh việc hạ thấp các rào cản truyền thống tới
khả năng tái sử dụng của ứng dụng. Tôn trọng nguyên tắc thiết kế này của SOA sẽ
giải quyết đƣợc bài toán lớn về vấn đề tích hợp cũng nhƣ bảo trì hệ thống phần
mềm đang là thách thức đối với các nhà phát triển công nghệ thông tin trong giai
đoạn hiện nay.

1.1.4. Tính chất của SOA
Kết nối lỏng lẻo: Vấn đề kết nối nói tới một số ràng buộc giữa các module
lại với nhau. Có 2 loại kết nối là lỏng lẻo và chặt chẽ. Các module có tính chất kết
nối lỏng lẻo có một số ràng buộc đƣợc mô tả rõ ràng trong khi các module có tính
kết nối chặt lại có nhiều ràng buộc không thể biết trƣớc. Hầu nhƣ mọi kiến trúc
phần mềm đều hƣớng đến tính kết nối lỏng lẻo giữa các module. Mức độ kết nối
của hệ thống ảnh hƣởng trực tiếp đến khả năng chỉnh sửa hệ thống. Kết nối càng
chặt bao nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra
Tái sử dụng: Bởi vì các dịch vụ đƣợc cung cấp trên môi trƣờng mạng và
đƣợc đăng ký ở một nơi nhất định nên chúng dễ ràng đƣợc tìm thấy và sử dụng lại.
Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến giao diện
mô tả. Các dịch vụ có thể đƣợc tái sử dụng lại bằng cách kết hợp lại với nhau theo
nhiều mục đích khác nhau. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành
phần trùng lặp và tăng tốc độ vững chắc trong cài đặt, nó c n giúp đơn giản hóa
việc quản trị.
Quản lý chính sách: Tập các chính sách là tập tất cả các qui tắc chung mà
mọi thành phần trong hệ thống đều phải tuân thủ. Khi sử dụng các dịch vụ chia sẻ
trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các chính
sách. Các chính sách cần đƣợc quản lý và áp dụng cho mỗi dịch vụ cả trong quá
trình thiết kế và trong thời gian triển khai.

Tự động dò tìm: SOA hỗ trợ khái niệm khai thác dịch vụ (service
discovery). Một ngƣời sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ
dựa trên một số tiêu chuẩn khi cần. Ngƣời sử dụng chỉ cần hỏi một registry về một
dịch vụ nào thỏa yêu cầu tìm kiếm.


11

Tự phục hồi: Với kích cỡ và độ phức tạp của những hệ thống phân tán ngày
nay, khả năng phục hồi của một hệ thống sau khi bị sự cố là một yếu tố rất quan
trọng. Một hệ thống tự phục hồi là hệ thống có khả năng tự phục hồi sau khi lỗi mà
không cần sự can thiệp của con ngƣời.
Độ tin cậy là mức độ đo khả năng của một hệ thống xử lý tốt nhƣ thế nào
trong tình trạng hỗn loạn. Trong SOA, các dịch vụ luôn có thể hoạt động hay ngừng
hoạt động bất cứ lúc nào, nhất là đối với những áp dụng tổng hợp từ nhiều dịch vụ
của nhiều tổ chức khác nhau

1.1.5. Các ƣu điểm của SOA
-

Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp.

-

Độc lập hệ thống : những service không phụ thuộc vào hệ thống và mạng cụ
thể.

-

Có khả năng tái sử dụng.

-

Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về
yêu cầu giao dịch.

-

Cho phép dễ dàng triển khai chƣơng trình, môi trƣờng chạy và quản lý
service dễ dàng hơn.

-

Hỗ trợ đa thiết bị và đa nền tảng.

1.2. Xây dựng hệ thống theo kiến trúc SOA
1.2.1. Mô hình tổng thể SOA
Hiện nay chƣa có một mô hình chính thức nào của SOA. Thật sự SOA là 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, nguồn tài
nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất. Mỗi một
công ty có một mô hình SOA khác nhau. Nhìn chung mô hình SOA có các đặc điểm
sau:


12

Hình 1.4: Mô hình SOA [11]

-

Tầng Connectivity: đây là tầng thấp nhất của SOA, có nhiệm vụ giao tiếp
trực tiếp với các thành phần khác nhƣ cơ sở dữ liệu, giao tiếp với các ứng
dụng khác, các web service… Vì vậy có thể coi đây là tầng vật lý của SOA.

-

Tầng Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và độc lập
với tầng vật lý phía bên dƣới. Tầng orchestration chứa các thành phần đóng
vai tr vừa là dịch vụ sử dụng vừa là những dịch vụ cung cấp. Những dịch vụ
này sử dụng nhữ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 những chức năng nghiệp vụ hơn.

-

Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục đích trình
diễn (presentation) và hiển thị thông tin cho ngƣời d ng cũng nhƣ cung cấp
một giao diện cho ngƣời d ng tƣơng tác với hệ thống nhƣ là một phần mềm
duy nhất. Tầng này có thể là các website, portal, các ứng dụng client mở
rộng (rich client), các thiết bị di động thông minh (smart device),…
Các thành phần khác: gồm có quy trình phát triển (development), quản lý

các dịch vụ (service management), và quản lý con ngƣời (governance). Nhƣ vậy có
thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổng hòa của rất
nhiều yếu tố: công nghệ, cơ sở hạ tầng, con ngƣời và quy trình nghiệp vụ.


13

Hình 1.5: Kiến trúc SOA và các quy trình [11]

1.2.2. Mô hình giao tiếp bằng thông điệp (message) trong SOA

Hình 1.6: Giao tiếp bằng message

Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau:
-

Độc lập nền: thông điệp (message) trở thành ngôn ngữ chung của các
platform và các ngôn ngữ lập trình khác nhau. Điều này đảm bảo các service
trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của
platform đó.

-

Giao tiếp bất đồng bộ: Ngƣời gửi và ngƣời nhận không cần phải chờ thông
điệp trả lời sau khi đã gởi đi một thông điệp. Điều này giúp cho ngƣời gửi và
ngƣời nhận tiếp tục xử lý công việc sau khi gửi thông điệp mà không cần
dừng thực thi để chờ thông điệp trả lời.

-

Giao tiếp tin cậy: các thông điệp từ bên gửi có thể đƣợc gửi đến một service
trung gian có nhiệm vụ lƣu trữ (store) các thông điệp. Service trung gian sẽ


14

chuyển tiếp (forward) thông điệp cho bên nhận khi bên nhận có thể xử lý yêu
cầu tiếp theo. Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽ

không bị thất lạc trong trƣờng hợp Receiver bị quá tải và không thể nhận
thêm yêu cầu mới.
-

Quản lý luồng: Việc trao đổi thông điệp theo cơ chế bất đồng bộ giúp ứng
dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có thể tạo ra
các luồng (thread) xử lý các công việc khác nhau.

-

Giao tiếp từ xa: Các thông điệp lƣu trữ thông tin về các đối tƣợng dữ liệu
dƣới dạng đặc tả hình thức thay thế việc phải serialization and deserialization
các đối tƣợng dữ liệu truyền qua mạng khi ứng dụng thực hiện gọi từ xa một
ứng dụng khác.

-

Bảo mật end-to-end: Thông điệp có thể lƣu trữ thông tin về hình thức bảo
mật của kênh giao tiếp. Điều này cung cấp khả năng điều khiển liên quan đến
bảo mật nhƣ xác thực và phân quyền.

1.2.3. Mô hình kiến trúc triển khai của SOA
1.2.3.1. Kiến trúc triển khai của SOA và các thành phần

Hình 1.7: Kiến trúc triển khai SOA [4]


15

-

Mô tả các thành phần trong sơ đồ kiến trúc:
o Front- end Channels: Các kênh thụ hƣởng dịch vụ, nghiệp vụ đƣợc
đƣa ra từ trục tích hợp dịch vụ, bao gồm: internetbanking, mobile
banking, ATM, partner gateway.v.v.
 Các hệ thống hƣởng thụ dịch vụ (Service Consumers): Kết nối
với tầng middleware thông qua các giao thức chuẩn; sử dụng
web-service với phƣơng thức SOAP over HTTP(s) hoặc SOA
over JMS.
o ESB: Trục tích hợp dịch vụ
 Kết nối trực tiếp với các hệ thống back-ends: Thông qua các
giao thức chuẩn(services), hoặc thông qua các adapters kết nối
có sẵn tùy thuộc vào hệ thống và công nghệ( TCP Sockets, DB
connector.v.v.)
 Xây dựng các dịch vụ tích hợp cốt lõi với các hệ thống backends, đƣa lên thành các dịch vụ chuẩn(service). Tổng hợp và
quản lý các dịch vụ cốt lõi cho các nghiệp vụ sử dụng, các
service consumenrs sử dụng.
o BPM:
 Là nền tảng quản lý quy trình của doanh nghiệp: Cho phép mô
hình hóa và triển khai các nghiệp vụ cho ngƣời dùng cuối.
o Khối Governance:
 Là một tập hợp các thành phần, công cụ hỗ trợ doanh nghiệp
quản lý xuyên suốt các dịch vụ, nghiệp vụ, các thành phần của
kiến trúc SOA
o Khối Business rules và in-memory event correlation(CEP):
 Đây là thành phần xử lý các sự kiện xảy ra đối với nghiệp vụ,
khi có các event liên quan đến chính sách kinh doanh thì phân
hệ này quyết định sử dụng dịch vụ, nghiệp vụ nào đƣợc xây
dựng trên BPM hoặc ESB để cung cấp cho nghiệp vụ

16

o Lớp trung gian đảm bảo các chính sách truy cập: -Access/Policy
Mediation
 Cho phép quản lý tập trung, bảo mật việc truy cập, sử dụng
dịch vụ, áp dụng các quy trình, quy định bảo mật dành cho dịch
vụ và các thành phẩn của kiến trúc SOA.
o Khối kết nối doanh nghiệp – doanh nghiệp B2B ( Business to
Business)
 Thực hiện việc tập trung hóa việc trao đổi thông tin với các đối
tác kinh doanh, đóng vai tr là cổng giao tiếp với sự cung cấp
đa giao thức(USSD, ISO8583, ISO 20022, IFX.v.v.)
 Thành phần này liên kết linh hoạt với các thành phần khác của
kiến trúc SOA tạo nên cổng cung cấp dịch vụ, sản phẩm của
doanh nghiệp cho các đối tác bên ngoài
o Back-ends:
 Toàn bộ các hệ thống của ngân hàng từ core banking đến các hệ
thống nhân sự, hệ thống thẻ, hệ thống tín dụng nội bộ.v.v.

1.2.3.2. Phƣơng pháp luận cho việc triển khai kiến trúc SOA
Quá trình xây dựng và triển khai kiến trúc SOA bao gồm các bƣớc cơ bản
sau:
-

Bƣớc 1: Thống nhất kiến trúc tổng quan và xác định lộ trình phát triển:
o Đƣa ra và thống nhất kiến trúc tổng quan trên toàn bộ hệ thống