Tài liệu Xây dựng hệ thống kết nối thanh toán giữa ngân hàng và các công ty chứng khoán

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Phạm Thị Hồng Nhung XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN Ngành: Công nghệ Thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC TS. NGUYỄN HẢI CHÂU Hà Nội - 2009 Trường Cao Đẳng Giao Thông VậnTải ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Phạm Thị Hồng Nhung XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN Ngành: Công nghệ Thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC TS. NGUYỄN HẢI CHÂU Hà Nội - 2009 Trường Cao Đẳng Giao Thông VậnTải 1 MỤC LỤC Trang phụ bìa Lời cam đoan Lời cảm ơn Mục lục ................................................................................................................... 1 Danh mục các thuật ngữ và các từ viết tắt ................................................................ 2 Danh mục các bảng ................................................................................................ 4 Danh mục các hình vẽ ............................................................................................ 5 MỞ ĐẦU .......................................................................................................................... 6 CHƢƠNG 1: TỔNG QUAN VỀ VẤN ĐỂ KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN ................................................. 8 1.1 Nhu cầu thực tiễn ..................................................................................................... 8 1.2 Hiện trạng các giải pháp kết nối thanh toán .............................................................. 9 1.3 Giải pháp đề xuất của luận văn ............................................................................... 11 CHƢƠNG 2: GIỚI THIỆU CÔNG NGHỆ WEBSPHERE MQ VÀ ỨNG DỤNG TRONG HỆ THỐNG KẾT NỐI THANH TOÁN ........................................................ 13 2.1 Giới thiệu công nghệ WebSphere MQ ................................................................... 13 2.1.1 Các đối tượng cơ bản của Websphere MQ ....................................................... 13 2.1.2 Đặc trưng của Websphere MQ và cơ chế truyền tải message ............................ 17 2.2 Công nghệ Web Service với WebSphere MQ ......................................................... 19 2.2.1 Cơ bản về Web Service.................................................................................... 19 2.2.2 Web Service và Websphere MQ ...................................................................... 21 2.3. An toàn bảo mật thông tin qua SSL với Websphere MQ và Web Service ............... 26 2.3.1. Vấn đề an toàn bảo mật thông tin qua SSL với Web service ............................ 26 2.3.2 SSL và Websphere MQ ................................................................................... 26 CHƢƠNG 3: XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN ........................................................... 29 3.1. Mô tả hoạt động nghiệp vụ .................................................................................... 29 3.1.1 Một số khái niệm ............................................................................................. 29 3.1.2 Mô tả nghiệp vụ:.............................................................................................. 29 3.1.3 Các yêu cầu của hệ thống................................................................................. 31 3.2. Xây dựng mô hình hệ thống................................................................................... 32 3.2.1 Mô hình kết nối ............................................................................................... 32 3.2.2 Cấu hình WebSphere MQ ................................................................................ 34 3.2.3 Cơ chế hoạt động ............................................................................................. 40 3.3. Phân tích thiết kế hệ thống..................................................................................... 50 3.3.1 Mô hình phân tích ............................................................................................ 50 3.3.2 Phát triển mô hình ca sử dụng .......................................................................... 53 3.3.3 Phân tích một số ca sử dụng điển hình của hệ thống ......................................... 61 2 Danh mục các thuật ngữ và các từ viết tắt Từ/cụm từ Authentication Bank Gateway CA (Current Account) Channel CipherSpec CipherSuite Client/Server CoreBanking Dead-letter queue Encryption HTTP (Hyper Text Transport Protocol) Listener Local queue Message MQI (Message Queue Interface) QM (Queue Manager) QMC (Queue Manager Cluster) Queue Receiver Remote queue Request Response Sender SOAP (Simple Object Access Protocol) SSL (Secure Sockets Layer) TA (Trading Account) Transmission queue UDDI (Universal Description Discovery and Integration) Ý nghĩa Xác thực Cổng giao tiếp/Máy chủ quản lý giao dịch giữa Ngân hàng và Công ty chứng khoán Tài khoản tiền gửi tại ngân hàng Kênh (dùng để truyền tải message) Thông số mã hóa và xác thực Bộ mật mã Máy khách/ Máy chủ Lõi ngân hàng Hàng đợi chứa các message không được phân phối Mã hoá Giao thức vận chuyển siêu văn bản Một tiến trình của WebSphere MQ để "nghe" các kết nối Queue cục bộ Thông điệp Giao diện quản lý các hàng đợi Quản trị các hàng đợi (queue) Bó cụm các queue manager Hàng đợi, nơi chứa các thông điệp Bên nhận Queue đại diện cho một queue khác ở xa Yêu cầu Đáp ứng Bên gửi Giao thức truy cập đối tượng đơn giản Giao thức truyền đạt thông tin một cách an toàn qua mạng Tài khoản chuyên dùng cho hoạt động thanh toán chứng khoán Queue truyền tải Hợp nhất và phát hiện các mô tả toàn thể 3 URI (Universal Resource Indicator or Identifier) Web Service WebSphere MQ (WebSphere Message Queue) Websphere MQ Explorer Định danh tài nguyên toàn thể Dịch vụ web Một công nghệ truyền tải thông điệp của IBM Trình quản lý và cấu hình WebSphere MQ một cách trực quan. WSDL (Web Services Description Ngôn ngữ mô tả dịch vụ web Language) XML (Extensible Markup Ngôn ngữ đánh dấu mở rộng Language) 4 Danh mục các bảng Bảng 3.2-1: Cấu hình WebSphere MQ trên các máy chủ .................................................. 36 Bảng 3.3-1: Các chức năng của hệ thống .......................................................................... 50 Bảng 3.3-2: Từ điển dữ liệu của hệ thống ......................................................................... 53 Bảng 3.3-3: Các tác nhân và vai trò trong hệ thống .......................................................... 55 Bảng 3.3-4: Mô tả ca sử dụng cập nhật CTCK ................................................................. 57 Bảng 3.3-5: Mô tả ca sử dụng cập nhật tài khoản TA ....................................................... 58 Bảng 3.3-6: Mô tả ca sử dụng vấn tin tài khoản TA .......................................................... 58 Bảng 3.3-7: Mô tả ca sử dụng phong toả tài khoản TA ..................................................... 59 Bảng 3.3-8: Mô tả ca sử dụng giải phong toả tài khoản TA .............................................. 59 Bảng 3.3-9: Mô tả ca sử dụng Chuyển tiền ....................................................................... 60 Bảng 3.3-10: Mô tả ca sử dụng tổng hợp kết quả giao dịch............................................... 61 Bảng 3.3-11: Mô tả ca sử dụng sao kê chi tiết tài khoản TA ............................................. 61 5 Danh mục các hình vẽ Hình 2.2-1: Mô hình kiến trúc Web Service ..................................................................... 20 Hình 2.2-2 Kiến trúc phân tầng của Web Service ............................................................. 21 Hình 2.2-3: Web Services qua HTTP ............................................................................. 22 Hình 2.2-4: Web Services qua WebSphere MQ .............................................................. 22 Hình 2.2-5: Web Service client sử dụng proxy ................................................................. 23 Hình 3.2-1: Mô hình Hệ thống kết nối thanh toán............................................................. 33 Hình 3.2-2: Cấu hình Remote queue Q.RMT.BR.GW ...................................................... 36 Hình 3.2-3: Cấu hình Remote queue Q.RMT.GW.BR ...................................................... 37 Hình 3.2-4: Cấu hình transmision queue Q.XMIT.BR ...................................................... 37 Hình 3.2-5: Cấu hình transmision queue Q.XMIT.GW.BR ............................................... 38 Hình 3.2-6: Các queue của queue manager GW ............................................................... 38 Hình 3.2-7: Cấu hình channel CH.BR.GW ....................................................................... 39 Hình 3.2-8: Các channel của queue manager GW ............................................................. 39 Hình 3.2-9: Cấu hình channel CH.BR.GW ....................................................................... 39 Hình 3.2-10: Mô hình “request-and-response” vận chuyển message dưới giao thức SOAP thông qua WebSphere MQ. ................................................................................... 40 Hình 3.2-11: Đường đi của message theo chế độ kết nối server. ....................................... 41 Hình 3.2-12: Triển khai WebSphere MQ transport for SOAP ........................................... 43 Hình 3.3-1: Sơ đồ tiến trình hoạt động kết nối thanh toán ................................................. 51 Hình 3.3-2: Biểu đồ thực thể của lĩnh vực quản lý hoạt động kết nối thanh toán ............... 52 Hình 3.3-3: Mô hình ca sử dụng mức tổng thể của hệ thống ............................................. 56 Hình 3.3-4: Biểu đồ tuần tự hệ thống Đăng ký tài khoản TA ............................................ 62 Hình 3.3-5: Biểu đồ lớp phân tích thực thi ca sử dụng Đăng ký tài khoản TA ................... 63 Hình 3.3-6: Biểu đồ tuần tự phân tích thực thi ca sử dụng Đăng ký tài khoản TA ............. 63 Hình 3.3-7: Biểu đồ tuần tự hệ thống Phong toả tài khoản TA .......................................... 64 Hình 3.3-8: Biểu đồ lớp phân tích thực thi ca sử dụng Phong toả tài khoản TA ................ 64 Hình 3.3-9: Biểu đồ tuần tự phân tích thực thi ca sử dụng Phong tỏa tài khoản TA........... 65 Hình 3.3-10: Biểu đồ tuần tự hệ thống Giải phong toả tài khoản TA................................. 65 Hình 3.3-11: Biểu đồ lớp phân tích thực thi ca sử dụng Giải phong toả tài khoản TA ....... 66 Hình 3.3-12: Biểu đồ tuần tự phân tích thực thi ca sử dụng Giải phong toả tài khoản TA . 66 Hình 3.3-13: Biểu đồ tuần tự hệ thống Chuyển tiền .......................................................... 67 Hình 3.3-14: Biểu đồ lớp phân tích thực thi ca sử dụng Chuyển tiền................................. 67 Hình 3.3-15: Biểu đồ tuần tự phân tích thực thi ca sử dụng Chuyển tiền ........................... 68 6 MỞ ĐẦU Theo điều 32, Quyết định số 27/2007/QD9-BTC ngày 24-4-2007 của Bộ Tài chính về việc ban hành quy chế tổ chức và hoạt động của công ty chứng khoán, các Công ty chứng khoán (CTCK) không được trực tiếp nhận tiền giao dịch chứng khoán của khách hàng (nhà đầu tư). Nếu như trước đây các CTCK vẫn kiêm nhiệm phần việc quản lý tiền của nhà đầu tư như một ngân hàng thực thụ, khách hàng khi giao dịch chứng khoán phải mở Tài khoản (TK) và nộp tiền vào CTCK, sau đó CTCK là người quản lý và kiểm soát TK và tài sản của khách hàng. Với những công ty lớn như SSI, BVSC, VCBS, ACBS… số dư tiền mặt trong tài khoản của nhà đầu tư có thời điểm lên tới vài nghìn tỷ đồng, một tài khoản đầu tư nhỏ lẻ cũng vài chục triệu đồng. Về nguyên tắc, quyền sử dụng tiền của nhà đầu tư không thuộc về các CTCK, nhưng với nhiều công ty đây là nguồn vốn khá quan trọng, họ có thể mượn tạm vào một thời điểm nào đó và hoàn lại tài khoản nhà đầu tư khi có nhu cầu. Cũng không loại trừ trường hợp CTCK nộp tiền vào ngân hàng với lãi suất theo thỏa thuận và ăn chênh lệch, cao hơn lãi suất nhà đầu tư được hưởng (loại không kỳ hạn). Tuy nhiên, việc một tổ chức không có nghiệp vụ quản lý tiền mặt và không phải chịu chế tài của một tổ chức tài chính, lại quản lý một lượng tiền lên tới hàng trăm tỷ đồng mỗi ngày có thể ẩn chứa nhiều rủi ro lớn về mặt vĩ mô cũng như vi mô, cho cả nền kinh tế và cho chính tổ chức đó. Theo Quyết định 27, các hoạt động nộp tiền, rút tiền và giữ tiền mặt của các nhà đầu tư chứng khoán đều phải tập trung về các Ngân hàng (NH), khách hàng sẽ mở TK tiền tại một ngân hàng thương mại do CTCK chỉ định trong danh sách các ngân hàng được Uỷ ban chứng khoán lựa chọn. Sau đó quá trình thanh toán trong giao dịch sẽ được ngân hàng đó thanh toán, đây là chức năng chính của ngân hàng chứ không phải là hoạt động của CTCK, còn chứng khoán của khách hàng sẽ được quản lý và lưu ký tại Trung tâm Lưu Ký Chứng Khoán. Như vậy cần phải có một hệ thống kết nối thanh toán giữa Ngân hàng và các CTCK, giúp các CTCK quản lý tiền gửi giao dịch chứng khoán của khách hàng và liên kết để kiểm tra điều kiện, thực hiện các giao dịch mua bán chứng khoán của khách hàng. Luận văn “Xây dựng hệ thống Kết nối thanh toán giữa Ngân hàng và các Công ty Chứng khoán” cung cấp giải pháp cho các công ty chứng khoán có thể dễ dàng kết nối, sử dụng các dịch vụ của ngân hàng nhằm đem đến cho nhà đầu tư các dịch vụ tiện ích hơn. Với các dịch vụ được cung cấp, công ty chứng khoán có nhiều phương án điều chỉnh tác nghiệp của mình: tích hợp ứng dụng chứng khoán, xây dựng chương trình độc lập,... Về bố cục, nội dung của luận văn bao gồm 3 chương: 7 Chương 1: Giới thiệu tổng quan về vấn để kết nối thanh toán giữa Ngân hàng và các Công ty Chứng khoán, xuất phát từ nhu cầu thực tiễn cũng như hiện trạng các giải pháp kết nối thanh toán hiện nay, từ đó đưa ra giải pháp của luận văn. Chương 2: Giới thiệu các công nghệ sử dụng trong giải pháp xây dựng Hệ thống kết nối thanh toán, bao gồm các công nghệ như: WebSphere MQ của IBM, Công nghệ web service và việc ứng dụng công nghệ web service vào vận chuyển message bằng SOAP qua WebSphere MQ. Chương 3: Đi sâu vào mô tả các hoạt động nghiệp vụ, xây dựng mô hình kết nối, cách cấu hình cũng như cơ chế hoạt động của mô hình, vấn đề bảo mật…Chương này cũng đi sâu phân tích thiết kế hệ thống, theo sát các yêu cầu nghiệp vụ để phát triển các ca sử dụng.. Phần kết luận: Đánh giá hiệu quả của giải pháp kết nối thanh toán, rút ra những điểm đã đạt được cũng như chưa đạt được của luận văn, đồng thời đưa ra hướng nghiên cứu, phát triển tiếp theo. Ngoài ra, luận văn còn có thêm các danh mục thuật ngữ, từ viết tắt, danh mục bảng biểu, hình vẽ và danh mục các tài liệu tham khảo để thuận tiện cho việc tìm hiểu và tra cứu nội dung của luận văn. 8 CHƢƠNG 1: TỔNG QUAN VỀ VẤN ĐỂ KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN 1.1 Nhu cầu thực tiễn Theo như Điều 32 Quyết định 27 (ban hành ngày 24/04/2007) của Bộ Tài chính về quy chế tổ chức và hoạt động của công ty chứng khoán, nhà đầu tư sẽ phải nộp tiền, rút tiền tại ngân hàng và thực hiện việc giao dịch chứng khoán tại các công ty chứng khoán. Rõ ràng là, khi chuyển qua hình thức quản lý mới này, khó khăn lớn nhất nằm ở chỗ hệ thống thông tin của nhiều công ty chứng khoán còn chưa kết nối được với hệ thống ngân hàng. Hơn nữa một công ty chứng khoán còn phải bảo đảm kết nối được cùng lúc với nhiều ngân hàng lớn, và ngược lại, các ngân hàng cũng mong muốn có được kết nối với nhiều công ty chứng khoán để hình thành nên mạng lưới đồng bộ và thông suốt. Từ trước tới nay, tất cả tài khoản giao dịch của nhà đầu tư đều mở tại các công ty chứng khoán. Những công ty này sẽ đứng ra nhận, trả tiền cho khách và chuyển tiền từ tài khoản này đến tài khoản khác trong quá trình giao dịch. Theo các chuyên gia, các công ty chứng khoán đã nắm giữ một số lượng tiền tới hàng chục nghìn tỷ đồng, trong khi họ không có chức năng và không đủ nghiệp vụ để giữ và kiểm soát tiền. Bản thân các công ty chứng khoán dù rất tiếc món hời bấy lâu cũng phải thừa nhận tình trạng này. Việc công ty chứng khoán giữ tiền của nhà đầu tư như hiện nay chỉ ở Việt Nam mới có, còn các nước trên thế giới đều áp dụng theo mô hình: Công ty chứng khoán không quản lý tiền trong tài khoản của nhà đầu tư mà việc này được giao cho các ngân hàng thực hiện nhằm đảm bảo sự minh bạch. Do đó việc thực hiện quản lý tách biệt tiền giao dịch chứng khoán của nhà đầu tư là việc làm cần thiết. Với cách quản lý trước đây, tiền gửi vào tài khoản do các công ty chứng khoán nơi nhà đầu tư mở tài khoản quản lý. Công ty chứng khoán sẽ gửi toàn bộ tiền của nhà đầu tư vào một tài khoản chung tại ngân hàng. Lúc này, ngân hàng chỉ biết tổng số tiền trong tài khoản chung còn con số cụ thể trong từng tài khoản của nhà đầu tư thì chỉ duy nhất công ty chứng khoán nắm được. Đã có không ít trường hợp tài khoản của nhà đầu tư tự nhiên thiếu một khoản tiền lớn hoặc có lệnh mua “từ trên trời rơi xuống” xuất hiện mà chủ tài khoản không hề đặt lệnh thực hiện. Việc quản lý tách biệt tiền gửi của nhà đầu tư là một trong những mục tiêu quan trọng của Bộ Tài chính nhằm cải cách hệ thống giao dịch trên thị trường chứng khoán và giúp tài khoản của nhà đầu tư được quản lý chặt chẽ, tránh tình trạng tiền bị sử dụng tùy tiện. Chính vì vậy, quyết định chuyển tiền của nhà đầu tư sang ngân hàng là phù hợp bởi đây vốn là chuyên môn của các nhà băng. Ngoài việc đủ nhân lực, cơ sở 9 vật chất để thực hiện, ngân hàng còn đảm bảo an toàn cho nguồn tiền đó cũng như các quyền lợi phát sinh khác có liên quan cho nhà đầu tư. Việc tập trung thu nhận tiền về một mối sẽ giúp các CTCK tập trung nhân lực cho các dịch vụ chính của mình. Hơn nữa, các ngân hàng có mạng lưới hoạt động rộng cũng sẽ tạo thuận lợi cho nhà đầu tư khi cần gửi tiền hay rút tiền...Quy định trên sẽ đem lại sự an toàn về tiền gửi cho khách hàng khi CTCK gặp những khó khăn trong hoạt động kinh doanh. Đây là một việc làm mới và tích cực trong việc minh bạch hóa hơn trong chuyện quản lý tài sản của khách hàng và là bước đi lớn trong việc quản lý vĩ mô của nhà nước về chứng khoán, đồng thời cũng mở ra một kênh huy động vốn khác cho các ngân hàng thương mại. Tuy nhiên, vấn đề đặt ra là để làm được điều này, thì việc quan trọng nhất là phải có sự liên thông giữa hệ thống phần mềm của ngân hàng với phần mềm quản lý giao dịch của các công ty chứng khoán. 1.2 Hiện trạng các giải pháp kết nối thanh toán Quy định về việc các công ty chứng khoán phải ủy quyền cho một ngân hàng thương mại nhận và quản lý tiền của nhà đầu tư là một thách thức không nhỏ đối với các ngân hàng, đặc biệt là các công ty chứng khoán, khi thực trạng về hạ tầng CNTT của các bên còn nhiều khác biệt, mức độ sẵn sàng cũng khác nhau. Vấn đề nhà đầu tư quan tâm là việc liên thông các hệ thống giao dịch của công ty chứng khoán với hệ thống lõi của ngân hàng sẽ được thực hiện thế nào để bảo đảm tính an toàn bảo mật, trực tuyến cho các giao dịch của họ ; đặc biệt là tính đa kết nối để tạo sự liên thông giữa hai bên, thuận lợi cho nhà đầu tư. Khi chuyển qua hình thức quản lý mới này, khó khăn lớn nhất là hệ thống thông tin của nhiều công ty chứng khoán còn chưa kết nối được với hệ thống ngân hàng. Hơn nữa, một công ty chứng khoán còn được yêu cầu phải bảo đảm kết nối được cùng một lúc với nhiều ngân hàng lớn. Ngược lại, các ngân hàng cũng muốn kết nối với nhiều công ty chứng khoán để hình thành nên một mạng lưới đồng bộ và thông suốt. Nếu giải pháp sử dụng cho ngân hàng, nó phải giúp ngân hàng phân tích thông tin đến từ các công ty chứng khoán khác nhau và đặc biệt cho phép có sự tương tác hai chiều giữa ngân hàng và công ty chứng khoán. Trước mắt, để quản lý nguồn tiền gửi của các nhà đầu tư, các công ty chứng khoán là người đại diện mở tài khoản chung tại ngân hàng và giao ngân hàng quản lý. Ngân hàng sẽ cử một đại diện bên cạnh công ty chứng khoán để thu tiền của các nhà đầu tư. Trên thực tế, trong tổng số 103 CTCK đang hoạt động, những CTCK hoàn tất việc tách bạch tài khoản tiền gửi của mình với nhà đầu tư tại ngân hàng đa phần là những công ty "trẻ", có số tài khoản không nhiều. Số còn lại vẫn đang ì 10 ạch tách tài khoản tiền gửi của nhà đầu tư sang ngân hàng quản lý. Việc chậm trễ này có rất nhiều lý do như CTCK sợ rủi ro về kỹ thuật, sợ không đảm bảo tính an toàn và nhanh chóng trong giao dịch, sợ quá tải, sợ những rủi ro trong quá trình kết nối khiến CTCK mất khách hàng… nên việc tách tài khoản tiền của nhà đầu tư sang ngân hàng vẫn chỉ làm rón rén... Hiện tại có rất ít CTCK có kết nối trực tuyến thực sự với ngân hàng để thực hiện các giao dịch mua bán chứng khoán (Ví dụ như CTCK Âu Lạc kết nối với ngân hàng Eximbank và ngân hàng Phương Đông; CTCK Viễn Việt, Phương Đông, Đông Á, Chợ Lớn kết nối với ngân hàng TMCP Đông Á; giải pháp SmartConnect của công ty FPT kết nối CTCK Sao Việt và Ngân hàng Phương Đông, CTCK MHBS và ngân hàng BIDV…). Còn lại với đa số các CTCK khác, mặc dù khách hàng đã mở tài khoản tiền gửi thanh toán chứng khoán tại ngân hàng và việc nộp rút tiền được thực hiện tại ngân hàng nhưng được thực hiện theo cách thủ công. Ví dụ, ngân hàng sẽ đặt một quầy giao dịch ngay tại sàn giao dịch của CTCK, khách hàng nộp tiền tại ngân hàng (vào tài khoản tổng của CTCK hoặc vào TK tiền gửi cá nhân), sau đó CTCK mới căn cứ vào phiếu nộp tiền để cập nhật vào TK đầu tư chứng khoán của nhà đầu tư. Hoặc khi khách hàng muốn rút tiền thì phải qua sự đồng ý của CTCK trước (để cập nhật số dư tài khoản đầu tư chứng khoán) sau đó cầm phiếu rút tiền sang bên ngân hàng để rút tiền (và ngân hàng cập nhật số dư tài khoản tiền gửi). Tương tự, việc cập nhật số dư tài khoản tiền gửi của khách hàng khi có kết quả mua bán chứng khoán cũng được thực hiện thủ công bằng cách CTCK căn cứ vào kết quả giao dịch của nhà đầu tư để gửi bảng kê sang yêu cầu ngân hàng chuyển tiền từ tài khoản tiền gửi của nhà đầu tư sang tài khoản tổng của CTCK và ngược lại. Cũng có những CTCK thực hiện kết nối trực tuyến với ngân hàng nhưng thông qua một công ty trung gian chuyên về thanh toán điện tử (Ví dụ như công ty cổ phần dịch vụ thanh toán điện tử Việt Phú là trung gian kết nối CTCK Thành Công với ngân hàng Công Thương và một số ngân hàng, CTCK khác). Công ty trung gian này sẽ đứng ra đảm nhiệm việc kết nối giữa nhiều ngân hàng và nhiều CTCK, đảm bảo thực hiện các thay đổi cần thiết về mặt kỹ thuật, công nghệ phía các CTCK để có thể thực hiện giao dịch với tài khoản tiền gửi của nhà đầu tư tại ngân hàng. Ưu điểm của giải pháp kết nối qua công ty trung gian này đối với Ngân hàng và CTCK là sẽ giảm thiểu được thời gian, nhân lực cho việc thay đổi cơ sở hạ tầng công nghệ đang sử dụng mà vẫn kết nối trực tuyến được với nhiều ngân hàng và nhiều CTCK vì việc này đã có công ty trung gian đảm nhiệm. Tuy nhiên hạn chế của mô hình này là chi phí cho việc kết nối chắc chắn sẽ cao hơn, và vì phải qua một công ty trung gian nên có thể sẽ phát sinh những vấn đề rủi ro khi thực hiện giao dịch mà rất khó tìm nguyên nhân xem lỗi là tại CTCK, tại ngân hàng hay tại công ty trung gian. 11 1.3 Giải pháp đề xuất của luận văn Trong xu thế các công ty chứng khoán ngày càng phát triển, để thực hiện triệt để quy định của Bộ tài chính cũng như thực hiện tách bạch tài khoản tiền gửi của nhà đầu tư với tài khoản của CTCK giống các nước khác trên thế giới mà không phải làm một cách thủ công thì nhu cầu kết nối trực tuyến giữa ngân hàng và chứng khoán cũng gia tăng theo. Như trên đã nói, hiện nay đã có một số ngân hàng và CTCK thực hiện kết nối trực tuyến với nhau, và đa số các giải pháp này sử dụng kênh kết nối qua Web Service. Luận văn cũng đưa ra giải pháp kết nối trực tuyến dùng Web Service nhưng được kết hợp với phương thức truyền tải message SOAP qua công nghệ WebSphere MQ (WebSphere Message Queue) của hãng IBM[6]. Các chức năng của hệ thống được lập trình bằng Microsft Visual studio .Net C# và sử dụng hệ quản trị cơ sở dữ liệu oracle. Việc dùng WebSphere MQ để truyền tải message sẽ đáp ứng được các nhu cầu sau của một hệ thống kết nối: - Sự tích hợp: Hệ thống kết nối cần phải tích hợp các ứng dụng lõi của các ngân hàng và các công ty chứng khoán, việc giao tiếp trở nên khó hoàn tất khi các ứng dụng này: mở rộng phạm vi giao dịch; được viết bằng nhiều ngôn ngữ khác nhau; dựa trên các hệ điều hành hoặc bộ xử lý khác nhau; sử dụng các phương thức giao tiếp khác nhau…WebSphere MQ cung cấp một phương thức chung để giao tiếp giữa các ứng dụng, không bị phụ thuộc bởi ngôn ngữ, hệ điều hành, bộ xử lý, các giao thức truyền thông. - Giao tiếp không đồng bộ: Giao tiếp đồng bộ đòi hỏi các chương trình ứng dụng phải cùng sẵn sàng tại một thời điểm, nếu không thì một số chương trình sẽ bị ngăn cản làm việc cho đến khi chương trình khác sẵn sàng. Vì vậy cần có chương trình để giao tiếp không phụ thuộc lẫn nhau. WebSphere MQ cung cấp một cơ chế giao tiếp độc lập giữa các chương trình với nhau (giao tiếp không đồng bộ) - Phân phối có bảo đảm: Khi toàn bộ hoặc một phần của hệ thống bị lỗi, tính toàn vẹn của thông tin đang truyền có thể bị tổn hại: Thông tin có thể bị mất nếu không được lưu trữ an toàn trong quá trình truyền đi hoặc có thể bị trùng nếu gửi lại một cách không cần thiết. WebSphere MQ bảo đảm thông tin trao đổi giữa các phần trong hệ thống không bị mất cũng như không bị trùng lặp khi truyền. 12 - Tính linh hoạt: Khi có thêm các CTCK kết nối vào hệ thống, thời gian và công sức bỏ ra để kết nối một hệ thống mới vào một mạng có sẵn có thể rất lớn và đòi hỏi phải có một thời gian đáng kể để ngắt dịch vụ và ngừng hoạt động. WebSphere MQ cung cấp một phương pháp để tích hợp các hệ thống mới vào với việc ngắt dịch vụ tối thiểu. - Tính nhanh chóng và tiện lợi: Việc truyền nhận message qua lại trong hệ thống sẽ trở nên nhanh chóng và dễ dàng hơn khi sử dụng WebSphere MQ để truyền tải message. Hơn nữa, để cài đặt, cấu hình WebSphere MQ và viết chương trình để sử dụng WebSphere MQ cũng rất đơn giản. WebSphere MQ sẽ đáp ứng tất cả các nhu cầu trên bằng việc cung cấp một môi trường cho việc truyền thông tin và sắp xếp hàng đợi các thông tin đó (messaging and queuing). Ngoài ra, việc dùng Web Service kết hợp với WebSphere MQ sẽ giúp cho việc truyền tải message nhanh chóng và chính xác hơn nhiều, giảm bớt thao tác cần phải thực hiện khi triển khai Web Service và quan trọng hơn cả là không cần phải dựng web server. 13 CHƢƠNG 2: GIỚI THIỆU CÔNG NGHỆ WEBSPHERE MQ VÀ ỨNG DỤNG TRONG HỆ THỐNG KẾT NỐI THANH TOÁN 2.1 Giới thiệu công nghệ WebSphere MQ 2.1.1 Các đối tƣợng cơ bản của Websphere MQ Trong bối cảnh cạnh tranh ngày càng khốc liệt, cùng với việc Việt Nam gia nhập WTO và phải đối mặt những đối thủ khổng lồ với hệ thống thông tin tích hợp hiện đại và chính xác thì nhu cầu tích hợp dữ liệu quản lý doanh nghiệp càng bức thiết cho bất cứ doanh nghiệp nào muốn đứng vững. IBM được coi là một trong những công ty tiên phong trong việc xây dựng các sản phẩm hỗ trợ tích hợp doanh nghiệp, và điển hình phải nói đến bộ sản phẩm tích hợp ứng dụng IBM WebSphere. Sản phẩm WebSphere Message Queue (hay thường gọi là Websphere MQ) là lựa chọn đầu tiên trong quá trình xây dựng kiến trúc tích hợp. Websphere MQ bao gồm các đối tượng thành phần cơ bản sau đây[7]: Message: Message có thể là tập hợp các dữ liệu nhị phân hoặc ký tự (ASCII hoặc EBCDIC) được sử dụng trong quá trình giao tiếp giữa các chương trình để chuyển đổi dữ liệu. Mỗi message bao gồm 2 phần: Message header và Data. Message header chứa các thông tin điều khiển như Message ID, địa chỉ gửi message đến… Queue Manager: Queue manager là một chương trình cung cấp các dịch vụ về message cho các ứng dụng. Các ứng dụng dùng Message Queue Interface (MQI) có thể đặt và lấy message từ các queue. Queue manager đảm bảo các message được gửi đúng tới một queue hoặc được định tuyến để chuyển tới một queue manager khác. Các Queue manager là các thành phần cơ bản trong WebSphere MQ. Queue manager chứa các queue và các channel để kết nối các queue manager với nhau. Mỗi máy tính chứa các queue đều cần phải có một Queue Manager. Mỗi Queue Manager có một tên duy nhất, có nhiệm vụ quản trị các queue được tạo trong nó (các local queue). Trong một Queue Manager, mỗi queue có một tên, tên queue cùng với queue manager của nó sẽ cung cấp một địa chỉ đích duy nhất cho các message. Queues: Là nơi chứa các message cho đến khi một chương trình lấy các message đó. Chương trình gửi sẽ đặt message vào một queue tương ứng và message sẽ được một chương trình khác lấy ra từ queue đó. Mỗi queue có thể lưu giữ một dung 14 lượng và số lượng giới hạn các message, đồng thời cũng giới hạn độ dài của mỗi message. Một số Queue cơ bản: - Local queue (queue cục bộ): là nơi dữ liệu được lưu trữ để chờ xử lý. Trong mỗi Queue manager, local queue lưu trữ các message mà queue manager nhận được. - Transmission queue (queue truyền tải): là 1 loại đặc biệt của local queue, nơi message được lưu trữ cho tới khi chúng có thể được truyền đi và lưu trữ thành công tại queue manager ở xa. - Remote queue (queue từ xa): Đặc trưng cho một queue tại Queue manager khác, nó định nghĩa một local queue của một queue manager khác. Để gửi một message tới một queue trong một queue manager ở xa, queue manager gửi phải có một định nghĩa về local queue của queue manager nhận trong nó và đó chính là remote queue. - Dead-letter queue: Mỗi queue manager thường có một dead-letter queue (được biết đến như một queue chứa các message không được phân phối), queue này thường được định nghĩa cùng với queue manager. Message được đưa vào queue này nếu nó không thể được phân phối tới đích đã được chỉ ra. - Cluster queue: là một queue được chia sẻ trong một cluster mà tất cả các queue manager trong cluster có thể đặt và lấy message từ queue sử dụng cluster channel. Channel: Các message được truyền tải giữa các queue manager thông qua các kênh (channel). Mỗi channel là một con đường để liên kết truyền thông giữa các queue manager, nó có thể truyền các message đã được định trước với số lượng bất kỳ các queue được đặt tại queue manager ở xa hoặc số lượng bất kỳ các queue manager đích. Để một message có thể gửi tới một queue manager ở xa, queue manager cục bộ phải định nghĩa một transmission queue và một channel tới queue manager ở xa đó. Cuối mỗi channel có một dấu hiệu phân tách để biết đó là kênh gửi hay kênh nhận. Một channel đơn giản gồm có channel gửi (định nghĩa tại queue manager cục bộ) và channel nhận (định nghĩa tại queue manager ở xa), hai định nghĩa này có cùng tên (tối đa 20 ký tự) và cùng nhau tạo thành định nghĩa cho mỗi channel. Mỗi channel có một hướng duy nhất, nếu ứng dụng yêu cầu các message (bao gồm cả message trả lời) được trả về từ một queue manager ở xa thì cần phải 15 có một channel khác, channel này được định nghĩa để thực hiện chiều ngược lại giữa các queue manager. Mỗi queue manager dùng một hoặc nhiều channel để gửi và nhận message. Trong một mạng TCP/IP, một channel sẽ gửi hoặc nhận dữ liệu qua một cổng đặc biệt. Mỗi sending channel có một đích đã được định nghĩa và được kết hợp với một transmission queue. Một receiving channel sẽ nhận dữ liệu từ bất kỳ Queue manager nào có cùng sending channel. Khi receiving channel nhận một message, nó kiểm tra xem queue manager và queue nào được định trước. WebSphere MQ sử dụng 2 loại channel khác nhau:  Message channel: là một liên kết truyền thông không trực tiếp giữa 2 queue manager. Websphere MQ sử dụng các message channel để truyền message giữa các queue manager. Message channel có thể là một trong các loại sau: - Sender: Sender channel là một message channel mà queue manager sử dụng để gửi message tới queue manager khác. Để gửi message dùng message channel, trong queue manager khác cũng phải tạo một receiver channel cùng tên với sender channel. - Server: một server channel là một message channel mà queue manager sử dụng để gửi message tới queue manager khác. Để gửi message sử dụng server channel trong queue manager khác cần phải tạo một receiver channel cùng tên với server channel. Có thể sử dụng server channel cùng requester channel. - Receiver: receiver channel là một message channel mà queue manager sử dụng để nhận message từ queue manager khác. Để nhận message bằng cách sử dụng receiver channel thì cần phải tạo trong queue manager khác một sender hoặc server channel cùng tên với receiver channel này. - Requester: Một requester channel là một message channel mà queue manager dùng để gửi message tới queue manager khác. Để gửi message qua requester channel cần phải tạo trong queue manager khác một sender channel, hoặc một server channel. - Cluster-sender: Cluster-sender channel định nghĩa đầu gửi của một channel trong phạm vi một cluster queue manager có thể gửi thông tin về cluster tới một trong các nơi chứa. Cluster-sender được sử dụng để thông báo nơi chứa của bất kỳ sự thay đổi nào tới trạng thái của queue manager (ví dụ việc bổ sung hoặc huỷ bỏ một queue). Clustersender channel cũng dùng để truyền tải message. Bản thân toàn bộ 16 nơi chứa các queue manager cũng có các cluster sender channel trỏ tới nhau để truyền các thay đổi trạng thái cluster cho nhau. - Cluster-receiver: Cluster-receiver channel định nghĩa đầu nhận của một channel trong phạm vi một cluster queue manager có thể nhận message từ các queue manager khác trong một cluster. Clusterreceiver channel mang thông tin về cluster đã được định trước cho nơi chứa. Bằng việc định nghĩa cluster receiver channel, queue manager chỉ ra cho các cluster queue manager khác rằng nó đã sẵn sàng cho việc nhận message.  MQI channel: để định hướng và kết nối một ứng dụng (MQI client) tới một queue manager trên máy chủ. Websphere MQ sử dụng MQI channel để truyền tải các lời gọi và đáp MQI giữa các MQI client và queue manager. MQI channel có thể là một trong 2 loại: - Server connection: Server connection channel là một MQI channel định hướng sử dụng để kết nối một Websphere MQ client tới một Websphere MQ server. Server connection channel là đầu server của channel. - Client connection: Client connection channel là một MQI channel định hướng sử dụng để kết nối một Websphere MQ client tới một Websphere MQ server. Websphere MQ Explorer cũng sử dụng client connection để kết nối tới các queue manager ở xa. Client connection channel là đầu client của channel. Khi ta tạo một client connection channel hệ thống sẽ tạo ra một file trong máy tính chứa queue manager và cần phải copy file này tới máy Websphere MQ Client. Listener Listener là một Websphere MQ process để “nghe” các kết nối tới queue manager. Mỗi đối tượng listener trong Websphere MQ Explorer biểu diễn một tiến trình “nghe”, tuy nhiên nếu tiến trình “nghe” này được start từ command line thì listener không được biểu diễn bởi listener object trong Websphere MQ Explorer. Do đó để quản lý tiến trình “nghe” từ Websphere MQ Explorer cần phải tạo đối tượng listener trong Websphere MQ Explorer và khi start đối tượng listener trong Websphere MQ Explorer, tiến trình “nghe” sẽ bắt đầu. Listener có chức năng phát hiện kết nối từ các channel và quản lý kết nối từ sending channel đến receiving channel. Trong mạng TCP/IP, Listener sẽ “nghe” các kết nối tại một cổng đặc biệt được chỉ ra khi cấu hình. Queue Manager Cluster: 17 Khi các queue được thêm vào hoặc bớt đi, việc quản trị việc truyền message trở nên khắt khe, có nhiều ngoại lệ hơn. Bằng việc dùng Queue Manager Cluster (QMC), gánh nặng quản trị có thể giảm. Queue Manager Cluster giống như một hộp đen chứa mọi Queue Manager, các chương trình bên ngoài có thể truy cập đến Queue Manager Cluster bằng WebSphere MQ Client. Các Queue manager trong cùng một QMC có thể trao đổi message mà không cần phải định nghĩa Remote Queue, Transmission Queue, Message Channel. Thông tin về tất cả các queue trong một cluster sẽ được lưu trong Cluster Full Repository. Khi một Queue manager muốn gửi message tới một queue trong cluster, nó sẽ sử dụng thông tin về vị trí của queue đích nhờ cluster full repository. Cluster Channel sẽ tự động được tạo ra. QMC giúp giảm tải giữa các chương trình: Nếu số lượng message được gửi đến một queue trong cluster vượt quá khả năng xử lý của queue đó, để giảm tải, ta có thể định nghĩa một queue mới có cùng tên với queue đó nhưng ở Queue Manager khác trong cluster. Khi message được gửi tới một queue mà được định nghĩa ở 2 Queue manager khác nhau, WebSphere MQ sẽ tự động làm công việc giảm tải bằng việc phân phối message đều cho mỗi queue. 2.1.2 Đặc trƣng của Websphere MQ và cơ chế truyền tải message Đảm bảo phân phối message: WebSphere MQ cung cấp sự đảm bảo phân phối message cùng lúc qua nhiều hệ nền khác nhau và đảm bảo rằng message không bao giờ bị mất nếu MQ đã được cấu hình. Hơn nữa WebSphere MQ cho phép truyền dữ liệu giữa các hệ thống với kiến trúc và giao thức khác nhau.[6] Không phụ thuộc thời gian và phạm vi ứng dụng: MQ cung cấp cho các trình thiết kế ứng dụng một cơ chế kiến trúc không phụ thuộc thời gian. Message có thể được gửi từ ứng dụng này tới ứng dụng khác ngay cả khi các ứng dụng này không cùng chạy tại một thời điểm. Nếu một ứng dụng nhận message không chạy khi ứng dụng khác gửi message đến thì Queue manager sẽ giữ message này cho tới khi ứng dụng nhận hỏi đến. Trật tự sắp xếp các mesage trong queue mặc định là FIFO.[6] Message có thể được truyền giữa các máy và các ứng dụng trong một mạng. Một queue có thể chứa các message gửi từ các ứng dụng trên cùng một máy hoặc các máy khác nhau. Đồng thời các ứng dụng trên cùng một máy hoặc các máy khác nhau cũng có thể lấy message ra từ một queue.[6] Giao tiếp trong phạm vi rộng lớn: 18 WebSphere MQ cung cấp một cơ chế mềm dẻo cho việc truyền thông điệp trong toàn bộ hệ thống. Sự mềm dẻo của WebSphere MQ cũng cho phép truyền thông điệp giữa các ứng dụng trong và ngoài hệ thống của doanh nghiệp.[6] Trong suốt đối với vị trí của queue: Một chương trình có thể gửi các message tới một queue ở xa mà không cần biết vị trí của nó miễn là queue ở xa đó đã được định nghĩa trong Queue Manager cục bộ. Remote Queue Definition lưu địa chỉ của queue đích và transmission queue. Queue Manager cục bộ dùng các thông tin này định vị được nơi gửi message đến. Bằng việc dùng Remote Queue Definition, Message Channel, Transmission Queue, mọi chương trình đều có thể gửi message tới mọi queue mà không cần quan tâm tới vị trí của queue đó. Giao tiếp với các Queue Manager cục bộ Các chương trình giao tiếp với các Queue Manager cục bộ thông qua một giao diện lập trình ứng dụng (API) như WebSphere MQ Message Queue Interface (MQI) hoặc Java Message Service (JMS) Chương trình tạo ra message và gửi nó tới Queue manager của nó bằng việc gọi các hàm API. Nếu queue đích là local queue thì QM sẽ gửi trực tiếp message tới đó. Thông qua các lời gọi API, chương trình cũng có thể lấy các message từ local queue. Giao tiếp bằng WebSphere MQ Clients Nếu một chương trình không có Queue Manager trên cùng một máy, ta có thể sử dụng việc gọi các hàm API thông qua WebSphere MQ Client. Client sẽ giao tiếp với queue manager ở xa bằng một client connection. Điều này cho phép chương trình có thể tương tác với Queue Manager ở xa giống như với Queue Manager cục bộ. Cơ chế truyền tải message tới một queue ở xa Nếu một chương trình muốn gửi message tới một queue ở xa (một queue thuộc queue manager khác) thì cần phải có các điều kiện sau: - Một Message Channel (dùng để kết nối giữa Queue Manager này tới một Queue Manager ở xa khác) - Một transmission queue dùng để lưu trữ message nếu message channel chưa sẵn sàng. Queue Manager sẽ đặt các message vào trong transmission Queue trước khi nó được gửi tới Queue Manager đích ở xa.