Hình 3 .6 Biểu đồ tuần tự hệ thống ca sử dụng thêm Yêu cầu lần 1
Hình 3.13 Biều đồ tuần tự hệ thống ca sử dụng Trả lời Yêu cầu
Ca sử dụng Duyệt trả lời
Tác nhân: Người dùng của TCTTT.
Mục đích: Để xác nhận cho các giao dịch đã được trả lời trước đó.
Mơ tả: Người dùng sau khi đăng nhập hệ thống, chọn chức năng Duyệt Trả lời Yêu cầu để xác nhận các yêu cầu đã được trả lời. Sau khi xác nhận xong thì giao dịch được trả về hiển thị bên phần Xem danh sách trả lời lần 2.
Luồng sự kiện:
Hành động tác nhân Phản ứng hệ thống Dữ liệu liên quan
1. Chọn chức năng Duyệt trả lời
2. Hiển thị danh sách các giao dịch đã được trả lời lần 1 và 2.
Dữ liệu giao dịch tra soát.
2. Chọn từng giao dịch và kiểm tra xem thông tin trả lời đúng hay chưa. Nếu đúng rồi thì xác nhận bằng cách nhấn vào nút Đồng ý.
4. Cập nhật thông tin giao dịch đã được duyệt.
Dữ liệu tra soát.
Biểu đồ tuần tự hệ thống
Hình 3.15: Biểu đồ tuần tự hệ thống ca sử dụng Duyệt trả lời
Ca sử dụng lập báo cáo
Mục đích: Tạo các báo cáo danh sách các giao dịch được trả lời/ chưa được trả lời đối với từng tổ chức
Mô tả: Người dùng lựa chọn chức năng lập báo cáo, lựa chọn loại báo cáo và chọn xem loại báo cáo đó.
Hành động tác nhân Phản ứng hệ thống Dữ liệu liên quan
1. Chọn chức năng Xem báo cáo
2. Hiển thị danh sách các loại báo cáo
Dữ liệu danh sách các báo cáo
2. Chọn loại báo cáo, nhập thời gian cần xem và nhấn nút Xem báo cáo
4. Hệ thống hiển thị báo cáo danh sách các giao dịch theo từng loại báo cáo
Dữ liệu tra soát
Biểu đồ tuần tự hệ thống
Biểu đồ lớp thực thi ca sử dụng
Hình 1.17: Biểu đồ lớp thực thi ca sử dụng Lập báo cáo
3.3 Phát triển mã nguồn ứng dụng
Ứng dụng viết gồm có hai phần: Phần mã nguồn giao diện Web (chạy trên dịch vụ Windows Azure) viết bằng Visual Studio và phần Cơ sở dữ liệu sử dụng SQL Azure.
Mã nguồn giao diện Web: Được phát triển dựa trên Visual Studio 2008, ngôn ngữ C#. Microsoft cung cấp gói tích hợp nền tảng Windows Azure cài đặt cùng với Visual Studio 2008 tạo môi trường phát triển giả lập giống như môi trường dịch vụ Windows Azure. Mã nguồn ứng dụng được chia làm 4 phân hệ chính: Phân hệ Quản lý Người dùng, Phân hệ Thêm Yêu cầu, phân hệ Trả lời Yêu cầu và Phân hệ Báo cáo
Phân hệ Quản lý Người dùng: Cho phép tạo người dùng thuộc các tổ chức được xác định trước. Các tổ chức ở đây cùng tham gia vào hệ thống chuyển mạch tài chính Banknetvn.
Phân hệ Trả lời Yêu cầu: Cho phép người dùn thuộc các tổ chức có thể trả lời các yêu cầu của các tổ chức khác.
Phân hệ Báo cáo: Cho phép một tổ chức có thể thống kê những giao dịch đã được trả lời, chưa được trả lời đối với yêu cầu của tổ chức mình hoặc các giao dịch mình đã trả lời cho tổ chức khác.
Cơ sở dữ liệu sử dụng cơ sở dữ liệu SQL Azure. Microsoft hỗ trợ việc phát triển cơ sở dữ liệu dựa trên SQL Server 2008, sau đó cập nhật trên dịch vụ SQL Azure. Chỉ có một chút sự thay đổi khi chuyển từ SQL Server 2008 lên dịch vụ SQL Azure, đó là việc loại bỏ một số thuộc tính mà dịch vụ SQL Azure không hỗ trợ. Sự loại bỏ này là cần thiết để phù hợp với chính sách lưu trữ trên dịch vụ này. Việc chuyển từ SQL Server 2008 lên SQL Azure đơn giản là chạy một kịch bản được xuất ra từ SQL Server 2008.
3.4 Cài đặt lên dịch vụ Azure của Microsoft
Chương trình ứng dụng được cài đặt trên máy chủ của Microsoft trên nền tảng dịch vụ Windows Azure. Việc cài đặt đơn giản và nhanh chóng nhờ sự hỗ trợ của các gói dịch vụ của Microsoft.
Tạo bản cài đặt bằng cách sử dụng tool cung cấp sẵn bởi Microsoft: Nhấn vào Publish để tạo bản cài như hình bên dưới.
Hình 3.18: Tạo bản cài đặt trên dịch vụ Windows Azure
Sau khi thực hiện tạo bản cài sẽ sinh ra 2 file: File chương trình đã được dịch và file cấu hình. Tiến hành Upload lên dịch vụ Windows Azure của Microsoft như hình bên dưới
Cơ sở dữ liệu được lưu trữ trên máy chủ của Microsoft và được quản trị bằng hệ quản trị SQL Server. Để Upload lên dịch vụ SQL Azure, tiến hành tạo Script của cơ sở dữ liệu trên máy cục bộ. Sau đó đăng nhập vào cơ sở dữ liệu SQL Azure và chạy Script này như hình dưới
3.5 Kết quả Demo
Giao diện trang chủ ứng dụng
Giao diện thêm yêu cầu lần 1
Hình 3.21: Chức năng thêm yêu cầu lần 1
Mô tả cách dùng: Người dùng điền các thơng tin giao dịch, chọn Mã u cầu tra sốt lần 1 (Mã YC1), chọn TCTTT (ACQ) sau đó nhấn nút Thêm YC để tạo yêu cầu tra soát lần 1.
Giao diện duyệt yêu cầu lần 1
Hình 3.22: Chức năng duyệt u cầu
Mơ tả cách dùng: Khi người dùng (KSV) vào chức năng này, giao diện sẽ hiển thị các yêu cầu đã được TSV tạo. Người dùng chọn vào link ―Duyệt‖ để chuyển sang phần duyệt yêu cầu này.
Giao diện duyệt trả lời
Hình 3.23: Duyệt các yêu cầu được trả lời
Mô tả cách dùng: Người dùng (KSV) sau khi đăng nhập chọn chức năng xem Danh sách trả lời. Chức năng này sẽ liệt kê các giao dịch đã được TSV trả lời. Người dùng sẽ chọn link ―Duyệt‖ để chuyển tới phần duyệt xác nhận giao dịch đã được trả lời. Sau khi duyệt xong giao dịch sẽ được gửi lại cho bên tạo yêu cầu kèm theo trả lời.
3.6 Nhận xét ưu nhược điểm
Chương này đã trình bày q trình phân tích, thiết kế cài đặt ứng dụng tra soát liên Ngân hàng. Quá trình này đã được trình bày một cách đầy đủ với mục đích đáp ứng được tiêu chí xây dựng ứng dụng thử nghiệm dựa trên nền tảng dịch vụ Azure. Ứng dụng có những ưu và nhược điểm sau:
Ứng dụng đáp ứng được yêu cầu đã đề ra: Cho phép các tổ chức thành viên thực hiện tra soát đối với những giao dịch bị lệch giữa các tổ chức thành viên trên giao diện web, thuận lợi cho việc cài đặt truy sử dụng
Ứng dụng xây dựng dựa trên nền tảng dịch vụ Windows Azure. Chương trình được đặt trên máy chủ của Microsoft, và Cơ sở dữ liệu được đặt ở trung tâm dữ liệu của Microsoft. Việc quản lý duy trì hệ thống hoạt động được do Microsoft đảm nhận. Người quản trị không cần lo lắng về việc sao lưu phục hồi dữ liệu. Bên cạnh đó khơng cần phải đầu tư một hệ thống lớn để duy trì hoạt động của ứng dụng khi nhu phát sinh cao: Ứng dụng sẽ chỉ trả tiền cho tài nguyên mà nó sử dụng.
Ứng dụng có khả năng dễ dàng được mở rộng về tốc độ do việc khai báo sử dụng số lượng thể hiện trong tệp cấu hình. Sauk hi khai báo xong, hệ thống Azure sẽ tự động cập nhật cấu hình và khỏi động lại cấu hình cho chương trình.
Cơ chế kiểm sốt điều khiển truy cập sử dụng cơ chế định danh cho phép sử dụng lại những đơn vị xác thực sẵn có, thơng qua một giao thức chuẩn và bảo mật để thực hiện việc truy cập sử dụng ứng dụng. Cơ chế này cũng cho phép ứng dụng không cần phải xây dựng cơ chế xác thực của riêng mình. Bên cạnh đó khi cần mở rộng, ứng dụng dễ dàng sử dụng lại cơ chế này để tạo điều kiện cho người dùng đăng nhập vào chương trình khác, đảm bảo khả năng đăng nhập một lần (single sign-on).
Nhược điểm của ứng dụng:
Việc duy trì hệ thống phụ thuộc hoàn toàn vào Microsoft, do đó tạo sự phụ thuộc của người quản trị vào nhà cung cấp dịch vụ (Microsoft)
Vấn đề bảo mật dữ liệu cũng bị phụ thuộc vào nhà cung cấp dịch vụ. Bên cạnh đó việc đưa dữ liệu nhạy cảm như trong ứng dụng này lên mạng cũng cần phải có những tính tốn phù hợp lại.
Tốc độ truy cập bị ảnh hưởng đôi chút so với việc chạy trên ứng dụng máy cục bộ.
Khả năng ứng dụng thực tế
Ứng dụng được xây dựng phục vụ cho cơng việc tra sốt của các thành viên tham gia vào tổ chức Banknetvn. Về mặt nghiệp vụ, ứng dụng đã đáp ứng được tương đối đầy đủ, tuy nhiên do tính chất quan trọng của dữ liệu nên ứng dụng vẫn còn
một số hạn chế về bảo mật cần phải tiếp tục nghiên cứu và cải tiến. Trong thời gian tới tơi sẽ tiếp tục hồn thiện để ứng dụng có khả năng áp dụng vào thực tiễn phục vụ cơng tác tra sốt giữa các thành viên của Banknetvn.
KẾT LUẬN
Trong suốt q trình làm luận văn tốt nghiệp, tơi đã cố gắng nghiên cứu để hiểu tổng quan về mơ hình Điện tốn đám mây, so sánh giữa các mơ hình để nắm bắt được những ưu nhược điểm của từng framework hỗ trợ cho việc xây dựng ứng dụng. Từ đó tơi đã đưa ra lựa chọn sẽ nghiên cứu sâu về nền tảng dịch vụ Azure của Microsoft. Đây là một nền tảng dịch vụ hỗ trợ đầy đủ, mạnh và thân thiện với người dùng. Tôi cũng đã xây dựng thử nghiệm ứng dụng hỗ trợ tra soát dành cho Ngân hàng để kiểm chứng các dịch vụ Windows Azure và SQL Azure. Ứng dụng được lưu trữ trên Windows Azure và sử dụng cơ sở dữ liệu lưu trên SQL Azure chạy ổn định.
Tuy nhiên trong q trình thực hiện vẫn cịn những vướng mắc nhất định như vấn đề bảo mật trên SQL Azure phải được làm rõ hơn, hay cơ chế điều khiển truy cập sử dụng dịch vụ ACS là một dịch vụ hay mà ở trong đề tài này mới dừng ở việc nghiên cứu lý thuyết. Hướng nghiên cứu trong tương lai là phải tìm hiểu sâu thêm về hai vấn đề này, đồng thời phát triển ứng dụng để đảm bảo phục vụ thực tiễn.
TÀI LIỆU THAM KHẢO
Tiếng Anh
1. Aaron Skonnard,Keith Brown (2009), ―An Introduction to Windows Azure platform AppFabric for Developers‖, Microsoft Corporation.
2. Ahmar Abbas (2004), ―Grid Computing: A Practical Guide to Technology and Applications‖, CHARLES RIVER MEDIA, INC.
3. Anthony T. Velte, Toby J. Velte, Robert Elsenpeter (2010), ―Cloud computing A Practical Approach‖, McGraw-Hill Companies.
4. Brad Calder, Tony Wang, Shane Mainali, and Jason Wu (2009), ―Windows Azure Blog‖, Microsoft Corporation.
5. DavidChappell (2008), ―Cloud Platforms An Enterprise- Oriented OverView‖, Microsoft Corporation.
6. DavidChappell (2009), ―Introducing Windows Azure‖, Microsoft Corporation. 7. Eucalyptus System, Inc (August 2009), ―Eucalyptus Open-Source Cloud Computing
Infrastructure-An Overview‖, Eucalyptus Systems, Inc.
8. George Reese (2009), Cloud Application Architectures-Building Applications and Infrastructure in the Cloud, O'REILLY.
9. Greg Boss, Padma Malladi, Dennis Quan, Linda Legregni, Harold Hall (2007), Cloud Computing, IBM Corporation.
10. IBM Company (2009), Cloud Security Guidance. 11. IBM Company (2009), Security and Cloud Computing. 12. IBM Company(2009), The Benefits of Cloud Computing.
13. Katarina Stanoevska-Slabeva, Thomas Wozniak, Santi Ristol(2010), ―Grid and Cloud Computing-A Business Perspective on Technology and Applications‖, Springer.
14. Marios D.Dikaiakos (Ed.) (2004), Grid Computing, Springer
15. Michael Miller (2008), ―Cloud Computing - Web-Based Applicaiton that change the way you work and collaborate online‖, QUE Pusblishing
16. Sun Microsystem (2005), ―Java Web Service Tutorial ―.
PHỤ LỤC
Bảng CSDL lưu giao dịch
STT Tên trường Mô tả
1 MSGTYPE Message type (Định dạng thông điệpj)
2 PAN
3 PCODE Processing code (Mã xử lý)
4 AMOUNT Số tiền
5 ORIGTRACE Số trace
6 LOCAL_DATE Ngày xử lý ở local
7 LOCAL_TIME Giờ, phút, giây xử lý ở local
8 ISSUER Ngân hàng phát hành
9 ACQUIRER Ngân hàng chấp nhận
10 RESPCODE Mã trả lời
11 TERMID ID của thiết bị
12 MERCHANT_TYPE Kiểu loại giao dịch (6011/6012) 13 REQUESTDATE1 Ngày đưa ra yêu cầu tra soát lần 1 14 REQUESTCODE1 Mã tra soát lần 1
16 REQUESTTSV1 Tên tra soát viên yêu cầu lần 1 17 REQUESTKSV1 Tên kiểm soát viên lần1
18 RESPONSEDATE1 Ngày trả lời lần 1 19 RESPONSECODE1 Mã trả lời lần 1 20 AMOUNTRETURN1 Số tiền hoàn trả lần 1 21 RESPONSENOTE1 Ghi chú trả lời lần 1
22 RESPONSEPATH1 Đường dẫn file attach lần 1 nếu có 23 RESPONSETSV1 Tên tra soát viên trả lời lần 1 24 RESPONSEKSV1 Tên KSV trả lời lần 1
25 REQUESTDATE2 Ngày yêu cầu lần 2 26 REQUESTCODE2 Mã TS lần 2
27 REQUESTNOTE2 Ghi chú yêu cầu tra soát lần 2 28 REQUESTTSV2 TSV yêu cầu lần 2
29 REQUESTKSV2 KSV yêu cầu lần 2 30 RESPONSEDATE2 Ngày TL lần 2 31 RESPONSECODE2 Mã TL lần 2
32 AMOUNTRETURN2 Số tiền hoàn trả lần 2 33 RESPONSENOTE2 Ghi chú TL lần 2
34 RESPOSNEPATH2 Đường dẫn file attach lần 2 nếu có 35 RESPONSETSV2 TSV trả lời lần 2
36 RESPOSNEKSV2 KSV trả lời lần 2
37 TYPE 0: giao dịch được TSV đưa vào yêu cầu tra soát lần 1
1: Giao dịch được KSV chấp nhận đưa ra yêu cầu tra soát lần 1
2: Giao dịch được TSV trả lời đưa ra trả lời lần 1 3: Giao dịch được KSV trả lời chấp nhận cho trả lời lần 1
4: Giao dịch được TSV đưa vào yêu cầu tra soát lần 2
5: Giao dịch được KSV chấp nhận đưa ra yêu cầu tra soát lần 2
6: Giao dịch được TSV trả lời đưa ra trả lời lần 2 7: Giao dịch được KSV trả lời chấpnhận cho trả lời lần 2
Mã tra sốt
Chu
trình Ký hiệu Tên Diễn giải Chi tiết về chứng
từ
Tra soát lần 1
101 Yêu cầu hồn trả số tiền tra sốt
102
u cầu hồn trả số tiền tra sốt, khách hàng nghi ngờ bị lợi dụng thẻ
Khách hàng nghi ngờ bị người khác sử dụng thẻ rút mất tiền
Đối với yêu cầu này, nếu khơng đồng ý hồn trả tiền, TCTT cần cung cấp thêm hình ảnh camera (nếu có) 103 TS ngoại lệ 104 Hủy TS Trong thời hạn chờ trả lời, nếu có yêu cầu hủy TS từ khách hàng thì TCPH gửi lệnh hủy TS đi. Trả lời tra soát lần 1
301 Giao dịch sẽ được điều chỉnh hoàn trả
Ngày đảo QT được hiểu chính là ngày trả lời (khi KSV bấm nút trả lời, giao dịch có mã TL là mã này sẽ được đảo ngay lập tức trên chương trình báo cáo)
tiền Biên bản kiểm quĩ (trong trường hợp khơng có biên bản kiểm quỹ thì cung cấp chứng từ chứng minh tiền đã được rút một phần). 303 Giao dịch đã được điều chỉnh hoàn trả từ trước đó 304 Giao dịch thành cơng, tiền đã được máy ATM chi ra và đã được lấy đi
- Nhật ký máy ATM (bắt buộc) - Các giấy tờ khác hoặc hình ảnh camera (nếu có), khơng giới hạn, để chứng minh được tiền đã được máy ATM chi ra và đã được lấy đi
305 Từ chối trả lời. (từ chối cung cấp chứng từ) Tra soát lần 2 201
Yêu cầu cung cấp chứng từ bổ sung cho lần 2
- Chứng từ cung cấp lần 1 chưa chứng minh được khách hàng đã nhận được tiền (do TCTT không cung cấp chứng từ hoặc cung cấp thiếu chứng từ, chứng từ
không rõ ràng...)
202
Giao dịch giả mạo, khách hàng không thực hiện giao dịch
Khách hàng nghi ngờ bị lợi dụng thẻ, tuy nhiên Lần 1 k/h mới chỉ yêu cầu hoàn trả số tiền tra soát.
Thư khiếu nại của chủ thẻ, có chữ ký của chủ thẻ, khẳng định rằng chủ thẻ không thực hiện giao dịch 203 TS ngoại lệ 204 Hủy TS Trả lời tra soát lần 2
401 Giao dịch sẽ được điều chỉnh hồn trả
Ngày đảo QT được hiểu chính là ngày trả lời (khi KSV bấm nút trả lời, giao dịch có mã TL là mã này sẽ được đảo ngay lập tức trên chương trình báo cáo)
402
Giao dịch được điều chỉnh hoàn trả 1 phần tiền
- Bắt buộc có Nhật ký máy ATM và