ứng dụng kiến trúc hướng dịch vụ trong bài toán thanh toán tập trung

Một cách cơ bản, 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 dụng có thể 'nói chuyện' với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong,

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

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

Ngành : Công nghệ Thông tin Chuyên ngành : Hệ thống thông tin

Mã số : 604805

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS NGUYỄN NGỌC HÓA

Hà Nội - 2010

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cá 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

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 động viên và cổ vũ lớn lao và là động lực giúp tôi thành công trong công việc và trong cuộc sống

Nguyễn Đức Ngọc

MỤC LỤC

LỜI CAM ĐOAN

LỜI CẢM ƠN

MỤC LỤC

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

DANH MỤC BẢNG BIỂU

DANH MỤC HÌNH VẼ

MỞ ĐẦU 1

Chương 1 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ 5

1.1 Mở đầu 5

1.2 Kiến trúc hướng dịch vụ 7

1.2.1 Khái niệm về SOA 7

1.2.2 Kiến trúc SOA 9

1.2.2.1 Tầng tầng thao tác hệ thống 9

1.2.2.2 Tầng thành phần tác nghiệp 9

1.2.2.3 Tầng dịch vụ 10

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

3.4 Cơ sở dữ liệu 30

3.5 Thiết kế Web service dùng trong hệ thống 30

3.6 Kết luận 32

Chương 4 - THỰC NGHIỆM VÀ ĐÁNH GIÁ 33

4.1 Môi trường tích hợp 33

4.2 Tích hợp thử nghiệm 34

4.3 Kết quả thực nghiệm 39

Chương 5 - KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 59

TÀI LIỆU THAM KHẢO 60

PHỤ LỤC - CÁC USE CASE CỦA HỆ THỐNG THANH TOÁN HÓA ĐƠN 61

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

BIDV Bank for Investment and

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à cung cấp các hợp đồng tùy theo yêu cầu của người sử dụng dịch vụ

Service contract Service contract Một hợp đồng (contract) là một đặc

tả về cách thức bên sử dụng dịch vụ trao đổi liên lạc với bên cung cấp dịch vụ Nó chỉ rõ ra định dạng và yêu cầu và đáp trả của dịch vụ

Siverlake

SOA Service Oriented

Architect

Kiến trúc hướng dịch vụ

DANH MỤC BẢNG BIỂU

Bảng 1- Các yêu cầu triển khai thử nghiệm 35

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ình 22 - Môi trường Message Queue của IBM 34

Hình 23 - Sơ đồ bảo mật của hệ thống thanh toán hoá đơn BIDV 35

Hình 24 - Sơ đồ backup Database 36

Hình 25 - Màn hình đăng nhập hệ thống 48

Hình 26 - Màn hình quản lý người sử dụng 48

Hình 27 - Màn hình quản lý chi nhánh 49

Hình 28 - Màn hình quản lý nhà cung cấp 49

Hình 29 - Màn hình quản lý dịch vụ 50

Hình 30 - Màn hình đăng ký khách hàng 50

Hình 31 - Màn hình vấn tin hóa đơn 51

Hình 32 - Màn hình thanh toán hóa đơn 51

Hình 33 - Các màn hình giao dịch tại ATM 54

Hình 34- Màn hình Gateway xử lý từ các kênh thanh toán 54

Hình 35 - Use case quản lý chi nhánh 62

Hình 36 - Use case quản lý người sử dụng 66

Hình 37 - Use case quản lý nhà cung cấp 71

Hình 38 - Use case quản lý dịch vụ 76

Hình 39 - Use case quản lý khách hàng 81

Hình 40 - Use case xử lý thanh toán hoá đơn 86

Hình 41 - Use case đăng nhập 92

MỞ ĐẦU

Trong thời kỳ phát triển và hội nhập kinh tế thế giới của Việt Nam những năm gần đây các doanh nghiệp Việt Nam gặp rất nhiều khó khăn khi phải cạnh tranh với các doanh nghiệp nước ngoài không những mạnh về quản trị nhân lực, mạnh về vốn

và cả công nghệ…

Việc áp dụng khoa học công nghệ vào lĩnh vực kinh tế, trong đó có ngành Ngân 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

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 : Thay vì phải đến các điểm bán thẻ trả trước để cào lấy mã số thẻ rồi nạp tiền thì khách

hàng có thêm một kênh là nạp tiền cho điện thoại di động qua tin nhắn hay mua thẻ tại ATM thông qua mở tài khoản tại ngân hàng

(iii) Dịch vụ nạp tiền ví điện tử vnmart: Đây là dịch vụ phối hợp với với công ty VNPAY Dịch vụ thanh toán trực tuyến mới phát triển trong vài năm gần đây tại Việt Nam Đây là dịch vụ giúp chủ thẻ tại BIDV có thể nạp rút tiền vào tài khoản ảo qua đó dùng ví điện tử này kết hợp với các website bán hàng trực tuyến để thanh toán trực tuyến Khi dùng dịch vụ ví điện tử này sẽ đảm bảo an toàn hơn khi thanh toán trực tuyến thay vì thanh toán trực tuyến bằng tài khoản ngân hàng Sự phát triển của dịch

vụ gắn liền với sự quảng bá dịch vụ với các website bán hàng trực tuyến

(iv) Dịch vụ nạp tiền tài khoản Vietpay: Đây là dịch vụ phối hợp với với công ty

VietPay dùng để nạp tiền game cho các ại lý

(v) Dịch vụ thanh toán vé máy bay Jetstart: Đây là dịch vụ phối hợp với với công

ty Onepay triển khai qua hai kênh ATM và quầy giao dịch : Khách hàng sau khi vào website của jetstart pacific để đặt chỗ rồi sẽ qua ATM hay quầy giao dịch của BIDV

để thanh toán bằng cách nhập vào mã đặt chỗ Đây là dịch vụ sẽ rất hữu ích tại những nơi không có đại lý bán vé máy bay của Jetstart đặc biệt tại các tỉnh và các huyện xa (vi) Dịch vụ mua bảo hiểm xe máy, ô tô qua ATM với công ty bảo hiểm BIDV (BIDV Insurance Company BIC) : Thay vì ra các đại lý bảo hiểm thì khách hàng là chủ thẻ của BIDV có thể ra ATM để đặt mua bảo hiểm ô tô, xe máy Phương thức này giúp khách hàng có thể tiết kiệm được thời gian đồng thời có tỉ lệ chiết khấu cao hơn khi ra đại lý mua vì công ty bảo hiểm sẽ không phải trích trả cho đại lý Đây cũng là hình thức quảng bá sự đa dạng dịch vụ cho BIDV Dịch vụ này mới triển khai

(vii) Dịch vụ thanh toán phí bảo hiểm qua ATM với công ty bảo hiểm Prudential: Phí đóng bảo hiểm hàng tháng sẽ được công ty gửi cho khách hàng qua bưu điện, email, điện thoại…Khách hàng chỉ cần ra ATM nhập mã hợp đồng và số tiền phải đóng vào là có thể thanh toán được phí bảo hiểm với Prudential Đây cũng là một dịch

vụ rất mới giúp cho công ty bảo hiểm giảm bớt số lượng cộng tác viên đồng thời giúp 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

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 dụng bằng cách xây dựng cổng làm việc điện tử, cổng giao dịch điện tử Ngoài hai hướng này, các hướng tiếp cận khác của SOA bao gồm tích hợp và tự động hóa quy trình nghiệp vụ, tích hợp thông tin và xây dựng kho tài nguyên dịch vụ có khả năng sử dụng lại trong các ứng dụng mới SOA là một mô hình kiến trúc tích hợp hiện đại dựa trên khái niệm dịch vụ Các chức năng nghiệp vụ và cơ sở hạ tầng được cung cấp như

là các dịch vụ, các dịch vụ này riêng lẻ hoặc kết hợp với nhau sẽ cung cấp các chức năng ứng dụng cho các ứng dụng đầu cuối hoặc cho các dịch vụ khác Các dịch vụ được kết nối với nhau thông qua trục tích hợp doanh nghiệp, xây dựng theo kiến trúc bus thay cho kiến trúc điểm-nối-điểm Nhờ kiến trúc tích hợp linh hoạt của SOA, doanh nghiệp có thể xây dựng các hệ thống linh hoạt cho phép thay đổi các quy trình nghiệp vụ nhanh chóng và có thể tái sử dụng các cấu thành hệ thống

Dịch vụ là yếu tố then chốt trong SOA Có thể hiểu dịch vụ như là hàm chức năng (mô-đun phần mềm) thực hiện qui trình nghiệp vụ nào đó Một cách cơ bản, 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 dụng có thể 'nói chuyện' với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong),

có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp

kỹ thuật bên dưới

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất kể công nghệ thực hiện dịch vụ Thay vì xây dựng các ứng dụng đơn

lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ Điều này cho phép tái sử dụng phần mềm tốt

hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ

Ưu điểm quan trọng nhất của SOA là khả năng kết nối "mềm dẻo" (nhờ sự chuẩn hóa giao tiếp) và tái sử dụng Các dịch vụ được đóng gói có thể được gọi bởi 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

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ơn nữa giữa các hệ thống khác nhau, các môi trường khác nhau sẽ không thể giao tiếp được với nhau một khi chưa thống nhất được chuẩn để giao tiếp với nhau Đó là khó khăn rất lớn trong quá trình tích hợp các hệ thống với nhau

Một nguyên nhân cũng gây rất nhiều khó khăn cho các đơn vị tích hợp hệ thống

là vấn đề lập trình dư thừa và không tái sử dụng được Ví dụ như Ngân hàng A phát triển một dịch vụ như chuyển khoản qua các kênh ATM, quầy giao dịch và internet của Ngân hàng A Các dịch vụ này đều có mục đích là truy nhập vào CoreBanking để thực hiện giao dịch cộng tiền vào tài khoản đích và trừ tiền vào tài khoản nguồn Nếu không được tái sử dụng thì ở mỗi kênh trên ta đều gặp phải bài toán là viết một đoạn chương trình thực hiện ghi có tài khoản đích và ghi nợ tài khoản nguồn Hơn nữa với tưng kênh giao dịch lại sử dụng môt ngôn ngữ lập trình khác nhau dẫn tới tốn rất nhiều thời gian và công sức thể thực hiện bài toán cho các kênh đó

Hình 11- 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

Cứ khi triển khai thêm một kênh mới như SMS, Mobile… thì công việc chuyển khoản lại phải xây dựng gây sự nhàm chán, tốn chi phí thời gian và tiền bạc với người lập trinh viên Như Hình 1 thì lập trình viên phải viết lại đoạn chương trình thực hiện chuyển khoản trên các ngôn ngữ khác nhau

Về mô hình kiến trúc phần mềm truyền thống, đã có rất nhiều cách tiếp cận khác nhau đối với việc xây dựng, phát triển các ứng dụng phân tán chẳng hạn:

 EJB (Enterprise Java Beans)

Hình 2 2- Kiến trúc EJB

 Common Object Request Broker Architecture (CORBA ) :

Hình 3 3- Mô hình CORBA

 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 dụng có thể ‘nói chuyện’ với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che

đi sự phức tạp kỹ thuật bên dưới

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ Thay vì xây dựng các ứng dụng

đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái

sử dụng trong toàn bộ quy trình nghiệp vụ Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ

SOA Trong SOA[5]-[8]-[11] có ba đối tượng chính là nhà cung cấp dịch vụ (service provider), người sử dụng dịch vụ (service consumer) và nơi lưa trữ dịch vụ (service registry) như minh họa trong Hình 5

Tìm dịch vụ() Xuất bản dịch vụ ()

Gọi dịch vụ()

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)

Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm và tái sử dụng Các dịch vụ có thể được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ Ví dụ như ứng dụng Java có thể liên kết với dịch vụ web NET và ngược lại

SOA dựa trên 2 nguyên tắc thiết kế quan trọng:

 Mô-đun hoá: Tách vấn đề lớn thành nhiều vấn đề nhỏ

 Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-dun đối với truy cập từ ngoài

Sau đây sẽ trình bày về kiến trúc phân tầng của SOA

1.2.2 Kiến trúc SOA

Sau đây là kiến trúc phân tầng của SOA[7] -[8] gồm 7 tầng chính là : Tầng Operational Systems (tầng tích hợp các hệ thống cũ đang hoạt động), tầng Enterprise components ( tầng thành phần tác nghiệp), tầng dịch vụ, tầng xử lý nghiệp vụ, tầng biểu diễn, tầng tích hợp và tầng theo dõi, quản lý chất lượng dịchvụ

Hình 6 - Kiến trúc phân tầng của hệ thống SOA

1.2.2.1 Tầng tầng thao tác hệ thống

Mục đích tầng này là gọi đến các ứng dụng cũ đã xây dựng trước đó như các ứng dụng xây dựng bằng các ngôn ngữ lập trình hướng đối tượng cũ, các ứng dụng thực hiện các thao tác nghiệp vụ thông minh, các gói ứng dụng CRM, ERP

Để tích hợp các hệ thống đã tồn tại này thì dùng kỹ thuật tích hợp hướng dịch

vụ

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

 Tính đóng gói dịch vụ

Tính đóng gói dịch vụ trong SOA nghĩa là các thành phần sử dụng thuộc phạm

vi bên ngoài của mỗi dịch vụ sẽ không được biết đến cài đặt của dịch vụ đó Các đối tượng sử dụng dịch vụ sẽ chỉ cần quan tâm đến đặc tả của dịch vụ Các chức năng chỉ được cung cấp thông qua các giao diện mà dịch vụ đó cung cấp Tính đóng gói dịch

vụ kế thừa từ kiến trúc hướng đối tượng đã có trước đó

 Sử dụng dịch vụ bất đồng bộ

SOA hỗ trợ triệu gọi bất đồng bộ : Bên gọi gửi thông điệp sang bên nhận xử lý

mà không cần chờ bên nhận xử lý xong thông điệp Do bên gọi không phải chờ 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 đồng bộ và bất đồng bộ

 Khả năng cộng tác

Khả năng cộng tác (Interoperability) là khả năng mà các hệ thống có thể giao

tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau

 Dò tìm dịch vụ (service discovery)

Dò tìm dịch vụ (service discovery): Trong SOA hỗ trợ dò tìm dịch vụ Đối

tượng sử dụng dịch vụ sẽ tìm các dịch vụ lưu trữ trong service registry nhờ SOA hỗ trợ dò tìm dịch vụ

 Loose coupling

Trong SOA các thành phần giao tiếp với nhau sẽ có sự ràng buộc vơi nhau Sự ràng buộc mang tính loose coupling có nghĩa là ràng buộc được mô tả rõ ràng Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các module Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch

1.4 Kết luận

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…

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

7 Lựa chọn công nghệ thực hiện

Sau đây ta sẽ xét chi tiết các bước phát triển theo mô hình SOA trên

2.2 Quy trình phát triển ứng dụng theo mô hình SOA

Ta xét tới bài toán thanh toán hóa đơn của Ngân hàng Đầu tư và Phát triển Việt Nam(BIDV) : Khách hàng có thể ra ATM hoặc quầy giao dịch của BIDV để thanh toán các loại hóa đơn tiền điện, nước…

2.2.1 Phân rã domain

Trong quy trình phát triển ứng dụng theo mô hình SOA.Bước này dùng để phân

rã toàn bộ qui trình nghiệp vụ thành các quy trình nghiệp vụ con, tiến trình [5] Hình 10 cho biết quá trình phân rã domain áp dụng cho bài toán thanh toán hóa đơn trên sẽ gồm 4 hệ thống con là ATM, Web Server, CoreBanking, Nhà cung cấp dịch vụ

con[3]-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

Hình 11 – Danh sách use case khi triển khai theo mô hình SOA

Hình 11 cho ta biết danh sách các use case của hệ thanh toán hóa đơn:

• Use case Vấn tin nhà cung cấp : Trên ATM khi lựa chọn giá trị gia tăng

sẽ hiển thị ra danh sách các nhà cung cấp dịch vụ để khách hàng có thể lựa chọn

• Use case Vấn tin dịch vụ : Sau khi đã hiển thị danh sách nhà cung cấp thì khác hàng lựa chọn nhà cung cấp để lấy ra danh sách các dịch vụ được cung cấp

• Use case Vấn tin hóa đơn : Đây là use case sẽ xử dụng hai use case con

- Use case vấn tin tài khoản SIBS : Đây là use case dùng để lấy thông tin của một tài khoản trên CoreBanking SIBS như họ tên tài khoản, số dư, số dư khả dụng, số cif…

- Use case vấn tin hóa đơn bên nhà cung cấp : Dùng để lấy thông tin khách hàng bên nhà cung cấp như họ tên khách hàng, địa chỉ khách hàng, kì hóa đơn, số tiền trong kỳ, chi tiết hóa đơn…

• Use case Gạch nợ : Use case này cũng xử dụng hai Use con

- Use case Hạch toán tài khoản trong CoreBanking : Có chức năng trừ tiền khách hàng bằng với số tiền trên hóa

đơn mà khách hàng nợ bên nhà cung cấp, cộng tiền vào tài khoản nhà cung cấp số tiền tương ứng

- Use case gạch nợ hóa đơn bên nhà cung cấp : Sau khi đã trừ tiền khách hàng trong CoreBanking của ngân hàng sẽ gửi sang bên nhà cung cấp để yêu cầu nhà cung cấp xóa

nợ cho khách hàng

• Use case Hủy gạch nợ : Use case này cũng xử dụng hai Use con

- Use case hủy hạch toán tài khoản trong CoreBanking : Khi phát sinh một lỗi như timeout hay gạch nợ hóa đơn bên nhà cung cấp không thành công thì sẽ yêu cầu hoàn tiền cho khách hàng Use case này sẽ làm nhiệm vụ hủy giao dịch hạch toán trong CoreBanking trước đó để hoàn lại tiền cho khách hàng

- Use case hủy gạch nợ bên nhà cung cấp : Một khi đã hoàn tiền cho khách hàng trong tài khoản CoreBanking ngân hàng thì sẽ yêu cầu bên nhà cung cấp hủy giao dịch xóa

nợ trước đó để khách hàng vẫn nợ hóa đơn trước đó

Các thành phần hệ thống con với các use case tạo thành các miền nghiệp vụ sau :

Hình 12 – Các domain và use case sử dụng

2.2.2 Xây dựng Goal-service

Mục đích của xây dựng goal-service[5] này là kiểm tra “các ứng cử viên” trong các mục tiêu trên có thật sự là tốt không? Ta sẽ xuất phát từ mục tiêu chính (goal) và từng bước phân tích để xác định các công việc cần làm để đạt được mục tiêu

ATM Use case : 1.Vấn tin nhà cung cấp 2.Vấn tin hóa đơn 3.Vấn tin dịch vụ 4.Thanh toán hóa đơn, 5.Hủy thanh toán

Web Server Use case :

1.Vấn tin dịch vụ 2.Thanh toán hóa đơn, 3.Hủy thanh toán

CoreBanking

Use case : 1.Vấn tin tài khoản CoreBanking

2.Hạch toán tài khoản CoreBanking

3.Hủy hạch toán tài khoản CoreBanking

Nhà cung cấp dịch vụ

Use case : 1.Vấn tin hóa đơn 2.Gạch nợ hóa đơn 3.Hủy gạch nợ hóa đơn

chính đó là gì (sub-goal) Quá trình phân rã như thế (goal thành các sub-goal) sẽ được thực hiện cho tới khi nào ta thấy rằng “mục tiêu này có thể được thực hiện bởi một dịch vụ nào đó

Trong quá trình xây dựng mô hình goal-service này, ta sẽ xác định thêm các dịch vụ cần thiết

2.2.3 Phân tích hệ thống con

Trong giai đoạn này các use case nghiệp vụ sẽ là dùng để thiết kế các use case

hệ thống Hệ thống con bao gồm các thành phần nghiệp vụ

Trong bài toán thanh toán hóa đơn, có các hệ thống con được phân rã trong bước phân rã domain là ATM, Web Server, CoreBanking và Nhà cung cấp dịch vụ Mỗi hệ thống con cung cấp một tập các service nghiệp vụ Một use case nghiệp vụ có thể bao gồm 1 hoặc nhiều use case hệ thống Như trong nghiệp vụ vấn tin hóa đơn sẽ

có hai use case hệ thống là use case vấn tin thông tin tài khoản trong CoreBanking và use case vấn tin hóa đơn bên Nhà cung cấp dịch vụ

2.2.4 Đưa ra các dịch vụ

Các dịch vụ đã được xác định qua hai giai đoạn là phân rã domain và xây dựng mô hình goal-service[5] Trong giai đoạn này, chúng ta sẽ thực hiện đưa các dịch vụ này vào các thành phần Bước này sẽ xác định xem thành phần nào sẽ cung cấp phần thực thi và quản lý cho mỗi dịch vụ Phân bổ dịch vụ sẽ thể hiện tính năng truy vết giữa các dịch vụ và các thành phần chịu trách nhiệm thực thi và quản lý chúng

Hình 13 – Đưa các dịch vụ vào các thành phần

2.2.5 Đặc tả thành phần

Bước này là đặc tả lại các thành phần sau khi đã thực hiện các bước trên như đặc tả đầu vào đầu ra web service…

2.2.6 Cấu trúc thành phần và dịch vụ

Trong giai đoạn này ta sẽ thực hiện đưa các dịch vụ và các thành phần vào các trong các tầng của SOA Đây là bước quan trọng vì sẽ ảnh hưởng đến kiến trúc hệ thống, ảnh hưởng đến công tác xây dựng và triển khai hệ thống

2.2.7 Lựa chọn giải pháp thực thi

Đây là bước quan trọng để quyết định giải pháp kỹ thuật ảnh hưởng đến tiến

độ và chi phí của dự án như quyết định có sử dụng lại hệ thống cũ với các chức năng

đã được thiết kế theo hướng dịch vụ hay là xây dựng một hệ thống hoàn toàn mới …

2.3 SOA và Web Service

SOA là một kiến trúc phần mềm, bao gồm một tập các nguyên tắc thiết kế độc lập với kỹ thuật và công nghệ nhằm liên kết các dịch vụ SOA bắt đầu với việc định nghĩa thành phần giao tiếp (interface) và sau đó, xây dựng kiến trúc hệ thống như là

sự liên kết của các thành phần interface, phần thực thi của các interface và cách thức tương tác giữa các interface Trong khi đó, Web services lại là một tập hợp các kỹ thuật và công nghệ (SOAP, WSDL, UDDI, HTTP ) được dùng để hiện thực hóa các nguyên tắc thiết kế của SOA Trong thực tế, khái niệm SOA không phải là một khái niệm hoàn toàn mới, mà đã xuất hiện cách đây khá lâu Và trong quá khứ đã có rất nhiều kỹ thuật khác được dùng để triển khai một hệ thống SOA như :

• Distributed object : như CORBA, J2EE, COM/DCOM

• Message-oriented middleware (MOM) : WebSphere MQ Phần dưới đây sẽ giới thiệu rõ hơn về Web service, khái niệm, kiến trúc và các thành phần trong Web service

2.3.1 Kiến trúc Web services

Web service [4]-[6]-[10] là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL và HTTP nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau Web services là những thành phần thực thi một số xử lý nghiệp

vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này

có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP Web services độc lập về ngôn ngữ và độc lập về nền tảng bởi vì nó tách biệt đặc tả ra khỏi cài đặt; nó còn hỗ trợ tích hợp loose coupling giữa các ứng dụng với nhau qua trao đổi các thông điệp đồng bộ và bất đồng bộ thông Web services dựa trên kiến trúc phân tán trong đó không có bất kì dịch vụ xử lý trung tâm nào và tất cả dạng truyền thông đều sử dụng các giao thức chuẩn Các giao thức không được có bất kì ý nghĩa ngầm định nào bên trong mà phải được mô tả rõ ràng

Trong Web services thì giữa thành phần triệu gọi web service(client) và Web services đều không cần biết cài đặt của nhau

Web services sử dụng XML, một ngôn ngữ độc lập trong việc biểu diễn dữ liệu, làm ngôn ngữ trao đổi thông tin

Mô hình web services dạng đơn giản định nghĩa cách thức tương tác giữa Service Requester, Service Provider, và Service Directory như sau : Bên sử dụng dịch

vụ tìm kiếm các dịch vụ trong một UDDI Service Directory Chúng sẽ lấy thông tin

mô tả WSDL của các Web services cung cấp bởi Service Providers từ trước thông qua Service Directory Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP Web services cơ bản bao gồm các khái niệm SOAP, WSDL, và UDDI Chúng ta sẽ lần lượt phân tích trong các phần sau Cần lưu ý là các chuẩn trên có thể được kết hợp với nhau hoặc dùng độc lập tùy trường hợp cụ thể

Hình 14 - Các tầng của Web service

Hình 14 mô tả các tầng hình thành nên Web service Hình 15 mô tả các tác nhân trong Web service tương ứng với các tầng này

Có 3 thành phần tác nhân chính tham gia vào Web service

1 Service Provider: Dùng Web Services Description Language (WSDL) để

mô tả dịch vụ mà mình có thể cung cấp cho Service Broker (tương tự với Service Registry trong SOA)

2 Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp Thành phần chính của Service Broker là Universal Discovery, Description, and Integration (UDDI) repositories

3 Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng và gởi cho service Broker

Nhà cung cấp dịch

vụ (Service Provider)

Môi giới dịch vụ(Service Broker)

2.3.2 Simple Object Access Protocol – SOAP

SOAP là một protocol giao tiếp dùng trong Web service được xây dựng dựa trên XML SOAP được sử dụng để đặc tả và trao đổi thông tin về các cấu trúc dữ liệu cũng như các kiểu dữ liệu giữa các thành phần trong hệ thống

Hình 16[4] mô tả giao tiếp của một ứng dụng với một web service được thực hiện qua thông điệp SOAP sử dụng giao thức HTTP Ứng dụng sẽ đặc tả yêu cầu trong SOAP message và thông qua giao thức mạng gởi đến cho web service Web service sẽ nhận và phân tích yêu cầu sau đó trả về kết quả thích hợp

Hình 16 - Truyền thông điệp sử dụng SOAP

Hình 17 - Cấu trúc SOAP message

Hình 17 mô tả cấu trúc một thông điệp SOAP Một thông điệp SOAP bao gồm các thành phần sau:

 Protocol Header: Chứa thông tin về các chuẩn giao thức được sử dụng

 SOAP Envelop: Bao gồm 2 thành phần là SOAP header và SOAP body Trong SOAP header chứa các header của message còn trong SOAP body chứa thông tin về name và data được đặc tả dưới dạng XML và trường lỗi được dùng để đưa ra các lỗi khi gọi web service

2.3.3 Web Service Description Language (WSDL)

Trong WSDL sẽ miêu tả các dịch vụ thực hiện một quy trình nghiệp vụ gồm đầu vào và đầu ra, cổng kết nối web service,…

Hình 18[4] mô tả các thành phần cơ bản của một file WSDL dùng để đặc tả một web service

Hình 18 – WSDL

 Port Types: định nghĩa một web service, các tác vụ mà service cung cấp và định dạng các thông điệp được sử dụng để khởi động các tác vụ này

 Services: Chứa các method có thể được sử dụng thông qua các giao thức

 Ports: Địa chỉ dùng để kết nối đến web service

 Operations: Mỗi operation có thể được xem như một method hay một lời gọi hàm trong các ngôn ngữ lập trình cổ điển

 Binding: chỉ định port type, các operation, SOAP binding stype (RPC/Document), SOAP protocol được dùng

 Message: Mỗi message tương ứng với một operation và chứa các thông tin cần thiết để thực thi operation đó Mỗi message có một name duy nhất và một hay nhiều logical part Các logical part được phân biệt với nhau qua name và có thể lưu trữ các tham số cần cho operation

 Element: Được định nghĩa trong Types Mỗi element có một name duy nhất và kiểu dữ liệu Element được dùng để đặc tả dữ liệu dùng trong message Element có thể đặc tả các dữ liệu đơn giản (string, integer) hay phức tạp hơn như array, struct,

 XSD file: Các element thường được định nghĩa trong các XML Schema Definition (XSD) file XSD file có thể ở trong cùng file WSDL hoặc ở file riêng biệt

2.3.4 UDDI

UDDI (Universal Description, Discovery, and Intergration) là chuẩn phục vụ các tổ chức đăng ký và tìm kiếm các Web Service UDDI hỗ trợ tìm kiếm, định vị thông tin về một nhà cung cấp dịch vụ bao gồm địa chỉ, thông tin liên lạc và các định danh

2.4 Kết luận

Chương này trình bày các vấn đề liên quan đến việc xây dựng và triển khai hệ thống SOA trong thực tế một cách hiệu quả, xem xét quy trình phát triển ứng dụng theo mô hình SOA

Trong chương cũng nêu các vấn đề liên quan đến Web services như kiến trúc Web service, các thành phần của Web service, các khai niệm về niệm SOAP, WSDL,

và UDDI trong Web service

Chương sau sẽ đề cập tới bài toán thanh toán hóa đơn tại BIDV sử dụng mô hình SOA dùng Web Service

Chương 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG

THANH TOÁN HÓA ĐƠN CỦA BIDV

3.1 Phát biểu bài toán

Trong những năm qua BIDV không ngừng 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ức gia nhập tổ chức thương mại thế giới WTO thì BIDV đ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ì cốt lõi 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ụ

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…

Dịch vụ nạp tiền cho thuê bao trả trước với nhà cung cấp dịch vụ VNPAY : Thay vì phải đến các điểm bán thẻ trả trước để cào lấy mã số thẻ rồi nạp tiền thì khách hàng có thêm một kênh là nạp tiền cho điện thoại di động qua tin nhắn hay mua thẻ tại ATM thông qua mở tài khoản tại ngân hàng

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[4] 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.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV

Thành phần sử lý trung tâm hệ thống thanh toán hoá đơn Bill Payment Gateway

sẽ định nghĩa ra các hàm web service để các kênh thanh toán như quầy giao dịch

BIDV Branch, Internet hay Mobile sẽ gọi và trao đổi thông điệp Sau khi Bill Payment Gateway xử lý sẽ truyền thông điệp sang nhà cung cấp dịch vụ cũng sử dụng web service để trao đổi dữ liệu Các thông điệp trao đổi là đồng bộ và Bill Payment Gateway có thể xử lý song song nhiều thông điệp Mô hình cũng đề xuất sử dụng Message Queue của IBM để tăng khả năng xử lý tránh trường hợp quá tải với Bill Payment Gateway

SIBS

` Chi nhánh 2

` Chi nhánh 1

` Chi nhánh 3 Web Server

Viettel

Mobil Phone

Web Service

Bill Payment Gateway

SMS

SMS

SM S

Web ServiceATM

se

esa e

VNPAY

Le as L

ine

Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV

Bill Payment Gateway: Trung tâm của hệ thống Thanh toán hóa đơn là hệ

thống Bill Payment Gateway đóng vai trò là cổng kết nối giao diện giữa hệ thống CoreBanking /SIBS, quầy giao dịch tại các chi nhánh của Ngân hàng Đầu tư và Phát triển Việt nam, hệ thống ATM/SWITCH với các nhà cung cấp dịch vụ Bill Payment Gateway được thiết kế và xây dựng để thực hiện các nhiệm vụ sau:

• Tiếp nhận các yêu cầu thanh toán hóa đơn từ 02 kênh thanh toán: ATM và quầy giao dịch của tất cả các chi nhánh trên phạm vi toàn hệ thống Ngân hàng Đầu tư

và phát triển Việt nam

• Thực hiện gửi các yêu cầu hạch toán online vào hệ thống SIBS đối với các giao dịch thanh toán hóa đơn xuất phát từ quầy giao dịch

• Switching giao dịch đến đúng nhà cung cấp dịch vụ theo yêu cầu thanh toán được gửi đến từ kênh thanh toán ATM hoặc quầy giao dịch

SWITCH: Máy chủ Switch được thiết kế và xây dựng để thực hiện các nhiệm

ATM Terminal: Các ATM Terminal đóng vai trò cung cấp dịch vụ thanh toán

hóa đơn cho khách hàng qua máy giao dịch tự động ATM ATM Terminal được cài đặt một phần mềm thích hợp để có thể gửi yêu cầu thanh toán hóa đơn tới SWITCH

Chi nhánh BIDV: Là danh sách các chi nhánh, hoặc điểm giao dịch của Ngân

hàng Đầu tư và phát triển Việt nam được chọn lựa để phục vụ yêu cầu thanh toán hóa đơn của khách hàng Tại các điểm này, một phần mềm thích hợp được trang bị để có

thể gửi yêu cầu thanh toán hóa đơn tới Bill Payment Gateway

CoreBanking – SIBS: tiếp nhận và xử lý các yêu cầu hạch toán vào tài khoản

các nhà cung cấp mở tại Ngân hàng Đầu tư và phát triển Việt nam từ Bill Payment Gateway và ATM/SWITCH

Các nhà cung cấp như EVN, Mobile Phone…: Giao tiếp với Bill Payment Gateway thông qua Web service

Các thuê bao di động sử dụng kênh SMS : giao tiếp thông qua tổng đài 8049,

máy chủ tổng sẽ giao tiếp với Bill Payment Gateway thông qua Web service

3.3 Quy trình hoạt động

Hiện tại BIDV mới triển khai hệ thống thanh toán hoá đơn qua các kênh chi nhánh BIDV, ATM và dịch vụ nạp tiền điện thoại cho thuê bao trả trước thêm kênh SMS Trong tương lai gần sẽ triển khai thêm kênh internet, kênh mobile cho tất cả các dịch vụ Ở đây ta sẽ chỉ đề cập chính đến hệ thống thanh toán hoá đơn cho hai kênh đã triển khai rộng là ATM và quầy giao dịch của BIDV

Luồng giao dịch giữa các cấu thành của hệ thống

Luồng giao dịch của kênh thanh toán tại quầy

Giao dịch vấn tin hóa đơn

Khách hàng ra quầy thanh toán sẽ nhập mã hóa đơn khách hàng rồi gửi lên Gateway Gateway sẽ xử lý và gửi sang bên nhà cung cấp rồi gửi trả lại web server để hiển thị lên màn hình cho biết chi tiết hóa đơn của khách hàng hay lỗi

BII: Inquiry Items

BIR: Inquiry Items Response

Giao dịch thanh toán hóa đơn

Sau khi vấn tin về thông tin hóa đơn xong nếu đồng ý thanh toán sẽ gửi lên Gateway để Gateway gửi message vào Corebanking để trừ tiền khách hàng sau đó Gateway gửi sang bên nhà cung cấp để xóa nợ Mỗi một trong các bước trên gặp lỗi

thì tiến trình sẽ dừng lại

BPM: Bill Payment

TFT: Fund Transfer

TFR: Fund Transfer Response

BPR: Bill Payment Response

Giao dịch hủy gạch nợ

Khi giao dịch muốn hủy thì từ Web Server sẽ gửi lên Gateway để Gateway gửi vào Corebanking để hủy giao dịch đã hạch toán trước đó đồng thời gửi sang bên nhà cung cấp để hủy giao dịch xóa nợ trước đó

BPC: Bill Payment Correction

TTC: Fund Transfer Correction

TCR: Fund Transfer Correction Response

Web

Server

Bill Gateway

NCC

SIBS TTC TCR

Web

Server

Bill Gateway

NCC

SIBS TFT TFR

BCR: Bill Payment Correction Response

Luồng giao dịch của kênh thanh toán qua ATM

Giao dịch vấn tin nhà cung cấp và dịch vụ

Khách hàng ra ATM của BIDV khi chọn dịch vụ giá trị gia tăng thì từ ATM yêu cầu sẽ gửi lên hệ thống Switch và hệ thống Switch sẽ gửi lên Gateway và Gateway sẽ

gửi trả danh sách các nhà cung cấp đã triển khai dịch vụ thanh toán hóa đơn tại BIDV

BIP: Inquiry Providers and Services

BPR: Inquiry Providers and Services Response

Giao dịch vấn tin hóa đơn

Tương tự như giao dịch tại quầy sau khi nhập thông tin khách hàng sẽ gửi lên Swtich sau đó sẽ gửi lên Gateway rồi gửi sang nhà cung cấp để lấy chi tiết hóa đơn khách hàng để hiển thị lên ATM

BII: Inquiry Items

BIR: Inquiry Items Response

Giao dịch thanh toán hóa đơn

Sau khi khách hàng chọn thanh toán sẽ gửi lên Switch để gửi hạch toán vào CoreBanking, nếu thành công thì sẽ gửi lên Bill Gateway để gửi sang nhà cung cấp dịch vụ để gạch nợ

TFR: Fund Transfer Response

BPR: Bill Payment Response

Giao dịch hủy gạch nợ

Khi giao dịch bị lỗi khi gạch nợ hóa đơn bên nhà cung cấp hay timeout bên nhà cung cấp sẽ xuất hiện giao dịch đảo để Switch gửi vào CoreBanking để hủy giao dịch hạch toán tiền trước đó đồng thời Gateway gửi sang bên nhà cung cấp để hủy giao dịch gạch nợ(nếu giao dịch đã thành công trước đó nhưng bị timeout bên nhà cung cấp)

BPC: Bill Payment Correction

TTC: Fund Transfer Correction

TCR: Fund Transfer Correction Response

BCR: Bill Payment Correction Response

Các tình huống phát sinh giao dịch nghịch đảo của hệ thống

Timeout tại Switch

Trong trường hợp xảy ra timeout tại Switch, ATM tự động gửi yêu cầu hủy giao dịch tới Switch Switch sẽ gửi tiếp yêu cầu hủy giao dịch tới SIBS và Bill Payment Gateway Cơ chế gửi yêu cầu hủy giao dịch là cơ chế store and forward

Timeout tại SIBS

Trong trường hợp xảy ra timeout tại SIBS, Switch sẽ gửi yêu cầu hủy giao dịch hạch toán tới SIBS mà không gửi yêu cầu gạch nợ sang Bil Payment Gateway

Timeout tại nhà cung cấp dịch vụ

Trong trường hợp xảy ra timeout tại nhà cung cấp, Bill Payment Gateway sẽ gửi yêu cầu hủy gạch nợ tới NCC và gửi kết quả không thành công về cho Switch Switch

sẽ gửi tiếp yêu cầu gạch nợ tới SIBS và trả lời cho ATM là giao dịch không thành công

Giao dịch gạch nợ tại nhà cung cấp dịch vụ không thành công

Trong trường hợp giao dịch gạch nợ tại NCC là không thành công, Bill Payment Gateway trả kết quả không thành công về cho Switch Switch gửi yêu cầu hủy hạch toán tới SIBS và gửi trả kết quả không thành công về cho máy ATM

Tình toán thời gian thực hiện của một giao dịch

Theo thiết kế mạng của NH ĐT&PT-VN, các giao dịch từ quầy giao dịch và máy ATM của chi nhánh phải qua hai tầng firewall mới đến được máy chủ Bill Payment Gateway Các giao dịch vì thế cũng sẽ bị trễ tuy nhiên thời gian trễ phụ thuộc vào tốc độ xử lý của firewall Hiện tại đỗ trễ của giao dịch khi đi qua firewall là không

Gateway

SIBS TTC TTR

Gateway

NCC BPC

BCR

SIBS TTC TTR

SWITCH

SIBS TTC TTR