Professional Documents
Culture Documents
Sample - J2ME
Sample - J2ME
Mục lục
- Thanh toán và tra cứu thông tin thanh toán các dịch vụ viễn thông
(ADSL, HomePhone, Mobile Post-Paid, Mobile Pre-Paid, Mua
hàng) thông qua điện thoại di động.
- Nạp tiền vào tài khoản, Chuyển tiền từ tài khoản ngân hàng này
sang tài khoản ngân hàng khác, từ số thuê bao điện thoại này sang
số thuê bao điện thoại khác.
3. Mục tiêu đồ án
Xây dựng demo dịch vụ M-wallet với mục tiêu cuối cùng là nhằm tạo thuận
tiện cho người sử dụng khi thanh toán một số dịch vụ, giảm tải cho hệ thống tiền tệ,
góp phần phát triển một nền tài chính không phải tiền mặt.
4. Phạm vi đồ án
Lĩnh vực lập trình ứng dụng không dây là một lĩnh vực khó tiếp cận với
những ràng buộc chặt chẽ, các nhà sản xuất và nhà phát triển đã cố gắng đưa ra các
tiêu chuẩn và công nghệ để có thể hỗ trợ tốt nhất cho lĩnh vực này. Ứng dụng không
dây, ngoài bản thân ứng dụng, còn phải được hỗ trợ rất nhiều từ phía server và nhà
cung cấp dịch vụ. Ứng dụng m-wallet trên thiết bị di động áp dụng các công nghệ
mới và tối ưu hóa cho thiết bị di động như J2ME, servlet. Đồng thời, giải pháp bảo
mật chính là trọng tâm của hệ thống thanh toán điện tử di động. Trong thời đại công
nghệ thông tin phát triển rất nhanh đến chóng mặt thì cùng với đó là nạn lừa đảo,
giả mạo, hack … cũng phát triển và gia tăng là vấn nạn của xã hội và nó đe dọa đến
việc phát triển một hệ thống thanh toán điện tử. Hệ thống M-wallet áp dụng các giải
pháp bảo mật như mã hóa đối xứng, bất đối xứng, chữ kí số, hybrid system … để
đảm bảo các giao dịch là tuyệt mật và an toàn.
Trong thời gian thực tập tốt nghiệp và thời gian làm đồ án, em đã cố gắng
tìm hiểu về thương mại di động cụ thể là thanh toán di động và các mô hình, kiến
trúc cũng như các công cụ để có thể xây dựng một dịch vụ phục vụ cho thiết bị di
động mà cụ thể trong đồ án này là dịch vụ m-wallet và em xin được trình bày những
nội dung sau trong đồ án:
Các khái niệm cơ bản về hệ thống thương mại di động.
Lĩnh vực ứng dụng không dây với công nghệ Java.
Bảo mật trong trao đổi thông tin.
Các chuẩn được áp dụng trong thương mại điện tử.
Xây dựng dịch vụ M-wallet.
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 11
Đồ án tốt nghiệp Dịch vụ Mobile-wallet
Chương 2. CƠ SỞ LÝ THUYẾT
1. Tổng quan về mobile commerce
1.1 Định nghĩa Di động (Mobile) và Không dây (Wireless)
Định nghĩa di động và không dây khác nhau tùy người và tùy tổ chức. Trong
nhiều trường hợp, thuật ngữ di động và không dây có thể được dùng thay thế cho
nhau, mặc dù chúng là hai khái niệm khác nhau. Hãy bắt đầu với thuật ngữ di động.
Di động là khả năng di chuyển. Một thiết bị di động là bất kỳ thứ gì có thể được
dùng trong khi di chuyển, từ laptop đến điện thoại di động. Miễn là vị trí không cố
định, thì nó sẽ được xem là di động.
Không dây đề cập đến việc giao tiếp mà truyền đạt thông tin từ nơi này đến
nơi khác mà không sử dụng bất kì các dây dẫn nào. Khoảng cách ở đây có thể ngắn
(vài mét như trong điều khiển tivi) hoặc dài (hàng ngàn kilomet trong giao tiếp sóng
radio). Nó cho phép nhân viên liên lạc với dữ liệu doanh nghiệp mà không cần phải
kết nối vật lý đến mạng. Các thiết bị không dây bao gồm các thiết bị sử dụng một
mạng không dây để gửi hay nhận dữ liệu. Mạng không dây, chính nó lại có thể được
truy xuất từ các nhân viên di động, cũng như ở vị trí cố định. Hình 1 mô tả mối liên
hệ giữa di động và không dây. Như ta thấy, trong hầu hết trường hợp, không dây là
một tập con của di động; nhưng trong nhiều trường hợp, một ứng dụng có thể là di
động mà không cần phải không dây.
Sự định vị (Localization)
Khả năng biết được vị trí vật lý của người dùng tại một thời điểm cụ thể cũng
làm tăng giá trị của thương mại di động. Với thông tin về định vị, ta có thể cung cấp
các ứng dụng dựa trên vị trí. Ví dụ, khi biết được vị trí của người dùng, dịch vụ di
động sẽ nhanh chóng thông báo cho họ biết khi nào bạn bè hay đồng nghiệp của họ
sẽ ở gần. Nó cũng sẽ giúp người dùng định vị một nhà hàng hay một máy rút tiền tự
động gần nhất.
dữ liệu lên đến 115 kbit/giây với GPRS. EDGE, là một phiên bản nhanh hơn của
GSM, được thiết kế để cho phép truyền dữ liệu multimedia và các ứng dụng băng
rộng khác. Nó sẽ sử dụng kỹ thuật điều biến (modulation) mới để cho phép tốc độ
dữ liệu lên đến 384 kbit/giây trên hạ tầng sẵn có của GSM.
UMTS
Universal Mobile Technology System (UMTS), còn được gọi là công nghệ
thế hệ thứ 3 (3G), nhắm vào truyền thông văn bản, thoại, video, và multimedia dựa
trên gói, có băng thông cao để hỗ trợ các ứng dụng cần nhiều dữ liệu. Một khi
UMTS được triển khai đầy đủ, máy tính và người dùng điện thoại có thể kết nối
Internet liên tục và truy xuất dịch vụ toàn cầu. Tích hợp chức năng của các thiết bị
đa dạng khác nhau, điện thoại di động thế hệ 3G có thể được dùng như một điện
thoại, một máy tính, một TV, một tờ giấy, một trung tâm hội thảo video, một tạp
chí, một sổ ghi nhớ, hay thậm chí là một thẻ tín dụng.
Các công nghệ thế hệ thứ tư
Mặc dù các công nghệ 3G chỉ mới xuất hiện ở nước ta, nhưng trên thế giới,
người ta cũng đã bắt đầu nghiên cứu các công nghệ thế hệ thứ tư (4G). Các nghiên
cứu này nhằm giải quyết hoàn thiện các giao diện vô tuyến đa dạng và thậm chí là
hạ tầng truy xuất vô tuyến hoàn toàn mới. Các phương thức điều biến tốt hơn và
công nghệ ăng-ten thông minh là hai lĩnh vực nghiên cứu chính cho phép hệ thống
vô tuyến thế hệ thứ tư tốt hơn mạng vô tuyến thế hệ thứ ba.
Công nghệ
4G
Bluetooth
Bluetooth là một công nghệ vô tuyến năng lượng thấp dùng cho truyền thông
và trao đổi dữ liệu. Sử dụng một chip đơn với mạch truyền vô tuyến gắn sẵn,
Bluetooth là một chuẩn vô tuyến sóng ngắn rẻ tiền hỗ trợ cho mạng cục bộ (LAN).
Nó được phát triển để thay thế cáp và kết nối hồng ngoại trong vòng bán kính 10m.
Bluetooth có thể được dùng để kết nối các thiết bị điện tử, ví dụ như máy vi tính,
máy in, thiết bị di động và PDA, với mạng dữ liệu vô tuyến.
Như mô tả trong hình 3, công nghệ vô tuyến thế hệ thứ nhất là điện thoại tế
bào tương tự (cellcular phone). Công nghệ vô tuyến thế hệ thứ hai, bao gồm điện
thoại tế bào số, băng tần thấp hiện tại được sử dụng rộng rãi. Công nghệ vô tuyến
thế hệ thứ ba cung cấp băng thông cao để hỗ trợ các ứng dụng cần nhiều dữ liệu.
WAP
Wireless Application Protocol (WAP) là một chuẩn mở toàn cầu cho giải
pháp di động, thiết kế riêng biệt cho phân phát thông tin Web đến thiết bị di động.
Là một giao thức ứng dụng end-to-end, nó cung cấp giải pháp cho việc phát triển
các ứng dụng di động, chẳng hạn như kết nối các thiết bị di động vào Internet và
làm cho các thiết bị di động trở thành các thiết bị truyền thông có khả năng truyền
thông với các thiết bị khác trên mạng vô tuyến. Nó cũng cho phép thiết kế các dịch
vụ di động tương tác và thời gian thực.
Response Response
Mạng hữu tuyến
Mạng vô tuyến
Mobile Portal
J2ME
J2ME (Java 2 Platform Micro Edition) là nền tảng Java, phiên bản thu nhỏ
của Sun Microsystems. J2ME được xây dựng nhằm mang đến khả năng phát triển
ứng dụng đa dạng, phong phú cho các thiết bị di động. Với ưu thế của ngôn ngữ
Java, dựa trên hạ tầng mạng có sẵn của WAP, J2ME có thể dùng để xây dựng các
ứng dụng từ đơn giản đến phức tạp nếu kết hợp với các công nghệ phía server.
và trình duyệt sẵn có làm cho người dùng tạo các tài liệu HTML kết hợp các đối
tượng multimedia một cách dễ dàng.
XML
eXtensible Markup Language (XML) là một siêu ngôn ngữ (meta-language),
được thiết kế để truyền thông ngữ nghĩa của dữ liệu thông qua một cơ chế mô tả.
Nó dùng thẻ dữ liệu và đặt nội dung vào trong ngữ cảnh (context), do đó cho phép
nhà cung cấp mã hóa ngữ nghĩa vào tài liệu của họ. Đối với các hệ thống thông tin
hỗ trợ XML, dữ liệu có thể được trao đổi thậm chí giữa các tổ chức với các hệ thống
hoạt động và mô hình dữ liệu khác nhau, miễn là các tổ chức này đồng ý về ngữ
nghĩa của dữ liệu mà họ trao đổi.
WML
Wireless Markup Language (WML), xuất phát từ XML, được phát triển đặc
biệt cho WAP. Nó cho phép thông tin được trình bày như các thẻ bài (card) thích
hợp để hiển thị trên các thiết bị di động. Như vậy WML chủ yếu cho WAP cũng
giống như HTML cho Internet.
SMS
Short Message Service (SMS) cho phép gửi và nhận các thông điệp văn bản
đến và đi từ điện thoại di động. Có thể trao đổi lên đến 160 ký tự chữ cái và số trong
mỗi thông điệp SMS. Nó cũng cung cấp các dịch vụ thông tin di động, chẳng hạn
như tin tức, thị trường chứng khoán, thể thao và thời tiết. Gần đây SMS chat và tải
nhạc chuông cũng đã được cung cấp.
MIDP
Mobile Information Device Profile (MIDP) là một bộ phận cụ thể của J2ME.
Ngày càng được các nhà cung cấp hàng đầu hỗ trợ xây dựng, MIDP tập hợp các thư
viện và API dùng để phát triển ứng dụng J2ME độc lập với phần cứng.
nữa đó là trò chơi di động. Các tiến bộ trong lĩnh vực sản xuất thiết bị di động làm
cho chúng trở thành các thiết bị tuyệt vời để chơi trò chơi.
2. Lĩnh vực ứng dụng không dây với công nghệ Java
2.1 Khái quát
Các ứng dụng Java cho các thiết bị không dây nhỏ (“MIDlet”) sẽ đóng một
vai trò – có thể là nhỏ, cũng có thể là lớn – trong các hệ thống phần mềm phân tán.
Khi đó, nó sẽ sinh ra một dạng phần mềm client mới. Chúng rất thích hợp với khái
niệm thin-client, nhưng do chúng quá nhỏ, yêu cầu phải có thêm sự phối hợp làm
việc hiệu quả với các thông tin được cung cấp bởi các servlet và JSP, và có thể là
EJB ở đằng sau.
Ta sẽ xem xét các công nghệ Java chủ chốt để phát triển ứng dụng không dây
trong hệ thống doanh nghiệp. Ta cũng sẽ xét đến các kiến trúc hỗ trợ client không
dây trong các hệ thống doanh nghiệp.
Trong lúc này, dịch vụ Web (Web service), có thể sẽ trở thành một phương
tiện vượt trội để hỗ trợ cho phần mềm client không dây trong một vài năm tới.
(profile), định nghĩa các API; các nhà thực hiện J2ME cho thiết bị cần tập trung đến
mức VM (Virtual Machine).
Các đặc tả cho các thiết bị không dây là Connected Limited Device
Configuration hay CLDC, và Mobile Information Device Profile hay MIDP. MIDP
định nghĩa các đặc tính tối thiểu của thiết bị như sau:
• Bộ nhớ không bay hơi có dung lượng 128K (nghĩa là, bộ nhớ có trạng thái
được giữ lại khi thiết bị đã tắt) dành cho các thành phần MIDP, bao gồm KVM,
Core API và chương trình MIDP.
• 8K bộ nhớ không bay hơi dành cho dữ liệu bền vững của ứng dụng.
• 32K bộ nhớ bay hơi cho bộ nhớ của chương trình.
• Màn hình hiển thị ít nhất là 96x54 pixel, có thể chỉ là một bit màu hay hỗ trợ
nhiều màu hoặc màu mức xám.
• Cơ chế nhập liệu hỗ trợ ít nhất một bộ phím số, hoặc một màn hình cảm ứng
có khả năng cấu hình hỗ trợ nhập liệu số.
• Khả năng kết nối mạng không dây hai chiều, với băng thông hạn chế và
thông thường là không liên tục.
Như vậy các thiết bị hỗ trợ MIDP cung cấp một nền tảng chuẩn cho các phần
mềm Java:
1. Ứng dụng đơn (standalone application) được nạp hoàn toàn vào thiết bị và
có thể chạy bất kỳ lúc nào thiết bị được mở, không yêu cầu tài nguyên bên
ngoài. Loại này bao gồm:
• Các ứng dụng PDA và ứng dụng organizer như sổ địa chỉ, danh sách
công việc và lịch hẹn.
• Các công cụ đơn giản như máy làm tính (calculator)
• Trò chơi
2. Ứng dụng nối mạng (networked application) được chia thành ít nhất hai
thành phần, một thành phần là client được triển khai trên thiết bị di động.
Thành phần này sẽ ít được dùng nếu không có kết nối đến ít nhất một
server trên hệ thống. Server thường là được đặt trong môi trường J2EE, và
phục vụ bằng Web hoặc các giao thức Internet khác.
Ở đây, ta hãy xét kỹ thuật ngữ client. Ta không gọi một MIDlet là một client
chỉ đơn giản là vì nó sử dụng kết nối mạng MIDP và liên lạc đến các thành phần
khác. Câu hỏi là phần luận lý lõi của ứng dụng đặt ở đâu? MIDlet có đảm nhận hầu
hết việc “suy nghĩ” và chỉ quan tâm đến mạng hay không? Đó không phải là client,
thật vậy – ít nhất là không theo đúng nghĩa trong ngữ cảnh của hệ thống enterprise.
Một client là một MIDlet dựa vào một server để suy nghĩ, lưu trữ, tải, xử lý, hay nói
cách khác là làm việc thay cho nó.
Ta xét thuật ngữ Enterprise software (phần mềm doanh nghiệp). Đây là một
thuật ngữ được định nghĩa không chặt. Nói chung, ta định nghĩa các hệ thống mức
doanh nghiệp bằng các yêu cầu và nhu cầu khi thực thi.
• Trong bất kỳ lĩnh vực và mức nào, các hệ thống doanh nghiệp thường
phải chịu áp lực rất cao: xử lý hay lưu trữ nhiều dữ liệu, xử lý nhiều yêu cầu,
thường là thường xuyên, nhiều công việc phải làm cho client. Hệ thống phải
có khả năng nâng cấp, và phải hoạt động có hiệu quả dưới áp lực cao.
• Hệ thống phải có tính sẵn sàng (available).
• Quản lý dữ liệu ứng dụng phải thỏa mãn tất cả tính chất của giao tác
ACID: atomicity (tính nguyên tử), consistency (tính toàn vẹn), isolation (tính
tách biệt), và durability (tính bền vững). Nói chung, điều này có nghĩa là
server phải hỗ trợ một chuẩn tin cậy rất cao trong việc xử lý dữ liệu.
• Các chức năng dữ liệu và ứng dụng phải an toàn (secure): điều này
bao gồm cần phải có xác thực, và chính sách cấp quyền.
Truyền thông điệp giữa các thành phần phải đáng tin cậy (reliable) – điều
này cũng giống như tính ACID của giao tác, nhưng ở đây ta áp dụng cho các thông
điệp của ứng dụng.
Data
phải được áp dụng cho dữ liệu khi nó thay đổi. Tầng này cung cấp cho tầng trình
diễn trước nó, và cũng là phương tiện cho việc lưu trữ và nhận dữ liệu của tầng
sau nó.
• Tầng persistent quản lý lưu trữ bền vững và lấy dữ liệu ứng dụng. Tầng này
có thể bao gồm mã chương trình cộng với hệ quản trị cơ sở dữ liệu quan hệ.
Mô hình mẫu có thể biểu diễn như hình dưới:
Web server EJB Container
Entity
RDB
Beans
2.8 Hỗ trợ các thiết bị MIDP thông qua tầng môi giới (Mediation)
Việc chuẩn bị đặc biệt dữ liệu từ tầng giữa để cho một dạng trình diễn đặc
biệt được gọi là sự môi giới (mediation). Tầng môi giới (mediator tier) là một tính
năng thông thường của các hệ thống N-tầng, thường được triển khai để hỗ trợ việc
dùng nhiều khung (framework) trình diễn khác nhau cho cùng một tầng domain.
JSPs
Mediator Business Data
Visual Basic
application
Đối với các MIDP client, sự môi giới thường là ở dạng một gateway, biên
dịch nội dung mức PC sang nội dung mức micro, và có thể xử lý chuyển đổi giao
thức, ví dụ như:
• Nội dung HTML có thể được biên dịch thành Wireless Markup Language,
hay WML
• Giao thức cơ bản có thể chuyển từ HTTP sang Wireless Application Protocol
hay WAP
• Các datagram sẽ không được cung cấp bằng User Datagram Protocol (UDP)
mà bằng Wireless Datagram Protocol hay WDP.
Kiến trúc cuối cùng sẽ là một trong hai biến thể của kiến trúc N-tầng của
kiến trúc J2EE mà ta đã thấy ở trên.
• Mediation của domain:
JSPs
Business Data
MIDlet Gateway
MIDP client sẽ dựa nhiều vào phần mềm J2EE và các gateway hay tầng môi
giới để đơn giản hóa hay định dạng nội dung cho việc trình diễn và xử lý ở người
dùng di động.
JNDI
CORBA
Hình 12. Kiến trúc mức cao của một ứng dụng doanh nghiệp Java không dây
Kiến trúc của một ứng dụng doanh nghiệp phục vụ các client không dây
cũng tương tự như của một ứng dụng J2EE chuẩn:
• Một client ứng dụng sử dụng MIDP hay được gọi là MIDlet client, cung cấp
giao diện người dùng trên thiết bị di động. MIDlet giao tiếp với một Java servlet,
thường là thông qua HTTP, và trên một kênh truyền bảo mật khi cần thiết.
• Servlet dịch yêu cầu từ MIDlet, và tới lượt nó, gửi yêu cầu đến các thành
phần EJB. Khi các yêu cầu được thỏa mãn, servlet phát sinh một hồi đáp cho
MIDlet.
• Các thành phần EJB, hay các enterprise beans, bao bọc logic nghiệp vụ của
ứng dụng. Một trình chứa EJB cung cấp các dịch vụ chuẩn như giao tác, bảo mật,
và quản lý tài nguyên để các nhà phát triển có thể tập trung vào việc thực hiện
logic nghiệp vụ.
Các thành phần servlet và EJB có thể sử dụng các API bổ sung để truy xuất
dữ liệu và dịch vụ. Ví dụ, chúng có thể sử dụng JDBC API để truy xuất cơ sở dữ
liệu quan hệ, hay JavaMail API để gửi e-mail cho người dùng.
Hình 13. Kiến trúc mức cao của một ứng dụng J2EE hỗ trợ client J2ME và client Brower
• Servlet mã hóa application response và đóng gói nó vào một HTTP response.
Content-Type và Content-Length header cũng phải được thiết lập đúng để bảo
đảm các gateway trung gian xử lý response đúng đắn.
Client nhận HTTP response và giải mã application response chứa trong đó.
Client có thể thiết lập một hoặc nhiều đối tượng và thực hiện một số công việc trên
các đối tượng cục bộ này.
Thiết kế định dạng thông điệp (Message Format)
Cách định dạng application request và response là tùy thuộc vào lập trình
viên. Các lựa chọn rơi vào hai cách sau:
Một cách là dùng định dạng nhị phân. Các thông điệp nhị phân có thể được
đọc và ghi sử dụng các lớp DataInputStream và DataOutputStream trong gói
java.io.
Trên thực tế, sử dụng các thông điệp này đạt được hiệu quả trao đổi bởi vì
tải được rút gọn. Chú ý rằng để tiết kiệm không gian, các thông điệp phải thỏa mãn
tính tự miêu tả (self-descriptive). Do đó, định dạng của thông điệp phải được biết
cả ở client và server, và do đó chúng gắn chặt với nhau.
Cách khác là sử dụng Extensible Markup Language (XML). Trong khi nền
tảng J2EE cung cấp rất nhiều hỗ trợ cho XML (đặc biệt là trong Web service), thì
đặc tả MIDP không yêu cầu hỗ trợ XML, mặc dù các nhà phát triển có thể thêm hỗ
trợ XML vào ứng dụng MIDP bằng cách kết hợp các thư viện bổ sung.
Để phân tích và xử lý tài liệu XML, các nhà phát triển có thể lựa chọn nhiều
cách thực hiện, bao gồm hai mô hình xử lý phổ biến, Document Object Model
(DOM) và Simple API for XML (SAX). (SAX và các bộ phân tích dựa trên sự kiện
khác thích hợp hơn DOM khi áp dụng cho các thiết bị di động với bộ nhớ và tốc độ
xử lý bị hạn chế). Các thư viện RPC dựa trên XML cũng được cung cấp, bao gồm
các bộ phân tích dựa trên đặc tả Simple Access Object Protocol (SOAP).
Tuy nhiên khi sử dụng định dạng XML, ngoài việc chi phí cho kích thước và
băng thông, còn có chi phí không nhỏ về bộ nhớ, xử lý và lưu trữ.
Liên quan đến truyền thông điệp, ta có các vấn đề sau:
Liên lạc an toàn (Communicating Securely)
Các client MIDP có thể dựa vào một số cơ chế giống các cơ chế dùng để hỗ
trợ liên lạc an toàn giữa các ứng dụng J2EE và các client trình duyệt Web.
Server ứng dụng J2EE và nhiều thiết bị MIDP hỗ trợ HTTP trên Secure
Sockets Layer (SSL). Các thiết bị MIDP sử dụng secure HTTP để xác thực với
server và tiến hành trao đổi an toàn với server đó. Khung kết nối tổng quát (Generic
Connection Framework) trong MIDP cho phép người lập trình mở kết nối secure
HTTP chỉ đơn giản bằng cách gọi phương thức Connector.open() với URL bắt đầu
bằng https.
Để xác thực ở phía client, các MIDP client dựa vào việc xác nhận do ứng
dụng quản lý, có thể dựa vào cơ chế tự đăng ký. Nói cách khác, MIDP client gửi
thông tin ủy nhiệm (ví dụ như tên đăng nhập và mật khẩu) đến ứng dụng J2EE, và
ứng dụng sẽ xác nhận các thông tin này, có thể bằng cách sử dụng cơ sở dữ liệu.
Quản lý lỗi
Khi server J2EE không thể thực hiện request cho MIDP client, nó cần phải
thông báo điều này cho client. Mặc dù chương trình của server có thể sử dụng cơ
chế quản lý ngoại lệ của Java để xử lý lỗi cục bộ, nó không thể sử dụng cơ chế này
để thông báo lỗi cho MIDP client khi liên lạc trên mạng. Nói cách khác, lập trình
viên không thể cài đặt một khối try-catch trong mã client để bắt trực tiếp ngoại lệ
được ném ra từ server. Thay vào đó, họ phải tổ chức một cơ chế thông báo lỗi vào
giao thức truyền thông điệp của họ.
Một cách là dành một phần cố định trong mỗi response của ứng dụng cho
một mã trạng thái thể hiện là request của ứng dụng có thành công hay không. Ví dụ,
khi sử dụng truyền thông điệp nhị phân, hai byte đầu tiên có thể dành cho mã trạng
thái số nguyên. Khi sử dụng HTTP, các nhà phát triển ứng dụng có thể dùng mã
trạng thái của HTTP response để thể hiện thành công hay thất bại ở mức truyền
thông. Ví dụ, mã trạng thái của 200 (“OK”) có thể dùng để chỉ thành công, trong
khi mã trạng thái 500 (“Internal Server Error”) có thể dùng để chỉ thất bại.
dùng, chẳng hạn như địa chỉ, mã ZIP, hay màu sắc ưa thích, sẽ không thay đổi từ
phiên làm việc này sang phiên làm việc khác. Bởi vì các dữ liệu này là ổn định, ứng
dụng có thể dùng nó để cá nhân hóa việc sử dụng của người dùng.
Việc cá nhân hóa một dịch vụ là có lợi vì hai lý do sau:
• Nó giảm việc yêu cầu nhập liệu. Người dùng sẽ chán nếu phải nhập đi nhập
lại các thông tin này mỗi lần sử dụng dịch vụ.
• Nó sẽ rút ngắn dòng chảy công việc (workflow). Người dùng có thể nhập
thông tin tài khoản vào lần đầu, và client sẽ giữ lại thông tin đăng nhập của họ.
Trong các lần sử dụng sau đó, người dùng có thể lựa chọn tự động đăng nhập mà
không phải qua màn hình đăng nhập.
Trong khi trạng thái phiên làm việc có thể xem là thông tin tạm thời, thì dữ
liệu cá nhân hóa sẽ có tính bền vừng. Lưu dữ liệu bền vững này ở đâu là tùy vào
người phát triển ứng dụng.
Khi quyết định lưu trữ dữ liệu cá nhân hóa, các nhà phát triển phải xem xét
các câu hỏi sau:
• Dữ liệu cá nhân hóa có thường xuyên ảnh hưởng đến client request không?
Ví dụ, ứng dụng đặt vé sẽ liệt kê các rạp dựa vào mã vùng của người dùng.
Server lưu trữ mã vùng này, do đó client không cần phải gửi lại mã vùng mỗi lần
nó gửi yêu cầu. Tuy nhiên cũng nên cho phép người dùng có thể bỏ qua mã vùng
này, ví dụ khi họ sang thăm một vùng khác.
• Thông tin cá nhân hóa có khả năng sử dụng giữa nhiều loại client hay
không? Ví dụ, người dùng sử dụng ứng dụng đặt vé trên điện thoại di động có thể
muốn truy xuất cùng ứng dụng đó qua Web. Khi đó, họ có thể muốn dữ liệu cá
nhân sẽ có sẵn để tránh việc nhập lại nó qua Web.
Quyết định nơi để lưu dữ liệu cá nhân hóa không phải luôn luôn là một quyết
định lựa chọn một trong hai. Dữ liệu cá nhân hóa có thể được lưu chồng ở cả client
và server. Khi dữ liệu cá nhân hóa được lưu chồng trên cả client và server, ứng
dụng có thể cần phải có thêm một số tính năng để đồng bộ hóa dữ liệu này. Các nhà
phát triển được khuyên là nên cân nhắc đến chi phí của việc thực hiện các tính năng
này.
Một nhu cầu thiết yếu trong truyền tải dữ liệu đó là tính toàn vẹn dữ liệu
(data integrity), trong đó có 2 việc cần quan tâm là: che giấu dữ liệu (bảo vệ khỏi bị
ăn trộm) và bảo vệ dữ liệu khỏi bị giả mạo.
Để che giấu dữ liệu:
- Encoding
- Encryption
- Symmetric Encryption
- Asymmetric Encryption
Để bảo vệ dữ liệu:
- Hashes/ Message disgest
- Digital Signature
- Digital Certificate
- Certificate Authorities
triển khai sử dụng PKI không đơn giản và có nhiều giải pháp của nhiều nhà sản xuất
khác nhau.
Mật mã đối xứng được chia làm hai dạng:
a. Block cipher
Block cipher là một giải pháp hoạt dộng chống lại sự hạn chế của dữ liệu
tĩnh. Dữ liệu được chia ra thành các blocks với size cụ thể và mỗi blocks được mã
hoá một cách khác nhau.
b. Stream cipher
Stream cipher là giải pháp hoạt động chống lại dữ liệu luôn luôn sử dụng một
phương thức để truyền. Một vùng đệm, ít nhất bằng một block, đợi cho toàn bộ
thông tin của block đó được chứa trong vùng đệm sau đó block đó sẽ được mã hoá
rồi truyền cho người nhận. Một sự khác nhau cơ bản giữa dữ liệu được truyền và dữ
liệu nguyên bản. Không như giải pháp sử dụng mật mã đối xứng là mỗi block được
sử dụng một key khác nhau trong quá trình truyền thông tin.
Dưới đây là các giải pháp mật mã đối xứng hay sử dụng nhất:
Ví dụ, khi Alice muốn gửi thông tin cho Bob, Alice sử dụng public key của
Bob để mã hóa thông tin rồi gửi cho Bob. Khi Bob nhận thông tin đã được mã hóa
của Alice sẽ giải mã thông tin bằng Pivate key của mình.
Mật mã bất đối xứng hoạt động chậm hơn phương thức mật mã đối xứng,
không phải nó mã hoá một khối lượng dữ liệu lớn. Nó thường được sử dụng để bảo
mật quá trình truyền key của mật mã đối xứng. Nó cung cấp bảo mật cho quá trình
truyền thông tin bằng các dịch vụ: Authentication, Integrity, Protection, và
Nonrepudiation.
Alice Bob
Chữ ký điện tử (digital signature) là đoạn dữ liệu ngắn đính kèm với văn bản
gốc để chứng thực tác giả của văn bản và giúp người nhận kiểm tra tính toàn vẹn
của nội dung văn bản gốc.
Chữ ký điện tử được tạo ra bằng cách áp dụng thuật toán băm một chiều trên
văn bản gốc để tạo ra bản phân tích văn bản (message digest) hay còn gọi là
fingerprint, sau đó mã hóa bằng private key tạo ra chữ ký số đính kèm với văn bản
gốc để gửi đi. Khi nhận, văn bản được tách làm 2 phần, phần văn bản gốc được tính
lại fingerprint để so sánh với fingerprint cũ cũng được phục hồi từ việc giải mã chữ
ký số (xem hình dưới).
public key của B. Nếu A dùng public key giả này mà tưởng là của B thì dẫn đến hệ
quả mọi thông tin A truyền đi đều bị hacker đọc được.
Vấn đề này được giải quyết nếu có một bên thứ ba được tin cậy, gọi là C,
đứng ra chứng nhận public key. Những public key đã được C chứng nhận gọi là
chứng nhận điện tử (public key certificate hay digital certificate).
thống một cặp khóa công khai/khóa bí mật. Các quá trình này thường được thực
hiện bởi một phần mềm đặt tại trung tâm và các phần mềm phối hợp khác tại các
địa điểm của người dùng. Khóa công khai thường được phân phối trong chứng thực
khóa công khai.
Khái niệm hạ tầng khóa công khai (PKI) thường được dùng để chỉ toàn bộ hệ
thống bao gồm nhà cung cấp chứng thực số (CA) cùng các cơ chế liên quan đồng
thời với toàn bộ việc sử dụng các thuật toán mật mã hóa khóa công khai trong trao
đổi thông tin. Tuy nhiên phần sau được bao gồm không hoàn toàn chính xác bởi vì
các cơ chế trong PKI không nhất thiết sử dụng các thuật toán mã hóa khóa công
khai.
PKI cho phép những người tham gia xác thực lẫn nhau và sử dụng thông tin
từ các chứng thực khóa công khai để mật mã hóa và giải mã thông tin trong quá
trình trao đổi. Thông thường, PKI bao gồm phần mềm máy khách (client), phần
mềm máy chủ (server), phần cứng (như thẻ thông minh) và các quy trình hoạt động
liên quan. Người sử dụng cũng có thể ký các văn bản điện tử với khóa bí mật của
mình và mọi người đều có thể kiểm tra với khóa công khai của người đó. PKI cho
phép các giao dịch điện tử được diễn ra đảm bảo tính bí mật, toàn vẹn và xác thực
lẫn nhau mà không cần phải trao đổi các thông tin mật từ trước.
Hầu hết các hệ thống PKI quy mô doanh nghiệp đều dựa trên các chuỗi
chứng thực để xác thực các thực thể. Chứng thực của người dùng sẽ được một nhà
cung cấp chứng thực số cấp, đến lượt nhà cung cấp này lại có chứng thực được một
nhà cung cấp khác ở cấp cao hơn tạo ra... Hệ thống sẽ bao gồm nhiều máy tính
thuộc nhiều tổ chức khác nhau với các gói phần mềm tương thích từ nhiều nguồn
khác nhau. Vì vậy, các tiêu chuẩn là yếu tố rất quan trọng đối với hoạt động của các
PKI. Hầu hết các tiêu chuẩn về PKI hiện tại được soạn thảo bởi nhóm làm việc
PKIX của IETF.
Các hệ thống PKI doanh nghiệp thường được tổ chức theo mô hình danh bạ
trong đó khóa công khai của mỗi người dùng được lưu trữ (bên trong các chứng
thực số) kèm với các thông tin cá nhân (số điện thoại, email, địa chỉ, nơi làm
việc...). Hiện nay, công nghệ danh bạ tiên tiến nhất là LDAP và định dạng chứng
thực phổ biến nhất (X.509) cũng được phát triển từ mô hình tiền nhiệm của LDAP
(X.500).
nhất chứng minh được về lý thuyết là không thể phá được ngay cả với tài nguyên vô
tận (tức là có thể chống lại kiểu tấn công brute-force). Để có thể đạt được mức độ
bảo mật của OTP, tất cả những điều kiện sau phải được thỏa mãn:
- Độ dài của chìa khóa phải đúng bằng độ dài văn bản cần mã hóa.
- Chìa khóa chỉ được dùng một lần.
- Chìa khóa phải là một số ngẫu nhiên thực.
Mới nghe qua có vẻ đơn giản nhưng trong thực tế những điều kiện này khó
có thể thỏa mãn được. Giả sử Alice muốn mã hóa chỉ 10MB dữ liệu bằng OTP, cô
ta phải cần một chìa khóa có độ dài 10MB. Để tạo ra một số ngẫu nhiên lớn như vậy
Alice cần một bộ tạo số ngẫu nhiên thực (TRNG - True Random Number
Generator). Các thiết bị này sử dụng nguồn ngẫu nhiên vật lý như sự phân rã hạt
nhân hay bức xạ nền vũ trụ. Hơn nữa việc lưu trữ, chuyển giao và bảo vệ một chìa
khóa như vậy cũng hết sức khó khăn.
OTP ngày nay được sử dụng rộng rãi và khá quen thuộc trong các giao dịch
điện tử. Ví dụ một giao dịch chuyển tiền qua điện thoại thì trước khi giao dịch được
thực hiện, người dùng sẽ được nhận một tin nhắn có chứa mã OTP, sau đó người
dùng phải điền OTP vào form có sẵn và gửi lên server để xác thực.
5.1 Chuẩn đóng gói bản tin giao tiếp ISO 8583
ISO 8583 là chuẩn quốc tế quy định đặc tả của bản tin trao đổi giữa các hệ
thống ngân hàng, tài chính trong giao dịch điện tử. Việc sử dụng chung một chuẩn
đóng gói bản tin sẽ dễ dàng trong việc giao tiếp, trao đổi thông tin, dữ liệu giữa các
ngân hàng và tổ chức tài chính.
Để xây dựng và đóng gói bản tin ISO 8583 trong JAVA, thư viện JPOS hỗ
trợ khá đầy đủ và dễ dàng triển khai.
ISO 8583 định nghĩa định dạng bản tin và luồng giao tiếp giúp các hệ thống
khác nhau có thể trao đổi thông tin. Mặc dù ISO 8583 định nghĩa một chuẩn chung,
nhưng nó không đặc trưng cho một mạng hay một hệ thống nào cả. Thay vào đó,
mỗi một mạng hay hệ thống sẽ sử dụng chuẩn này để xây dựng tùy biến các trường,
các cách sử dụng. Một bản tin ISO 8583 được chia làm 3 phần:
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 46
Đồ án tốt nghiệp Dịch vụ Mobile-wallet
Một bản tin ISO sẽ có ít nhất 1 BITMAP, được gọi là PRIMARY BITMAP, được
dùng để chỉ ra các trường từ 1 đến 64. Bitmap có thể được truyền đi dưới dạng
8bytes dữ liệu nhị phân, hoặc 16 kí tự hexa.
Một trường chỉ được thể hiện khi nó được chỉ định trong 1 bit của BITMAP
là true. Ví dụ, byte “82x có dạng binary là ‘1000 0010’ sẽ chỉ ra rằng trường 1 và 7
sẽ được thể hiện trong bản tin, còn các trường 2,3,4,5,6,8 sẽ không được thể hiện”.
c. Data Elements
Data elements là các trường trong bản tin ISO, chỉ ra các thông tin về giao
dịch. Mỗi data element có một ý nghĩa và một định dạng khác nhau.
5.2.4 Các yêu cầu của tiêu chuẩn quốc tế ISO 27001:2005
- Hệ thống quản lý an ninh thông tin
- Trách nhiệm lãnh đạo
5.2.5 Các bước chủ yếu xây dựng và áp dụng ISO 27001:2005
- Cam kết thực hiện dự án của lãnh đạo
- Thành lập Ban chỉ đạo ANTT
- Khảo sát đánh giá thực trạng Hệ thống hiện hành
- Đào tạo nhận thức về ISO 27001
- Đào tạo viết tài liệu
- Đưa ra chính sách mục tiêu và phạm vi an ninh thông tin
- Phân tích, đánh giá rủi ro trong phạm vi của Hệ thống ISMS
- Lựa chọn mục tiêu, biện pháp kiểm soát phù hợp để thực thi
- Áp dụng thử
- Đào tạo chuyên gia đánh giá nội bộ
- Tiến hành đánh giá nội bộ
5.3 PKCS
PKCS (tiếng Anh: Public Key Cryptography Standards) là một chuẩn do
phòng thí nghiệm RSA Data Security Inc phát triển. Nó dựa vào các cấu trúc ASN.1
và thiết kế cho phù hợp với chứng chỉ X.09, các tiêu chuẩn này do ANSI thiết kế,
theo đó dữ liệu được chia thành từng khối nhỏ nhất là 8 bit (octet). PKCS hiện tại
bao gồm các chuẩn PKCS#1, PKCS#3, PKCS#5,PKCS#7, PKCS#8, PKCS#9,
PKCS#11, PKCS#12, PKCS#13, PKCS#15. Hiện tại phiên bản của các bản đang là
2.1. Trong đó có thể tìm được các chuẩn để mã hóa dữ liệu, chuẩn này được thiết kế
dựa vào cách mà các thám mã dùng để tấn công vào đoạn mã. Có thể mô tả sơ qua
thế này, trong PKCS#1 có các chuẩn mã hóa - giải mã RSAES - OAEP scheme,
chuẩn tạo chữ ký điện tử - kiểm tra RSASSA - PSS scheme ver2.1, hay trong
PKCS#7 là các chuẩn mã hóa cho password. PKCS#11 là phức tạp nhất, nó là
chuẩn cho việc truyền thông tin trên mạng dưới dạng các gói tin đã mã.
• Ghi chú: Những ai phát triển sản phẩm IS có sử dụng đến module mật mã
đều cần quan tâm đến tiêu chuẩn này.
• Ghi chú: Những ai phát triển sản phẩm IS có sử dụng đến module mật mã
đều cần quan tâm đến tiêu chuẩn này.
Xây dựng demo dịch vụ mobile wallet nhằm chứng minh tính thực tiễn của
đề tài, hướng tới mục tiêu xây dựng và cung cấp dịch vụ sau này, tạo sự thuận tiện
cho người dùng khi thanh toán một số dịch vụ, giảm tải cho hệ thống tiền tệ, góp
phần phát triển nền tài chính không phải tiền mặt. Trong đó, bao gồm các dịch vụ
cơ bản và thiết yếu sau:
- Nạp tiền vào tài khoản, chuyển tiền từ tài khoản ngân hàng này sang
tài khoản ngân hàng khác, từ số thuê bao điện thoại này sang số thuê
bao điện thoại khác.
- Thanh toán và tra cứu thông tin thanh toán các dịch vụ viễn thông
(ADSL, HomePhone, Mobile Post-Paid, Mobile Pre-Paid, Mua hàng)
thông qua điện thoại di động
Hệ thống được xây dựng qua tham khảo các chức năng, nghiệp vụ của các
nhà cung cấp dịch vụ mobile wallet đã có trên thị trường như mobivi, payplus…
hay các dịch vụ mobile banking của các ngân hàng MB, Vietcombank…
MobileWallet
Login
Khac Mo the
Ngon ngu
Đăng nhập
Điện thoại
Bắt đầu
Xác nhận N
Kiểm tra MK
N Y
Kết thúc
o Nếu sai sẽ thông báo lỗi trên màn hình Mobile theo ngôn ngữ
được thiết lập mặc định trên ứng dụng
o Nếu trùng khớp thì lấy thông tin ngôn ngữ mặc định lưu trong
RMS ra
Bước 4: Hiển thị tất cả các chức năng theo ngôn ngữ, kết thúc nghiệp vụ
1.1.4 Mô tả dòng sự kiện phụ (Alternative Flow)
KH chọn “Cancel” để hủy tiếp tục: thoát ra khỏi ứng dụng “M-Wallet”
Tại bất kỳ màn hình nhập liệu nào đều có nút “Back”, khi KH không
nhập liệu mà bấm nút “Back” thì ứng dụng sẽ trở về màn hình trước đó
Ứng dụng kiểm tra MK không hợp lệ: ứng dụng hiển thị thông báo lỗi
tương ứng và nút “OK”. KH bấm OK thì STK quay lại màn hình “Nhập
mật khẩu”. Thông báo lỗi tương ứng: “Sai mat khau truy cap”.
Bước 7: Core server xử lý yêu cầu rồi gửi trả về kết quả cho Mobile
gateway.
Bước 8: Mobile gateway nhận kết quả trả về, xử lý thông tin, đóng gói
và gửi về cho client.
Bước 9: Ứng dụng client hiển thị kết quả nếu thành công là:KH chuyển
tiền: "Quy khach da thuc hien chuyen thanh cong <Amount> VND cho
thuê bao <RECV_MSISDN>, So du cua qui khach la <Amount>. Kết
thúc nghiệp vụ.
KQ nhận được nếu có lỗi thì sẽ được hiển thị lên màn hình. KH bấm OK,
ứng dụng trở về menu chính (sau khi đăng nhập ứng dụng thành công), kết thúc
nghiệp vụ.
ifi
W
thanh toán hoặc thanh toán được rất ít các dịch vụ, tối thiểu phải là các dịch vụ thiết
yếu như thanh toán tiền điện, nước, thuê bao điện thoại,…
Phần core server là thành phần chính của hệ thống đảm nhiệm các xử lý
nghiệp vụ, tương tác với CSDL … Với mỗi một giao dịch cần được xử lý, mobile
gateway lại mở một kết nối socket đến core server để giao tiếp. Việc đóng mở kết
nối thường xuyên sẽ làm tiêu tốn nhiều tài nguyên cũng như thời gian của cả hệ
thống. Chính vì vậy, để tối ưu kết nối đến core server, ta cần quản lý được kết nối
đến nó; điều này dễ dàng làm được với Apache pooling. Apache pooling sẽ quản lý
việc mở bao nhiêu kết nối đến core server, và mỗi khi mở kết nối thì các kết nối này
sẽ không bị đóng lại mà sẽ để ở dạng chờ (Idle) để phục vụ cho những lần sau.
Apache pooling còn được sử dụng trong việc kết nối đến database của hệ thống.
Phần core server do thời gian hạn hẹp cũng như thiếu thốn về kiến thức,
nghiệp vụ nên em chưa thể xây dựng hoàn chỉnh với công nghệ EJB. Hiện tại thì
core server chỉ có thể xử lý một số yêu cầu đơn giản, và kết nối trực tiếp với
database để thực hiện lệnh.
4.2 MAC
MAC được sinh bằng cách băm bản tin và session key. Hacker nếu muốn giả
dạng, hay thay đổi bản tin cũng không được vì session key là bí mật, được trao đổi
bằng mã hóa bất đối xứng. Trong mỗi bản tin gửi lên luôn phải kèm theo MAC để
xác thực tính toàn vẹn của bản tin.
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 68
Đồ án tốt nghiệp Dịch vụ Mobile-wallet
4.8 SEQUENCE
Relay attach là phương thức tấn công khá phổ biến, đối tượng hacker gửi liên
tiếp một bản tin cùng một nội dung lên server, lợi dụng delay của hệ thống để chuộc
lợi. Để ngăn chặn relay attach, ta sử dụng thêm biến sequence. Mỗi một giao dịch
khi xử lý luôn đảm bảo là phải hoàn thành trước khi xử lý tiếp một giao dịch khác.
Khi một giao dịch hoàn thành, biến sequence lại được tăng lên 1 đơn vị. Ngoài ra,
các client khi gửi thông tin lên đều phải được đặt thuộc tính user-agent để kiểm tra.
4.9 OTP
OTP là từ có lẽ được nhắc khá nhiều trong bảo mật ngân hàng, chứng
khoán… OTP được coi là giải pháp tối ưu nhất trong bảo mật. OTP là password chỉ
được sử dụng một lần duy nhất, và nó có hiệu lực trong một khoảng thời gian nhất
định. Ví dụ trong giao dịch thanh toán, khi người dùng chuyển tiền từ 1 tài khoản
đến 1 tài khoản, để xác nhận việc chuyển tiền này là từ đúng thuê bao của người
dùng, server sẽ gửi OTP qua tin nhắn đến thuê bao đó, và người dùng sẽ nhập OTP
nhận được vào form và gửi lên cho server, tại đây, server sẽ xác thực OTP. Vì OTP
chỉ có hiệu lực trong 1 khoảng thời gian ngắn, nên hacker không có đủ thời gian để
bẻ khóa, và cũng không thể giả danh người dùng được vì OTP được gửi qua kênh
SMS, một kênh được cho là rất bảo mật, rất khó và rất đắt đỏ khi giả mạo. Vậy việc
áp dụng OTP vào trong hệ thống M-wallet như thế nào?
Trong các ứng dụng thực đã triển khai OTP, OTP sẽ được truyền qua kênh
tin nhắn, độc lập với kênh giao tiếp của ứng dụng với server. Người dùng sẽ phải
thoát ứng dụng ra, vào inbox, ghi nhớ OTP, rồi lại vào ứng dụng để ghi OTP. Điều
này rất bất tiện cho người sử dụng. Thật may mắn là J2ME có hỗ trợ API về
Wireless messaging (WMA), cho phép lập trình viên có thể viết ứng dụng gửi và
nhận tin nhắn một cách tự động. Khi server gửi tin nhắn về, ta cần yêu cầu SMSC
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 70
Đồ án tốt nghiệp Dịch vụ Mobile-wallet
gửi tin nhắn theo 1 cổng mà ứng dụng đang lắng nghe. Khi có tin nhắn về, ứng dụng
bắt được tin nhắn, đọc nội dung, rồi hiển thị lên ứng dụng cho người dùng. Ở mức
độ demo, ta có thể sử dụng một modem GSM thay vì phải sử dụng một SMSC thực
thụ để nhắn tin SMS. Chi tiết hướng dẫn sử dụng NOWSMS, tham khảo trên trang
web chính thức www.nowsms.com
Rõ ràng, với việc áp dụng thêm OTP, hệ thống M-wallet sẽ đảm bảo được
tính bảo mật cao, tính xác thực của hệ thống. Số ngẫu nhiên sẽ được sinh từ server
với sức mạnh gấp nhiều lần client sẽ đảm bảo được tính bảo mật, không gian khóa
lớn.
Chương 4. THIẾT KẾ
1. Thiết kế CSDL
Để phục vụ cho dịch vụ, ta cần một cơ sở dữ liệu ngân hàng. Cơ sở dữ liệu
được xây dựng ở mức đơn giản, trước mắt đây là phiên bản đầu để phục vụ cho việc
demo chương trình.
1.1 Xây dựng các thực thể và các bảng cho cơ sở dữ liệu
Cơ sở dữ liệu phải được xây dựng bao gồm các thực thể sau đây:
1. Khách hàng
2. Tài khoản
3. Tài khoản điện thoại (kênh thanh toán trên điện thoại)
4. Tài khoản card (kênh thanh toán trên thẻ)
5. Giao dịch
6. Thuê bao điện thoại
Chi tiết các thực thể được xây dựng thành các bảng như dưới đây:
_NO
25 RECV_MSISDN VARCHAR2(20) Y Số MSISDN của KH nhận tiền
RECV_BANK_CO VARCHAR2(15) Y Mã ngân hàng của TK KH
26
DE nhận tiền
27 RESPONSE_CODE VARCHAR2(3) Y Mã lỗi trả về
RECV_MSISDN_T VARCHAR2(1) Y Xác định loại thuê bao: 0 - trả
28
YPE trưuớc, 1 - trả sau
ví dụ:
http://192.168.168.74/MobileGateway/TxGateway?d=0230313539663d3033
266f3d38343136353735303132373726703d31323334353626723d34636163643730
3062363936613733346431373831353766616163623833663364623836633539393
5653463316632626635373535363937386365393930336564633962363330663064
3633636462333831643232376637623937303935376461663165656337633637363
96261333465626465646437633437663630393934
Kết quả được trả về là luồng bytes dữ liệu, sử dụng định dạng http request
Ví dụ:
36539393033656463396236333066306436336364623338316432323766376
2393730393537646166316565633763363736396261333465626465646437633437
663630393934
b. Danh sách chức năng
Giá trị Mô tả
03 Truy vấn số dư
04 Truy vấn giao dịch External
05 chuyển tiền ví điện tử - ví điện tử
06 Chuyển tiền ví điện tử - ngân hàng
07 Chuyển tiền sử dụng CMTND
08 Nạp tiền
09 Rút tiền
11 Nạp tiền thuê bao trả trước
12 Gạch nợ cước thuê bao trả sau
13 Gạch nợ cước home phone trả sau
14 Gạch nợ cước ADSL
15 Gạch nợ cước các dịch vụ khác
16 Thanh toán dịch vụ
17 Yêu cầu thanh toán dịch vụ (Request to pay)
18 Kích hoạt ví điện tử
Response:
f=05&r=05&ms=giao%20dich%20thanh%20cong
c. Định nghĩa tham số cho các chức năng
CMTND
08 x Nạp tiền
09 x Rút tiền
11 x x x x Nạp tiền thuê bao trả
trước
12 x x x x Gạch nợ cước thuê bao
trả sau
13 x x x x Gạch nợ cước home
phone trả sau
14 x x x x Gạch nợ cước ADSL
15 x x x Gạch nợ cước các dịch vụ
khác
16 x Thanh toán dịch vụ
17 x Yêu cầu thanh toán dịch
vụ (Request to pay)
18 Kích hoạt ví điện tử
19 x x x Thay đổi PIN
21 x Khóa ví điện tử
22 x Truy vấn giao dịch
internal
23 x Lấy tên phiên bản mới
nhất trên server
24 Truy vấn kết quả giao
dịch cuối
25 x x Bản tin trao đổi session
key
26 x x Bản tin kích hoạt client
27 x x Bản tin kích hoạt thẻ
28 x x Bản tin cập nhật thông tin
cá nhân
Bảng 16. Các tham số cho từng chức năng
d. Cách thức tạo dữ liệu trường
Ví dụ:
http://192.168.168.74/MobileGateway/TxGateway?d=010630313539663d30
33266f3d38343136353735303132373726703d31323334353626723d346361636437
3030623639366137333464313738313537666161636238336633646238366335393
9356534633166326266353735353639373863653939303365646339623633306630
6436336364623338316432323766376239373039353764616631656563376336373
6396261333465626465646437633437663630393934&o=xxxx&ma=yyyy
xxxx : số msisdn tài khoản
yyyy : mac của dữ liệu truyền đi
dữ liệu:
010630313539663d3033266f3d38343136353735303132373726703d313233
34353626723d3463616364373030623639366137333464313738313537666161636
2383366336462383663353939356534633166326266353735353639373863653939
3033656463396236333066306436336364623338316432323766376239373039353
7646166316565633763363736396261333465626465646437633437663630393934
byte1: byte giá trị thể hiện kết quả trả về từ mobile gateway
byte2 byte5: 4 bytes biểu diễn chiều dài dữ liệu theo dạng BCD
byte6 end: mảng bytes dữ liệu
byte6 end: 3des(f=x&….&ma=yyy)
e. Bảng mã lỗi
(Xem thêm ở phụ lục)
Hình 28. Màn hình Splash Hình 29. Màn hình đăng nhập
Hình 30. Màn hình chính Hình 32. Chức năng tra cứu TK
Hình 31. Màn hình nhập PIN Hình 33. Màn hình chờ
Hình 34. Màn hình kết quả Hình 35. Màn hình nhập OTP
2.2 Bộ nhớ
J2ME Wireless Toolkit có công cụ Memory Monitor cho phép giám sát bộ
nhớ sử dụng của ứng dụng trong quá trình thực thi.
• Hệ thống được phân tích, thiết kế khá hoàn chỉnh, hoàn toàn có thể
đưa vào thực tiễn.
Một lần nữa, em xin chân thành cảm ơn cô giáo thạc sĩ Bùi Thị Hòa đã
hướng dẫn và chỉ dạy tận tình cho em trong quá trình thực hiện đồ án.
Phụ lục
TT Mã lỗi Mô tả
1 000 Giao dịch thành công
2 901 Số điện thoại không hợp lệ hoặc không đúng định dạng
3 902 Số tiền không hợp lệ hoặc không đúng định dạng
4 903 PIN sai
5 904 Hệ thống bảo dưỡng
6 905 Dịch vụ yêu cầu chưa có hoặc đang ngừng hoạt động
7 101 Ví điện tử chưa được kích hoạt
8 103 Merchant không hợp lệ
9 105 Ví điện tử bị khóa
10 109 Giao dịch đang trong quá trình xử lý
11 113 Số lượng tiền giao dịch không hợp lệ
12 114 Ví điện tử không tồn tại
13 122 Hệ thống đang tạm dừng
14 125 Bản tin yêu cầu không hợp lệ
15 136 Tài khoản ví điện tử không có quyền thực hiện giao dịch
16 140 Hệ thống chưa hỗ trợ bản tin yêu cầu
17 141 Ví điện tử đang bị khóa do khai báo mất thẻ
18 151 Ví điện tử không đủ số dư để thực hiện giao dịch
19 154 Ví điện tử bị khóa vĩnh viễn
20 161 Số lượng tiền giao dịch vượt quá hạn mức cho phép
21 175 Vượt quá số lần nhập sai PIN cho phép. Hệ thống sẽ tạm thời khóa ví
điện tử
22 177 Dữ liệu không đúng định dạng
23 178 Ngày giao dịch không hợp lệ
24 185 Hệ thống từ chối xử lý giao dịch
25 200 Giao dịch time-out
26 210 Mã dịch vụ yêu cầu không tồn tại
27 216 Mã số thẻ cào không tồn tại
28 217 Thẻ cào đã sử dụng