Bài toán đặt ra ở đây là giải quyết vấn đề xung đột khi có nhiều giao dịch cùng thực hiện trên một tài khoản để đảm bảo an toàn cho ngân hàng cũng như không gây phiền toái cho khách hàng. Để giải quyết bài toán này, ta có thể áp dụng một số thuật toán phân tán, mỗi thuật toán có ưu và nhược điểm riêng. Trong bài luận văn này, chúng ta sẽ sử dụng thuật toán Mutual Exclution của Burn áp dụng cho bài toán để minh hoạ.
Sau đây là phần mô tả cách thức giải quyết bài toán.
Phân tích: chúng ta cũng biết, vấn đề tương tranh chỉ xảy ra đối với các giao dịch trên cùng một tài khoản. Hệ thống ngân hàng có rất nhiều tài khoản và thuật toán xử lý tương tranh sẽ được áp dụng trên từng tài khoản, và ta có thể coi mỗi tài khoản có một kênh xử lý. Khi nhận được thông điệp yêu cầu về các giao dịch thì đầu tiên, chúng ta sẽ lấy số hiện tài khoản của tiến trình đó, sau đó đặt vào kênh giải quyết tương ứng. Để thực hiện điều này thì tất cả các tiến trình giao dịch sẽ được đặt vào một hàng đợi thông điệp. Một vấn đề nữa mà chúng ta cần quan tâm ở đây là việc đánh số các tiến trình. Theo như các thuật toán mà chúng ta nghiên cứu trước đây, mọi vòng lặp đều thực hiện dựa trên số lượng tiến trình n. Số n càng lớn thì thời gian thực hiện các vòng
lặp càng nhiều. Vì vậy giải pháp đưa ra ở đây là số của tiến trình sẽ được thiết lập lại sau một ngày hoạt động. Thông thường giờ được chọn để thiết lập lại việc đánh số của tiến trình sẽ là thời điểm có ít giao dịch nhất, có thể là 1 hoặc 2 giờ sáng. Việc đánh số của tiến trình cũng không phải theo tổng số giao dịch của toàn hệ thống mà là dựa trên tài khoản của tiến trình đó.
Áp dụng giải thuật của Burn: Các biến chia xẻ
tk: số lượng tài khoản khách hàng tối đa mà hệ thống hiện có.
n: là số lượng giao dịch tối đa có thể của một khách hàng trong một ngày. Số n sẽ được tính bằng số lượng thẻ ATM tối đa có thể được cấp cho khách hàng nhân với số lượng giao dịch tối đa của mỗi thẻ có thể được thực hiện trong một ngày.
id: mảng số tự nhiên lưu số hiệu tiến trình giao dịch cho mỗi tài khoản [1..tk], nhận giá trị trong miền [1..n+1]. Mỗi biến id[j] đều được đọc và ghi bởi tất cả các tiến trình của tài khoản j.
flag: là một mảng hai chiều [1..tk][1..n] có giá trị nằm trong tập {0,1}, trong đó flag[j][i] được viết bởi tiến trình pi của tài khoản j và được đọc bởi tất cả các tiến trình của tài khoản j.
Đoạn mã thiết lập lại số cho các tiến trình: For i {1, .., tk} do
id[i]1 End for
Đoạn mã đánh số tiến trình:
Với mỗi tiến trình đến, đặt tiến trình vào hàng đợi thông điệp Với mỗi tiến trình được lấy ra từ hàng đợi
- Lấy số tài khoản j của tiến trình - Gán số hiệu cho tiến trình bằng id[j] - Tăng giá trị id[j] thêm 1.
- Đặt tiến trình vào kênh tài khoản j. Đoạn mã cho mỗi tiến trình pi của tài khoản j
L :
flag[j][i] 0
For x {1,2, ... , i-1} do
if ( flag[j][x] = 1 ) then goto L ; end if
end for flag[j][i] 1
For x {1, 2, ..., i-1} do
end if end for M :
for x {i+1, ..., id[j]-1} do
if flag[j][x] = 1 then goto M end if
end for
******Critical region*********
Thực hiện xử lý giao dịch cho tiến trình flag[j][i] 0
****** Remainder********
Nhận xét : Chúng ta thấy rằng về bản chất thì các thuật toán phân tán mà chúng ta đề cập trước đây đều giải quyết vấn đề sao cho tại một thời điểm chỉ có duy nhất một tiến trình duy nhất được phép truy nhập vào tài khoản của khách hàng để thực hiện giao dịch. Sự khác biệt của các thuận toán phân tán với cách xử lý hiện tại của hệ thống là trạng thái bận của tài khoản không được lưu trên 1 trường ở cơ sở dữ liệu nữa mà được lưu vào mảng flag tương ứng cho từng tài khoản. Việc lưu trạng thái tài khoản vào mảng flag như vậy đem lại các cải tiến sau :
giảm bớt việc kết nối đến cơ sở dữ liệu, làm tăng tốc độ giao dịch của khách hàng.
các giao dịch trên cùng tài khoản khi chưa được xử lý sẽ đợi cho đến khi tài khoản ở chế độ rỗi và sau đó được thực hiện. Như vậy sẽ giảm số lượng số lượng thông điệp trên đường truyền khi khách hàng không phải thực hiện lại giao dịch. (adsbygoogle = window.adsbygoogle || []).push({});
Kết luận
Như vậy, chúng ta đã nghiên cứu một số khía cạnh liên quan đến việc phát triển các hệ thống phần mềm phân tán hướng thành phần được ứng dụng vào các ứng dụng ngân hàng hiện nay, bao gồm:
Thứ nhất là vấn đề kỹ nghệ phần mềm hướng thành phần, đây là một lĩnh vực cần thiết để trợ giúp các nhà phát triển phần mềm có được phương pháp luận trong việc quản lý quá trình phát triển phần mềm hướng thành phần. Luận văn đã đề cập một cách tổng quan giúp người đọc có được cái nhìn khái quát về lĩnh vực này. Luận văn cũng đã giới thiệu một khía cạnh quan trọng trong lĩnh vực này, đó là vấn đề giám sát và dò vết các thành phần phần mềm, đưa ra các phương pháp dò vết để trợ giúp việc tìm kiếm, xác định lỗi trong quá trình phát triển phần mềm.
Vấn đề thứ hai mà luận văn đề cập tới là mô hình đối tượng phân tán. Đây là một phương thức lập trình mới khác hẳn với mô hình truyền thông điệp trước đây và được ứng dụng rất nhiều trong ứng dụng triển khai tại ngân hàng nhằm nâng cao năng lực tính toán của hệ thống.
Phần thứ ba là các thuật toán phân tán, một lĩnh vực cốt lõi trong các bài toán xử lý trên môi trường phân tán. Luận văn đã trình bày một số thuật toán xử lý tương tranh áp dụng cho các mô hình đồng bộ và không đồng bộ để từ đó ta có thể lựa chọn thuật toán áp dụng vào các bài toán xử lý phân tán trong thực tế.
Cuối cùng, luận văn đã trình bày về bài toán xử lý giao dịch trên hệ thống ATM, một bài toán điển hình về sự phân tán trong hệ thống ngân hàng. Luận văn đã trình bày về chuẩn ISO 8583 được áp dụng cho các máy ATM, cách thức xử lý phân tán hiện tại và các vấn đề lỗi nảy sinh trên cách thức xử lý đó. Từ việc xác định được nguyên nhân gây ra lỗi, áp dụng các thuật toán phân tán cho mô hình không đồng bộ, luận văn đã giới thiệu minh hoạ thuật toán Burn nhằm cải thiện quá trình xử lý giao dịch.
Với các nội dụng trình bày ở trên, chúng ta đã có được khái niệm cơ bản về việc phát triển các ứng dụng phần mềm hướng thành phần trên môi trường phân tán. Việc nghiên cứu các thuật toán xử lý trên môi trường phân tán đã chỉ ra được các vấn đề nảy sinh trong qua trình phát triển hệ thống phân tán. Như chúng ta cũng biết, hiện tại ở Việt Nam chưa có một công ty phần mềm nào có khả năng cung cấp được phần mềm phân tán áp dụng cho ngân hàng có hiệu quả, có thể xử lý online tất cả các giao dịch của ngân hàng với số lượng lớn. Tất cả các ngân hàng (có 7 ngân hàng) trong tiểu dự án Hiện đại hoá ngân hàng đều phải trang bị hệ thống ngân hàng cốt lõi từ các nhà cung cấp nước ngoài. Với hiện trạng ở nước ta như hiện nay, việc nghiên cứu để có thể xây dựng được một hệ thống như vậy thì chúng ta không có khả năng, buộc phải đi mua. Nhưng nếu không có hiểu biết để chọn lựa sản phẩm được mua thì thứ nhất là không đánh giá được chất lượng các sản phẩm phần mềm do đó không mua được sản phẩm chất lượng tương ứng với số tiền bỏ ra. Vấn đề thứ hai là bị phụ thuộc hoàn toàn vào nhà cung cấp, điều này rất quan trọng vì mất đi tính chủ động trong việc phát triển các sản phẩm dịch vụ của ngân hàng. Mỗi khi phát triển một sản phẩm dịch vụ mới,
nếu hệ thống không cung cấp sẵn thì ta lại phải mời nhà cung cấp phần mềm sang xây dựng, chi phí rất tốn kém. Ngay cả quy trình nghiệp vụ của chúng ta cũng phải phụ thuộc, và còn rất nhiều vấn đề khác nữa xung quanh vấn đề này.
Hiện tại, về mặt kỹ thuật công nghệ, nếu xét tất cả các bước trong mô hình phát triển phần mềm thì luận văn chỉ có ý nghĩa trong việc xây dựng bản yêu cầu người sử dụng, trong giai đoạn kiểm thử và triển khai hệ thống. Bản yêu cầu người sử dụng là nội dung chính của hợp đồng giữa ngân hàng với nhà cung cấp phần mềm. Để có được bản yêu cầu người sử dụng chất lượng, bao quát được chiến lược phát triển của ngân hàng, lường trước được các khả năng có thể xảy ra đối với hệ thống thì buộc chúng ta phải có hiểu biết nhất định về hệ thống phân tán. Đối với giai đoạn kiểm thử cũng vậy, khi ta đã xác định được các vấn đề cần giải quyết thì ta sẽ xây dựng được chiến lược kiểm thử hệ thống phù hợp, đảm bảo được chất lượng của hệ thống.
Với các thuật toán đã trình bày ở trên ta đã có bước cải thiện đáng kể về tốc độ xử lý giao dịch cũng như giảm thiểu lưu lượng truyền tin trên mạng. Tuy nhiên thuật toán này vẫn chưa giải quyết được vấn đề lỗi hệ thống xảy ra khi trạng thái tài khoản không được trả về chế độ rỗi (vấn đề thứ ba trong phần 4.3 Xử lý phân tán hiện tại). Do đó việc phải làm tiếp theo là chúng ta phải nghiên cứu về các vấn đề thứ lỗi của hệ thống, nghiên cứa các thuật toán giải quyết vấn đề này để áp dụng, nâng cao chất lượng xử lý của hệ thống. Ngoài ra khi ta nghiên cứu các thuật toán trên hai mô hình đồng bộ và không đồng bộ ta cũng thấy rằng các thuật toán trên mô hình không đồng bộ dễ cài đặt hơn so với mô hình không đồng bộ, vấn đề mô hình hoá các mô hình không đồng bộ trở thành mô hình đồng bộ để có thể áp dụng các thuật toán đơn giản cũng là một xu hướng mà chúng ta cần nghiên cứu trong tương lai.
Như vậy, luận văn đã cung cấp một cái nhìn tổng quan về hệ thống ngân hàng, đưa ra được vấn đề nảy sinh của hệ thống phân tán, các phương pháp giải quyết vấn đề đó. Trong tương lai, ngân hàng sẽ trang bị các trang thiết bị hiện đại cần thiết để đáp ứng các yêu cầu của việc nghiên cứu hệ thống. Với cơ sở phương pháp luận mà chúng ta đã đề cập trên đây, công việc cần phải làm là tiếp tục nghiên cứu các công nghệ liên quan trực tiếp đến hệ thống hiện tại để từ đó đưa ra được các giải pháp tốt nhất cho việc xây dựng các sản phẩm dịch vụ ngân hàng, cung cấp cho người sử dụng sản phẩm chất lượng nhất, nâng cao năng lực cạnh tranh của ngân hàng với các ngân hàng khác.
Tài liệu tham khảo
Tiếng Việt
1. Các tài liệu về hệ thống ngân hàng.
Tiếng Anh
2. C. Szyperski et al, Component Software – Beyond Object-Oriented Programming, Second Edition, Addison-Wesley/ACM Press, 2002
3. D. D' Souza and A. Wills. Objects, Components, and Frameworks with UML, Addison-Wesley, 1998
4. Distributed Algorithms, Nancy A. Lynch và Boaz Patt-Shamir, Janury 1993. 5. Distributed Systems: Principles and Paradigms, Andrew S. Tanenbaum và Maarten van Steen, January 2002.
6. Microsoft Corporation. Distributed Component Object Model Protocol- DCOM/1.0, draft, November 1996.
7. M. L. Liu, Distributed Computing – Principles and Applications, Pearson Addison-Wesley, 2004
8. A Component Architecture for Java July 1996
http://tec.uno.edu/george/thesis/news/JavaBeans.WhitePaper.html
9. Component-Based Software Development – An Overview, (http://cbs.colognet.org/overview.php)
10. Java Remote Method Invocation,
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html.
11. Monitoring Software Component and Component-Base Software, (http://www.engr.sjsu.edu/gaojerry/report/compsac2000.pdf)
12. Software Component Basics – (http://www.webbasedprogramming.com/Presenting-
JavaBeans/html/ch01.htm)
13. Một số trang Web: http://www.Inprise.com, www.sun.com...;
http://fsl.cs.uiuc.edu/papers/chen-wang-mei-yang-02.pdf; (adsbygoogle = window.adsbygoogle || []).push({});
PDF Merger
Merger! To remove this page, please register your program!
Go to Purchase Now>>
Merge multiple PDF files into one
Select page range of PDF to merge
Select specific page(s) to merge
Extract page(s) from different PDF
files and merge into one