Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Còn công nghệ web service thì cho phép truy cập thông qua định nghĩa giao thức-và- giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhƣng chúng không phải là một.
Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng nhƣ là mô hình các giao tiếp, hiện thực giao tiếp và phƣơng thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi ―kiến trúc định hƣớng giao tiếp‖ thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ đƣợc truy cập thông qua giao tiếp, thƣờng theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tƣơng tác định hƣớng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ.
Định nghĩa cơ bản của web service dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp.
Rõ ràng, theo định nghĩa thì web service là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Web service đƣa ra giải pháp kỹ thuật để thực hiện SOA, nhƣng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải web service (và không phải tất cả web service đều có kiến trúc SOA). Tuy nhiên, với các công nghệ nhƣ DCOM và CORBA đòi hỏi sự 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, thì với web service, việc giao tiếp giữa các đối tƣợng trở nên linh hoạt và rất dễ dàng. Chính vì vậy có thể nói SOA và dịch vụ web có mối quan hệ tƣơng hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công.
Hình 3.1: Mô hình SOA phát triển lên từ mô hình đối tượng
3.2. Bài toán ứng dụng công nghệ Web Service trong xây dựng kiến trúc hướng dịch vụ
Bài toán tích hợp hiện nay là bài toán mà bất kỳ doanh nghiệp nào cũng có thể gặp phải, đặc biệt là trong các tổ chức tài chính và ngân hàng. Cùng với sự gia nhập WTO của Việt Nam, sức ép cạnh tranh giữa các tổ chức tín dụng là rất lớn, đòi hỏi các ngân hàng luôn phải không ngừng có sự cải tiến về công nghệ, tăng cƣờng phát triển các dịch vụ để nâng cao vị thế và sức cạnh tranh của mình trƣớc các đối thủ. Tuy nhiên, để có thể tung ra các dịch vụ một cách nhanh chóng mà vẫn phải đảm bảo chất lƣợng không phải là một vấn đề đơn giản, đòi hỏi hệ thống phải có một kiến trúc mềm dẻo và linh hoạt. Chính vì vậy việc sử dụng kiến trúc hƣớng dịch vụ SOA là một lựa chọn mà các ngân hàng hiện nay đang nhắm tới [7]. Bên cạnh đó, do đặc thù của các hệ thống ngân hàng là các hệ thống chứa những thông tin và dữ liệu nhạy cảm, đòi hỏi sự bảo mật cao, vì thế nó thƣờng là các hệ thống đóng, các cơ chế, các chuẩn giao tiếp cũng nhƣ định dạng dữ liệu thƣờng do hệ thống ngân hàng lõi (core banking) tự định nghĩa. Do vậy, khi các ngân hàng muốn phát triển các sản phẩm dịch vụ có sự tƣơng tác với các hệ thống bên ngoài (ví dụ nhƣ các dịch vụ thanh toán, dịch vụ B2B, dịch vụ ebanking,..) thƣờng gặp phải những khó khăn về vấn đề giao tiếp.Để các hệ thống bên ngoài có thể giao tiếp với hệ thống ngân hàng lõi mà vẫn đảm bảo bí mật thông tin về cơ chế tổ chức dữ liệu, kiến trúc và hoạt động của hệ thống ngân hàng lõi,việc sử dụng công nghệ web service là một lựa chọn phù hợp. Bài toán tập trung vào giải quyết vấn đề tƣơng tác giữa các hệ thống bên ngoài với hệ thống ngân hàng lõi, trong đó xây dựng một web service đóng vai trò là thành phần trung gian, giúp 2 hệ thống sử dụng các định dạng thông điệp khác nhau có thể giao tiếp đƣợc với nhau.
Bài toán xây dựng một web service hỗ trợ việc tích hợp giữa hệ thống core banking của ngân hàng với các hệ thống dịch vụ bên ngoài sử dụng các chuẩn thông điệp (message) khác nhau.Các hệ thống ngoài sử dụng định dạng thông điệp phổ biến nhất hiện nay là định dạng XML để giao tiếp với hệ thống ngân hàng lõi, hệ thống core sử dụng một định dạng thông điệp đặc biệt để giao tiếp giữa các module dịch vụ. Web service này sẽ thực hiện việc tiếp nhận thông điệp yêu cầu từ hệ thống bên ngoài, sau đó thực hiện chuyển đổi (transform) giữa 2 định dạng thông điệp, bổ sung các thông tin cần thiết với thông điệp đó theo đặc tả của hệ thống ngân hàng lõi, và gọi đến các module xử lý tƣơng ứng. Khi nhận kết quả trả về từ các module của hệ thống, web service sẽ thực hiện việc bóc tách đoạn thông điệp để lấy ra dữ liệu trả về, sau đó tiến hành chuyển đổi định dạng để tạo thành thông điệp theo chuẩn của hệ thống dịch vụ và gửi trả kết quả đến hệ thống này.
3.2.2. Đặc tả về các hệ thống giao tiếp
- Hệ thống ngân hàng lõi (Core banking): Các module trong hệ thống ngân hàng lõi sử dụng cơ chế truyền thông điệp (message) để giao tiếp với nhau. Định dạng thông điệp do hệ thống tự định nghĩa. Các thông điệp từ bên ngoài gửi vào hệ thống thông qua giao thức TCP/IP. Sau khi đƣợc gửi vào tầng Socket của hệ thống, các thông tin chứa trong phần header của thông điệp đƣợc bóc tách để trích xuất các thông tin cần thiết và đƣợc gửi đến các module xử lý tƣơng ứng. Sau khi xử lý xong, thông điệp chứa dữ liệu trả về lại đƣợc ghép các thông tin trong header và gửi trả lại tầng socket của hệ thống để trả kết quả ra bên ngoài.
- Các hệ thống dịch vụ: có rất nhiều các hệ thống dịch vụ bên ngoài cần kết nối tới hệ thống ngân hàng lõi, đặc biệt có thể kể đến hệ thống thanh toán (thanh toán vé tàu, thanh toán các loại hóa đơn, thanh toán vé máy bay, các hệ thống thanh toán online trên internet, hệ thống nạp tiền cho di động bằng tải khoản ATM, …), các hệ thống B2B (các công ty chứng khoán, thuế, hải quan,…),tuy nhiên trong bài toán đặt ra ta sẽ không quan tâm đến một hệ thống cụ thể nào mà chỉ quan tâm đến việc giao tiếp của nó tới hệ thống ngân hàng lõi (core banking). Các dịch vụ mà các hệ thống này có thể yêu cầu tới hệ thống ngân hàng lõi bao gồm: dịch vụ vấn tin số dƣ tài khoản, dịch vụ cập nhật số dƣ tài khoản,…
Hình 3.2:Mô hình kết nối giữa 2 hệ thống
Chúng ta hãy tham khảo mô hình kiến trúc SOA cho ngân hàng. Đây là mô hình tham khảo dựa trên nền tảng kiến trúc SOA do công ty IBM đề xuất [3]. Trong mô hình này bao gồm các thành phần tham khảo sau:
Hình 3.3: Mô hình kiến trúc SOA cho ngân hàng của IBM - Cung cấp các dịnh vụ ngân hàng thông qua eBanking
o eTeller o Mobile banking o Internet banking o Call center o ATM online - Dịch vụ Business-to-Business (B2B) gateway o Chứng khóan o Hải Quan o Thuế
o Thanh toán online
- Tích hợp và quản lí qui trình tự động hóa cho ngân hàng (BPM & ESB) o Cognos: hệ thông báo cáo thông minh
o Ứng dụng quản lí tự động hóa qui trình tín dụng (Loans Origination) o Ứng dụng quản lí rủi ro (Risk Mgmt)
o Hệ thông ngân hàng lõi (Core Banking) o Ứng dụng quản lí quan hệ khách hàng (CRM) o Vá các ứng dụng khác
- Bus Dịch vụ doanh nghiệp (Enterprise Service Bus): cung cấp một cơ sở hạ tầng có thể loại bỏ bất kỳ kết nối trực tiếp nào giữa ngƣời sử dụng dịch vụ và nhà cung cấp dịch vụ. Ngƣời dùng kết nối với bus dịch vụ doanh nghiệp chứ không phải là với nhà cung cấp đã thực sự triển khai dịch vụ. Kiểu kết nối này phân tách ngƣời dùng dịch vụ và nhà cung cấp dịch vụ ở mức độ cao hơn nữa. Bus dịch vụ cũng triển khai các năng lực bổ sung giá trị khác nữa. Chẳng hạn nhƣ, việc đảm bảo an ninh và giao dịch cũng có thể đƣợc triển khai tập trung bên trong bus dịch vụ thay vì nhúng chúng vào trong các ứng dụng. Nhà cung cấp dịch vụ có thể giao tiếp với hệ thống sử dụng 2 giao thức: web service hoặc message queue.
Bài toán mà chúng tôi đang xây dựng mới chỉ thử nghiệmvới một số dịch vụ giữa hệ thống thanh toán và hệ thống core (dịch vụ vấn tin TK, cập nhật số dƣ,..), sử dụng công nghệ web service để thực hiện. Khi số lƣợng các dịch vụ phát triển, định hƣớng tiếp theo là xây dựng một Enterprise ServiceBus (ESB) chứa các dịch vụ chuẩn, đã đƣợc tối ƣu hóa để có thể tái sử dụng nhiều lần giữa các ứng dụng. Khi đó khi xây dựng các dịch vụ mới, tích hợp với các hệ thống mới, các ứng dụng có thể tìm kiếm và sử dụng lại các dịch vụ này một cách dễ dàng mà vẫn đảm bảo tính bảo mật của hệ thống core, giảm thiểu chi phí và thời gian phát triển.
Hình 3.4: Hệ thống theo kiến trúc SOA sử dụng công nghệ WS
3.2.3. Đặc tả về giao diện kết nối
Đị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
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