2 Kết cấu luận văn
2.2.3 Mô hình hệ thống
Phần này sẽ bàn về mô hình thiết kế của hệ thống. Hệ thống sẽ được mô tả dưới góc độ cấu trúc – yếu tố quan trọng để tạo ra hệ thống. Điểm được nhấn mạnh trong đó là mô tả nền tảng logic thương mại. Các chi tiết về triển khai sẽ không nằm trong phạm vi phân tích.
a) Cấu trúc hệ thống
Trong Hình 8, cốt lõi của hệ thống được minh họa dưới dạng UML. Đương nhiên sẽ có một số các lớp khác mà hệ thống sử dụng và đỏi hỏi. Các lớp này mang tính chi tiết và sẽ không được đề cập ở đây.
Hình 8 - Các lớp trung tâm và giao diện của Hệ thống thanh toán di động Cốt lõi của Hệ thống thanh toán di động chính là server thanh toán. Nó phối
các hệ thống ngoài với nhau. Bản ghi thanh toán được ghi lại từ giao dịch thanh toán, nó giữ thông tin và nó luôn đi cùng với các nhân tố thanh toán và các bước của giao dịch thanh toán.
b) Sơ đồ thứ tự
Sơ đồ thứ tự của một giao dịch thanh toán được minh họa bởi mô hình UML tại Hình 9. Người thanh toán có 2 vai trò – trong vai trò PCD, người thanh toán mua hàng và khởi đầu việc thanh toán bằng cách thông báo với người bán rằng anh ta muốn trả tiền. Trong vai trò PTD, người dùng thực hiện việc thanh toán thật. Người mua trong sơ đồ đại diện cho hệ thống thương mại – các bên khác được mô tả bằng sơ đồ lớp (Hình 8). Tất cả những cuộc gọi trong sơ đồ đều đồng bộ và tùy thuộc vào hoàn cảnh, sẽ mang lại doanh thu.
Hình 9 – Sơ đồ thứ tự
Giao dịch thanh toán được quản lý như một bản ghi thanh toán trong Hệ
Người thanh toán (vai trò PCD)
Người thanh toán (vai trò PCD)
Người bán Server thanh
toán Hệ thống hóa đơn Hệ thống ủy quyền Kho thanh toán Thực hiện
thanh toán Gửi đề nghị thanh toán
Lưu bản ghi thanh toán
Nhận hóa đơn để ký
Nhận bản ghi thanh toán
Nộp hóa đơn đã ký
Ký
Xác minh chữ ký và chủ thể
Đặt chế độ ghi thanh toán Xác minh thanh toán
Đặt chế độ bản ghi thanh toán
Đặt chế độ bản ghi thanh toán Nhận chế độ bản ghi thanh toán Lưu lại giao
dịch Cam kết thanh toán
Truy vấn chế độ thanh toán Thanh toán
được thực hiện
thống. Các tình trạng và sự thay đổi tình trạng cho phép trong bản ghi thanh toán được minh họa trong Hình 10. Server thanh toán điều khiển sự thay đổi tình trạng.
Hình 10: Vòng đời bản ghi thanh toán
c) Đồng bộ hóa
Một giao dich thanh toán hoàn chỉnh liên quan đến rất nhiều bên. Việc đồng bộ hóa những hoạt động của các bên chính là một thử thách lớn đối với hệ thống. Mục tiêu là bất cứ điều gì xảy tra trong thứ tự đúng và nhanh nhất có thể và với ít can thiệp của người thanh toán – sẽ không có nhiều thời gian chết tiềm ẩn giữa các hành động. Do thiết kế của hệ thống là dựa trên một mô hình phân phối mở nên không thể đòi hỏi sự đồng bộ trong giao tiếp hai chiều giữa tất cả các thành phần, nghĩa là giao tiếp không thể khởi tạo từ cả hai phía. Rõ ràng, cần phải có một số thoả hiệp để duy trì sự mở và phân phối. Dưới đây, tất cả các kết nối giao tiếp tồn tại giữa các bên tham gia giao dịch thanh toán sẽ được đề cập và sự lựa chọn về mô hình đồng bộ hóa sẽ được làm rõ.
Tạo và gửi
Hủy bỏ buôn bán
Nhận tín hiệu hợp đồng
Cam kết thanh toán
Lưu trữ Hủy bỏ buôn bán Hủy bỏ buôn bán Chờ Ủy quyền Cam kết Lưu trữ Mới Gửi tín hiệu hợp đồng Không thiết lập
Ngƣời bán - ngƣời thanh toán.
Vấn đề đồng bộ hóa giữa người bán và người thanh toán đưa đến tình huống mà người bán cần được chỉ định rằng việc thanh toán đã được thực hiện. Trường hợp tối ưu là, người bán có thể tự động nhận được thông tin về giao dịch thanh toán hoàn thành từ Hệ thống thanh toán di động. Tuy nhiên, điều đó không dễ dàng đạt được – điều đó có nghĩa là rất nhiều yêu cầu kỹ thuật dành cho hệ thống thương mại không thể thực hiện được. Phương pháp không đồng bộ đã được lựa chọn và gây ra một số hậu quả sau:
1. Người thanh toán gửi chữ ký cho Hệ thống thanh toán di động.
2. Hệ thống thanh toán di động xác minh và lưu giữ chữ ký
3. Người thanh toán thông báo cho hệ thống thanh toán rằng việc thanh toán
đã được thực hiện
4. Hệ thống thương mại yêu cầu thẩm định từ Hệ thống thanh toán di động
Ngƣời thanh toán – Hệ thống thanh toán di động
Việc đồng bộ hoá là một vấn đề khi hệ thống thương mại chuyển quyền kiểm soát cho Hệ thống thanh toán di động. Ở điểm này, người sử dụng nên dùng một kênh và thiết bị khác để thực hiện hoạt động uỷ quyền qua WAP. Một cách tối ưu, người dùng sẽ tự động được “đưa” hoá đơn vào thiết bị di động WAP của mình, điều này có thể thực hiện được nếu có 2 điều kiện:
1. Một số thuê bao của người sử dụng phải được Hệ thống thương mại biết
đến
2. Người sử dụng có thiết bị di động WAP có chức năng WAP PUSH
Nếu các điều kiện đều đạt được, hệ thống thương mại có thể tạo một SI (Báo hiệu dịch vụ) hoặc SL (Tải dịch vụ) đẩy tin nhắn đến người sử dụng, nơi mà một
đường nối tới Hệ thống thanh toán di động với xác nhận tham chiếu thanh toán sẽ được chuyển giống như một tham số.
Trong trường hợp không đạt được các điều kiện, hệ thống thương mại có thể chỉ cho người thanh toán biết xác nhận tham chiếu thanh toán ở ngay trên giao diện. Hệ thống thanh toán di động sẽ không thông báo được cho người sử dụng. Trong trường hợp này, hệ thống sẽ không có tính thân thiện với người sử dụng, nhưng đồng thời sẽ giảm được chi phí bởi không dùng WAP PUSH. Người sử dụng cũng sẽ là nặc danh đối với hệ thống thương mại.
Ngƣời bán – Hệ thống thanh toán di động
Trong phần trước đã bàn về vấn đề đồng bộ hóa giữa hệ thống thương mại và Hệ thống thanh toán di động. Vấn đề gặp phải khi đồng bộ hóa toàn bộ giao dịch, bao gồm cả việc Hệ thống thanh toán di động thông báo cho người bán khi thanh toán hoàn thành có thể được giải quyết bằng hai cách:
1. Kết nối từ hệ thống thương mại đến Hệ thống thanh toán di động có thể để
mở sau khi hệ thống thương mại đã chuyển hóa đơn thanh toán. Do đó hệ thống thương mại có thể tiếp tục “online” để đợi tín hiệu thanh toán đã hoàn thành.
2. Hệ thống thương mại có thể thực hiện cơ chế gọi lại, ví dụ một server
HTTP sẽ nhận được tín hiệu về giao dịch thanh toán hoàn thành.
Cả hai cách trên đều có khả năng tiêu tốn nhiều dung lượng trên các trang. Trong một số trường hợp cách thứ 2 còn không thực hiện được nếu như hạ tầng thương mại không có những cải tiến lớn. Trong trường hợp nào thì như vậy cũng sẽ tạo ra các đe dọa tiềm năng về tính bảo mật bởi có thêm nhiều “lỗ hổng” được mở ra trong hệ thống thương mại.
Do không được biết từ trước rằng người trả tiền sẽ mất bao nhiêu thời gian để thanh toán, có khả năng rằng kết nối sẽ bị hết giờ. Cả hai cách thay thế trên đều có thể làm cho hệ thống thương mại đợi thanh toán được hoàn tất trước khi người thanh toán được phục vụ ở trang mới. Dĩ nhiên vấn đề về hết thời gian cũng nằm ở đây.
Trong dự án này, sự đồng bộ hóa được giữ nguyên ở khả năng tối đa có thể. Như miêu tả ở trên, trong hầu hết các giao diện, một phương thức giao tiếp không đồng bộ đã được lựa chọn. Ở một góc độ nào đó thì như vậy sẽ giúp cho hệ thống dễ dàng nâng cấp – không cần lưu giữ tình trạng trong khi chạy hệ thống.
d) Thực thể dữ liệu
Tất cả mọi thực thể dữ liệu được sử dụng trong giao tiếp giữa các thực thể đều được mô tả ở đây, trong ký hiệu ASN.1. Tuy nhiên, điều đó không có nghĩa rằng ví dụ như BER tiêu chuẩn mã hóa của thực thể ASN.1 có thể được sử dụng giữa các thực thể - cách mã hóa sẽ được lựa chọn tùy vào từng trường hợp. Ký hiệu ASN.1 để mô tả thực thể dữ liệu được sử dụng chỉ vì đây là một cách chung nhất.
Dữ liệu ký
Chữ ký số ủy quyền thanh toán được chuyển từ thiết bị di động như là một thực thể dữ liệu ký. Thực thể này tuân theo các tiêu chuẩn trong thư viện WMLScript Crypto (sau đây gọi là Dữ liệu đã ký WAP. Đây là một dạng được đơn giản hóa và không dây của thực thể Dữ liệu ký PKCS #7 mà vẫn thường được dùng rộng rãi. Tuy nhiên, nay đã có một sơ đồ trực tiếp từ Dữ liệu ký WAP đến Dữ liệu ký PKCS #7.
nối WAP sớm khiến cho việc chuyển đổi không được thực hiện đúng chức năng. Đó là lý do tại sao nội dung tín hiệu WMLScript cũng cần được xử lý ở cấp độ ứng dụng. Để linh hoạt, Hệ thống thanh toán di động sẽ có khả năng xử lý cả hai
dạng chữ ký.
Hình 11 – Nội dung tín hiệu có thể được chuyển thành PKCS #7 tại Cổng WAP Nhất thiết, cả nội dung tín hiệu WAP và PKCS #7 SignedData đều phải chứa một bản mã hóa của tài liệu gốc, thông tin về phân loại và thuật toán mã hóa, thông tin về người ký (chứng nhận của anh ta và tài liệu gốc không bắt buộc). Trong trường hợp này tổng hợp của tài liệu gốc trong chữ ký là không bắt buộc nhưng có lợi.
Nếu có cả nội dung gốc, chữ ký là một bằng chứng đầy đủ và rõ ràng của việc ủy quyền thanh toán. Định dạng mã hóa của nội dung ký PKCS #7 là ASN.1 với BER. Nội dung tín hiệu WMLScript được mã hóa với một mã phù hợp quy định trong [4]. Mối quan hệ giữa nội dung tín hiệu và PKCS #7 SignedData được minh họa trong Bảng 2 và Bảng 3.
Thiết bị đầu cuối di động Thiết bị đầu cuối di động Ứng dụng Ứng dụng
Nội dung tín hiệu WAP
Nội dung tín hiệu WAP Nội dung tín hiệu WAP
Dữ liệu ký PKCS#7
Trường hợp 2 Trường hợp 1
Bảng 2 – Nội dung tín hiệu trong thư viện WMLScriptCrypto (với các phần liên quan) [12]
Bảng 3 – Dữ liệu ký (SignedData) trong PKCS#7 (với các phần liên quan) [13]
Yêu cầu thanh toán
Người bán chuyển thông tin về giao dịch thanh toán mà họ định thực hiện trong một thực thể Yêu cầu thanh toán. Yêu cầu thanh toán sẽ bao gồm các thông tin cốt lõi và chi tiết như giá, thông tin giao dịch. Người thanh toán sẽ không được
Bảng 4 – Yêu cầu thanh toán
Yêu cầu thanh toán và Báo cáo tình trạng thanh toán
Người bán đề nghị Hệ thống thanh toán di động báo cáo về tình trạng thanh toán bằng một Yêu cầu Tình trạng thanh toán. Đáp lại họ sẽ nhận được một Báo cáo tình trạng thanh toán
Bảng 5 – Yêu cầu và báo cáo tình trạng thanh toán
Yêu cầu thẩm định ủy quyền và Báo cáo thẩm định ủy quyền
Khi Hệ thống thanh toán di động đã nhận được chữ ký ủy quyền từ người thanh toán và thẩm định là đúng, để thanh toán, hệ thống sẽ yêu cầu thẩm định từ Hệ thống ủy quyền bằng một Yêu cầu thẩm định ủy quyền. Đáp lại sẽ là một Báo
cáo thẩm định ủy quyền.
Yêu cầu cam kết thanh toán
Người bán yêu cầu giao dịch thanh toán được cam kết bằng một Yêu cầu cam kết thanh toán. Đáp lại sẽ là một Báo cáo cam kết thanh toán.
Bảng 7 – Yêu cầu cam kết thanh toán