Định dạng thông điệp
- Hệ thống ngân hàng lõi: các module trong hệ thống giao tiếp với nhau sử dụng thông điệp theo định dạng ABCS. Đây là một định dạng đặc biệt do hệ thống core tự định nghĩa.Theo định dạng này, các trƣờng trong thông điệp có độ dài cố định và không có kí tự phân tách giữa các trƣờng. Hệ thống sử dụng một file đặc tả để định nghĩa độ dài, kiểu dữ liệu cũng nhƣ ràng buộc của các trƣờng. Một thông điệp (message) trong hệ thống core gồm 2 phần: phần header và phần dữ liệu (data). Phần header chứa các thông tin hỗ trợ việc định tuyến, bảo mật đoạn thông điệp, phần dữ liệu chứa dữ liệu thực cần xử lý. Hình 3.5 và hình 3.6cho ta ví dụ minh họa về một thông điệp theo định dạng ABCS và file đặc tả cấu trúc của các trƣờng dữ liệu. Trong hình 3.5, phần tô đậm là các thông tin của trƣờng header, phần còn lại là dữ liệu thực cần xử lý
Hình 3.6: File đặc tả các trường trong header
- Hệ thống giao tiếp bên ngoài: định dạng thông điệp mà hệ thống thanh toán sử dụng là XML, đây là dạng thông điệp đƣợc sử dụng phổ biến nhất trong các ứng dụng hiện nay.
CHƯƠNG 4. THỰC NGHIỆM 4.1 Thực nghiệm
Trên cơ sở mô tả bài toán ở trên, chúng tôi tiến hành xây dựng một web service thực hiện với hai giao dịch giữa hệ thống core và hệ thống thanh toán là giao dịch vấn tin tài khoản và giao dịch cập nhật số dƣ tài khoản.
4.1.1. Giao dịch vấn tin tài khoản (Account Inquiry)
Mô tả giao dịch:Hệ thống thanh toán muốn vấn tin tài khoản khách hàng trong hệ thống ngân hàng lõi (core banking) để kiểm tra xem tài khoản của khách hàng có đủ để thanh toán hay không. Để thực hiện điều này, hệ thống gửi một thông điệp XML chứa thông tin về số tài khoản của khách hàng tới hệ thống ngân hàng lõi. Web service client ở phía hệ thống thanh toán sẽ tiến hành đóng gói thông điệp thành SOAP message, sau đó gửi lên phía server. Tại phía ngân hàng, thông điệp SOAP sau khi đã bóc tách, từ thông tin trong thông điệp, web service phía ngân hàng sẽ tìm kiếm trong đặc tả WSDL để sẽ gọi đến service AccountInquiry, service này sẽ thực hiện việc biến đổi đoạn thông điệp (XML) thành định dạng của hệ thống core (ABCS), thêm các header cần thiết vào đoạn thông điệp (dựa trên file đặc tả header của hệ thống) và gửi vào tầng socket của hệ thống core. Tại tầng socket sẽ có 1 listener thực hiện việc lắng nghe các thông điệp gửi tới hệ thống, tiếp nhận các thông điệp này và gửi vào trong hệ thống tới các module tƣơng ứng để xử lý. Quá trình diễn ra tƣơng tự với đoạn thông điệp phản hồi từ hệ thống ngân hàng.
Mô tả chi tiết các trường trên thông điệp
Các bảng dƣới đây đƣa ra mô tả chi tiết về các trƣờng trong thông điệp gửi đến và thông điệp kết quả trả về.
Bảng 4. 1: Bảng mô tả chi tiết các trường trong phần header của thông điệp
Tên trường Độ dài Kiểu DL Mô tả I/O Ghi chú
RIND 2 Character Response
Result Code
O ‗AA‘ – reply good ‗AB‘ – reply bad ‗ ‗ – Time out Default value ‗OO‘ TMID 15 Character Terminal ID I VD: ―10.10.10.2‖ MODID 9 Character Module ID I VD: ‗MD1062‘ ACCD 1 Character Action Code I ‗A‘ – Add record
‗C‘ – Change record ‗D‘ – Delete record
‗I‘ – Inquiry
USID 10 Character User ID I Ngƣời thực hiện giao dịch
RESERRCD 7 Character Response Error Code
O
Bảng 4.2: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp gửi đi
Tên trường Độ dài Kiểu DL Mô tả I/O Ghi chú
ACCTNO 10 Character Account Number I Số tài khoản
Bảng 4.3: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp trả về
Tên trường Độ dài Kiểu DL Mô tả I/O Ghi chú
BNKNUM 2 Number Bank number O
BRNNUM 5 Number Branch number O
CUSNAME 40 Character Customer Name
O
CUSTYP 1 Character Customer Type
O (adsbygoogle = window.adsbygoogle || []).push({});
BALANCE 15 Number Account Balance O
Định dạng thông điệp được gửi đến (request message):
Hình 4.1: Thông điệp gửi đến
Hình 4.2 : Thông điệp sau khi được thêm header và chuyển sang định dạng của hệ
thống core
Hàm của web service: Hàm AccountInquiry
publicstring AccountInquiry(stringaccountNo)
Input: accountNo: Chuỗi message yêu cầu.
Ví dụ: accountNo = "0128020"
Output:Chuỗi message trả về (sau khi đã bóc tách thông tin trong
header).
Ví dụ: reply message = ―VB102 NGUYENNGOCMINH V‖
4.1.1. Giao dịch cập nhật số dư tài khoản (Balance Update)
Mô tả giao dịch: Sau khi thanh toán hệ thống thanh toán muốn cập nhật thông tin về số dƣ tài khoản mới cho khách hàng trong hệ thống ngân hàng lõi. Để thực hiện điều này, hệ thống gửi một thông điệp XML chứa thông tin về số tài khoản, số tiền cần cập nhật, loại hình cập nhật (thêm/trừ) của khách hàng tới hệ thống ngân hàng lõi. Web service client ở phía hệ thống thanh toán sẽ tiến hành đóng gói thông điệp thành SOAP message, sau đó gửi lên phía server. Tại phía ngân hàng, thông điệp SOAP sau khi đã bóc tách, từ thông tin trong thông điệp, web service phía ngân hàng sẽ tìm kiếm trong đặc tả WSDL sẽ gọi đến service BalanceUpdate, service này sẽ thực hiện việc biến đổi đoạn thông điệp (XML) thành định dạng của hệ thống core (ABCS), thêm các header cần thiết vào đoạn thông điệp (dựa trên file đặc tả header của hệ thống) và gửi vào tầng socket của hệ thống core. Tại tầng socket sẽ có 1 listener thực hiện việc lắng nghe các thông điệp gửi tới hệ thống, tiếp nhận các thông điệp này và gửi vào trong hệ thống tới các module tƣơng ứng để xử lý. Nếu giao dịch thực hiện thành công, hệ thống sẽ gửi thông điệp xác nhận, còn trong trƣờng hợp xảy ra lỗi, hệ thống sẽ gửi thông điệp thông báo lỗi về phía hệ thống thanh toán.
Mô tả chi tiết các trường trên thông điệp
Các bảng dƣới đây đƣa ra mô tả chi tiết về các trƣờng trong thông điệp gửi đến và thông điệp kết quả trả về.
Bảng 4. 4: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp gửi đi
ACCTNO 10 Character Account Number I Số tài khoản
AMOUNT 15 Number Amount I Số tiền
TRANTYP 1 Character Transaction type I Loại giao dịch ‗A‘ – Cộng vào TK ‗S‘ – Trừ vào TK
Bảng 4.5: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp trả về
Tên trường Độ dài Kiểu DL Mô tả I/O Ghi chú
ERRCD 7 Character Response error code
O
TRANSTS 10 Character Transaction status O
Định dạng thông điệp được gửi đến (request message)
Hình 4.3: Thông điệp gửi đến Hàm của web service: Hàm UpdateBalance
PublicstringUpdateBalance(stringaccountNo,double amount, string trantyp) Input: accountNo, amount, trantyp: Chuỗi message yêu cầu.
Ví dụ: accountNo = "0128020", amount =‖100000‖, transaction type = ―S‖ – trừ tiền vào tài khoản
Output: Chuỗi message trả về (sau khi đã bóc tách thông tin trong header).VD: ―0000SUCCESS‖ (adsbygoogle = window.adsbygoogle || []).push({});
4.2. Đánh giá kết quả thực nghiệm.
Sau khi tiến hành thử nghiệm trên 2 giao dịch vấn tin và cập nhật số dƣ tài khoản, kết quả cho thấy web service đã thực hiện đƣợc việc kết nối thành công giữa 2 hệ thống.
Đễ hỗ trợ việc xây dựng web service, chúng tôi sử dụng bộ công cụ WebSphere của IBM. Bộ công cụ này cung cấp môi trƣờng để giúp ngƣời lập trình có thể thiết kế, xây dựng, lập trình, thử nghiệmvà quản lý đƣợc các luồng xử lý tiến trình trong các module một cách nhanh chóng.Ta có thể sử dụng nó để xây dựng một bus dịch vụ doanh nghiệp (ESB) chứa các service mà ta đã xây dựng (theo định hƣớng SOA đã nêu ở phần trên).
Một số giao diện của chƣơng trình
Hình 4.4: Giao diện luồng xử lý thông điệp
Hình trên mô tả luồng xử lý thông điệp từ bên ngoài gửi đến hệ thống, các thông điệp gửi đến qua nút SOAPInput, trong nút này có chỉ đến phần mô tả WSDL về các hàm xử lý của web service.
Hình 4.5: Thao tác với file đặc tả WSDL
Nút ServiceIB sẽ thực hiện việc bóc tách thông điệp SOAP, sau đó dựa vào phần đặc tả trong WSDL sẽ gửi thông điệp đến nút xử lý tƣơng ứng (JavaCompute_Inquiry hoặc JavaCompute_UpdateBalance).
Tại mỗi nút JavaCompute_Inquiry và JavaCompute_UpdateBalance ta định nghĩa một luồng xử lý thông điệp khác. Hình 4.6 là luồng xử lý các thông điệp của giao dịch Inquiry. Thông điệp XML gửi đến sẽ qua nút Transform_XML2ABCS để chuyển sang định dạng thông điệp của hệ thống ngân hàng lõi, sau đó sẽ gọi đến nút Call_Inquiry_Service để thực hiện việc gửi thông điệp đó vào hệ thống core qua tầng giao thức TCP/IP, và gọi đến module xử lý tƣơng ứng.
Hình 4.6: Luồng xử lý tại nút Inquiry Hình dƣới đây là đoạn lập trình tại nút Call_Inquiry_Service
Hình 4.8: Đoạn lập trình các thao tác làm việc với core
Sau khi xây dựng các luồng xử lý tiến trình, tiến hành deploy thành web service chạy ngầm trong hệ thống
Hình 4.11: Thử nghiệm với thông điệp đầu vào của giao dịch Vấn tin TK
KẾT LUẬN
Từ khi gia nhập WTO năm 2006 đến này, đã có hơn 1000 doanh nghiệp nƣớc ngoài thành lập ở Việt Nam [4] và đó là một trong những dấu hiệu cho sự cạnh tranh sắp tới. Để phát triển và nâng cao năng lực cạnh tranh, các doanh nghiệp trong nƣớc không ngừng đầu tƣ về nhân lực, về vốn và cơ sở hạ tầng, tuy nhiên rất ít doanh nghiệp chú trọng đến việc chuẩn hóa lại kiến trúc hệ thống thông tin. Chính vì vậy, khi tiến hành phát triển thêm các dịch vụ, mở rộng hệ thống hay khi có những thay đổi về mặt quy trình, định hƣớng doanh nghiệp thì hầu hết các hệ thống trong các doanh nghiệp đều bộc lộ những khiếm khuyết. Do vậy, hƣớng tiếp cận SOA là một trong những lựa chọn tối ƣu cho các doanh nghiệp hiện nay trong việc chuẩn hóa lại kiến trúc hệ thống. Và để triển khai kiến trúc hƣớng dịch vụ, công nghệ web service là lựa chọn lý tƣởng bởi khả năng đáp ứng mềm dẻo và linh hoạt của nó. Trong cuốn luận văn này, tôi đã trình bày những khái niệm tổng quan về công nghệ web service, những ƣu điểm của công nghệ này trong việc giải quyết bài toán tích hợp giữa các hệ thống, cũng nhƣ khả năng ứng dụng của nó trong việc xây dựng mô hình kiến trúc hƣớng dịch vụ. Bài luận văn cũng đã đƣa ra bài toán xây dựng thử nghiệm một web service hỗ trợ việc giao tiếp giữa hai hệ thống sử dụng các định dạng thông điệp khác nhau là hệ thống dịch vụ thanh toán và hệ thống ngân hàng lõi. Kết quả thử nghiệm trên hai loại giao dịch cơ bản là giao dịch vấn tin tài khoản và giao dịch cập nhật số dƣ tài khoản cho thấy hai hệ thống đã có thể giao tiếp đƣợc với nhau trong khi vẫn đảm bảo che giấu đƣợc các thông tin về đặc tả dữ liệu cũng nhƣ hoạt động của từng hệ thống.
Hƣớng nghiên cứu tiếp theo của luận văn là tiếp tục hoàn thiện chƣơng trình thử nghiệm, phát triển thêm các web service thực hiện các giao dịch phức tạp hơn nữa, đồng thời nghiên cứu về bài toán quản lý và tăng cƣờng khả năng bảo mật các web service.
TÀI LIỆU THAM KHẢO
Tiếng Việt:
[1]. PHẠM HẢI,―IBM chia sẻ kinh nghiệm SOA‖,Tạp chí PC World
[2]. NGUYỄN PHƢƠNG LAN, HOÀNG ĐỨC HẢI (2001), ―XML nền tảng và ứng
dụng”, Nhà xuất bản Giáo Dục.
[3]. NGÂN HÀNG CÔNG THƢƠNG VIỆT NAM (2010), “Giải pháp tích hợp với
bên ngoài và tích hợp nội bộ cho Vietinbank”, tr.10-12.
[4]. NGUYỄN QUANG (2008); ―Tổng quan về tích hợp ứng dụng‖;Tạp chí PC
World, tr. 24-26.
[5]. BÙI QUANG THÁI (2006); “SOA và Web Services”, Diễn đàn Java Việt Nam. [6]. NGUYỄN ANH TUẤN; ―Tìm hiểu SOA‖;Tạp chí Thế giới vi tính.
[7]. ―Phát triển dịch vụ thanh toán trung gian‖, Tạp chí Thế giới vi tính
Tiếng Anh:
[8]. ELIZABETH BOOK (2006), “Web Services in Retail Banking”
[9]. SANDEEP CHATTERJEE, JAMES WEBBER (2003), “Developing Enterprise (adsbygoogle = window.adsbygoogle || []).push({});
Web Services: An Architec’s Guide”, Prentice Hall.
[10]. THOMAS ERL (2005), ―Service-Oriented Architecture-Concepts, Technology,
and Design”, Prentice Hall, pp.26-67.
[11]. BILL EVJENET (2007); ―Professional XML‖, Wrox Press, pp.34-90. [12]. ITNOWEXTRA (2006). “The future of banking technology?”
[13]. SHARADGARG (2004), ―Web Services Architecture Requirements”, http://www.w3.org/TR/wsa-reqs/
[14]. RICHARDMONSON HAEFEL (2003), “J2EE Web Services”, Addition
[15]. REI LAI (2003), ―J2EE Platform Web Services”, Prentice Hall.
[16]. QUSAY H. MAHMOUD (2005), ―Service-Oriented Architecture (SOA) and
Web Services: The Road to Enterprise Application Integration (EAI)”, http://java.sun.com/developer/technicalArticles/WebServices/soa/
[17]. FILIP NOWAK, MOHSIN QASIM, ―A Comparison of Distributed Object
TechnologiesCORBA vs DCOM”
[18]. OBJECT MANAGEMENT GROUP (2009), ―COBRA BASIC” http://www.omg.org/gettingstarted/corbafaq.htm
[19]. DAVID REILLY ,―Introduction to Java RMI” [20]. CHIYOUNG SEO, “Web Service Architecture”