ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN ĐỨC NGỌC ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ
TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG LUẬN VĂN THẠC SĨ Hà Nội - 2010
nhân tôi. Trong toàn bộ nội dung của luận văn, những điều được trình bầy hoặc là của
cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo
đều có xuất xứ rõ ràng và được trích dẫn hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy
định cho lời cam đoan của mình.
Hà Nội, ngày 30 tháng 5 năm 2010
Người cam đoan Nguyễn Đức Ngọc
LỜI CẢM ƠN
Trong quá trình học tập và hoàn thành luận văn tốt nghiệp, tôi đã nhận
được rẩt nhiều sự giúp đỡ, động viên từ thầy cô, gia đình và bạn bè. Tôi muốn bày tỏ
sự cảm ơn sâu sắc của mình tới tất cả mọi người.
Tôi xin bày tỏ sự cám ơn đặc biệt tới TS Nguyễn Ngọc Hóa, người đã định
hướng cho tôi trong lựa chọn đề tài, đưa ra những nhận xét quý giá và trực tiếp hướng
dẫn tôi trong suốt quá trình nghiên cứu và hoàn thành luận văn tốt nghiệp.
Tôi xin cảm ơn các thầy cô trong khoa CNTT - Trường Đại học Công nghệ
- ĐHQG Hà Nội đã dạy bảo tận tình cho tôi trong suốt khoảng thời gian học tập tại
trường.
Tôi xin cảm ơn toàn thể bạn bè đồng nghiệp tại Trung tâm Công nghệ
Thông tin Ngân hàng Đầu tư và Phát triển Việt Nam, đơn vị mà tôi đang công tác, đã
chia sẻ, giúp đỡ tạo điều kiện cho tôi tham gia khoá học và hoàn thành khoá luận này.
Xin cảm ơn tất cả những bạn bè đã giúp đỡ tôi trong suốt quá trình học tập và công
tác.
Cuối cùng, tôi xin gửi lời cảm ơn sâu sắc nhất tới gia đình của mình, nguồn
1.2.2.4 Tầng xử lý nghiệp vụ 10
1.2.2.5 Tầng biểu diễn 10
1.2.2.6 Tầng tích hợp 11
1.2.2.7 Tầng QoS(Tầng chất lượng dịch vụ) 11
1.3 Các tính chất của một hệ thống SOA 11
1.4 Kết luận 12
Chương 2 - CÁC BƯỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO MÔ HÌNH
SOA 13
2.1 Các phương pháp tiếp cận trong triển khai SOA 13
2.2 Quy trình phát triển ứng dụng theo mô hình SOA 14
2.2.1 Phân rã domain 14
2.2.2 Xây dựng Goal-service 16
2.2.3 Phân tích hệ thống con 17
2.2.4 Đưa ra các dịch vụ 17
2.2.5 Đặc tả thành phần 17 2.2.6 Cấu trúc thành phần và dịch vụ 18
2.2.7 Lựa chọn giải pháp thực thi 18
2.3 SOA và Web Service 18
2.3.1 Kiến trúc Web services 18
2.3.2 Simple Object Access Protocol – SOAP 20
2.3.3 Web Service Description Language (WSDL) 21
2.3.4 UDDI 22
2.4 Kết luận 22
Chương 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN
HÓA ĐƠN CỦA BIDV 23
3.1 Phát biểu bài toán 23
3.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV 23
3.3 Quy trình hoạt động 25
Người sử dụng dịch vụ ở đây có thể
là một ứng dụng, một dịch vụ hoặc
là các module phần mềm khác yêu
cầu sử dụng dịch vụ. Đây là thực thể
thực thi quá trình định vị dịch vụ
thông qua service registry, liên kết
với dịch vụ và thực thi các chức
năng của dịch vụ. Người sử dụng
dịch vụ thực thi chức năng dịch vụ
bằng cách một gửi yêu cầu theo
đúng dịnh dạng được mô tả trong
hợp đồng.
Service provider
Service provider Nhà cung cấp dịch vụ ở đây là một
dịch vụ chấp nhận và xử lý những
yêu cầu từ người sử dụng dịch vụ.
Nó có thể là một hệ thống
mainframe, một thành phần hoặc
các dạng phần mềm khác xử lý yêu
cầu dịch vụ. Nhà cung cấp gửi hợp
đồng lên service registry để những
người sử dụng dịch vụ có thể truy
cập đến nó.
Service Registry
Service Registry Service registry là chứa tất cả các
dịch vụ đăng ký. Service registry
chấp nhận và lưu trữ các hợp đồng
gửi đến từ nhà cung cấp dịch vụ và
Bảng 2- Bảng kịch bản test dịch vụ vnmart 47
Bảng 3 - Kết quả triển khai thực tế 55
Bảng 4 - Các dịch vụ và kênh thanh toán dự kiến triển khai trong tương lai 56
Bảng 5 - Danh sách các use case hệ thống 62
DANH MỤC HÌNH VẼ
Hình 1- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản.5
Hình 2 - Kiến trúc EJB 6
Hình 3 - Mô hình CORBA 6
Hình 4 - Mô hình DCOM 7
Hình 5 - Các đối tượng trong SOA 8
Hình 6 - Kiến trúc phân tầng của hệ thống SOA 9
Hình 7 - Một khung nhìn chi tiết về một dịch vụ 10
Hình 8 - Các dịch vụ khác nhau được cung cấp trên một website 10
Hình 9 - Các bước cần thực hiện khi triển khai một hệ thống SOA. 13
Hình 10 - Phân rã domain hệ thống thanh toán hóa đơn 14
Hình 11 – Danh sách use case khi triển khai theo mô hình SOA 15
Hình 12 – Các domain và use case sử dụng 16
Hình 13 – Đưa các dịch vụ vào các thành phần 17
Hình 14 - Các tầng của Web service 19
Hình 15 - Tương tác giửa các tác nhân trong Web service 19
Hình 16 - Truyền thông điệp sử dụng SOAP 20
Hình 17 - Cấu trúc SOAP message 20
Hình 18 – WSDL 21
Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV 24
Hình 20- Web service dùng trong hệ thống thanh toán hoá đơn 32
Hình 21 - Môi trường RAD cuả IBM 33
hàng, một trong những ngành kinh tế đặc biệt tác động trực tiếp đến hệ thống tài chính
của quốc gia, trở nên cấp thiết hơn bao giờ hết.
Trong quá trình điều hành và vận hành hệ thống Ngân hàng, điều mà các lãnh
đạo quan tâm nhất là làm sao nắm bắt được tình hình hoạt động của hệ thống mình
một cách nhanh nhất, chính xác và kịp thời nhất, để đưa ra các quyết định đúng đắn,
giảm tối thiểu rủi ro, đảm bảo lợi ích của Ngân hàng mình. Hơn nữa, các ngân hàng
thương mại còn phải hướng đến việc nâng cao chất lượng dịch vụ để phục vụ khách
hàng. Với việc Việt Nam chính thứ gia nhập tổ chức thương mại thế giới WTO thì các
ngân hàng đang phải đối mặt với sự cạnh tranh của các ngân hàng ngoại vốn mạnh về
tài chính và công nghệ và còn phải cạnh tranh khốc liệt với khối ngân hàng nội đang
từng bước lớn mạnh.
Để cạnh tranh được thì vấn đề cốt lõi của các ngân hàng là phải hiện đại hóa về
hệ thống CNTT mà nền tảng là đa dạng hóa dịch vụ. Một trong những dịch vụ quan
trong cần phải đặc biệt chú trong dó chính là dịch vụ thanh toán tập trung tại ngân
hàng.
Bài toán thực tế
Trước khi đi vào mục tiêu chính của luận văn, chúng ta sẽ phân tích bài toán
thực tế tại ngân hàng Đầu tư và phát triển Việt Nam BIDV như sau:
(i) Tập đoàn điện lực Việt Nam EVN từ trước đến nay đều thu tiền điện qua
mạng lưới cộng tác viên đến thu tiền trực tiếp tại nhà dân hay tại các điểm thu tiền của
EVN. Điều này dẫn tới mạng lưới đội ngũ cộng tác viên này rất lớn phức tạp trong
quản lý. Hơn nữa số tiền mà các cộng tác viên này thu được phải mất vài ngày đến
hàng tuần mới đến nộp được cho sở điện lực. Nếu số tiền này mà được gửi ngay tại
ngân hàng thì EVN vừa dễ quản lý và theo dõi lại được phát sinh một số tiền lãi rất
lớn. Ngoài ra cũng tránh được nhiều nguy cơ rủi ro như tiền giả, cộng tác viên dùng sai
mục đích…
Các yêu cầu về thanh toán cước viễn thông trả sau với Tổng công ty viễn thông
quân đội Viettel, với tập đoàn bưu chính viễn thông Việt Nam VNPT, với công ty viễn
thông điện lực EVN Telecom, thu hộ tiền nước…
(ii) Dịch vụ nạp tiền cho thuê bao trả trước với nhà cung cấp dịch vụ VNPAY :
quản lý dòng tiền thu được từ khách hàng một cách nhanh chóng chính xác tránh nhiều
rủi ro khi cần đội ngũ cộng tác viên đi thu như mất tiền, tiền không hợp lệ…
Nắm bắt được các yêu cầu của các doanh nghiệp trong nghiệp vụ thanh toán hóa
đơn cũng như phát triển thêm thanh toán không dùng tiền mặt đồng thời đẩy mạnh
phát triển dịch vụ tại BIDV. BIDV đã tiến hành khảo sát và ký kết với các đơn vị trên
để phát triển một cổng thanh toán đáp ứng được các nghiệp vụ thanh toán hóa đơn.
Vấn đề là cổng thanh toán đó phải tích hợp được nhiều kênh thanh toán như ATM,
quầy, SMS… đồng thời phải mở rộng được các nhà cung cấp dịch vụ mới.
Kiến trúc hướng dịch vụ SOA (Service Oriented Architecture) ra đời như là giải
pháp tối ưu để tích hợp các dịch vụ giữa BIDV và các nhà cung cấp để giải quyết bài
toán thanh toán trên.
3
SOA là một trong những hướng thời sự hiện nay của ngành công nghệ thông tin.
Nó cho phép cung cấp những dịch vụ có tính đầy đủ nhất đối với nhu cầu của người sử
dụng. Vấn đề tích hợp được đặt ra để cho phép các ứng dụng, cơ sở dữ liệu riêng lẻ có
thể tích hợp với nhau trong các quy trình nghiệp vụ và không chỉ giới hạn trong nội bộ
doanh nghiệp mà còn có khả năng tích hợp với các quy trình của khách hàng và đối tác
bên ngoài. Tuy nhiên, trong đa số trường hợp, việc tích hợp chỉ mới dừng lại ở mức
tích hợp doanh nghiệp và trong một số ít trường hợp ở mức tích hợp logic nghiệp vụ,
sử dụng các phương cách tích hợp truyền thống như tích hợp điểm-nối-điểm (hai ứng
dụng cần trao đổi thông tin sẽ kết nối trực tiếp với nhau), tích hợp tĩnh (ví dụ như viết
các mã tích hợp đan xen với mã ứng dụng nên khó thay đổi trong tương lai). Theo thời
gian, phương cách tích hợp truyền thống sẽ tạo ra một hệ thống kết nối chồng chéo,
phụ thuộc lẫn nhau một cách chặt chẽ, rất khó chỉnh sửa khi yêu cầu nghiệp vụ thay
đổi, dẫn đến chi phí tích hợp ngày càng gia tăng đáng kể.
Một số tổ chức, doanh nghiệp Việt Nam đang bước đầu tiếp cận kiến trúc tích
hợp linh hoạt của SOA và thường bắt đầu theo hai hướng: tích hợp con người nhằm
nâng cao năng suất làm việc và mở rộng thêm các kênh truy cập vào hệ thống ứng
ngôn ngữ bất kỳ.
Với ngữ cảnh đó, luận văn hướng đến mục tiêu tập trung nghiên cứu, tìm hiểu
sâu về mô hình kiến trúc hướng dịch vụ, từ đó ứng dụng trong bài toán thanh toán tập
trung tại ngân hàng BIDV.
Nội dung chính của luận văn được tổng hợp, trình bày trong 5 chương chính sau:
- Chương 1: Giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các tính
chất của hệ thống SOA. Chương này cũng trình bày về kiến trúc phân tầng của hệ
thống SOA.
- Chương 2: Chương thứ hai của luận văn đề cập đến xây dựng một bài toán
dựa theo mô hình SOA, giới thiệu về Web Service…
- Chương 3: Chương này đưa ra ứng dụng SOA trong bài toán thanh toán hoá
đơn của BIDV bao gồm phát biểu bài toán, mô hình tích hợp đề xuất và nêu quy trình
hoạt động của bài toán, thiết kế chi tiết bài toán.
- Chương 4: Giới thiệu môi trường phát triển và triển khai hệ thống thanh toán
hoá đơn, chính sách bảo mật của hệ thống, kết quả thực nghiệm sau khi triển khai.
- Chương 5: Kết luận và hướng phát triển của đề tài. 5
Chương 1 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ
1.1 Mở đầu
Trong những năm qua có rất nhiều kiến trúc phần mềm đã và đang được xây
dựng và triển khai nhằm giải quyết các vấn đề như giảm chi phí phát triển phần mềm,
giảm chi phí bảo trì vận hành phần mềm
Rất nhiều hãng phần mềm khác nhau trên thế giới đã nghiên cứu, tìm tòi nhiều
công nghệ mới, nhiều kiến trúc phần mềm khác nhau nhưng lại dựa trên các chuẩn
khác nhau dẫn đến môi trường không đồng nhất. Nhiều hệ thống cũ thay vì được sử
dụng lại thì lại được xây dựng lại từ đầu dẫn đến quá tốn kém về thời gian và tiền bạc.
Hình 2 2- Kiến trúc EJB
Common Object Request Broker Architecture (CORBA ) :
Hình 3 3- Mô hình CORBA 7
DCOM – Distributed Component Object Model:
Hình 44 - Mô hình DCOM
Các kiến trúc trên đều yêu cầu kiến trúc triển khai cài đặt bên phía nhà cung cấp
dịch vụ và phía sử dụng dịch vụ phải giống nhau. Mỗi khi có một sự thay đổi thì thì
yêu cầu đều phải thay đổi cả bên cung cấp dịch vụ và bên triệu gọi sử dụng dịch vụ.
Các kiến trúc trên đa phần là chuẩn đóng rất khó để giao tiếp với các chuẩn khác…
Chính vì những nhược điểm của các mô hình đã có yêu cầu tìm ra một kiến trúc
mới có thể tương thích được các chuẩn, các môi trường và sử dụng lại được các hệ
thống cũ. Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) ra đời giúp
giải quyết các nhược điểm của các mô hình phân tán đã có.
1.2 Kiến trúc hướng dịch vụ
1.2.1 Khái niệm về SOA
Trước khi ta hiểu khái niệm kiến trúc hướng dịch ta ta tìm hiểu khái niệm về
dịch vụ là gì?
Dịch vụ là là các thành phần logic dùng để thực hiện một thao tác nghiệp vụ
được truy nhập qua internet sử dụng các chuẩn mở.
Kiến trúc hướng dịch vụ là một 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ụ. Dịch vụ là yếu tố then chốt
trong SOA. SOA là tập hợp các dịch vụ kết nối ‘mềm dẻo’ với nhau (nghĩa là một ứng
Hình 55 - Các đối tượng trong SOA
Nhà cung cấp dịch vụ (service provider) : Cung cấp thông tin về dịch vụ cho
một nơi lưu trữ thông tin dịch vụ (service registry).
Người sử dụng dịch vụ (service consumer) : Thông qua service registry để tìm
kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía
nhà cung cấp.
Nơi lưu trữ thông tin dịch vụ (service registry) : Là nơi lưu trữ các dịch vụ khi
một dịch vụ của nhà cung cấp dịch vụ được đưa ra. Đây chính là nơi người sử dụng
dịch vụ có thể tìm và triệu gọi các dịch vụ được cung cấp.
SOA cung cấp 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à cơ sở và nền tảng cho
việc tích hợp, tái sử dụng lại những tài nguyên hiện có.
Tư tưởng của SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc
tương tự. Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví
dụ như các ứng dụng phân tán muốn làm việc với nhau phải đạt được thỏa thuận về chi
tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay
đổi tương ứng đối với mã lệnh truy cập thành phần COM này.
Nơi đăng ký dịch
vụ (Service
Registry)
Người sử dụng
dịch vụ (Service
Consumer)
Nhà cung cấp dịch
vụ (Service
Provider)
Tầng dịch vụ đưa ra các đặc tả dịch vụ, đặc tả các đơn vị thành phần nghiệp vụ.
1.2.2.4 Tầng xử lý nghiệp vụ
Các dịch vụ được đưa vào thành 1 luồng để xử lý như một ứng dụng đơn lẻ.
Tầng này hỗ trợ đặc tả các use case và thực hiện các quy trình nghiệp vụ.
1.2.2.5 Tầng biểu diễn
Hình 7 - Một khung nhìn chi tiết về một dịch vụ
11
Hình 8 - Các dịch vụ khác nhau được cung cấp trên một website
Tầng biểu diễn cung cấp các ứng dụng cho người dùng cuối dưới dạng các dịch
vụ được xây dựng từ các tầng trên. Người dùng cuối sẽ không quan tâm đến xử lý
trong bản thân các dịch vụ mà chỉ quan tâm đến đầu vào và đầu ra của dịch vụ.
1.2.2.6 Tầng tích hợp
Tầng này cho phép tích hợp các dịch vụ trước đó như đưa ra tập các khả năng tin
cậy như định tuyến thông minh, các giao thức điều chỉnh hoặc các cơ chế chuyển đổi
khác thường được miêu tả là ESB.
1.2.2.7 Tầng QoS(Tầng chất lượng dịch vụ)
Tầng này cung cấp các khả năng để quản lý, theo dõi,vận hành chất lượng các
dịch vụ như an ninh, hiệu năng xử dụng của hệ thống và độ sẵn sàng của hệ thống.
Đây là bước xử lý phía sau và cần cài đặt các công cụ để theo dõi vận hành ứng
dụng SOA.
1.3 Các tính chất của một hệ thống SOA
SOA gồm các tính chất cơ bản sau [8]-[9]
Sử dụng lại dịch vụ
Trong SOA tính chất sử dụng lại dịch vụ cho phép các một dịch vụ mới có thể
tái sử dụng các dịch vụ đã. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành
Chương 1 trình bày về một số khó khăn của ngành công nghệ phần mềm hiện
nay. Từ đó giới thiệu, phân tích các ưu khuyết điểm của một số mô hình kiến trúc
phân tán được xây dựng để giải quyết các khó khăn trên như là EJB,CORBA,
DCOM…
Chương này cũng giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các tính
chất của hệ thống SOA, giới thiệu về kiến trúc phân tầng của hệ thống SOA… 13
Chương 2 - CÁC BƯỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO
MÔ HÌNH SOA
2.1 Các phương pháp tiếp cận trong triển khai SOA
Phần này sẽ giới thiệu các phương pháp để xác định các dịch vụ hai phương
pháp cơ bản là phương pháp top-down (xuất phát từ các yêu cầu nghiệp vụ) và
bottom-up (xuất phát từ thực trạng của hệ thống hiện có).
• Top-down : trong xây dựng một hệ thống SOA, thì phương pháp top-down là
phương pháp mà điểm xuất phát của nó sẽ là từ các yêu cầu nghiệp vụ để xác định các
yêu cầu chức năng, các tiến trình và tiến trình con, các trường hợp sử dụng (use cases)
để tiến tới việc xác định các thành phần hệ thống (components), các dịch vụ…
• Bottom-up : phương pháp này sẽ dựa trên việc phân tích tình trạng, các tài
nguyên của hệ thống hiện có và sẽ tái sử dụng lại những thành phần này trong việc
xây dựng các dịch vụ mới.
Phương pháp này bao gồm 7 bước chính được thể hiện ở Hình 9[5].
Hình 9 - Các bước cần thực hiện khi triển khai một hệ thống SOA.
Trong Hình 9 ta sẽ tiếp cận mô hình theo phương pháp top-down đi từ trên
xuống.Với các bước mà song song nhau thì trong thực tế có thể tiến hành cùng một
lúc.
Các bước chính để xây dựng hệ thống dựa trên SOA đó là :
Hình 10 - Phân rã domain hệ thống thanh toán hóa đơn
Sau khi phân rã domain thành một dãy các vùng chức năng liên quan, ta tiếp
tục phân tích từng vùng chức năng để xác định các sơ đồ use case .
ATM
Web Server
CoreBanking
Nhà cung cấp dịch
v
ụ
Copyright: Tài liệu đại học ©