2 Kết cấu luận văn
2.2.4Cấu trúc hệ thống
Hệ thống thanh toán di động được triển khai trên công nghệ Java. Cấu trúc
được thực hiện theo lớp và mô hình MVC (Model View Controller)[20], như vậy sẽ tuân theo logic kinh doanh và giúp bảo trì tốt hơn. Mô hình lớp đồng thời cũng cho phép sự độc lập của server ứng dụng, tức là server chạy logic kinh doanh, từ Internet. Điều đó có nghĩa là khả năng truy cập vào server ứng dụng chỉ có thể là từ server web mà trình bày rõ lớp chức năng. Sự xác thực được thực hiện tại khu điều khiển. Theo cách này, người sử dụng không được ủy quyền có thể không bao giờ truy cập được vào server ứng dụng. Servlets hoạt động giống như một bộ điều khiển trong hệ thống, đảm bảo sự điều phối đúng chức năng của giao dịch và giao diện người sử dụng. Bản trình bày logic được triển khai trong trang JSP mà servlets gửi đi những ý kiến lập luận cần thiết. JSPs gửi giao diện người sử dụng – lượng tối thiểu của các yếu tố năng động được gắn vào JSPs để cho một mô hình
Hình 12 – Cấu trúc phần mềm của hệ thống
Lớp logic kinh doanh
PaymentServer đóng vai trò là mô hình từ thiết kế MVC. Nó mở rộng giao diện java.rmi.server.UnicastRemoteObject và chạy như là một server RMI nghe và hỗ trợ các cuộc gọi từ người thanh toán và người bán. Do PaymentServer được triển khai như là một RMI server, một có chế rãnh chung thích ứng sẽ tự động hoạt động. Điều này cho phép nâng cấp quá trình song song của các yêu cầu cùng một lúc. The PaymentServer không nhìn thấy dịch vụ đặt trên RMI.
Phần mềm bán hang (mọi nền chạy) Phần mềm bán hàng (java) Server bán hàng
Java API Server
thanh toán Dịch vụ ủy quyền Dịch vụ Hóa đơn/tài khoản Phần mềm bán hang (mọi nền chạy) Lưu bản ghi thanh toán LDPA người thanh toán Lớp khách hàng Lớp thích nghi HTTP Lớp trình diễn
và điều khiển kinh doanh Lớp logic Lớp dữ liệu Lớp phụ trợ
Máy Java ảo
Di động của khách/ thiết bị đầu cuối WAP
Máy Java ảo Hệ thống quản lý dữ liệu
Ranh giới phạm vi hệ thống
Biểu thị giao diện của thành phần được bổ sung trong phạm vi của hệ thống
Phương tiện Servlet với
SOAP
Phương tiện Servlet
Lớp logic kinh doanh không lưu giữ một tình trạng giao dịch nào. Các yêu cầu liên tục được xử lý như các công việc độc lập. Logic và quy tắc xử lý yêu cầu được mã hóa thành PaymentServer và hỗ trợ các lớp tiện ích.
Lớp thích nghi HTTP
Lớp thích nghi HTTP chuyển yêu cầu đến Hệ thống thanh toán di động thông qua HTTP để gọi HTTP servlets thực hiện vai trò điều hành. Lớp thích nghi HTTP nằm ngoài Hệ thống thanh toán di động. Nó chứa các mô-đun giao thức thoại để chuyển các giao thức và công nghệ không phù hợp trở thành HTTP và phù hợp với Internet.
Khi một kết nối RMI trực tiếp không thể được thực hiện từ hệ thống thương mại nền tảng Java đến Hệ thống thanh toán di động, giao diện khách hàng từ xa có thể được sử dụng để tích hợp hai hệ thống. Nó tạo các cuộc gọi theo phương pháp Java qua HTTP để dễ dàng vượt qua firewall.
Cổng nối WAP chuyển các yêu cầu WAP qua WSP đến HTTP mà lớp điều khiển servlets của Hệ thống thanh toán di động có thể hiểu được. Cổng WAP không có một logic ứng dụng cụ thể nào cả. Nó có thể được coi là một giao thức rõ ràng để chuyển giữa khách hàng sử dụng WAP và Hệ thống thanh toán di động.
Lớp trình bày và điều khiển
Lớp trình bày và điều khiển bao gồm logic giao diện người dùng của Hệ thống thanh toán di động và API của hệ thống thương mại. Về bản chất, nó chuyển những yêu cầu qua HTTP đến các cuộc gọi RMI đến Hệ thống thanh toán.
Như minh họa trong Hình 12, có 2 cách để hệ thống thương mại có thể dùng giao diện tương tác với Hệ thống thanh toán di động. Có hai cách thức thông tin mà người bán có thể dùng để giảm thiểu các yêu cầu của các hệ thống thương
mại dựa trên Java lên việc tích hợp khi mà cả các hệ thống thương mại không dựa trên Java cũng có thể tương tác với hệ thống. Lớp bao gồm các servlets và RPC router chỉ dẫn sơ đồ các cuộc gọi theo phương pháp SOAP sang các cuộc gọi theo phương pháp Java.
PayerServlet triển khai giao diện sử dụng của người thanh toán. PayerServlet đóng vai trò điều khiển mô hình MVC. Nó chuyển các trang JSP để mượn giao diện người sử dụng WML. Các trang JSP đóng vai trò quan sát mô hình MVC.
MerchantServlet làm thích ứng sự truyền tải HTTP cho phù hợp với Server thanh toán. RPC router của SOAP về về cơ bản cũng họat động tương tự - nó chỉ dẫn sơ đồ tin nhắn SOAP để tạo các cuộc gọi và đối tượng Java.
Lớp dữ liệu
Các bản ghi về thanh toán được lưu giữ trong lớp dữ liệu có tên là Bản ghi thanh toán. Nơi lưu trữ các bản ghi về mặt vật lý chính là RDBMS. Dữ liệu được truy cập vào bằng JDBC từ lớp logic kinh doanh. Các yêu cầu được viết bằng ngôn ngữ SQL.
Việc sử dụng một cơ sở dữ liệu liên tục giúp cho các giao dịch được độc lập và nhất quán – lớp logic kinh doanh không cần phải quản lý các giao dịch mà nó chỉ cần quan tâm đến việc phục vụ các yêu cầu độc lập có liên tục không. Với đặc điểm này các vấn đề về khả năng nâng cấp và hoạt động đều truyền tất cả các con đường tới lớp dữ liệu – đây là nhược điểm duy nhất và chính là “nút cổ chai” của cả hệ thống. Tất cả các lớp khác đều có thể nâng cấp một cách linh hoạt. Ví dụ, một giải pháp cân bằng tải mức độ mạng lưới có thể được dùng để phân phối tải giữa Presentation/Controller kép (hoặc số lượng lớn hơn nữa) – và lớp logic kinh doanh dẫn cho tất cả sử dụng chung một cơ sở dữ liệu. Nếu như việc hoạt động
dữ liệu ở cấp độ ứng dụng có thể được đặt ra,ví dụ, tất cả những người bán bắt đầu với tên từ vần A đến M sẽ dùng chung một cơ sở dữ liệu và những người còn lại dùng một cơ sở dữ liệu khác.
Danh mục LDAP nằm ngoài Hệ thống thanh toán di động. Cơ quan đăng ký dịch vụ di động mà phát hành các chứng nhận cho người thanh toán sẽ quản lý danh mục này. Có khả năng rằng các chữ ký tạo ra trong WIM không chứa các chứng nhận để nhận diện người ký mà một URL sẽ tham chiếu nó ở trong một danh bạ [7], [12]. Lựa chọn này đã được xác định trong WAP Forum một phần để giảm lưu lượng mạng và một phần để giúp cho cơ quan đăng ký có một cơ hội kinh doanh, thu lợi nhuận từ những yêu cầu danh bạ. Những yêu cầu này cần cho việc xác thực các chữ ký với đường link duy nhất đến Chứng nhận. Danh bạ được truy nhập từ lớp logic kinh doanh thông qua JNDI qua LDAP.
CHƢƠNG 3: THỰC HIỆN VÀ THỬ NGHIỆM HỆ THỐNG
Chương này mô tả khái quát việc thực hiện hệ thống như đã nói ở chương trước. Quá trình thử nghiệm và tóm tắt kết quả thu được cũng được đề cập đến vì chúng rất hữu ích trong việc phân tích kết quả cuối cùng của luận văn trong việc đánh giá kết quả đạt được được ghi ở phần 1 của phần kết luận.
3.1 Môi trƣờng, nền tảng và sản phẩm
Phần này mô tả các công cụ, nền tảng và sản phẩm được sủ dụng để tiến hành Hệ thống Thanh toán Di động.