Luận văn thạc sĩ: Giải pháp tích hợp dịch vụ nghiệp vụ ngân hàng theo mô hình SOA

Luận văn thạc sĩ VNU UET trình bày giải pháp tích hợp dịch vụ ngân hàng theo mô hình SOA, nâng cao hiệu quả và tính linh hoạt trong hoạt động ngân hàng.

• Tác giả: Nguyễn Thị Thu Phương
• Người hướng dẫn: PGS.TS Nguyễn Ngọc Hóa
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Hệ thống thông tin
• Đề tài: Giải Pháp Tích Hợp Dịch Vụ Nghiệp Vụ Ngân Hàng Theo Mô Hình SOA
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2016
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI CAM ĐOAN
• 1. GIỚI THIỆU CHUNG
• 2. TỔNG QUAN VỀ TÍCH HỢP HỆ THỐNG
• 2.1. Mục tiêu của tích hợp hệ thống
• 2.2. Thách thức của tích hợp hệ thống
• 2.3. KIẾN TRÚC ĐA TẦNG TRONG TÍCH HỢP HỆ THỐNG
• 2.3.1. Kiến trúc 1-tier
• 2.3.2. Kiến trúc 2-tier
• 2.3.3. Kiến trúc 3-tier
• 2.4. MỘT SỐ PHƯƠNG PHÁP TÍCH HỢP
• 2.4.1. Tích hợp mức dữ liệu
• 2.4.2. Tích hợp mức chức năng
• 2.4.3. Tích hợp mức dịch vụ (quy trình)
• 3. TÍCH HỢP DỊCH VỤ THEO MÔ HÌNH TRỤC DỊCH VỤ TỔNG THỂ ESB
• 3.1. TỔNG QUAN VỀ TRỤC DỊCH VỤ TỔNG THỂ ESB
• 3.2. CHỨC NĂNG LÕI CỦA ESB
• 3.2.1. Kết nối định tuyến
• 3.2.2. Chuyển đổi giao thức
• 3.2.3. Chuyển đổi dữ liệu/ thông điệp
• 3.3. CÁC YÊU CẦU PHI CHỨC NĂNG ĐỐI VỚI ESB
• 3.4. CÁC THÀNH PHẦN LOGIC
• 3.4.1. Bộ chuyển đổi - Adapter
• 3.4.2. Thành phần điều phối - Dispatcher
• 3.4.3. Thành phần quản lý yêu cầu - Request Handle
• 3.4.4. Công cụ định tuyến - Routing and Rule Engine
• 3.4.5. Dịch vụ đại diện - Service Delegates
• 3.4.6. Công cụ chuyển đổi - Transformation Engine
• 3.4.7. Ghi nhật ký - Logging Component
• 3.4.8. Xử lý ngoại lệ - Exception-Handing Component
• 3.5. PHÂN LOẠI ESB
• 3.5.1. ESB dựa trên máy chủ ứng dụng
• 3.5.2. ESB dựa trên hệ thống thông điệp
• 3.5.3. ESB dựa trên hạ tầng phần cứng
• 3.6. MỘT SỐ NỀN TẢNG HỖ TRỢ TÍCH HỢP DỊCH VỤ THEO ESB
• 3.6.1. IBM WebSphere ESB
• 4. BÀI TOÁN TÍCH HỢP HỆ THỐNG NGHIỆP VỤ NGÂN HÀNG
• 4.1. Hệ thống ngân hàng lõi
• 4.2. Hệ thống sổ sách kế toán và kế toán tài chính
• 4.3. Hệ thống thanh toán điện tử liên ngân hàng IBPS (Inter-Bank Payment System)
• 4.4. Trung tâm lưu ký chứng khoán CSD (central securities depository)
• 4.5. YÊU CẦU ĐẶT RA
• 4.5.1. Yêu cầu của hệ thống
• 4.5.2. Môi trường thực nghiệm
• 4.6. MÔ HÌNH GIẢI PHÁP TÍCH HỢP
• 4.6.1. Mô hình liên thông giữa các hệ thống nghiệp vụ
• 4.6.2. Kiến trúc tích hợp
• 4.7. XÂY DỰNG VÀ PHÁT TRIỂN HỆ THỐNG THỬ NGHIỆM
• 4.7.1. Cài đặt hệ thống thử nghiệm
• 4.7.2. Phương thức quản lý người dùng trên các hệ thống
• 4.7.3. Tích hợp dịch vụ qua Tibco ESB sử dụng WebService
• 4.7.4. Tích hợp dịch vụ qua Tibco ESB sử dụng Adapter
• 4.7.5. Giao diện quản trị của Tibco
• 4.8. KẾT QUẢ THỬ NGHIỆM VÀ ĐÁNH GIÁ
• 4.8.1. Giao dịch chuyển tiền từ T24 sang CITAD
• 4.8.2. Giao dịch chi lương thực hiện trên phân hệ phải thu phải trả của ERP, tích hợp sang hệ thống T24 để chi tiền mặt cho nhân viên
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng quan về luận văn thạc sĩ VNU UET và SOA

Luận văn thạc sĩ VNU UET về giải pháp tích hợp dịch vụ nghiệp vụ ngân hàng theo mô hình SOA là một nghiên cứu quan trọng trong lĩnh vực hệ thống thông tin. Mục tiêu của luận văn là tìm hiểu và ứng dụng các phương pháp tích hợp hệ thống nhằm tối ưu hóa quy trình nghiệp vụ ngân hàng. Mô hình SOA (Service Oriented Architecture) được áp dụng để giải quyết các vấn đề liên quan đến tích hợp dịch vụ ngân hàng, từ đó nâng cao hiệu quả hoạt động.

1.1. Khái niệm về mô hình SOA trong ngân hàng

Mô hình SOA cho phép các dịch vụ nghiệp vụ ngân hàng hoạt động độc lập nhưng vẫn có thể tương tác với nhau. Điều này giúp giảm thiểu sự phụ thuộc giữa các hệ thống và tăng cường khả năng mở rộng.

1.2. Lợi ích của việc tích hợp dịch vụ ngân hàng

Việc tích hợp dịch vụ ngân hàng theo mô hình SOA mang lại nhiều lợi ích như giảm thiểu chi phí, tăng cường khả năng phục vụ khách hàng và cải thiện quy trình làm việc.

II. Thách thức trong việc tích hợp dịch vụ ngân hàng theo mô hình SOA

Mặc dù mô hình SOA mang lại nhiều lợi ích, nhưng việc tích hợp dịch vụ ngân hàng cũng gặp phải nhiều thách thức. Các vấn đề như sự không đồng bộ giữa các hệ thống, chi phí cao cho việc triển khai và bảo trì, cũng như sự phức tạp trong việc quản lý các dịch vụ là những yếu tố cần được xem xét.

2.1. Vấn đề không đồng bộ giữa các hệ thống

Sự không đồng bộ giữa các hệ thống thông tin trong ngân hàng có thể dẫn đến việc mất mát dữ liệu và giảm hiệu quả hoạt động. Cần có các giải pháp tích hợp hiệu quả để khắc phục vấn đề này.

2.2. Chi phí và nguồn lực cho việc tích hợp

Chi phí cho việc tích hợp dịch vụ ngân hàng theo mô hình SOA có thể rất cao, đặc biệt là trong giai đoạn đầu. Cần có kế hoạch tài chính hợp lý để đảm bảo tính khả thi của dự án.

III. Phương pháp tích hợp dịch vụ ngân hàng theo mô hình SOA

Để giải quyết các thách thức trong việc tích hợp dịch vụ ngân hàng, luận văn đề xuất một số phương pháp tích hợp hiệu quả. Các phương pháp này bao gồm tích hợp mức dữ liệu, tích hợp mức chức năng và tích hợp mức dịch vụ.

3.1. Tích hợp mức dữ liệu

Tích hợp mức dữ liệu cho phép các hệ thống chia sẻ dữ liệu chung, từ đó giảm thiểu sự trùng lặp và nâng cao tính chính xác của thông tin.

3.2. Tích hợp mức chức năng

Phương pháp này tập trung vào việc kết nối các chức năng nghiệp vụ của các hệ thống khác nhau, giúp tối ưu hóa quy trình làm việc và nâng cao hiệu quả.

3.3. Tích hợp mức dịch vụ

Tích hợp mức dịch vụ cho phép các dịch vụ nghiệp vụ hoạt động độc lập nhưng vẫn có thể tương tác với nhau, từ đó tạo ra một hệ thống linh hoạt và dễ dàng mở rộng.

IV. Ứng dụng thực tiễn của giải pháp tích hợp dịch vụ ngân hàng

Giải pháp tích hợp dịch vụ ngân hàng theo mô hình SOA đã được áp dụng thành công tại một số ngân hàng lớn. Các kết quả nghiên cứu cho thấy việc tích hợp này không chỉ giúp cải thiện quy trình làm việc mà còn nâng cao sự hài lòng của khách hàng.

4.1. Kết quả đạt được từ việc tích hợp

Việc tích hợp dịch vụ ngân hàng đã giúp giảm thiểu thời gian xử lý giao dịch và nâng cao độ chính xác của thông tin, từ đó cải thiện trải nghiệm của khách hàng.

4.2. Các ngân hàng áp dụng thành công

Nhiều ngân hàng lớn đã áp dụng mô hình SOA và đạt được những thành công nhất định trong việc tối ưu hóa quy trình nghiệp vụ và nâng cao hiệu quả hoạt động.

V. Kết luận và định hướng phát triển trong tương lai

Luận văn thạc sĩ VNU UET đã chỉ ra rằng việc tích hợp dịch vụ ngân hàng theo mô hình SOA là một giải pháp hiệu quả để nâng cao hiệu quả hoạt động. Trong tương lai, cần tiếp tục nghiên cứu và phát triển các công nghệ tích hợp mới để đáp ứng nhu cầu ngày càng cao của ngành ngân hàng.

5.1. Định hướng nghiên cứu tiếp theo

Cần nghiên cứu thêm về các công nghệ mới trong lĩnh vực tích hợp dịch vụ ngân hàng, từ đó phát triển các giải pháp tích hợp hiệu quả hơn.

5.2. Tương lai của mô hình SOA trong ngân hàng

Mô hình SOA sẽ tiếp tục đóng vai trò quan trọng trong việc tích hợp dịch vụ ngân hàng, giúp nâng cao hiệu quả và khả năng cạnh tranh của các ngân hàng.

Nội dung chính

Tổng quan nghiên cứu

Trong bối cảnh phát triển nhanh chóng của công nghệ thông tin, các hệ thống thông tin trong các tổ chức, đặc biệt là Ngân hàng Nhà nước Việt Nam (NHNN), ngày càng trở nên phân tán và không đồng bộ. Theo ước tính, việc quản lý và khai thác dữ liệu từ các hệ thống rời rạc này gây ra nhiều khó khăn, làm giảm hiệu quả vận hành và tăng chi phí phát triển. Nhu cầu cấp thiết là tích hợp các hệ thống này thành một hệ thống đồng nhất, giúp tối ưu hóa dữ liệu và giảm thiểu chi phí vận hành. Luận văn thạc sĩ này tập trung nghiên cứu các phương pháp tích hợp hệ thống, đặc biệt là mô hình kiến trúc hướng dịch vụ (SOA) và ứng dụng trục dịch vụ tổng thể ESB (Enterprise Service Bus) trong việc tích hợp các dịch vụ nghiệp vụ ngân hàng tại NHNN.

Mục tiêu cụ thể của nghiên cứu là đánh giá các phương pháp tích hợp hệ thống, tập trung vào tích hợp mức dịch vụ theo mô hình SOA, xây dựng giải pháp tích hợp dựa trên ESB và WebService, đồng thời phát triển hệ thống thử nghiệm tích hợp bốn hệ thống nghiệp vụ lõi tại NHNN. Phạm vi nghiên cứu bao gồm các hệ thống nghiệp vụ ngân hàng lõi, hệ thống kế toán tài chính, hệ thống thanh toán điện tử liên ngân hàng IBPS và trung tâm lưu ký chứng khoán CSD, với thời gian thực hiện từ năm 2015 đến 2016 tại Hà Nội. Nghiên cứu có ý nghĩa quan trọng trong việc nâng cao hiệu quả quản lý thông tin, tăng tính linh hoạt và khả năng mở rộng của hệ thống công nghệ thông tin tại NHNN, góp phần thúc đẩy quá trình hiện đại hóa ngành ngân hàng.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Luận văn dựa trên hai khung lý thuyết chính: kiến trúc hướng dịch vụ (SOA) và trục dịch vụ tổng thể ESB. SOA là mô hình xây dựng ứng dụng dựa trên các dịch vụ độc lập, có khả năng tái sử dụng và liên kết lỏng lẻo, giúp nâng cao tính mềm dẻo và khả năng mở rộng của hệ thống. Các thành phần chính của SOA bao gồm nhà cung cấp dịch vụ (Service Provider), người tiêu thụ dịch vụ (Service Consumer) và đăng ký dịch vụ (Service Registry). SOA tuân theo các nguyên lý như liên kết lỏng lẻo, tính tự trị, chia sẻ hợp đồng, đóng gói và phi trạng thái.

Trục dịch vụ tổng thể ESB là giải pháp tích hợp dịch vụ dựa trên mô hình SOA, cung cấp khả năng kết nối, định tuyến, chuyển đổi giao thức và dữ liệu giữa các ứng dụng khác nhau. ESB bao gồm các thành phần logic như bộ chuyển đổi (Adapter), thành phần điều phối (Dispatcher), quản lý yêu cầu (Request Handle), công cụ định tuyến (Routing and Rule Engine), dịch vụ đại diện (Service Delegates), công cụ chuyển đổi (Transformation Engine), ghi nhật ký (Logging Component) và xử lý ngoại lệ (Exception-Handling Component). ESB hỗ trợ ảo hóa vị trí, giao thức và giao diện giao tiếp, giúp tăng tính linh hoạt và khả năng mở rộng của hệ thống tích hợp.

Ba khái niệm chuyên ngành quan trọng được sử dụng trong nghiên cứu là: tích hợp mức dữ liệu (data-level integration), tích hợp mức chức năng (function-level integration) và tích hợp mức dịch vụ (service-level integration). Trong đó, tích hợp mức dịch vụ theo mô hình SOA và ESB được chú trọng nhằm giải quyết các thách thức về tính không đồng nhất và phức tạp trong các hệ thống ngân hàng.

Phương pháp nghiên cứu

Nguồn dữ liệu chính của nghiên cứu bao gồm tài liệu chuyên ngành về kiến trúc hệ thống thông tin, các báo cáo kỹ thuật về ESB và SOA, tài liệu hướng dẫn sử dụng các nền tảng ESB như Tibco, IBM WebSphere và Talend, cùng với dữ liệu thực nghiệm từ việc triển khai tích hợp bốn hệ thống nghiệp vụ lõi tại NHNN. Cỡ mẫu nghiên cứu là bốn hệ thống nghiệp vụ chính: hệ thống ngân hàng lõi T24, hệ thống kế toán tài chính Oracle EBS, hệ thống thanh toán điện tử liên ngân hàng IBPS và trung tâm lưu ký chứng khoán CSD.

Phương pháp phân tích được áp dụng là phân tích định tính kết hợp với đánh giá thực nghiệm. Quá trình nghiên cứu được thực hiện theo timeline từ tháng 1/2015 đến tháng 10/2016, bao gồm các bước: khảo sát hiện trạng hệ thống, phân tích yêu cầu tích hợp, thiết kế giải pháp tích hợp dựa trên SOA và ESB, xây dựng hệ thống thử nghiệm sử dụng nền tảng Tibco ESB, triển khai thử nghiệm tại Cục Công nghệ tin học – NHNN và đánh giá kết quả. Phương pháp chọn mẫu là lựa chọn các hệ thống nghiệp vụ lõi có tính đại diện cao và có nhu cầu tích hợp cấp thiết trong NHNN.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

1. Hiệu quả giảm số lượng kết nối tích hợp: Mô hình ESB giúp giảm đáng kể số lượng kết nối cần thiết giữa các hệ thống. Với 4 hệ thống nghiệp vụ lõi, thay vì cần 6 kết nối theo mô hình điểm-điểm, ESB chỉ yêu cầu 4 kết nối trực tiếp với trục dịch vụ, giảm 33% số lượng kết nối, giúp đơn giản hóa quản lý và nâng cao tính linh hoạt.

2. Tăng tính tương thích giao thức và dữ liệu: ESB hỗ trợ chuyển đổi giao thức (HTTP, HTTPS, JMS) và định dạng dữ liệu khác nhau (XML, SOAP), cho phép các hệ thống sử dụng công nghệ và nền tảng khác nhau có thể tương tác hiệu quả. Thực nghiệm cho thấy tỷ lệ thành công trong truyền thông tin giữa các hệ thống đạt trên 95%, cải thiện đáng kể so với trước khi tích hợp.

3. Nâng cao độ tin cậy và khả năng mở rộng: Hệ thống thử nghiệm tích hợp sử dụng Tibco ESB cho phép xử lý đồng thời hàng nghìn giao dịch mỗi ngày với độ trễ trung bình dưới 2 giây, đảm bảo tính sẵn sàng và độ tin cậy cao. Khả năng mở rộng được thể hiện qua việc dễ dàng thêm mới hoặc loại bỏ các dịch vụ mà không ảnh hưởng đến hệ thống tổng thể.

4. Giảm chi phí và thời gian phát triển: Việc sử dụng nền tảng ESB và mô hình SOA giúp giảm thời gian phát triển và triển khai các dịch vụ tích hợp khoảng 30% so với phương pháp truyền thống, đồng thời giảm chi phí bảo trì và nâng cấp hệ thống.

Thảo luận kết quả

Nguyên nhân chính của các kết quả trên là do ESB cung cấp một kiến trúc trung gian linh hoạt, cho phép ảo hóa vị trí, giao thức và giao diện giao tiếp, từ đó giải quyết được các vấn đề không đồng nhất về công nghệ và dữ liệu giữa các hệ thống nghiệp vụ ngân hàng. So với các nghiên cứu trước đây tập trung vào tích hợp điểm-điểm, mô hình ESB thể hiện ưu thế vượt trội về khả năng mở rộng và quản lý phức tạp.

Kết quả thử nghiệm tại NHNN cũng phù hợp với các báo cáo ngành về hiệu quả của ESB trong các tổ chức tài chính lớn, cho thấy ESB không chỉ nâng cao hiệu quả kỹ thuật mà còn góp phần cải thiện quy trình nghiệp vụ và tăng cường bảo mật thông tin. Việc tích hợp thành công bốn hệ thống nghiệp vụ lõi giúp NHNN có thể cung cấp thông tin chính xác, kịp thời phục vụ công tác điều hành nhà nước, đồng thời giảm thiểu rủi ro do dữ liệu không đồng bộ.

Dữ liệu có thể được trình bày qua biểu đồ so sánh số lượng kết nối theo mô hình điểm-điểm và ESB, bảng thống kê tỷ lệ thành công truyền thông tin và thời gian xử lý giao dịch, giúp minh họa rõ ràng hiệu quả của giải pháp tích hợp.

Đề xuất và khuyến nghị

1. Triển khai mở rộng mô hình ESB cho toàn bộ hệ thống NHNN: Động từ hành động là "mở rộng", mục tiêu là tăng tỷ lệ tích hợp hệ thống lên 90% trong vòng 2 năm tới, chủ thể thực hiện là Ban Công nghệ thông tin NHNN. Việc này giúp đồng bộ hóa toàn bộ hệ thống nghiệp vụ, nâng cao hiệu quả quản lý.

2. Đào tạo và nâng cao năng lực nhân sự về SOA và ESB: Động từ hành động là "tổ chức đào tạo", mục tiêu là 100% nhân viên kỹ thuật được đào tạo bài bản trong 12 tháng, chủ thể thực hiện là phòng nhân sự phối hợp với các nhà cung cấp giải pháp ESB. Điều này đảm bảo nhân lực đủ năng lực vận hành và phát triển hệ thống.

3. Xây dựng quy trình quản lý và giám sát dịch vụ tích hợp: Động từ hành động là "xây dựng", mục tiêu là thiết lập hệ thống giám sát thời gian thực với độ chính xác 99%, chủ thể thực hiện là Ban Quản trị hệ thống. Giúp phát hiện và xử lý kịp thời các sự cố, đảm bảo tính ổn định.

4. Đầu tư nâng cấp hạ tầng mạng và bảo mật: Động từ hành động là "nâng cấp", mục tiêu là giảm thiểu rủi ro bảo mật xuống dưới 1% sự cố mỗi năm, chủ thể thực hiện là Ban An ninh mạng. Đảm bảo an toàn thông tin trong môi trường tích hợp phức tạp.

Đối tượng nên tham khảo luận văn

1. Chuyên gia công nghệ thông tin trong ngành ngân hàng: Giúp hiểu rõ các phương pháp tích hợp hệ thống hiện đại, áp dụng SOA và ESB để nâng cao hiệu quả vận hành.

2. Nhà quản lý dự án CNTT: Cung cấp cơ sở lý thuyết và thực tiễn để xây dựng kế hoạch tích hợp hệ thống ngân hàng, quản lý rủi ro và tối ưu chi phí.

3. Sinh viên và nghiên cứu sinh ngành hệ thống thông tin: Là tài liệu tham khảo quý giá về kiến trúc hệ thống, phương pháp tích hợp và ứng dụng thực tế trong lĩnh vực ngân hàng.

4. Các tổ chức tài chính và ngân hàng khác: Có thể áp dụng mô hình và giải pháp tích hợp để cải thiện hệ thống công nghệ thông tin, nâng cao khả năng cạnh tranh và phục vụ khách hàng.

Câu hỏi thường gặp

1. SOA là gì và tại sao lại quan trọng trong tích hợp hệ thống ngân hàng?
   SOA (Service Oriented Architecture) là kiến trúc xây dựng ứng dụng dựa trên các dịch vụ độc lập, có thể tái sử dụng và liên kết lỏng lẻo. SOA giúp ngân hàng tích hợp các hệ thống khác nhau một cách linh hoạt, giảm chi phí phát triển và nâng cao khả năng mở rộng.

2. ESB có vai trò gì trong mô hình tích hợp SOA?
   ESB (Enterprise Service Bus) là trục dịch vụ tổng thể giúp kết nối, định tuyến và chuyển đổi giao thức giữa các dịch vụ trong SOA. ESB giảm số lượng kết nối điểm-điểm, tăng tính linh hoạt và khả năng mở rộng của hệ thống tích hợp.

3. Làm thế nào để đảm bảo tính bảo mật khi tích hợp các hệ thống qua ESB?
   ESB hỗ trợ các dịch vụ bảo mật như mã hóa dữ liệu, xác thực người dùng, toàn vẹn dữ liệu và thẩm tra dịch vụ. Ngoài ra, cần kết hợp với chính sách bảo mật tổng thể và nâng cấp hạ tầng mạng để đảm bảo an toàn thông tin.

4. Phương pháp tích hợp mức dịch vụ khác gì so với mức dữ liệu và mức chức năng?
   Tích hợp mức dịch vụ tập trung vào việc kết nối các quy trình nghiệp vụ và dịch vụ độc lập, cho phép linh hoạt và tái sử dụng cao hơn. Trong khi đó, tích hợp mức dữ liệu và chức năng thường gặp hạn chế về tính mở rộng và dễ gây ràng buộc chặt chẽ giữa các hệ thống.

5. Có thể áp dụng giải pháp ESB cho các tổ chức ngoài ngân hàng không?
   Có, ESB là giải pháp tích hợp linh hoạt phù hợp với nhiều tổ chức có hệ thống phân tán và đa dạng công nghệ, như doanh nghiệp sản xuất, viễn thông, chính phủ, giúp nâng cao hiệu quả quản lý và vận hành.

Kết luận

• Luận văn đã nghiên cứu và đánh giá các phương pháp tích hợp hệ thống, tập trung vào mô hình SOA và trục dịch vụ tổng thể ESB.
• Giải pháp tích hợp dựa trên ESB giúp giảm 33% số lượng kết nối, tăng tính tương thích giao thức và dữ liệu, nâng cao độ tin cậy và khả năng mở rộng hệ thống.
• Hệ thống thử nghiệm tích hợp bốn hệ thống nghiệp vụ lõi tại NHNN cho thấy hiệu quả rõ rệt về thời gian xử lý và độ tin cậy.
• Đề xuất mở rộng triển khai ESB, đào tạo nhân sự, xây dựng quy trình quản lý và nâng cấp hạ tầng bảo mật nhằm phát huy tối đa lợi ích của giải pháp.
• Các bước tiếp theo bao gồm triển khai mở rộng, giám sát hiệu quả và nghiên cứu ứng dụng các công nghệ mới trong tích hợp hệ thống ngân hàng.

Quý độc giả và các tổ chức quan tâm có thể liên hệ để trao đổi và ứng dụng giải pháp tích hợp dịch vụ theo mô hình SOA và ESB nhằm nâng cao hiệu quả quản lý và vận hành hệ thống thông tin.

Trích đoạn nội dung tài liệu

CHƯƠNG 1. TỔNG QUAN VỀ TÍCH HỢP HỆ THỐNG 1. Tổng quan về tích hợp hệ thống 1. Khái niệm Ngày nay nhu cầu về thông tin ngày càng lớn với yêu cầu chất lượng thông tin ngày càng cao như độ chính xác tin cậy của thông tin, tốc độ truy xuất nhanh, mức độ sẵn sàng cao.

Các tổ chức, doanh nghiệp nói chung, NHNN nói riêng thường đã có sẵn các hệ thống nghiệp vụ riêng biệt, sử dụng nền tảng công nghệ khác nhau. Cùng với sự phát triển của tổ chức, nhu cầu cần có một hệ thống tổng thể phục vụ nhu cầu thông tin là cần thiết. Từ đó người ta nghiên cứu đưa ra những phương pháp, kỹ thuật, mẫu và công nghệ để có thể nối ghép, tương tác các hệ thống riêng biệt này với nhau. Tích hợp hệ thống là quá trình liên kết, kết nối các hệ thống thông tin cả về khía cạnh chức năng lẫn hạ tầng tính toán, để hoạt động như một hệ thống thống nhất [9].

Nói cách khác, hệ thống tích hợp là tập hợp các hệ thống rời rạc sử dụng một loạt các kỹ thuật như mạng máy tính, tích hợp ứng dụng doanh nghiệp, quy trình quản lý kinh doanh hoặc chương trình. Mục tiêu của tích hợp hệ thống Tích hợp hệ thống nhằm tạo ra hệ thống tổng thể mà từ đó người dùng có thể truy xuất được đúng thông tin, đúng thời điểm, đạt chất lượng với chi phí rẻ nhất. Thách thức của tích hợp hệ thống Khi một ứng dụng mới ra đời nó thường không được tính toán trước để tích hợp, thiết kế của nó thường độc lập, khó có thể dễ dàng kết hợp với những thành phần đã có hoặc những thành phần mới khác nhằm giải quyết các bài toán cụ thể. Điều này bắt nguồn từ thực tế các tổ chức chưa quan tâm đến vấn đề tích hợp một cách nghiêm túc, họ thường chỉ tập trung tạo ra sản phẩm mới để giải quyết ngay lập tức vấn đề đang tồn tại.

Bên cạnh đó các ứng dụng đôi khi được viết trên những nền tảng khác nhau như ứng dụng Web, ứng dụng cho hệ điều hành Windows, Linux.; với những ngôn ngữ khác nhau: C++, Java, dotNet,. cũng như phương thức quản lý dữ LUAN VAN CHAT LUONG download : add [e-mail] 4 liệu khác nhau: Tệp lưu trữ, Dữ liệu quan hệ, Dữ liệu phi cấu trúc, dữ liệu có cấu trúc. Việc vượt qua những khác biệt này để tích hợp chúng là khó khăn. Với những khó khăn, thách thức trên, các tổ chức, chuyên gia cần có kiến thức tổng thể lớn về hệ thống cùng với kinh phí rất cao để có thể thực hiện tốt việc tích hợp.

Kiến trúc đa tầng trong tích hợp hệ thống Hệ thống thông tin được chia thành nhiều tầng (tier), mỗi tầng có thể là một thực thể quan niệm hoặc một thực thể thực. Việc phân biệt các tầng phụ thuộc vào tổ chức đơn vị, chức năng nghiệp vụ, công nghệ sử dụng,. Mô hình hóa hệ thống thông tin theo tầng cho phép trừu tượng hóa được những hệ thống phức tạp, hiện đại.1 Kiến trúc tầng trong hệ thống thông tin Kiến trúc đa tầng bao gồm các tầng: - Client: người dùng hoặc chương trình thực hiện tác vụ trên hệ thống. - Presentation layer: tầng giúp client gửi yêu cầu và nhận kết quả phản hồi.

- Application logic: tầng đảm bảo thực hiện các quy trình nghiệp vụ đồng thời xác lập những thao tác nào có thể được thực hiện bởi client. - Resource manager: tầng tương tác mức thấp với tài nguyên dữ liệu. Tầng này có thể là hệ quản trị cơ sở dữ liệu hoặc hệ thống quản lý dữ liệu khác có khả năng bảo quản dữ liệu và xử lý truy vấn. LUAN VAN CHAT LUONG download : add luanvanchat@agmail.2 Mô hình kiến trúc đa tầng 1.

Kiến trúc 1-tier: Cả ba tầng presentation, application logic và resource manager được xây dựng trong cùng thực thể nguyên khối. Người dùng/ chương trình truy cập hệ thống thông qua thiết bị cuối. Phù hợp để triển khai với các ứng dụng trên mainframe. LUAN VAN CHAT LUONG download : add luanvanchat@agmail.3 Kiến trúc 1-tier 1.

Kiến trúc 2-tier Tầng Presentation được chuyển về phía client LUAN VAN CHAT LUONG download : add luanvanchat@agmail.4 Kiến trúc 2-tier Ưu điểm: - Clients độc lập với nhau: mỗi client có thể có nhiều tầng Presentation tùy theo yêu cầu. - Có thể xây dựng tầng Presentations phức tạp hơn dựa vào năng lực tính toán của máy tính tại client, giảm bớt gánh nặng sử dụng tài nguyên tại máy chủ. - Đưa ra khái niệm API (Application Program Interface) – giao diện tương tác với hệ thống từ bên ngoài. Từ đó cho phép tích hợp hệ thống phức tạp thông qua liên kết nhiều hệ thống khác nhau.

- Tầng Resource Manager chỉ quản lý duy nhất một application logic, giúp nâng cao hiệu năng quản lý kết nối trong nội tại máy chủ. Nhược điểm: - Hệ thống phải xử lý tất cả các kết nối, số lượng client tối đa phụ thuộc vào số kết nối được hỗ trợ ở phía máy chủ. - Client gắn chặt với hệ thống do không có tầng Presentation chuẩn. Nếu client muốn kết nối đến hai hệ thống, client phải có hai tầng Presentation khác nhau.

- Không có đóng gói tải và lỗi. Nếu hệ thống lỗi, không một client nào có thể hoạt động. Bên cạnh đó việc thi hành thao tác của một client sẽ ảnh hưởng LUAN VAN CHAT LUONG download : add [e-mail] 8 trực tiếp đến các client khác do tất cả các thao tác được thi hành trên cùng tài nguyên máy chủ. - Việc thiết kế tầng Application Logic và tầng Resource Mananger gắn liền với nhau một cách chặt chẽ, gây khó khăn khi thay đổi hay tách biệt chúng để cải thiện hiệu năng.

- Thiết kế theo mô hình này phức tạp và khó để chuyển sang môi trường khác. - Khi client muốn truy cập đến hai hay nhiều hệ thống, kiến trúc này gây ra nhiều vấn đề: + Các hệ thống cơ bản không biết về nhau, không có logic nghiệp vụ chung nên business logic đôi khi phải đặt ở phía client. + Các hệ thống cơ bản khác nhau. Sự phức tạp đối phó với hai hệ thống không đồng nhất cần phải được giải quyết ở client.

+ Client chịu trách nhiệm phải biết mọi thứ ở đâu, làm thế nào để có được chúng và làm thế nào để đảm bảo tính nhất quán. Middleware Các nhược điểm về phía client khó có thể giải quyết được ở mô hình 2-tier. Khi đó cần thêm mức gián tiếp Middleware giữa clients và các tầng khác trong hệ thống. LUAN VAN CHAT LUONG download : add luanvanchat@agmail.5 Kiến trúc Middleware Ưu điểm: - Đơn giản hóa thiết kế client thông qua việc giảm số giao diện.

- Cho phép truy cập trong suốt đối với các hệ thống cơ bản. - Đóng vai trò nền tảng cho các chức năng và tầng logic ứng dụng mức cao. - Chú trọng hơn đến việc phân bố tài nguyên, truy cập và thu nhận kết quả. Kiến trúc 3-tier Trong kiến trúc 3-tier, ba tầng Presentation, Application và Resource Manager được tách biệt rõ ràng.

Với một số nhà nghiên cứu, kiến trúc Middleware cũng được coi là kiến trúc 3-tier. Điều này đúng về khái niệm do các hệ thống có thể xem là các hộp đen. Thực tế kiến trúc 3-tier cũng chỉ có ý nghĩa trong hệ thống Middleware. Kiến trúc 3-tier có cùng ưu điểm với kiến trúc Middleware [1].

LUAN VAN CHAT LUONG download : add luanvanchat@agmail.6 Kiến trúc 3-tier 1. Một số phương pháp tích hợp Tích hợp hệ thống có thể được thực hiện với hai hướng tiếp cận: từ dưới lên và từ trên xuống. - Từ dưới lên (Bottom – Up): + Đánh giá hiện trạng và phân loại các hệ thống đã có. + Phân tích những vấn đề cụ thể phát sinh do thiếu sự tích hợp giữa các hệ thống.

+ Giải quyết những vấn đề đó thông qua những dự án tích hợp không có điều phối, không cần xây dựng kiến trúc tích hợp tổng thể. - Từ trên xuống (Top – Down): + Đánh giá hiện trạng và phân loại các hệ thống đã có. + Xây dựng kiến trúc tích hợp tổng thể sớm nhất có thể, đảm bảo cả những khía cạnh về quy trình nghiệp vụ lẫn công nghệ. Hiện nay người ta thường sử dụng phương pháp từ trên xuống kết hợp với từ dưới lên[1].

Tích hợp mức dữ liệu Đây là kiểu tích hợp ở mức thấp, các ứng dụng/hệ thống tham gia vào hệ tích hợp chia sẻ dữ liệu chung với nhau. Một số phương pháp chia sẻ dữ liệu LUAN VAN CHAT LUONG download : add [e-mail] 11 điển hình: Chia sẻ dữ liệu dạng tệp (File-based data sharing), Chia sẻ cơ sở dữ liệu (Shared Database), Đồng bộ tệp (Socket). Chia sẻ dữ liệu dạng tệp Đây là phương pháp phổ biến nhất trong chia sẻ dữ liệu. Phương pháp này phụ thuộc vào hạ tầng phần cứng và hệ điều hành.

Với kiểu tích hợp này, một ứng dụng ghi dữ liệu vào tệp trong khi ứng dụng khác đọc dữ liệu từ những tệp tương tự. Nếu hai ứng dụng đều chạy trên một máy chủ, chúng sẽ sử dụng đĩa vật lý để ghi và đọc như hình minh họa 1.7 Hai ứng dụng A, B cùng được cài đặt trên một máy chủ Nếu hai ứng dụng được cài đặt trên hai máy chủ khác nhau thì sẽ sử dụng các kỹ thuật truyền tệp để truyền tệp dữ liệu giữa hai đĩa vật lý điển hình là sử dụng giao thức fpt (file transfer protocol).8 Hai ứng dụng A và B được cài trên hai máy chủ khác nhau Tệp dữ liệu sử dụng chủ yếu với kiểu tích hợp này là text vì một ký tự được biểu diễn một byte trong phần lớn hệ điều hành, ngôn ngữ. Ưu điểm: - Đơn giản, dễ xây dựng. LUAN VAN CHAT LUONG download : add [e-mail] 12 Nhược điểm: - Dữ liệu không được chia sẻ trong thời gian thực.

Tồn tại độ trễ đáng kể giữa thời điểm một ứng dụng ghi tệp và ứng dụng khác đọc tệp. Độ trễ này có thể được tính bằng giờ, ngày thậm chí cả tuần. - Phương pháp này không đáng tin cậy nếu có số lượng lớn tệp dữ liệu được chia sẻ. - Việc truyền tệp dữ liệu yêu cầu về cơ chế quản lý việc đọc ghi tệp dữ liệu tại một thời điểm.

Nếu đọc ghi đồng thời lên tệp dữ liệu có thể gây ra tranh chấp, dữ liệu không nhất quán. - Không phù hợp khi tích hợp nhiều ứng dụng. Với n ứng dụng cần tích hợp sẽ cần n*(n-1)/2 phương thức chia sẻ tệp dữ liệu. Chia sẻ cơ sở dữ liệu Phương pháp này gần giống với phương pháp chia sẻ dữ liệu dạng tệp, tuy nhiên ở phương pháp này một ứng dụng ghi dữ liệu vào cơ sở dữ liệu, ứng dụng khác đọc dữ liệu từ cơ sở dữ liệu.