- Các thông số còn lại (không có dấu ngoặc) là dành cho mọi giao thức trong họ iKP.
5.1.PHÂN TÍCH HỆ THỐNG 1 Phân tắch tổng thể
CHƯƠNG 5 HỆ THỐNG THANH TOÁN đIỆN TỬ iKP
5.1.PHÂN TÍCH HỆ THỐNG 1 Phân tắch tổng thể
5.1.1. Phân tắch tổng thể
Mục ựắch của phần này là ựưa ra ựược một mô hình tổng thể về kiến trúc của hệ thống.
Quá trình hoạt ựộng của một giao dịch thương mại ựiện tử trên Internet sẽ ựược chia thành 2 quy trình như sau:
- Sử dụng hạ tầng truyền thông truyền thống: Buyer sử dụng trình duyệt Web truy cập vào Website TMđT của Seller, thực hiện duyệt hàng và ựưa vào shopping card của mình. Sau khi hoàn thành việc duyệt hàng, buyer kiểm tra lại shopping card mình ựã tạo rồi kắch hoạt chức năng thanh toán ựể thanh toán cho những món ựồ mình ựã chấp nhận mua. Quá trình này hoàn toàn sử dụng hạ tầng truyền thông truyền thống, cụ thể là phắa buyer thì sử dụng một trình duyệt Web (Internet Explorer, Firefox,Ầ) ựể tương tác với phắa seller là Website TMđT ựang chạy trên một môi trường Web server nào ựó (IIS, Apache,Ầ).
- Sử dụng hạ tầng toán ựiện tử: Website TMđT nhận ựược lệnh yêu cầu thực hiện giao dịch thanh toán, nó sẽ thực hiện triệu gọi hệ thống thanh toán. Lúc này quá trình giao dịch ựược hoàn toàn chuyển cho hệ thống thanh toán.
Như vậy, kiến trúc tổng thể của hệ thống bao gồm hai lớp thành phần chắnh: hạ tầng truyền thông truyền thống và hạ tầng thanh toán ựiện tử. Hạ tầng thanh toán ựiện tử lại ựược chia thành: Hệ thống thanh toán ựiện tử và hệ thống mạng thanh toán liên ngân hàng (Clearing Network).
Hình 5.1: Kiến trúc tổng thể hệ thống thanh toán ựiện tử
Hệ thống thanh toán ựiện tử sẽ bao gồm có 3 module chắnh:
Electronic Wallet của Buyer (e-Wallet): với vai trò như là một chiếc vắ ựiện tử, nó chứa các thông tin tài khoản thẻ tắn dụng của Buyer, ựảm nhiệm chức năng mã hóa và truyền các thông tin này cùng một số thông tin giao dịch khác an toàn ựến iKP Payemt Gate của Acquirer.
iKP Payment Gate của Seller: có vai trò là một giao diện thanh toán cho các Website TMđT triệu gọi. Module này sau khi nhận yêu cầu thực hiện giao dịch thanh toán từ Website TMđT sẽ kết nối với Electronic Wallet và iKP Payment Gate của Acquirer ựể phối hợp thực hiện giao dịch.
iKP Payment Gate của Acquirer: có vai trò như một giao diện giữa hệ thống thanh toán iKP với mạng thanh toán liên ngân hàng (Clearing Network). Chức năng của nó là nhận các thông tin giao dịch thành toán của Buyer và Seller từ Seller gửi tới và cung cấp những thông tin này ựến mạng thanh toán liên ngân hàng ựể yêu cầu chứng thực và thực hiện chuyển khoản.
Ngoài ra, cũng cần phải kể ựến hệ thống thanh toán liên ngân hàng (Clearing Network), nó chắnh là hệ thống thực sự thực hiện yêu cầu thanh toán (chuyển tiền từ tài khoản của người mua sang tài khoản của người bán (hai tài khoản này có thể nằm ở những Ngân hàng khác nhau)). Tuy nhiên Clearing Network không nằm trong giao thức iKP và ựược coi là ựã tồn tại.
Vì hệ thống thanh toán ựiện tử là một hệ thống phân tán, mỗi module chạy trên các máy tắnh khác nhau, vì vậy cần tắnh ựến vấn ựề truyền thông giữa những module này. Giải pháp thứ nhất cho vấn ựề này là xây dựng cả 3 module của hệ thống theo kiểu thuần TCP, tức là cả 3 module ựều là các ứng dụng TCP, chúng sử dụng trực tiếp TCP/IP ựể truyền thông với nhau. Giải pháp thứ hai là xây dựng theo kiểu thuần Web Service. Giải pháp thứ ba là kết hợp giữa Windows Application và Web Service.
Trong quá trình phân tắch và tìm kiếm giải pháp kỹ thuật ựể xây dựng hệ thống cho ựồ án của mình, tác giả ựồ án ựã tắnh ựến cả ba cách tiếp cận trên. Dưới ựây là những phân tắch cụ thể ưu nhược ựiểm của từng cách tiếp cận.
Giải pháp 1: Thuần TCP.
Do toàn bộ các module của hệ thống ựều là các ứng dụng TCP/IP nên xét về mặt kỹ thuật, ựể xây dựng một hệ thống phân tán như hệ thống thanh toán ựiện tử sẽ rất phức tạp. Sự phức tạp thể hiện ở một số ựiểm như nó ựòi hỏi ta phải làm việc với các tầng thấp của hệ thống mạng, phải tự xây dựng một Transaction Manager Layer ựể quản lý mọi vấn ựề diễn ra trong quá trình giao dịch, một module con Communication quản lý truyền thông giữa các module Buyer, Seller, Acquirer của hệ thống thông qua môi trường Internet, ta khó có thể xem mạng Internet như một môi trường trong suốt. Xét về vần ựề triển khai, do các module sử dụng trực tiếp TCP/IP ựể truyền thông với nhau nên những giao dịch giữa chúng có thể bị chặn bởi các firewall. để vượt qua ựược những khó khăn trên ựòi hỏi người xây dựng hệ thống phải có một trình ựộ chuyên môn rất cao. Dưới ựây là kiến trúc hệ thống thanh toán ựã ựược IBM triển khai theo kiểu thuần TCP ựể hiện thực hóa giao thức iKP của họ.
Hình 5.2: Kiến trúc triển khai hệ thống theo kiểu thuần TCP (ZiP prototype của IBM)
Vắ những lý do trên, người viết ựồ án ựã không lựa chọn giải pháp này ựể xây dựng hệ thống.
Giải pháp 2: Thuần Web Service.
đặc trưng của cách tiếp cận này là cả ba module của Buyer, Seller, Acquirer ựều là Web Service. Ưu ựiểm ở ựây là nó ẩn ựi ựược sự phức tạp của hạ tầng mạng bên dưới,
ta không cần phải bận tâm về vấn ựề truyền thông giữa các module phân tán. để truyền dữ liệu giữa các Web Service thì Web Service truyền chỉ ựơn giản gọi các hàm dịch vụ nhận dữ liệu ựược cung cấp bởi Web Service nhận. Sự phức tạp trong làm việc với các tầng thấp của hạ tầng mạng ựã ựược giao thức SOAP của Web Service ựảm nhận. Do vậy việc xây dựng ứng dụng phân tán không khác nhiều so với cách thức xây dựng các ứng dụng thông thường. Cũng cần nói thêm rằng, dữ liệu truyền nhận giữa các Web Service ựều sẽ ựược chuyển thành text nên hầu như sẽ không bị chặn bởi các firewall.
Tuy nhiên, do e-Wallet của Buyer cũng ựược xây dựng là một Web Service nên khi muốn chạy thì máy tắnh của Buyer cần phải ựược cài ựặt như một Web Server (chẳng hạn IIS). Ngoài ra, vì là Web Service nên ựể các module khác có thể kết nối ựến thông qua Internet Buyer cần phải có một ựịa chỉ IP public cho Web Service của mình. Do vậy, tuy giải pháp xây dựng hệ thống theo kiểu thuần Web Service cung cấp sự ựơn giản nhưng nó không mang tắnh thực tế cao. Một nhược ựiểm dễ thấy nữa ựó là nếu xây dựng theo kiểu này thì Buyer sẽ không có tắnh khả chuyển, tắnh di ựộng bởi khi họ di chuyển từ máy tắnh này sang máy tắnh khác và muốn thực hiện giao dịch thanh toán thì lại phải cài ựặt lại hệ thống mới từ ựầu. Vì những lý do này, người viết ựồ án cũng ựã không chọn giải pháp này ựể xây dựng hệ thống.
Giải pháp 3: Kết hợp giữa Windows Application và Web Service.
Kiến trúc hệ thống theo cách tiếp cận này sẽ như sau: các module của Seller và
Acquirer ựược xây dựng là các Web Service. Module của Buyer là một ứng dụng Windows thông thường, nó tương tác với Seller, Acquirer thông qua việc gọi các hàm dịch vụ ựược cung cấp bởi hai Web Service trên. Cách tiếp cận này thỏa mãn ựược các yêu cầu về tắnh ựơn giản khi xây dựng hệ thống và cung cấp tắnh di ựộng cho người dùng (Buyer). Có ựược tắnh ựơn giản bởi việc truyền thông giữa các module của hệ thống ựược ựảm nhiệm giao thức truyền thông của Web Service (SOAP), nó ẩn ựi ựược sự phức tạp của hạ tầng mạng phắa dưới, do vậy ta có thể xem Internet như một môi trường trong suốt. Tắnh di ựộng cho Buyer có ựược bởi e-Wallet là một Windows Application, nó có thể ựược ựặt trên Website của Seller, do vậy bất kể Buyer di chuyển ựến máy tình nào thì chỉ cần tài e-Wallet về và chạy mà không phải cài ựặt thêm bất cứ thành phần bổ sung nào.
Dù triển khai hệ thống theo cách tiếp cận nào ựi nữa thì một vấn ựề cần phải giải quyết là làm thế nào ựể ựồng bộ phiên giao dịch, tức làm thế nào ựể hệ thống nhận biết ựược yêu cầu, dữ liệu nhận ựược hay truyền ựi là thuộc về giao dịch nào. Giải pháp cho vấn ựề này là sẽ sử dụng một số ngẫu nhiên SessionID ựược sinh bởi Seller ựể ựịnh danh cho mỗi giao dịch. Lý do, Seller chứ không phải Buyer hay Acquirer thực hiện chức năng sinh SessionID là bởi khách hàng sau khi ựã duyệt hàng trên website TMđT của Seller và chấp nhận mua họ sẽ kắch hoạt chức năng thanh toán của website này ựể thanh toán cho những mặt hàng mình ựã chọn, do vậy tất cả các phiên giao dịch thanh toán ựiện tử ựều ựược khởi phát từ phắa Seller.
Sau khi Seller ựã tạo ra SessionID ựể ựịnh danh cho phiên giao dịch, SessionID này cần phải ựược truyền ựến e-Wallet của Buyer. Nếu hệ thống triển khai theo giải pháp thứ nhất thì ựiều này là ựơn giản bởi tất cả các module ựều là ứng dụng TCP nên iKP Payment Gate của Seller chỉ cần khởi tạo kết nối TCP ựến Electronic Wallet của Buyer
rồi truyền SessionID. Với giải pháp thứ 2 lại càng ựơn giản, tất cả ựều là Web Service nên không cần quan tâm ựến việc phải khởi tạo kết nối giữa 2 module mà ựơn giản iKP Payment Gate của Seller chỉ cần gọi hàm nhận SessionID ựược cài ựặt trên e-Wallet của Buyer. Với giải pháp thứ 3, khó khăn sẽ xảy ra: e-Wallet của Buyer không phải là một ứng dụng TCP hay một Web Service nên iKP Payment Gate của Seller không thể chủ ựộng khởi tạo kết nối TCP ựến Wallet hay gọi gọi hàm dịch vụ nhận SessionID của Wallet ựể truyền SessionID nó. Giải pháp mà tác giả ựồ án ựưa ra là:
o Bên phắa Seller, Website TMđT sẽ nhận SessionID sinh ra bởi iKP Payment Gate của Seller rồi ghi vào một Cookie trên trình duyệt của Buyer.
o Bên phắa Buyer, e-Wallet sẽ ựược cài ựặt thêm một module con CookieManager có chức năng quản lý Cookie của trình duyệt. CookieManager ựược chạy thường trú nên khi có Cookie của Website TMđT ựược ghi vào nó sẽ thực hiện ựọc và kiểm tra thông tin trong Cookie này, nếu ựúng là thông tin SessionID của giao dịch thanh toán CookieManager khởi ựộng e-Wallet ựể tham gia vào giao dịch thanh toán.
Khi triển khai theo giải pháp thứ 3 này, kiến trúc hệ thống sẽ có sự thay ựổi chút ắt như ựược thể hiện trong hình sau: (adsbygoogle = window.adsbygoogle || []).push({});
Hình: Kiến trúc hệ thống thanh toán theo giải pháp kết hợp giữa Windows Application và Web Service
Với những ưu ựiểm ựược cung cấp bởi giải pháp thứ 3 này, tác giả ựồ án ựã chọn nó ựể xây dựng hệ thống.
Các thành phần của hệ thống có thể ựược thể hiện rõ hơn trong biểu ựồ phân cấp sau ựây.
Trong ựó: tương ứng các thành phần trong sơ ựồ phân cấp và sơ ựồ kiến trúc như sau:
iKP_eWallet tương ứng với module Electronic Wallet của Buyer: có chức năng là làm giao diện thanh toán phắa Buyer cho hệ thống. iKP_eWallet ựược cài ựặt và chạy trên máy tắnh của Buyer.
iKP_WS_Seller tương ứng với module iKP Payment Gate của Seller: có chức năng là làm giao diện thanh toán phắa Seller cho hệ thống. iKP_WS_Seller là một Web Service ựược cài ựặt và chạy trên máy chủ Web của Seller.
iKP_WS_Acquirer tương ứng với module iKP Payment Gate của Acquirer: có chức năng là làm giao diện thanh toán phắa Acquirer cho hệ thống. iKP_WS_Acquirer cũng là một Web Service ựược cài ựặt và chạy trên máy chủ Web của Acquirer.
Chi tiết về các chức năng của từng thành phần sẽ ựược thể hiện trong phần phân tắch hệ thống về xử lý.
5.1.2. Phân tắch hệ thống về xử lý
để phân tắch một hệ thống về mặt xử lý ta có thể sử dụng hai dạng biểu ựồ: biểu ựồ phân cấp chức năng (BPC), và biểu ựồ luồng dữ liệu (BLD).
Biểu ựồ phân cấp chức năng (BPC) diễn tả sự phân rã dần dần các chức năng của hệ thống từ chức năng tổng quát nhất ựến từng chức năng con chi tiết hơn, tất cả ựược thể hiện trên một biểu ựồ dạng cây.
Hệ thống thanh toán ựiện tử
iKP_eWallet iKP_WS_Seller iKP_WS_Acquirer
Biểu ựồ luồng dữ liệu (BLD) diễn tả (ở mức logic) tập các chức năng của hệ thống trong các mối qua hệ trước sau trong tiến trình xử lý, trong việc chuyển giao thông tin, dữ liệu cho nhau.
Các thành phần cấu thành biểu ựồ BLD:
Tên thành phần Ký hiệu biểu diễn
Chức năng xử lý
Luồng dữ liệu ( 1 chiểu, 2 chiều) Kho dữ liệu
Tác nhân ngoài
Tác nhân trong
Hình 5.5: Các thành phần cấu thành biểu ựồ luồng dữ liệu (BLD)
Một số ký hiệu khác:
Luồng dữ liệu trao ựổi giữa các tác nhân ngoài với hệ thống
Luồng dữ liệu nội tại trao ựổi giữa các thành phần của hệ thống
đ ồ á n t ố t n g h iệ p ự H ệ t h ố n g t h a n h t o á n ự iệ n t ử ứ n g d ụ n g c h o t h a n h t o á n q u a I n te rn e t d ự a t rê n h ọ g ia o t h T ra n g 5 8 5 .1 .2 .1 . B iể u ự ồ p h â n c ấ p c h ứ c n ă n g ( B P C ) H ìn h 5 .6 : B iể u ự ồ p h ân c ấp c h ứ c n ăn g củ a h ệ th ố n g
5.1.2.2. BLD mức khung cảnh
5.1.2.3. BLD mức ựỉnh
Thanh toán ựiện tử thông qua hệ
thống thanh toán iKP
Buyer Website TMđT (adsbygoogle = window.adsbygoogle || []).push({});
Clearing Network