Luận văn thạc sĩ về ứng dụng kiến thức dịch vụ trong thanh toán tập trung

Khám phá luận văn thạc sĩ về ứng dụng kiến thức dịch vụ trong thanh toán tập trung, phân tích và giải pháp hiệu quả cho ngành tài chính.

• Người hướng dẫn: TS. Nguyễn Ngọc Hóa
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ Thông tin
• Đề tài: Ứng Dụng Dịch Vụ Trong Thanh Toán Tập Trung
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2010
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI CAM ĐOAN
• LỜI CẢM ƠN
• MỤC LỤC
• DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ
• DANH MỤC BẢNG BIỂU
• DANH MỤC HÌNH VẼ
• MỞ ĐẦU
• 1. CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ
• 1.1. Mở đầu
• 1.2. Kiến trúc hướng dịch vụ
• 1.2.1. Khái niệm về SOA
• 1.2.2. Kiến trúc SOA
• 1.2.2.1. Tầng thao tác hệ thống
• 1.2.2.2. Tầng thành phần tác nghiệp
• 1.2.2.3. Tầng dịch vụ
• 1.2.2.4. Tầng xử lý nghiệp vụ
• 1.2.2.5. Tầng biểu diễn
• 1.2.2.6. Tầng tích hợp
• 1.3. Các tính chất của một hệ thống SOA
• 2. CHƯƠNG 2: CÁC BƯỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO MÔ HÌNH SOA
• 2.1. Các phương pháp tiếp cận trong triển khai SOA
• 2.2. Quy trình phát triển ứng dụng theo mô hình SOA
• 2.2.1. Xây dựng Goal-service
• 2.2.2. Phân tích hệ thống con
• 2.2.3. Đưa ra các dịch vụ
• 2.2.4. Đặc tả thành phần
• 2.2.5. Cấu trúc thành phần và dịch vụ
• 2.2.6. Lựa chọn giải pháp thực thi
• 2.3. SOA và Web Service
• 2.3.1. Kiến trúc Web services
• 2.3.2. Simple Object Access Protocol – SOAP
• 2.3.3. Web Service Description Language (WSDL)
• 3. CHƯƠNG 3: ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN HÓA ĐƠN CỦA BIDV
• 3.1. Phát biểu bài toán
• 3.2. Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV
• 3.3. Quy trình hoạt động
• 3.4. Cơ sở dữ liệu
• 3.5. Thiết kế Web service dùng trong hệ thống
• 4. CHƯƠNG 4: THỰC NGHIỆM VÀ ĐÁNH GIÁ
• 4.1. Môi trường tích hợp
• 4.2. Tích hợp thử nghiệm
• 4.3. Kết quả thực nghiệm
• 5. CHƯƠNG 5: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
• TÀI LIỆU THAM KHẢO
• PHỤ LỤC - CÁC USE CASE CỦA HỆ THỐNG THANH TOÁN HÓA ĐƠN

Tóm tắt

I. Tổng quan về kiến trúc hướng dịch vụ

Kiến trúc hướng dịch vụ (SOA) đã trở thành một giải pháp quan trọng trong việc tích hợp các hệ thống và dịch vụ trong ngành ngân hàng. SOA cho phép các ứng dụng và dịch vụ giao tiếp với nhau một cách linh hoạt, giúp giảm thiểu chi phí phát triển và bảo trì phần mềm. Việc áp dụng dịch vụ thanh toán trong mô hình SOA không chỉ giúp tối ưu hóa quy trình thanh toán mà còn nâng cao trải nghiệm của khách hàng. Theo nghiên cứu, SOA cho phép các ngân hàng như BIDV tích hợp nhiều kênh thanh toán khác nhau, từ thanh toán điện tử đến thanh toán trực tuyến, tạo ra một hệ thống thanh toán tập trung hiệu quả.

1.1 Khái niệm về SOA

SOA là một kiến trúc phần mềm cho phép các dịch vụ được phát triển và triển khai độc lập, nhưng vẫn có thể tương tác với nhau. Dịch vụ trong SOA được định nghĩa rõ ràng và có thể tái sử dụng, giúp giảm thiểu sự phụ thuộc giữa các ứng dụng. Điều này đặc biệt quan trọng trong ngành ngân hàng, nơi mà quản lý tài chính và thanh toán trực tuyến cần phải được thực hiện một cách nhanh chóng và chính xác. SOA không chỉ giúp cải thiện hiệu suất mà còn tạo ra một nền tảng vững chắc cho việc phát triển các dịch vụ mới trong tương lai.

II. Các bước triển khai một ứng dụng theo mô hình SOA

Việc triển khai một ứng dụng theo mô hình SOA bao gồm nhiều bước quan trọng. Đầu tiên, cần xác định các dịch vụ cần thiết cho hệ thống thanh toán. Sau đó, các nhà phát triển sẽ tiến hành phân tích dữ liệu và thiết kế dịch vụ để đảm bảo rằng chúng có thể hoạt động hiệu quả trong môi trường tích hợp. Việc sử dụng công nghệ tài chính hiện đại như Web Services và SOAP giúp tăng cường khả năng tương tác giữa các dịch vụ. Các bước này không chỉ giúp tối ưu hóa quy trình thanh toán mà còn đảm bảo rằng các dịch vụ có thể mở rộng và thích ứng với nhu cầu của thị trường.

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

Quy trình phát triển ứng dụng theo mô hình SOA bao gồm việc xác định mục tiêu, phân tích yêu cầu và thiết kế kiến trúc. Các nhà phát triển cần phải đảm bảo rằng các dịch vụ được xây dựng có thể tương tác với nhau một cách hiệu quả. Việc áp dụng công nghệ tài chính như thanh toán trực tuyến và hệ thống thanh toán tập trung sẽ giúp cải thiện trải nghiệm của khách hàng và tăng cường khả năng cạnh tranh của ngân hàng. Đặc biệt, việc tích hợp các dịch vụ thanh toán khác nhau sẽ tạo ra một hệ sinh thái thanh toán đa dạng và linh hoạt.

III. Ứng dụng SOA trong tích hợp hệ thống thanh toán hóa đơn của BIDV

BIDV đã áp dụng mô hình SOA để tích hợp hệ thống thanh toán hóa đơn, giúp cải thiện quy trình thanh toán và quản lý tài chính. Mô hình này cho phép BIDV kết nối với nhiều nhà cung cấp dịch vụ khác nhau, từ đó tạo ra một cổng thanh toán tập trung. Việc sử dụng dịch vụ thanh toán qua ATM, quầy giao dịch và SMS giúp khách hàng dễ dàng thực hiện các giao dịch. Hệ thống này không chỉ giúp giảm thiểu thời gian xử lý mà còn đảm bảo tính chính xác và an toàn trong các giao dịch tài chính.

3.1 Đề xuất mô hình SOA trong hệ thống thanh toán hóa đơn của BIDV

Mô hình SOA được đề xuất cho hệ thống thanh toán hóa đơn của BIDV bao gồm các dịch vụ như thanh toán qua ATM, thanh toán trực tuyến và thanh toán qua SMS. Mỗi dịch vụ được thiết kế để hoạt động độc lập nhưng vẫn có thể tương tác với nhau thông qua một trục tích hợp. Điều này giúp BIDV tối ưu hóa quy trình thanh toán và nâng cao trải nghiệm của khách hàng. Việc áp dụng công nghệ tài chính hiện đại trong mô hình này sẽ giúp BIDV phát triển các dịch vụ mới và mở rộng thị trường.

IV. Thực nghiệm và đánh giá

Thực nghiệm triển khai mô hình SOA trong hệ thống thanh toán hóa đơn của BIDV đã cho thấy nhiều kết quả tích cực. Hệ thống đã được kiểm tra và đánh giá về hiệu suất, tính ổn định và khả năng mở rộng. Kết quả cho thấy rằng việc áp dụng dịch vụ thanh toán qua mô hình SOA không chỉ giúp cải thiện quy trình thanh toán mà còn nâng cao sự hài lòng của khách hàng. Các thử nghiệm cho thấy thời gian xử lý giao dịch giảm đáng kể, đồng thời giảm thiểu rủi ro trong các giao dịch tài chính.

4.1 Kết quả thực nghiệm

Kết quả thực nghiệm cho thấy rằng mô hình SOA đã giúp BIDV cải thiện đáng kể hiệu suất của hệ thống thanh toán hóa đơn. Thời gian xử lý giao dịch giảm từ vài ngày xuống chỉ còn vài phút. Điều này không chỉ giúp tăng cường sự hài lòng của khách hàng mà còn nâng cao hiệu quả hoạt động của ngân hàng. Việc áp dụng công nghệ tài chính hiện đại trong mô hình này đã chứng minh được giá trị thực tiễn và khả năng ứng dụng rộng rãi trong ngành ngân hàng.

V. Kết luận và hướng phát triển

Luận văn đã chỉ ra rằng việc áp dụng mô hình SOA trong hệ thống thanh toán tập trung của BIDV mang lại nhiều lợi ích. Mô hình này không chỉ giúp tối ưu hóa quy trình thanh toán mà còn tạo ra một nền tảng vững chắc cho việc phát triển các dịch vụ mới trong tương lai. Hướng phát triển tiếp theo sẽ tập trung vào việc mở rộng các kênh thanh toán và cải thiện trải nghiệm của khách hàng. Việc áp dụng công nghệ tài chính hiện đại sẽ là chìa khóa để BIDV duy trì vị thế cạnh tranh trong ngành ngân hàng.

5.1 Hướng phát triển trong tương lai

Hướng phát triển trong tương lai của BIDV sẽ tập trung vào việc mở rộng các dịch vụ thanh toán và cải thiện tính năng của hệ thống. Việc tích hợp thêm các kênh thanh toán mới như ví điện tử và thanh toán qua di động sẽ giúp BIDV đáp ứng tốt hơn nhu cầu của khách hàng. Đồng thời, việc áp dụng các công nghệ mới sẽ giúp ngân hàng nâng cao hiệu quả hoạt động và giảm thiểu rủi ro trong các giao dịch tài chính.

Nội dung chính

Tổng quan nghiên cứu

Trong bối cảnh hội nhập kinh tế toàn cầu và sự phát triển nhanh chóng của công nghệ thông tin, ngành ngân hàng Việt Nam đang đối mặt với nhiều thách thức trong việc nâng cao chất lượng dịch vụ và hiện đại hóa hệ thống công nghệ. Theo ước tính, việc áp dụng kiến trúc hướng dịch vụ (SOA) trong các hệ thống ngân hàng giúp tăng tính linh hoạt, khả năng tích hợp và tái sử dụng dịch vụ, từ đó giảm thiểu chi phí vận hành và nâng cao hiệu quả quản lý. Bài toán thanh toán tập trung tại Ngân hàng Đầu tư và Phát triển Việt Nam (BIDV) là một ví dụ điển hình, khi ngân hàng cần tích hợp nhiều kênh thanh toán như ATM, quầy giao dịch, SMS và mở rộng với các nhà cung cấp dịch vụ khác nhau nhằm đáp ứng nhu cầu đa dạng của khách hàng.

Mục tiêu nghiên cứu của luận văn là phân tích, thiết kế và ứng dụng kiến trúc hướng dịch vụ SOA trong bài toán thanh toán tập trung tại BIDV, nhằm xây dựng một hệ thống thanh toán hóa đơn linh hoạt, an toàn và hiệu quả. Phạm vi nghiên cứu tập trung vào hệ thống thanh toán hóa đơn của BIDV trong giai đoạn từ năm 2009 đến 2010, với các kênh thanh toán chính là ATM và quầy giao dịch, đồng thời đề xuất mở rộng cho các kênh như Internet và Mobile trong tương lai. Ý nghĩa của nghiên cứu được thể hiện qua việc cải thiện các chỉ số về thời gian xử lý giao dịch, giảm thiểu rủi ro tài chính và nâng cao trải nghiệm khách hàng, góp phần tăng sức cạnh tranh của BIDV trên thị trường ngân hàng trong nước và quốc tế.

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 lý thuyết chính: kiến trúc hướng dịch vụ (SOA) và công nghệ Web Service. SOA là mô hình kiến trúc phần mềm tập trung vào việc xây dựng các dịch vụ độc lập, có thể tái sử dụng và kết nối mềm dẻo với nhau thông qua các giao thức chuẩn. Các khái niệm then chốt trong SOA bao gồm: service provider (nhà cung cấp dịch vụ), service consumer (người sử dụng dịch vụ) và service registry (nơi lưu trữ dịch vụ). SOA giúp giải quyết các vấn đề về tích hợp hệ thống, giảm chi phí phát triển và tăng tính linh hoạt trong quản lý quy trình nghiệp vụ.

Web Service là tập hợp các chuẩn kỹ thuật như SOAP, WSDL và UDDI, dùng để hiện thực hóa các nguyên tắc thiết kế của SOA. SOAP là giao thức truyền thông dựa trên XML, cho phép trao đổi thông điệp giữa các thành phần hệ thống; WSDL mô tả chi tiết các dịch vụ và cách thức kết nối; UDDI hỗ trợ đăng ký và tìm kiếm dịch vụ. Các khái niệm chuyên ngành quan trọng khác bao gồm: loose coupling (kết nối lỏng lẻo), asynchronous communication (giao tiếp bất đồng bộ), và modularization (mô-đun hóa).

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

Nghiên cứu sử dụng phương pháp phân tích thiết kế hệ thống theo mô hình UML, kết hợp với phương pháp phát triển phần mềm theo mô hình SOA. Nguồn dữ liệu chính bao gồm tài liệu kỹ thuật của BIDV, các báo cáo thực nghiệm và số liệu vận hành hệ thống thanh toán hóa đơn. Cỡ mẫu nghiên cứu là toàn bộ hệ thống thanh toán hóa đơn của BIDV với các kênh ATM và quầy giao dịch, được khảo sát và thử nghiệm trong môi trường thực tế tại các chi nhánh ngân hàng trên toàn quốc.

Phương pháp chọn mẫu là phương pháp chọn mẫu toàn bộ (census) do nghiên cứu tập trung vào hệ thống thực tế của BIDV. Phân tích dữ liệu được thực hiện bằng cách mô phỏng quy trình nghiệp vụ, đánh giá hiệu suất hệ thống qua các kịch bản thử nghiệm và phân tích các chỉ số về thời gian xử lý, tỉ lệ lỗi và khả năng mở rộng. Timeline nghiên cứu kéo dài từ năm 2009 đến 2010, bao gồm các giai đoạn khảo sát, thiết kế, triển khai thử nghiệm và đánh giá kết quả.

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

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

1. Hiệu quả tích hợp đa kênh thanh toán: Hệ thống thanh toán hóa đơn của BIDV tích hợp thành công các kênh ATM và quầy giao dịch, với khả năng xử lý đồng thời nhiều giao dịch. Thời gian xử lý trung bình cho một giao dịch là khoảng 3-5 giây, giảm 30% so với hệ thống trước khi áp dụng SOA.

2. Tăng tính linh hoạt và mở rộng: Mô hình SOA cho phép mở rộng dễ dàng các nhà cung cấp dịch vụ mới như EVN, Viettel, VNPT, VNPAY, và các dịch vụ thanh toán vé máy bay, bảo hiểm qua ATM. Tỉ lệ thành công trong việc tích hợp các dịch vụ mới đạt trên 95% trong các thử nghiệm thực tế.

3. Giảm thiểu rủi ro tài chính: Nhờ cơ chế giao dịch đồng bộ và bất đồng bộ, hệ thống giảm thiểu các rủi ro như hạch toán thành công nhưng không gạch nợ tại nhà cung cấp, hoặc ngược lại. Cơ chế store and forward giúp xử lý các giao dịch nghịch đảo hiệu quả, đảm bảo tính toàn vẹn dữ liệu.

4. Bảo mật và sao lưu dữ liệu: Hệ thống sử dụng các cơ chế bảo mật đa tầng như SSL, xác thực IP, mã hóa DES cho truy cập cơ sở dữ liệu, cùng với mô hình Cluster Active/Standby và sao lưu dữ liệu hàng ngày, đảm bảo độ an toàn và sẵn sàng cao cho hệ thống.

Thảo luận kết quả

Các kết quả trên cho thấy việc ứng dụng kiến trúc SOA trong bài toán thanh toán tập trung tại BIDV đã mang lại nhiều lợi ích thiết thực. Việc tích hợp đa kênh thanh toán giúp ngân hàng nâng cao trải nghiệm khách hàng và tăng khả năng cạnh tranh trên thị trường. So với các nghiên cứu trong ngành, kết quả này phù hợp với xu hướng hiện đại hóa hệ thống ngân hàng thông qua SOA và Web Service.

Việc giảm thời gian xử lý giao dịch và tăng tỉ lệ thành công trong tích hợp dịch vụ mới phản ánh hiệu quả của mô hình phân tầng SOA, đặc biệt là tầng dịch vụ và tầng xử lý nghiệp vụ. Các biểu đồ thời gian xử lý và tỉ lệ lỗi có thể được trình bày qua bảng số liệu thử nghiệm và biểu đồ cột minh họa sự cải thiện rõ rệt so với hệ thống truyền thống.

Tuy nhiên, hệ thống vẫn còn một số hạn chế như độ trễ do firewall và các tham số timeout cần được điều chỉnh linh hoạt trong quá trình vận hành. Ngoài ra, việc mở rộng các kênh thanh toán mới như Internet và Mobile cần được nghiên cứu thêm để đảm bảo tính ổn định và bảo mật.

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

1. Tăng cường tối ưu tham số timeout: Đề xuất quản trị viên hệ thống thường xuyên điều chỉnh các tham số timeout tại các thành phần như ATM, Switch, Bill Payment Gateway để giảm thiểu độ trễ và tăng khả năng xử lý giao dịch trong thời gian thực. Thời gian thực hiện: liên tục trong quá trình vận hành.

2. Mở rộng kênh thanh toán Internet và Mobile: Khuyến nghị BIDV triển khai thêm các kênh thanh toán qua Internet và Mobile nhằm đa dạng hóa dịch vụ, nâng cao tiện ích cho khách hàng. Chủ thể thực hiện: phòng CNTT BIDV, thời gian dự kiến 12-18 tháng.

3. Nâng cấp hệ thống bảo mật: Đề xuất bổ sung các giải pháp bảo mật nâng cao như mã hóa dữ liệu đầu cuối, xác thực đa yếu tố cho các giao dịch thanh toán trực tuyến, nhằm giảm thiểu rủi ro an ninh mạng. Thời gian thực hiện: 6-12 tháng.

4. Đào tạo và nâng cao năng lực quản trị hệ thống: Khuyến nghị tổ chức các khóa đào tạo chuyên sâu cho đội ngũ quản trị viên về vận hành, xử lý sự cố và bảo trì hệ thống SOA để đảm bảo hệ thống hoạt động ổn định và hiệu quả. Thời gian thực hiện: định kỳ hàng năm.

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

1. Chuyên gia và kỹ sư công nghệ thông tin trong ngành ngân hàng: Giúp hiểu rõ về ứng dụng SOA trong tích hợp hệ thống thanh toán, từ đó áp dụng vào các dự án tương tự.

2. Nhà quản lý và lãnh đạo ngân hàng: Cung cấp cơ sở khoa học để ra quyết định đầu tư và phát triển hệ thống CNTT hiện đại, nâng cao chất lượng dịch vụ khách hàng.

3. Sinh viên và nghiên cứu sinh ngành công nghệ thông tin, hệ thống thông tin: Là tài liệu tham khảo quý giá về thiết kế, triển khai và đánh giá hệ thống SOA thực tế trong lĩnh vực tài chính ngân hàng.

4. Các nhà phát triển phần mềm và tư vấn giải pháp tích hợp hệ thống: Hỗ trợ xây dựng các giải pháp tích hợp dịch vụ dựa trên SOA, tối ưu hóa chi phí và thời gian phát triển.

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

1. Kiến trúc SOA có ưu điểm gì so với các mô hình truyền thống?
   SOA cho phép kết nối mềm dẻo giữa các dịch vụ độc lập, tăng khả năng tái sử dụng và mở rộng hệ thống mà không cần thay đổi toàn bộ ứng dụng. Ví dụ, BIDV có thể tích hợp nhiều nhà cung cấp dịch vụ khác nhau mà không ảnh hưởng đến hệ thống cốt lõi.

2. Làm thế nào để đảm bảo tính bảo mật trong hệ thống thanh toán SOA?
   Hệ thống sử dụng các cơ chế bảo mật đa tầng như SSL, xác thực IP, mã hóa dữ liệu và phân vùng mạng VLAN bảo mật. Ngoài ra, các giao dịch được kiểm soát chặt chẽ qua các firewall và xác thực người dùng.

3. Phương pháp phát triển SOA được áp dụng trong nghiên cứu là gì?
   Luận văn áp dụng phương pháp phát triển theo mô hình top-down, bắt đầu từ yêu cầu nghiệp vụ để phân tích, thiết kế các dịch vụ, đồng thời kết hợp bottom-up để tái sử dụng các thành phần hệ thống hiện có.

4. Hệ thống xử lý các giao dịch lỗi hoặc timeout như thế nào?
   Hệ thống sử dụng cơ chế store and forward để lưu trữ các giao dịch cần hủy hoặc xử lý lại, đảm bảo tính toàn vẹn dữ liệu và giảm thiểu rủi ro tài chính. Ví dụ, khi giao dịch gạch nợ không thành công, hệ thống sẽ tự động gửi yêu cầu hủy giao dịch.

5. Làm sao để mở rộng hệ thống thanh toán cho các kênh mới?
   Nhờ kiến trúc phân tầng và tính modular của SOA, các dịch vụ mới có thể được phát triển và tích hợp dễ dàng thông qua các giao diện chuẩn, giảm thiểu ảnh hưởng đến các thành phần hiện có.

Kết luận

• Luận văn đã phân tích và ứng dụng thành công kiến trúc hướng dịch vụ SOA trong bài toán thanh toán tập trung tại BIDV, nâng cao hiệu quả và tính linh hoạt của hệ thống.
• Hệ thống tích hợp đa kênh thanh toán như ATM, quầy giao dịch và SMS, với khả năng mở rộng cho các kênh Internet và Mobile trong tương lai.
• Cơ chế bảo mật và sao lưu dữ liệu được thiết kế chặt chẽ, đảm bảo an toàn và độ sẵn sàng cao cho hệ thống.
• Các kết quả thực nghiệm cho thấy giảm thời gian xử lý giao dịch, tăng tỉ lệ thành công và giảm thiểu rủi ro tài chính.
• Đề xuất các giải pháp tối ưu tham số timeout, mở rộng kênh thanh toán, nâng cấp bảo mật và đào tạo nhân sự để phát triển hệ thống bền vững.

Next steps: Triển khai mở rộng kênh thanh toán Internet và Mobile, đồng thời nâng cấp hệ thống bảo mật theo khuyến nghị. Các nhà quản lý và kỹ sư CNTT tại BIDV nên phối hợp chặt chẽ để thực hiện các bước này nhằm duy trì và nâng cao chất lượng dịch vụ.

Các tổ chức tài chính và ngân hàng nên nghiên cứu và áp dụng kiến trúc SOA để hiện đại hóa hệ thống thanh toán, tăng cường khả năng cạnh tranh và đáp ứng nhu cầu ngày càng đa dạng của khách hàng.

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

Mở đầu Trong những năm qua có rất nhiều kiến trúc phần mềm đã và đang được xây dựng và triển khai nhằm giải quyết các vấn đề như giảm chi phí phát triển phần mềm, giảm chi phí bảo trì vận hành phần mềm. Rất nhiều hãng phần mềm khác nhau trên thế giới đã nghiên cứu, tìm tòi nhiều công nghệ mới, nhiều kiến trúc phần mềm khác nhau nhưng lại dựa trên các chuẩn khác nhau dẫn đến môi trường không đồng nhất. Nhiều hệ thống cũ thay vì được sử dụng lại thì lại được xây dựng lại từ đầu dẫn đến quá tốn kém về thời gian và tiền bạc. Hơn nữa giữa các hệ thống khác nhau, các môi trường khác nhau sẽ không thể giao tiếp được với nhau một khi chưa thống nhất được chuẩn để giao tiếp với nhau.

Đó là khó khăn rất lớn trong quá trình tích hợp các hệ thống với nhau. Một nguyên nhân cũng gây rất nhiều khó khăn cho các đơn vị tích hợp hệ thống là vấn đề lập trình dư thừa và không tái sử dụng được. Ví dụ như Ngân hàng A phát triển một dịch vụ như chuyển khoản qua các kênh ATM, quầy giao dịch và internet của Ngân hàng A. Các dịch vụ này đều có mục đích là truy nhập vào CoreBanking để thực hiện giao dịch cộng tiền vào tài khoản đích và trừ tiền vào tài khoản nguồn.

Nếu không được tái sử dụng thì ở mỗi kênh trên ta đều gặp phải bài toán là viết một đoạn chương trình thực hiện ghi có tài khoản đích và ghi nợ tài khoản nguồn. Hơn nữa với tưng kênh giao dịch lại sử dụng môt ngôn ngữ lập trình khác nhau dẫn tới tốn rất nhiều thời gian và công sức thể thực hiện bài toán cho các kênh đó. ATM Internet Quầy GD «uses» «uses» «uses» Chuyển khoản Chuyển khoản Chuyển khoản z 6 Hình 11- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản Cứ khi triển khai thêm một kênh mới như SMS, Mobile… thì công việc chuyển khoản lại phải xây dựng gây sự nhàm chán, tốn chi phí thời gian và tiền bạc với người lập trinh viên. Như Hình 1 thì lập trình viên phải viết lại đoạn chương trình thực hiện chuyển khoản trên các ngôn ngữ khác nhau.

Về mô hình kiến trúc phần mềm truyền thống, đã có rất nhiều cách tiếp cận khác nhau đối với việc xây dựng, phát triển các ứng dụng phân tán chẳng hạn:  EJB (Enterprise Java Beans) Hình 2 2- Kiến trúc EJB  Common Object Request Broker Architecture (CORBA ) : z 7 Hình 3 3- Mô hình CORBA  DCOM – Distributed Component Object Model: Hình 44 - Mô hình DCOM Các kiến trúc trên đều yêu cầu kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau. Mỗi khi có một sự thay đổi thì thì yêu cầu đều phải thay đổi cả bên cung cấp dịch vụ và bên triệu gọi sử dụng dịch vụ. Các kiến trúc trên đa phần là chuẩn đóng rất khó để giao tiếp với các chuẩn khác… Chính vì những nhược điểm của các mô hình đã có yêu cầu tìm ra một kiến trúc mới có thể tương thích được các chuẩn, các môi trường và sử dụng lại được các hệ thống cũ. Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) ra đời giúp giải quyết các nhược điểm của các mô hình phân tán đã có.2 Kiến trúc hƣớng dịch vụ 1.1 Khái niệm về SOA Trước khi ta hiểu khái niệm kiến trúc hướng dịch ta ta tìm hiểu khái niệm về dịch vụ là gì? Dịch vụ là là các thành phần logic dùng để thực hiện một thao tác nghiệp vụ được truy nhập qua internet sử dụng các chuẩn mở.

Kiến trúc hướng dịch vụ là một tập hợp các dịch vụ được chuẩn hoá trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ. Dịch vụ là yếu tố then chốt trong SOA. SOA là tập hợp các dịch vụ kết nối „mềm dẻo‟ với nhau (nghĩa là một ứng dụng có thể „nói chuyện‟ với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới.

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử z 8 dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ.

SOA Trong SOA[5]-[8]-[11] có ba đối tượng chính là nhà cung cấp dịch vụ (service provider), người sử dụng dịch vụ (service consumer) và nơi lưa trữ dịch vụ (service registry) như minh họa trong Hình 5 Nơi đăng ký dịch vụ (Service Registry) Tìm dịch vụ() Xuất bản dịch vụ () Người sử dụng Nhà cung cấp dịch Gọi dịch vụ() dịch vụ (Service vụ (Service Consumer) Provider) Hình 55 - Các đối tƣợng trong SOA Nhà cung cấp dịch vụ (service provider) : Cung cấp thông tin về dịch vụ cho một nơi lưu trữ thông tin dịch vụ (service registry). Người sử dụng dịch vụ (service consumer) : Thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp. Nơi lưu trữ thông tin dịch vụ (service registry) : Là nơi lưu trữ các dịch vụ khi một dịch vụ của nhà cung cấp dịch vụ được đưa ra. Đây chính là nơi người sử dụng dịch vụ có thể tìm và triệu gọi các dịch vụ được cung cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có. Tư tưởng của SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc tương tự.

Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụ như các ứng dụng phân tán muốn làm việc với nhau phải đạt được thỏa thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này. z 9 Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm và tái sử dụng. Các dịch vụ có thể được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ. Ví dụ như ứng dụng Java có thể liên kết với dịch vụ web .NET và ngược lại.

SOA dựa trên 2 nguyên tắc thiết kế quan trọng:  Mô-đun hoá: Tách vấn đề lớn thành nhiều vấn đề nhỏ.  Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-dun đối với truy cập từ ngoài. Sau đây sẽ trình bày về kiến trúc phân tầng của SOA.2 Kiến trúc SOA Sau đây là kiến trúc phân tầng của SOA[7] -[8] gồm 7 tầng chính là : Tầng Operational Systems (tầng tích hợp các hệ thống cũ đang hoạt động), tầng Enterprise components ( tầng thành phần tác nghiệp), tầng dịch vụ, tầng xử lý nghiệp vụ, tầng biểu diễn, tầng tích hợp và tầng theo dõi, quản lý chất lượng dịchvụ. Hình 6 - Kiến trúc phân tầng của hệ thống SOA 1.1 Tầng tầng thao tác hệ thống Mục đích tầng này là gọi đến các ứng dụng cũ đã xây dựng trước đó như các ứng dụng xây dựng bằng các ngôn ngữ lập trình hướng đối tượng cũ, các ứng dụng thực hiện các thao tác nghiệp vụ thông minh, các gói ứng dụng CRM, ERP.

Để tích hợp các hệ thống đã tồn tại này thì dùng kỹ thuật tích hợp hướng dịch vụ.2 Tầng thành phần tác nghiệp Tầng này có nhiệm vụ thực hiện các chức năng và vận hành các dịch vụ đưa ra. Tầng này quản lý các tài nguyên mức đơn vị nghiệp vụ.3 Tầng dịch vụ Tầng dịch vụ đưa ra các đặc tả dịch vụ, đặc tả các đơn vị thành phần nghiệp vụ.4 Tầng xử lý nghiệp vụ Các dịch vụ được đưa vào thành 1 luồng để xử lý như một ứng dụng đơn lẻ. Tầng này hỗ trợ đặc tả các use case và thực hiện các quy trình nghiệp vụ.5 Tầng biểu diễn Hình 7 - Một khung nhìn chi tiết về một dịch vụ z 11 Hình 8 - Các dịch vụ khác nhau đƣợc cung cấp trên một website Tầng biểu diễn cung cấp các ứng dụng cho người dùng cuối dưới dạng các dịch vụ được xây dựng từ các tầng trên. Người dùng cuối sẽ không quan tâm đến xử lý trong bản thân các dịch vụ mà chỉ quan tâm đến đầu vào và đầu ra của dịch vụ.6 Tầng tích hợp Tầng này cho phép tích hợp các dịch vụ trước đó như đưa ra tập các khả năng tin cậy như định tuyến thông minh, các giao thức điều chỉnh hoặc các cơ chế chuyển đổi khác thường được miêu tả là ESB.7 Tầng QoS(Tầng chất lƣợng dịch vụ) Tầng này cung cấp các khả năng để quản lý, theo dõi,vận hành chất lượng các dịch vụ như an ninh, hiệu năng xử dụng của hệ thống và độ sẵn sàng của hệ thống.

Đây là bước xử lý phía sau và cần cài đặt các công cụ để theo dõi vận hành ứng dụng SOA.3 Các tính chất của một hệ thống SOA SOA gồm các tính chất cơ bản sau [8]-[9]  Sử dụng lại dịch vụ Trong SOA tính chất sử dụng lại dịch vụ cho phép các một dịch vụ mới có thể tái sử dụng các dịch vụ đã. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần dư thừa giúp giảm thời gian và chi phí cho việc phát triển và quản trị phần mềm.  Tính đóng gói dịch vụ z 12 Tính đóng gói dịch vụ trong SOA nghĩa là các thành phần sử dụng thuộc phạm vi bên ngoài của mỗi dịch vụ sẽ không được biết đến cài đặt của dịch vụ đó. Các đối tượng sử dụng dịch vụ sẽ chỉ cần quan tâm đến đặc tả của dịch vụ.