2 Kết cấu luận văn
3.1.1 Phát triển phần cứng và phần mềm
Việc phát triển được thực hiện trên môi trường trạm làm việc Windows 2000, với Oracle RDBMS (Hệ thống quản lý dữ liệu tương quan) chạy trên nền Sun Solaris. Các công cụ được sử dụng là Borland Jbuilder 4 cho việc phát triển Java và TOAD phiên bản 7 cho việc tạo mô hình cơ sở dữ liệu.
Việc lắp đặt Hệ thống Thanh toán Di động với mục đích thử nghiệm và chạy thử được thực hiện trên một máy tính Pentium 3, 700 MHz với thanh RAM 450MB cài phiên bản Windows 2000 Proffesional với SP2. Việc phát triển và thử nghiệm được thực hiện với cùng một phiên bản Oracle.
Môi trường Java
Môi trường Java, Enterprise Edition phiên bản 1.3 (còn được gọi là SDK 1.3.1) được chọn làm nền tảng, việc sử dụng SDK 1.3 là rất hợp lý vì nó phối hợp tốt với Java HotSpot Server VM và có thể tăng hiệu quả làm việc lên khoảng 30% [13]. Vì mục tiêu của công việc là áp dụng hệ thống theo cách có thể tương thích với nhiều nền máy chủ khác nhau, nên việc ra quyết định không hướng tới mục
lựa chọn này không làm giảm đáng kể độ tin cậy, bởi vì sự chặt chẽ và thống nhất của giao dịch được thực hiện bởi RDBMS tập trung. Do vậy, ngay cả khi không có màn hình TP kích thước thực thì vẫn có thể đạt được Thời gian Trung Bình giữa các lỗi (MTBF) là 3 tháng và Thời gian Sửa chữa Trung Bình là 1giờ đồng hồ với việc áp dụng một một hệ thống không có lỗi đã được kiểm nghiệm.
Apache.org Tomcat được lựa chọn là môi trường cho các servlet. Mặc dù Tomcat là một sản phẩm không có tính thương mại, nhưng nó vẫn là một công cụ đáng tin cậy và đủ mạnh để thực hiện mục tiêu đề ra. Hơn nữa, nó là chuẩn mực trong việc thực thi servlet engine. Tuy nhiên, việc thực thi servlet vào hệ thống không hề ràng buộc hệ thống với Tomcat. Các servlet trong hệ thống tương thích với bất kỳ chuẩn servlet engine nào.
3.1.3 Bộ phận điều khiển RDBMS và JDBC
Hệ thống quản lý cơ sở dữ liệu quan hệ Oracle 8.1.5 (Oracle 8i) được lựa chọn là cơ sở dữ liệu hệ thống. Lựa chọn sản phẩm cơ sở dữ liệu hệ thống là sự cân nhắc giữa một mySQL rẻ tiền với một Oracle tốn kém nhưng hiệu quả. Do bản thân các nguyên lý áp dụng chạy trong một môi trường không đáng tin cậy, nên không thể mang lại khả năng xử lý giao dịch thích hợp mà cơ sở dữ liệu phải cáng đáng. Việc mySQL không đủ khả năng xử lý giao dịch dẫn đến sự lựa chọn Oracle.
Bộ điều khiển Oracle Thin JDBC được sử dụng để kết nối cơ sở dữ liệu. Đây là bộ điều khiển JDBC Type IV, là một thư viện Java 100%. Nó thực hiện việc kết nối giữa các ổ cắm Java với máy chủ Oracle không giống như bộ điểu khiển Type II cồng kềnh. Hoạt động của bộ điều khiển nhỏ gọn này nhìn chung được nhận xét là ngang bằng, hoặc gần như ngang bằng với bộ phận điều khiển OCI Type II. OCI Type II cũng là một bộ điều khiển có thể sử dụng trong ứng dụng này. Hơn nữa, với việc sử dụng bộ phận điều khiển nhỏ gọn này, việc triển
khai phần mềm cũng trở nên dễ dàng hơn vì việc cài đặt khách hàng Oracle với máy chủ trở nên không cần thiết.
3.1.4 Mô đun mật mã
Như đã nêu trên, có hai phương pháp thực hiện cổng WAP đối chọn (12).
Cổng WAP có thể xử lý nội dung tín hiệu WAP như một dữ liệu rõ ràng hoặc có
thể chuyển đổi nó và trình bày dưới dạng tín hiệu dữ liệu PKCS #7. Hệ thống thanh toán di động hỗ trợ cả hai định dạng này. Do nội dung tín hiệu WAP là một định dạng sở hữu riêng, nó không trực tiếp được hỗ trợ trong bảo mật Java API. Và cũng không có bất kỳ một thư viện có tính thương mại nào có thể hỗ trợ nó. Do đó, phải tận dụng bảo mật Java API để thực thi nó.
Java Cryptography Extensions cho phép sử dụng các thư viện bảo mật từ các nhà cung cấp khác nhau một cách dễ dàng thông qua chuẩn API. Các nhà cung cấp thư viện phải thực hiện thư viện theo Java Cryptography Architechture [14]. Các nhà cung cấp công nghệ bảo mật lớn như RSA và Baltimore Technologies đều cung cấp các loại thư viện như vậy. Bất kỳ loại thư viện nào như vậy đều có thể sử dụng với hệ thống này. Tuy nhiên, các thư viện có tính thương mại lớn rất đắt, và vì trong trường hợp này chỉ có duy nhất một nhu cầu cụ thể là thực thi PKCS#7, nên một sự lựa chọn tốn kém hơn là không khả thi. IAIK (Học viện Ứng dụng Xử lý Thông tin và Liên lạc) của Đại học Công nghệ Graz đã áp dụng thư viện JCE với sự hỗ trợ của PKCSs. Vì gói thư viện này hỗ trợ toàn bộ PKCS#7 với mức giá đăng ký hợp lý, nó được chọn làm thư viện mật mã trong việc xử lý dữ liệu PKCS#7.
Để giữ cho giao diện bên trong và bên ngoài ở mức chuẩn nhất có thể, việc sử dụng duy nhất java.security.cert trong việc thực hiện chứng nhận và CRLs được lựa chọn. Điều này khiến việc tích hợp hệ thống với các hệ thống bên ngoài được dễ dàng hơn; ví dụ như không cần phải cài đặt gói IAIK hoặc các gói thư viện
khác trong Java SDK. Qua đó, trong nội bộ hệ thống chỉ duy nhất lớp xử lý chữ ký cần phải nhận biết được các thư viện không phải Java SDK.
3.1.5 Cổng WAP và Thiết bị đầu cuối
Không cần sử dụng bất kỳ một cổng WAP nào trong suốt quá trình thực hiện hệ thống. Nokia Mobile Internet Toolkit 3.0 có một cổng mô phỏng gắn liền được sử dụng thay cho việc tiến hành thử nghiệm mô đun. Nokia Activ Server 2.0.1 được lựa chọn để thử nghiệm chức năng, vì nó được sự hỗ trợ cần thiết trong việc mã hóa WML Script signText.
Nokia Mobile Internet Toolkit 3.0 được sử dụng trong quá trình thực hiện hệ thống như công cụ cạnh tranh WAP đầu cuối. Việc lựa chọn sản phẩm không có gì khó khăn vì trong thời điểm này, nó là công cụ thương mại với các đặc điểm và chức năng cần thiết sẵn có duy nhất. Các thử nghiệm chức năng được thực hiện sử dụng thiết bị đầu cuối Ericsson T68 GSM với thẻ mật mã WIM của hãng Gemplus. Do không có giá trị phát sinh nào đạt được thông qua sử dụng GPRS như là công cụ chuyên chở WAP nên các thử nghiệm được thực hiện thông qua việc chạy qua mạch chuyển đổi dữ liệu GSM. Tại thời điểm hành các thử nghiệm chức năng, Ericsson là nhà cung cấp thiết bị đầu cuối có hỗ trợ WIM và WMLScript signText duy nhất. Do đó, các thiết bị đầu cuối khác ngoài T68 không được thử nghiệm để xác nhận tính tương thích với hệ thống.
3.2 Các vấn đề trong quá trình thực hiện
Phần này mô tả việc ra quyết định trong quá trình thực hiện, những quyết định đã mang lại tính năng cuối cùng của hệ thống. Như thường lệ, trong một số trường hợp, phạm vi của chức năng hệ thống được giới hạn ở các đặc trưng tuyệt đối liên quan – ví dụ, sẽ không khả thi nếu thực hiện tất cả các tùy chọn theo một số các tiêu chuẩn nào đó.
3.2.1 Nội dung tín hiệu WAP
Cốt lõi của Hệ thống Thanh toán Di động về mặt chức năng và cải tiến kỹ thuật chính là sự hỗ trợ chữ ký số WAP. Như đã nói trên, sự lựa chọn nhằm thực thi nguyên lý thiết kế xử lý cho nội dung tín hiệu WAP được quyết định trực tiếp dựa trên nền Java 2 SE.
Chỉ những sự lựa chọn có liên quan nhất tới nội dung tín hiệu WAP [12] mới được thực hiện. Chữ ký dạng đường cong elip X.9.62 và các chứng nhận X.9.68 không được hỗ trợ. Đặc trưng này được hỗ trợ bởi việc thực hiện các bước nêu trong Bảng 8.
Bảng 8 – Yêu cầu xác minh ủy quyền thanh toán và phản hồi
3.2.2 Giao diện thư mục
Chữ ký nội dung tín hiệu WAP có một tùy chọn có khả năng kết hợp chỉ với những tham chiếu với chứng nhận của người ký. Tham chiếu trong chữ ký là một URL dẫn tới một thư mục LDAP. Để có thể tìm lại được chữ ký thì phải thực hiện giao diện LDAP.
JNDI (Java Naming and Directory Interface) được sử dụng để yêu cầu thư mục LDAP cung cấp chứng nhận của người sử dụng. Việc phân tích biểu trưng
URL của lệnh LDAP phải được thực hiện bằng tay, vì nó không hoàn toàn được hỗ trợ bởi JNDI.
3.2.3 Tạo chung liên kết cơ sở dữ liệu
Vì PayerServer là một ứng dụng máy chủ xuyên suốt nên tối đa hóa việc sử dụng liên kết cơ sở dữ liệu trở thành vấn đề trung tâm – việc thiết lập các liên kết cơ sở dữ liệu theo yêu cầu, ví dụ tại mọi yêu cầu, là rất tốn nguồn lực và có thể làm hoạt động của hệ thống giảm sút đáng kể. Việc tạo chung liên kết cơ sở dữ liệu một cách thông minh là rất cần thiết để đảm bảo các đặc tính ACID trong quá trình xử lý giao dịch. Nguồn dữ liệu chung Java của Oracle và việc thực hiện cache kết nối Oracle được sử dụng phục vụ mục đích này. Cache kết nối được đặt ở chế độ động và giới hạn trên của số lần kết nối hiệu lực xảy ra đồng thời tạo ra một thông số mà người sử dụng hệ thống có thể cài đặt được. Theo cách này việc tạo chung và cache kết nối trở nên rất rõ ràng đối với phần còn lại của code ứng dụng.
3.2.4 Thực hiện Mẫu Thiết kế MVC
Mẫu thiết kế MVC cho phép tóm lược và phân chia nguyên lý ứng dụng và nguyên lý trình bày giao diện sử dụng. Mô hình thiết kế được thực hiện như máy chủ RMI. Máy chủ trưng bày giao diện với các servlet điều khiển. Các servlet lần lượt gửi đi các trang JSP để đáp lại giao giện sử dụng trong khi điều khiển tương tác sử dụng và dòng chuyển động. Các tham chiếu JSP được thông số hóa cho các servlet điều khiển và do đó có thể định cấu hình một cách linh hoạt.
Đương nhiên phương pháp thực hiện MVC trong J2EE chỉ là một trong rất nhiều phương pháp. Tuy nhiên, phương pháp này được chấp nhận rộng rãi và cho phép duy trì ứng dụng một cách linh hoạt và tùy biến mà không có nhiều ảnh hưởng tới toàn bộ hệ thống.
3.3 Thử nghiệm
Thử nghiệm hệ thống được tiến hành cả về mặt tính năng và mặt hoạt động. Việc thử nghiệm chức năng tất nhiên sẽ tập trung vào xác minh độ chính xác của hệ thống. Việc thử nghiệm được xây dựng theo các thông số. Mục đích của thử nghiệm hoạt động là để xác minh thông lượng thích hợp của hệ thống và nhận biết các điểm có khả năng vướng mắc và kém hiệu quả của hệ thống.
3.3.1 Thử nghiệm chức năng
Mục đích của thử nghiệm chức năng hệ thống là để chắc chắn rằng hệ thống hoạt động chính xác. Do đó, các phép thử nghiệm hệ thống được tiến hành tập trung vào thử nghiệm xuất phát từ quan điểm của người sử dụng. Các tiêu chí cho
việc thử nghiệm chức năng được nêu cụ thể tại phần 2.1 Các tiêu chí Thiết kếlà cơ
sở cho việc thử nghiệm chức năng.
Môi trường thử nghiệm chức năng được mô tả tại Hình 13. Để thực hiện mục tiêu thử nghiệm chức năng của hệ thống, một web dịch vụ thương mại được thiết lập. Việc thiết lập này cũng phục vụ mục đích thử nghiệm việc tích hợp hệ thống với một hệ thống mua bán qua web thực sự. Dịch vụ thương mại được xây dựng bằng cách lập trình một cặp Java servlet có khả năng giúp người sử dụng lựa chọn sản phẩn vào giỏ mua sắm và yêu cầu thanh toán. Khi người sử dụng thực hiện lệnh này, hệ thống thương mại sẽ đệ trình thanh toán tới Hệ thống Thanh toán Di động, người sử dụng ủy quyền thanh toán thông qua thiết bị đầu cuối WAP của mình. Sau khi ủy quyền, người sử dụng cho hệ thống thương mại biết về việc thanh toán đã được ủy quyền và hệ thống thương mại cam kết thực hiện thanh toán.
Hình 13 – Môi trường thử nghiệm chức năng.
Các tình huống thử nghiệm và kết quả
Phần dưới đây mô tả các tình huống thử nghiệm chức năng. Mô tả chỉ có tính bao quát – các phép thử nghiệm được giải thích cặn kẽ trong phần kết quả. Trong ba tình huống thử nghiệm dưới đây, mỗi tình huống dẫn tới một số tình huống thực tế được coi là các giá trị đầu vào khác nhau và các kết cấu đều được kiểm nghiệm. Các phép thử nghiệm và kết quả thử nghiệm được tóm tắt trong các bảng phía dưới mỗi tình huống.
Tình huống #1: Tạo một yêu cầu thanh toán
Hệ thống thương mại có thể tạo ra yêu cầu thành toán với tất cả các dữ liệu liên quan đến thanh toán, như mô tả tại phần 4.3.4.
Phép thử nghiệm Kết quả
Xuất trình một yêu cầu thanh toán theo Yêu cầu thanh toán được chấp nhận
Trạm duyệt Web và thiết bị đầu cuối WAP
The Oracle 8i Server
Hệ thống thanh toán di động Server bán hàng Môi trường
đúng format
Xuất trình một yêu cầu thanh toán với một nhận dạng đã tồn tại trong kho hồ sơ thanh toán
Yêu cầu thanh toán không được chấp nhận. Hệ thống báo có hai nhận dạng thanh toán đúp.
Xuất trình một yêu cầu thanh toán với dữ liệu thiếu
Nếu bất kỳ dữ liệu then chốt nào hoặc sự kết hợp nào do vậy mà bị thiếu, yêu cầu sẽ không được chấp nhận
Xuất trình một thanh toán mà tổng của các hạng mục không khớp với tổng thanh toán
Yêu cầu thanh toán không được chấp nhận. Hệ thống báo một yêu cầu thanh toán không đủ chất lượng.
Tình huống #2: Ủy quyền thanh toán
Người chi trả có thể kết nối với Hệ thống thanh toán di động để thực hiện ủy quyền thanh toán. Hệ thống thanh toán di động chấp nhận một chữ ký đúng định dạng và công nhận tính hợp lệ của nó.
Phép thử nghiệm Kết quả
Xuất trình một chữ ký thích hợp Ủy quyền được chấp nhận
Xuất trình một dữ liệu ngẫu nhiên được coi là chữ ký
Ủy quyền không được chấp nhận. Hệ thống báo chữ ký không hợp lệ, chứng nhận không hợp lệ và nội dung không hợp lệ.
Xuất trình một chữ ký dựa trên nội dung không phải hợp đồng thanh toán gốc
Ủy quyền không được chấp nhận. Hệ thống báo nội dung không hợp lệ. Xuất trình một chữ ký thích hợp.
(chứng nhận của người chi trả bị xóa khỏi phạm vi tin cậy)
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ. Xuất trình một chữ ký có kết nối tới thư Ủy quyền được chấp nhận
mục LDAP, tại đó chứng nhận của người chi trả có thể được khôi phục Xuất trình một chứ ký với đường dẫn tới thư mục LDAP không hoạt động
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ Xuất trình một chữ ký hợp lệ. (chứng
nhận của người chi trả được thêm vào CRL)
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ Xuất trình một chữ ký cho một chỉ danh
thanh toán không tồn tại trong kho hồ sơ thanh toán
Ủy quyền không được chấp nhận. Hệ thống báo không tìm thấy hồ sơ thanh toán
Xuất trình một chữ ký hợp lệ sau khi hệ thống đang ở trạng thái tạm nghỉ trong 24h
Ủy quyền không được chấp nhận.
Tình huống #3 : Cam kết thực hiện thanh toán
Chỉ khi người chi trả ủy quyền giao dịch, hệ thống thương mại mới có thể cam kết thực hiện giao dịch. Cam kết thực hiện giao dịch sẽ dẫn đến việc đăng ký giao dịch thanh toán vào biên lai hoặc hệ thống quản lý tài khoản.
Phép thử nghiệm Kết quả
Cam kết một thanh toán đã được ủy quyền hợp lệ
Cam kết thanh toán thành công Cam kết một thanh toán không được ủy
quyền
Thanh toán không được cam kết. Hệ thống thanh toán di động thông báo trạng thái thanh toán không hợp lệ.