Đề tài Mobile Wireless và hệ thống dịch vụ giá trị gia tăng trên Web

nh shell để xử lý tin nhắn này và coi nội dung của stdout chính là nội dung trả về. Các tham số cũng có thể được dùng ở đây. Cách này không được khuyến cáo dùng do vấn đề bảo mật. accepted-smsc: Chỉ chấp nhận các tin nhắn tới từ smsc có số hiệu (smsc-id) nằm trong danh sách này. Các số hiệu cách nhau bởi dấu ‘;’. catch-all: Nếu được đặt bằng true thì sẽ xử lý tất cả các tin nhắn mà không quan tâm đến nội dung của tin. Thường chỉ được đặt bằng true với dịch vụ có từ khoá là default. max-messages: Nếu như tin nhắn trả về có nội dung vượt quá 160 ký tự thì tin nhắn đó sẽ phải được chia thành nhiều tin nhắn nhỏ. Tham số này sẽ quyết định số lượng tin nhắn tối đa có thể gửi trả lại cho người dùng dịch vụ. concatenation: Nếu được đặt bằng true thì khi gửi tin trả lại có nội dung dài hơn 160 ký tự, tin trả lại sẽ được chia thành nhiều tin nhỏ và các tin này sẽ được gửi đi như một tin nhắn dài. Với các loại điện thoại có hỗ trợ tin nhắn dài thì nó sẽ tự động ghép các tin nhắn ngắn lại và coi như là chỉ nhận được một tin nhắn. Hầu hết các loại điện thoại ngày này đều hỗ trợ tính năng này. accept-x-kannel-headers: Chấp nhận các Kannel header (sẽ mô tả chi tiết trong phần sau) trong nội dung trả về trong trường hợp dùng yêu cầu HTTP. assume-plain-text: Trong trường hợp dùng yêu cầu HTTP, nếu như module xử lý tin không đặt Content-Type cho nội dung trả về thì nó sẽ được xử lý như là dữ liệu nhị phân (kiểu application/octet-stream). Nếu đặt biến này bằng true thì trong trường hợp này dữ liệu trả về sẽ được coi là plain/text và được xử lý như là tin nhắn văn bản (text message). omit-empty: Nếu biến này được đặt bằng true thì khi nội dung trả về là rỗng Kannel sẽ không gửi trả người dùng tin nhắn có nội dung được đặt trong biến cấu hình reply-emptymessage của nhóm smsbox. Người dùng sẽ không được gửi trả bất cứ tin nhắn nào. Thường được dùng nếu hệ thống muốn tự gửi tin nhắn (thông qua giao diện gửi tin qua các yêu cầu HTTP của Kannel) trả lại sau khi đã xử lý mà không trả lại ngay để có thể đóng kết nối hiện tại. Sau đây là danh sách các tham số có thể truyền cho module xử lý tin nhắn: %k – Từ khoá trong tin nhắn SMS (là từ đầu tiên trong tin nhắn) %s – Từ tiếp theo trong tin nhắn SMS, bắt đầu từ từ thứ hai, mỗi lần dùng tham số này số thứ tự của từ trong tin sẽ được tăng thêm 1 (lần đầu tiên dùng tham số này là từ thứ 2, lần thứ 2 dùng tham số này sẽ là từ thứ 3 ). Đã xử lý vấn đề các ký tự không được cho phép khi sử dụng URL (URL encoded, ví dụ '+' trở thành '%2B'). %S – Giống như %s, nhưng '*' được chuyển thành '~' (có ích khi tự gõ URL). %r – Toàn bộ các từ chưa được dùng bởi các %s. %a – Tất cả các từ trong tin nhắn kể cả từ đầu tiên. Nếu có nhiều dấu trắng liên tiếp sẽ được chuyển thành còn 1 dấu trắng. %b – Nội dung của tin nhắn dưới dạng nhị phân. %t – Thời gian tin nhắn được gửi với cấu trúc "YYYY-MM-DD HH:MM", ví dụ "2006-04-20 14:00". %T – Thời gian tin nhắn được gửi theo định dạng UNIX epoch timestamp (là một số nguyên chính là số giây tính từ 00:00:00 01/01/1970 cho tới thời điểm hiện tại). %p – Số điện thoại của người đã gửi tin nhắn này. %P – Số điện thoại đã nhận tin nhắn này, thường được dùng để phân biệt xem người dùng đã gửi vào số dịch vụ nào trong dải số của mình để có những xử lý phù hợp. %q – Giống %p, nhưng nếu bắt đầu bằng ‘00’ sẽ được thay thế bằng ‘+’. %Q - Giống %P, nhưng nếu bắt đầu bằng ‘00’ sẽ được thay thế bằng ‘+’. %i - smsc-id của kết nối đã nhận tin nhắn này. %I - SMS ID của chính tin nhắn này (nằm ở trong cấu trúc của tin nhắn). %d – Giá trị của bản ghi thông tin truyền nhận (delivery report). Sẽ nói chi tiết hơn ở phần riêng cho Delivery Report. %n – Tên của sendsms-user hay sms-service. %c – Cách số hoá tin nhắn: 0 (mặc định, 7 bits), 1 (7 bits), 2 (8 bits) hay 3 (Unicode). %C – Bộ chữ cái của tin nhắn: cho các tin nhắn bình thường thì sẽ là: "GSM" (mã là 1), "binary" (mã là 2) or "UTF16-BE" (mã là 3). Nếu tin nhắn đã số hoá lại thành công từ Unicode bộ chữ sẽ là "ISO-8859-1". %u – udh (User Data Header) của tin nhắn đến. Nhóm sendsms-user Mỗi nhóm này tạo ra một tài khoản để gửi tin SMS bằng yêu cầu HTTP qua hệ thống của Kannel. Nó chứa các thuộc tính của tài khoản này. Sau đây là các biến cấu hình của nhóm này: group: Bắt buộc phải là “sendsms-user”. username: Tên sử dụng của tài khoản này. password: Mật khẩu tương ứng với tài khoản này. name: Tên được dùng để phân biệt khi ghi nhật ký (file log). user-deny-ip: Danh sách các ip không được gửi tin nhắn bằng tài khoản này. user-allow-ip: Danh sách các ip được phép gửi tin nhắn bằng tài khoản này. forced-smsc: Tin nhắn khi gửi bằng tài khoản này bắt buộc phải gửi qua SMSC có smsc-id trùng với biến này. default-smsc: Tin nhắn khi gửi bằng tài khoản này sẽ được gửi qua SMSC có smsc-id trùng với biến này đầu tiên. Nếu tại thời điểm gửi kết nối tới SMSC này bị ngắt thì Kannel sẽ thử với các SMSC khác. Biến này sẽ không có ý nghĩa nếu đặt biến forced-smsc. default-sender: Biến này sẽ được đặt là số điện thoại đã gửi tin này nếu như không được đặt bởi tham số dùng khi gửi tin. max-messages: Giống với trong nhóm sms-service nhưng là cho tài khoản này. concatenation: Giống với trong nhóm sms-service nhưng là cho tài khoản này. dlr-url: URL sẽ được gọi khi có thông tin về việc chuyển tin nhắn (delivery report) của hệ thống và tham số dlr-mask được đặt. Có thể xem kỹ hơn ở phần sau. split-chars: Ký tự dùng để phân cách các tin nhắn nếu như muốn gửi nhiều tin nhắn bằng cùng một yêu cầu HTTP. Cách gửi tin nhắn thông qua giao diện HTTP của Kannel Phần này sẽ trình bày cách để gửi tin nhắn thông qua giao diện HTTP của Kannel. Để gửi tin nhắn cần phải gửi tới một yêu cầu HTTP tới Kannel. URL đó sẽ bắt đầu bằng giá trị của biến sendsms-url trong nhóm smsbox. Sau đó là các tham số nếu dùng phương thức GET, hoặc phần HTTP header sẽ chứa các tham số dưới dạng X-Kannel-header nếu sử dụng phương thức POST. Sau đây là một ví dụ url gửi tin nhắn thông qua giao diện này: Sau đây là danh sách các tham số với X-Kannel-header tương ứng có thể được dùng để gửi tin nhắn: username hay user - X-Kannel-Username. password hay pass - X-Kannel-Password. from - X-Kannel-From. to - X-Kannel-To. text - Nội dung của yêu cầu HTTP. charset - Trùng với trường charset ở Header Content-Type của yêu cầu HTTP. udh - X-Kannel-UDH. smsc - X-Kannel-SMSC. dlr-mask - X-Kannel-DLR-Mask. dlr-url - X-Kannel-DLR-Url. Sau đây là ý nghĩa của các tham số trên: username hay user: Tên của tài khoản, tài khoản này phải được tạo ra bằng một nhóm sendsms-user. password hay pass: Mật khẩu tương ứng với tài khoản trên. from: Số điện thoại sẽ được coi là số điện thoại gửi tin nhắn này. Thường dùng để chọn số gửi trong dải số được cung cấp. to: Số điện thoại sẽ nhận tin. text: Nội dung của tin. Phải được chuẩn hoá cho việc sử dụng URL (URL encoded). charset: Bộ ký tự sử dụng. udh: User Data Header cho tin nhắn này. smsc: smsc-id của SMSC sẽ gửi tin này. dlr-mask: Yêu cầu có thông tin về trạng thái của việc gửi tin đi (delivery report). Giá trị của biến này là tổ hợp (tổng hay phép or) của các giá trị: 1-đã gửi tới điện thoại, 2-không gửi được tới điện thoại, 4-đã gửi tới SMSC và đang được xếp trong hàng đợi, 8-đã gửi tới SMSC, 16-không gửi được tới SMSC. Khi đặt giá trị của tham số này thì bắt buộc phải đặt tham số dlr-url khi gửi hay đặt giá trị của biến cấu hình dlr-url trong nhóm sendsms-user. dlr-url: Mỗi khi có trạng thái tương ứng với các bit đã được đặt trong tham số dlr-mask thì URL này sẽ được gọi. Sau đây là một ví dụ về file cấu hình của group = core admin-port = 10000 #sms section smsbox-port = 10001 #others admin-password = xxx admin-deny-ip = "*.*.*.*" admin-allow-ip = "127.0.0.1" box-deny-ip = "*.*.*.*" box-allow-ip = "127.0.0.1" unified-prefix = "+84,0" access-log = "access.log" # SMSC CONNECTIONS # include all smpp configure include = "/programs/kannel/sbin/smpps" # SMSBOX SETUP group = smsbox bearerbox-host = localhost sendsms-port = 8068 access-log = "access.log" http-request-retry = 3 http-queue-delay = 10 reply-couldnotfetch = "Xin loi ban, hien tai dich vu dang duoc sua chua. Xin vui long thu lai sau." reply-couldnotrepresent = "Xin loi ban, hien tai dich vu dang duoc sua chua. Xin vui long thu lai sau." reply-requestfailed = "Xin loi ban, hien tai dich vu dang duoc sua chua. Xin vui long thu lai sau." # SEND-SMS USERS group = sendsms-user username = xxx password = xxx max-messages = 3 concatenation = true #user-deny-ip = "*.*.*.*" #user-allow-ip = "127.0.0.1" # SERVICES # there should be default always group = sms-service keyword = default get-url= "" omit-empty = yes catch-all = true max-messages = 3 concatenation = true 2.4. GSM Modem và các loại điện thoại chuẩn GSM Việc sử dụng tin nhắn SMS vào mục đích tra cứu, cung cấp thông tin hoặc điều khiển hệ thống có thể thực hiện mà không cần có một số điện thoại dịch vụ mà các nhà cung cấp sóng điện thoại cung cấp. Việc đó có thể thực hiện được nhờ một GSM Modem hay một loại điện thoại chuẩn GSM hỗ trợ lập trình AT Command. Các thiết bị phần cứng này có thể kết nối trực tiếp với máy tính và cho phép lập trình để gửi và nhận cũng như xử lý tin nhắn dưới dạng tin nhắn văn bản thông thường cũng như dưới dạng tin nhắn thông minh. Các loại thiết bị này có thể thực hiện vai trò như một tổng đài dịch vụ giả lập. Có thể kể tên một số loại GSM Modem và điện thoại chuẩn sau đây: Modem Siemens MC35, điện thoại Nokia 8310, 6100, 6610, 7250, 6230,Sony Ericson T68, T610 Để sử dụng các GSM Modem hay các loại điện thoại chuẩn GSM hỗ trợ AT Command chúng ta cần thiết phải làm các bước sau đây: Mua các thiết bị GSM Modem hay loại điện thoại chuẩn cùng với dây cáp nối qua cổng COM, USB hoặc kết nối qua hồng ngoại hay Bluetooth. Kết nối các thiết bị với máy tính và cài đặt phần mềm cho modem. Các phần mềm này được cung cấp bởi các nhà sản xuất thiết bị đó. Sử dụng phần mềm có sẵn hoặc lập trình để gửi nhận tin nhắn từ điện thoại vào máy tính. Xây dựng các ứng dụng xử lý tin nhắn. 2.5. WAP WAP (Wireless Application Protocol - Giao thức ứng dụng không dây) là một tiêu chuẩn dùng cho thông tin di động. WAP cho phép các thiết bị di động như máy điện thoại di động, PDA (Personal Digital Assistant), máy nhắn tin, truy nhập và lấy các thông tin từ các nguồn khác nhau, chủ yếu là từ các Website. WAP, theo định nghĩa của WAP Forum, là những chỉ tiêu kỹ thuật mang tính mở, toàn cầu, cho phép người sử dụng di động dùng các thiết bị không dây dễ dàng truy nhập và tương tác với thông tin và các dịch vụ một cách tức thời. WAP Forum là một hiệp hội công nghiệp bao gồm hơn 500 thành viên với chức năng là phát triển tiêu chuẩn toàn cầu cho thông tin và các dịch vụ điện thoại không dây trên các thiết bị điện thoại di động cũng như các thiết bị không dây khác. Như đã trình bày ở trên, WAP Forum được sáng lập vào tháng 12 năm 1997 bởi 3 nhà cung cấp thiết bị thông tin di động Nokia, Ericsson và Motorola cùng với Unwired Planet (hiện nay là phone.com). Trong số những thành viên của WAP Forum có những nhà cung cấp hạ tầng mạng thông tin di động nổi tiếng hàng đầu thế giới như Nokia, Ericsson, Motorola, Siemens, Alcatel, NEC, những nhà khai thác mạng thông tin di động như NTT DoCoMo, Vodafone, France Telecom, cũng như các hãng máy tính, phần mềm nổi tiếng như Microsoft, ORACLE, IBM, HP, Intel Mục đích của WAP Forum là đề ra các tiêu chuẩn WAP thống nhất trên phạm vi toàn cầu. Các thiết bị WAP giống như các trình duyệt WEB thu nhỏ, cho phép tương tác với các ứng dụng Internet. Tuy nhiên, do hạn chế về kích thước màn hình, khả năng hiển thị đồ họa, dung lượng bộ nhớ, nội dung WAP được soạn không phải bẳng ngôn ngữ HTML (HyperText Mark-up Language) giống như WEB mà sử dụng ngôn ngữ WML (Wireless Mark-up Language). Tương tự như HTML, WML sử dụng các màn hình hiển thị thông tin, gọi là card, để hiển thị thông tin. Thực chất WML chính là một dạng của XML (eXtensible Mark-up Language), ngôn ngữ được sử dụng phổ biến hiện nay cho các ứng dụng Internet. XML mô tả cấu trúc của nội dung thông tin, khác với HTML mô tả các trang được “mark-up”. Các loại nhãn (tag) khác nhau của WML tương ứng với các giao diện khác nhau có thể tạo ra và hiển thị trên các thiết bị WAP. Các Script, có nghĩa là các chương trình ứng dụng nhỏ như các trò chơi, cũng có thể viết cho các thiết bị WAP sử dụng các WMLScript, một dạng Script tương tự như JavaScript. Tóm lại, WAP cho phép người sử dụng: Nhận và gửi E-Mail qua máy điện thoại di động ví dụ như là các dạng E-Mail POP/SMTP. Nhận các thông tin từ Internet, dưới cả hai dạng các trang nội dung và các truy vấn từ cơ sở dữ liệu (database queries). Nhận các thông tin mang tính chất thông báo, ví dụ như là thông báo về giá cổ phiếu thay đổi, thông báo có E-Mail mới Thực hiện các tác vụ thương mại điện tử (M-Commerce) như mua hàng qua điện thoại di động. WAP thực chất chạy trên dịch vụ Data của mạng thông tin di động. Vì vậy để có thể sử dụng dịch vụ WAP, thuê bao thông tin di động nhất thiết cần phải có dịch vụ Data. 2.5.1. Cấu trúc WAP Hình sau mô tả cấu trúc WAP, bao gồm các giao thức mạng, bảo mật và môi trường ứng dụng. Hình 2.11: Cấu trúc WAP Như hình vẽ mô tả, tiêu chuẩn WAP được phân lớp có nghĩa là các tiêu chuẩn được đặt trên tiêu chuẩn khác và do đó phụ thuộc lẫn nhau khi cung cấp các dịch vụ. Việc phân lớp các giao thức được sử dụng để đơn giản hóa việc thiết kế mạng bằng cách chia nhỏ thành các lớp chức năng và ấn định mỗi giao thức thực hiện một chức năng tại lớp đó. Ngoài việc giao tiếp với lớp trên thì mỗi lớp giao thức WAP đều có thể giao tiếp trực tiếp với các dịch vụ và các ứng dụng. Ví dụ như một số ứng dụng nhất định chỉ sử dụng các dịch vụ cung cấp bởi lớp truyền WDP (Wireless Datagram Protocol). Ứng dụng đó có thể sử dụng trực tiếp các dịch vụ WDP mà không cần phần overhead của lớp cao hơn. Tất cả các lớp trên đều đối xứng có nghĩa là các lớp đều chạy cả ở phía thiết bị không dây và phía hạ tầng mạng. Ví dụ như lớp tương tác WTP (Wireless Transaction Protocol) của thiết bị đầu cuối sẽ liên lạc với lớp WTP của hạ tầng mạng. Các thành tố của tiêu chuẩn WAP bao gồm: Phần hỗ trợ vật mang: Xóa bỏ sự khác biệt về các giao thức báo hiệu và kênh của các mạng không dây khác nhau trên thế giới. Các giao thức dịch vụ: Bao gồm các giao thức mang lại các dịch vụ khác nhau để truyền dữ liệu qua mạng không dây. Các dịch vụ này bao gồm bảo mật, đảm bảo độ tin cậy và đệm. Môi trường ứng dụng: Môi trường trình duyệt mạnh để hỗ trợ các loại ứng dụng khác nhau trên các loại máy đầu cuối khác nhau của các hãng sản xuất khác nhau. 2.5.2. Vật mang WAP Hiện nay, trên thế giới, có các loại hạ tầng mạng không dây như sau: Advanced Mobile Phone System (AMPS): Hạ tầng mạng thông tin di động tương tự, sử dụng phổ biến ở Bắc Mỹ. Cellular Digital Packet Data (CDPD): Dịch vụ truyền dữ liệu gói số tốc độ 19.2 Kbps, sử dụng công nghệ FDM, trong đó bên phát gửi các gói dữ liệu trên các tần số khác nhau. Sử dụng ở Mỹ và Canađa. IS-54/IS-136/ANSI-136: sử dụng công nghệ TDMA, phổ biến ở Mỹ và Canađa. IS-95 hay Code Division Multiple Access (CDMA): Công nghệ đa truy nhập theo mã do hãng Qualcomm phát triển và được sử dụng phổ biến ở Mỹ, Canađa và một phần Châu Á. Personal Digital Cellular (PDC): Cung cấp cả dịch vụ thoại và truyền số liệu. Sử dụng kết hợp cả TDM và FDM. Sử dụng rỗng rãi tại Nhật Bản. Personal Handy Phone System (PHS): Điện thoại cordless kỹ thuật số, sử dụng phổ biến ở Nhật Bản. Flex: Giao thức nhắn tin (paging) một chiều của hãng Motorola. Giao thức ReFlex cho phép nhắn tin hai chiều. Global System for Mobile Communications (GSM): Tiêu chuẩn thông tin di động ở tần số 800-900 MHz, sử dụng rộng rãi ở Châu Âu, Úc và Châu Á. Sử dụng kết hợp cả TDM và FDM. Tại Mỹ, GSM sử dụng ở tần số khác và thường được biết tới với tên gọi DCS 1800 (tần số 1800MHz) và PCS 1900 (tần số 1900MHz). Các tiêu chuẩn hạ tầng mạng thông tin di động mới như EDGE, GPRS và UMTS. Như vậy là WAP có thể chạy trên nền của dịch vụ SMS, thông tin di động chuyển mạch kênh như GSM hoặc chuyển mạch gói như CDPD, GPRS. Để có thể xóa bỏ sự khác biệt của các vật mạng khác nhau như trên, sử dụng các giao thức (bearer protocol) khác nhau, WAP sử dụng lớp thấp nhất - Wireless Datagram Protocol (WDP). Dịch vụ WDP là dịch vụ truyền cho phép một đầu của mạng gửi thông điệp tới đầu bên kia của mạng. Dịch vụ này không đảm bảo độ tin cậy, tính bảo mật, thứ tự cũng như thời gian dữ liệu tới đích. Thay vào đó, các dịch vụ này sẽ do các lớp trên đảm nhận. Do các vật mạng khác nhau cung cấp các dịch vụ khác nhau nên WDP là một tập hợp các giao thức. Mỗi khi một ứng dụng nào đó gửi thông điệp qua bộ giao thức WAP, một giao thức WDP riêng sẽ được sử dụng, tùy thuộc vào giao thức mạng của vật mang. Trong một số trường hợp, WDP sử dụng luôn giao thức mạng của vật mang để cung cấp dịch vụ, đặc biệt là đối với các mạng IP sử dụng giao thức UDP (User Datagram Protocol). Trong trường hợp này, các giao thức dịch vụ WAP sẽ được đóng gói vào các gói UDP/IP. Trong một số trường hợp khác, các giao thức mạng có thể có nhiều tính năng hơn WDP, ví dụ như đối với các kết nối chuyển mạch kênh có thêm tính năng đảm bảo thứ tự gói. Khi đó, WDP sẽ chỉ sử dụng các tính năng cần thiết của giao thức mạng và bỏ qua các tính năng khác. Tính năng đảm bảo thứ tự gói của chuyển mạch kênh sẽ được WDP bỏ qua và nhường cho các lớp trên đảm nhận nhằm tránh lặp tính năng có thể gây ra lãng phí băng thông. 2.5.3. Bộ giao thức WAP (WAP Protocol Stack) Bộ giao thức WAP có so sánh với bộ giao thức Internet được mô tả ở hình 2. Hình 2.12: Bộ giao thức WAP so sánh với bộ giao thức internet 2.5.4. Môi trường ứng dụng WAP, WML và WMLScript Môi trường ứng dụng WAP chính là “trình duyệt WAP”. Môi trường ứng dụng WAP bao gồm một bộ tiêu chuẩn xác định một nhóm các định dạng cho các nội dung thông tin và các chương trình ứng dụng có thể tải về máy đầu cuối cũng như cách thức để các máy chủ chạy chương trình ứng dụng có thể đưa các thông tin đó tới môi trường ứng dụng WAP. Các tiêu chuẩn này đã được tối ưu hóa để sử dụng cho các thiết bị đầu cuối có màn hình hiển thị nhỏ, hạn chế về khả năng điều khiển (bàn phím nhỏ, ít phím, không có chuột) cũng như hạn chế về bộ nhớ. Các tiêu chuẩn của môi trường ứng dụng WAP thường dựa trên môi trường ứng dụng Internet WEB với ngôn ngữ HTML cho nội dung thông tin, JavaScript cho các chương trình ứng dụng và XML cho các dữ liệu có cấu trúc. Nhưng các tiêu chuẩn này đã được tối ưu hóa và dành riêng cho các thiết bị đầu cuối và hạ tầng mạng không dây. Môi trường ứng dụng WAP độc lập hoàn toàn đối với các giao thức WAP và các tiêu chuẩn lớp của WAP. Thật vậy, một thiết bị đầu cuối WAP vẫn có thể tải các ứng dụng WAP trên một mạng IP băng rộng và ngược lại, một máy tính với đầy đủ bàn phím, chuột, màn hình, bộ nhớ lớn vẫn có thể chạy các ứng dụng WEB trên một mạng không dây băng thông hẹp. Tuy nhiên, trong môi trường ứng dụng WAP, người ta sử dụng ngôn ngữ đánh dấu không dây WML (Wireless Markup Language) cho nội dung thông tin và WMLScript cho các chương trình ứng dụng. Ngôn ngữ đánh dấu không dây WML là một dạng nội dung được thiết kế sử dụng đối với các thiết bị có màn hình nhỏ và không có cơ chế nhập số liệu (bàn phím và chuột) phức tạp. WML được thiết kế để cho phép các thiết bị đầu cuối thực hiện các thao tác xử lý sao cho giảm số lượng tương tác với mạng mà vẫn có thể nhận được nội dung thông tin trong quá trình truy cập thông tin. Kết hợp cùng với tiêu chuẩn Wireless Binary XML (WBXML), sử dụng để mã hóa văn bản WML, WML và WBXML tạo thành một bộ tiêu chuẩn dùng cho các mạng băng thông hẹp. Các đặc tính của WML: Cấu trúc văn bản theo kiểu “Deck of Cards”: Mối địa chỉ WML URL tham chiếu tới một văn bản, gọi là “deck”. Deck bao gồm nhiều trang, gọi là “card”. Mặc dù toàn bộ deck được tải về thiết bị đầu cuối, tại một thời điểm, chỉ có duy nhất một card được hiển thị tại thiết bị đầu cuối. Mô hình deck bao gồm nhiều card cho phép các trang màn hình kích thước nhỏ chứa nội dung thông tin được thu nhận trong một tương tác với mạng. Mô hình truy cập Intradeck và Interdeck: Mỗi card nằm trong một deck được ấn định một tên duy nhất. Do đó, mỗi lệnh truy cập có thể tham chiếu tới bất kỳ card nào trong cùng một deck hoặc tham chiếu tới card nằm trong deck khác. Hơn thế nữa, trình duyệt còn duy trì một ngăn lịch sử, một danh sách theo kiểu LIFO (Last-in First-out: Vào sau ra trước) các card đã được người sử dụng truy cập trước đó. Các lệnh truy cập có thể gọi ngăn lịch sử để hiển thị các card đã truy nhập trước đó. Mô hình đệm (Caching): Đặc tính WAP xác định việc lưu trữ các văn bản WML trong bộ đệm của thiết bị đầu cuối. Khi chuyển một văn bản WML tới thiết bị đầu cuối, máy chủ sẽ thiết kế khoảng thời gian để văn bản đó được lưu trong bộ đệm của thiết bị đầu cuối một cách an toàn trước khi buộc phải bị làm tươi (refresh) từ máy chủ. Mô hình đệm này là hết sức cần thiết giống như giao thức HTTP trên mạng Internet để người sử dụng có thể xem ở chế độ off-line và giảm thời gian kết nối mạng. Giao tiếp người máy độc lập đối với các thiết bị khác nhau: Các thiết bị Mobile Internet có thể rất khác nhau về khả năng nhập dữ liệu từ việc sử dụng bàn phím với đầy đủ các phím của các thiết bị PDA đến một số phím tối thiểu của điện thoại di động hoặc là một hoặc hai phím của thiết bị nhắn tin. Để tránh phụ thuộc vào một loại thiết bị đầu cuối cụ thể, WML cung cấp mô hình giao tiếp người máy trừu tượng cho phép mỗi thiết bị đầu cuối lựa chọn phương thức tốt nhất để truy cập nội dung thông tin. Một số ví dụ về các tính năng của mô hình này: Các bộ đếm theo loại trình duyệt: WML deck có thể đặt các bộ đếm và thực hiện một hành động nào đó khi thời gian vượt quá giới hạn của bộ đếm. Các dạng vào dữ liệu: Người sử dụng có thể nhập dữ liệu theo một số cách khác nhau đối với WML trong đó bao gồm cách lựa chọn hoặc cách nhập văn bản. Khi mô tả một thực đơn (menu), WML có thể yêu cầu một mục của thực đơn tương ứng với một phím nhập nhất định. Ví dụ như mục đầu tiên của thực đơn tương ứng với phím “1”. Thiết bị đầu cuối sẽ tự động ấn định phím này dựa trên yêu cầu tạo ra bởi WML deck và khả năng thực tế của thiết bị đầu cuối đó. Các phím mềm: Các phím mềm là các phím ảo do các nhà lập trình WML tạo ra. WML xác định một số loại sự kiện bao gồm Accept, Prev, Help, Reset, Options và Delete. Khi nhận được văn bản WML, thiết bị đầu cuối sẽ ấn định các sự kiện trên tương ứng với các tác động vật lý vào các phím trên thiết bị đầu cuối đó. Bằng cách này thì giao tiếp với người sử dụng sẽ được thực hiện một cách hoàn toàn chủ động dựa vào năng lực của từng thiết bị đầu cuối. Mô hình quản lý trạng thái: Trình duyệt WML duy trì trạng thái động của các bộ thuộc tính - một cặp giá trị bao gồm tên của biến và giá trị tương ứng của biến đó. Các lệnh thực hiện trong văn bản WML có thể đọc hoặc viết các biến này. Một biến mới sẽ tự động được tạo ra khi được viết lần đầu tiên. Hơn thế nữa, WML còn cho phép thay thế theo thời gian thực các biến này vào các dòng văn bản hiển thị trên các thiết bị đầu cuối. Trạng thái này của trình duyệt cho phép truy cập thông tin một cách rất hiệu quả không những giữa các card trong một deck riêng lẻ mà còn giữa các deck. Màn hình hiển thị và ảnh: WML thừa kế rất nhiều nhãn (tags) của HTML để điều khiển việc hiển thị văn bản và ảnh. Các nhãn này bao gồm xuống dòng, bảng, chữ béo, chữ gạch chân, chữ nghiêng, font to, nhỏ. WML đồng thời còn hỗ trợ hiển thị ảnh dưới dạng WBMP (Wireless Bitmap) trên màn hình thiết bị đầu cuối. Ngôn ngữ WMLScript xác định dạng của các logic được tải về và chạy trên thiết bị đầu cuối. Các Script này có thể được sử dụng cho rất nhiều mục đích khác nhau: Kiểm tra tính hợp lệ của dữ liệu được nhập vào các trường WML. Lựa chọn và truy cập URL điều khiển bởi ứng dụng. Tạo ra đối thoại động với người sử dụng mà không cần kết nối mạng. Truy nhập vào các phụ kiện của thiết bị đầu cuối ví dụ như các tính năng điện thoại, SIM card. Cho phép tải về các chương trình ứng dụng hoặc các phần mềm như Screen Saver để chạy trên thiết bị đầu cuối. WMLScript dựa trên ECMAScript, một dạng Script dựa trên ngôn ngữ Netscape JavaScript và Microsoft Jscript. Tuy nhiên, WMLScript nhỏ hơn, đơn giản hơn ECMAScript và thêm vào các tính năng cho môi trường điện thoại di động. Khác với ECMAScript, WMLScript được xây dựng theo cú pháp mã byte xác định và WMLScript được dịch trước tại máy chủ trước khi tải về thiết bị đầu cuối WAP. Việc mã hóa nhị phân cho phép giảm băng thông mạng khi tải WMLScript về thiết bị đầu cuối. Đồng thời mã hóa nhị phân cũng cho phép giảm bộ nhớ cần thiết của thiết bị đầu cuối để lưa trữ WMLScript cũng như giảm tài nguyên vi xử lý để chạy WMLScript. Môi trường WMLScript bao gồm các thư viện như thư viện ngôn ngữ chính, thư viện dialog, thư viện giao tiếp trình duyệt. Các nhà sản xuất thiết bị đầu cuối, các nhà cung cấp trình duyệt cũng như các nhà lập trình có thể xác định những thư viện WMLScript của riêng mình. 2.5.5. WAP Push Một trong những khả năng của WAP đó là cho phép đưa các nội dung đến các thiết bị di động. Có hai cách để lấy nội dung về một thiết bị di động. Cách thứ nhất là “pull” có nghĩa là người dùng tự nguyện tải nội dung về máy khi họ duyệt WAP. Nói một cách khác có nghĩa là khi họ duyệt trang WAP mà gặp các nội dung có sẵn trên internet mà họ muốn tải về (tất nhiên là nội dung này được phép tải) thì họ sẽ tự nguyện tải nội dung về thiết bị di động, cách này được gọi là “pull” nghĩa quá trình tải được thiết lập bởi người dùng WAP. Tuy nhiên thế giới internet là vô cùng rộng lớn thế nhưng mỗi người lại chỉ cần một số thông tin nhất định ví dụ như Email, thông tin về thị trường chứng khoán. Vì thế có một cách khác để tải thông tin về đó là “push” nghĩa là quá trình tải được thiết lập bởi một nơi khác chứ không phải người dùng WAP. Một nội dung cần tải được gửi tới một thiết bị di động qua dưới dạng tin nhắn dịch vụ mà không nhất thiết thiết bị nhận tin nhắn đó có kết nối WAP hay không và người dùng có tải về không là tùy họ. Khi người dùng muốn tải thì thiết bị di động mới kết nối WAP để tải nội dung đó về. Tương ứng với 2 cách trên là 2 dạng WAP Push đó là SI (Service Indication) và SL (Service Loading). Service Loading Service Indication Nội dung được tự động chuyển về thiết bị di động Một tin nhắn dịch vụ dưới dạng thông báo cho gửi tới thiết bị di động Người dùng sẽ không thấy gì cả cho tới khi dịch vụ được tải bởi kỹ thuật pull Người dùng có thể tải nội dung hoặc không Không an toàn và hiện nay không còn hỗ trợ bởi các loại điện thoại mới. An toàn được dùng phổ biến trong các dịch vụ cung cấp nhạc chuông hình ảnh hiện nay. Bảng 2.5 : So sánh giữa WAP Push SL và SI 2.5.6. WTA (Wireless Telephony Applications) WTA là những ứng dụng cho phép tương tác với các chức năng của điện thoại trong khi duyệt WAP và chúng được cung cấp bởi các nhà cung cấp sóng điện thoại, hay chính xác hơn là WAP Gateway cung cấp những chức năng này. Việc lập trình cụ thể cho các chức năng này có thể tham khảo ở các tài liệu về lập trình WML và WAP. Sau đây là các chức năng hay dùng: Thực hiện cuộc gọi Nhận cuộc gọi Gửi và nhận tin nhắn Thêm, tìm kiếm hay xóa một địa chỉ trong danh bạ Ví dụ đoạn mã thực hiện cuộc gọi: <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//EN" ""> Nhap so dien thoai can goi: Kết quả hiện thị trên mà hình điện thoại: Hình 2.13: Thiết lập cuộc gọi từ trình duyệt WAP CHƯƠNG 3 XÂY DỰNG HỆ THỐNG MVAS (Mobile Value Added Service) Nội dung chương này đề cập đến những vấn đề chính sau: Giới thiệu hệ thống MVAS Thiết kế hệ thống MVAS Xây dựng hệ thống MVAS 3.1. Giới thiệu hệ thống MVAS là một hệ thống chương trình cho phép cung cấp dịch vụ nội dung cho các điện thoại di động. Hệ thống cho phép khách hàng có thể truy cập vào website để lấy các nội dung cũng như tra cứu thông tin. Hệ thống cho phép nhà cung cấp nội dung kết nối với các nhà cung cấp điện thoại di động để mở các dịch vụ cung cấp nội dung cũng như các cuộc thi, bình chọn. Hệ thống MVAS gồm 2 hệ thống con là: hệ thống Website(MVAS-WEB), hệ thống kết nối để xử lý gửi nhận tin nhắn(MVAS-SMS). Hệ thống dự kiến được xây dựng trên nền tảng ngôn ngữ java và cơ sở dữ liệu Oracle. Hệ thống Website được xây dựng trên nền tảng struts và jsp. Sau đây là biểu đồ phân cấp hệ thống: Hình 3.1: Biểu đồ phân cấp hệ thống MVAS 3.2. Thiết kế hệ thống 3.2.1. Mô hình hệ thống Mô hình hệ thống Hình 3.2: Mô hình hệ thống MVAS 3.2.2. Biểu đồ phân cấp chức năng Hình 3.3: Biểu đồ phân cấp chức năng hệ thống MVAS-WEB Hình 3.4: Biểu đồ phân cấp chức năng hệ thống MVAS-SMS 3.2.3. Chi tiết các chức năng Tên chức năng Loại Mô tả 1.1.1 Cung cấp thông tin về chủ đề nhạc chuông Web Form Hiển thị thông tin về chủ đề nhạc chuông 1.1.2 Cung cấp thông tin về tên và mã số nhạc chuông Web Form Hiển thị thông tin về tên và mã số nhạc chuông 1.2.1 Cung cấp thông tin về chủ đề hình nền Web Form Hiển thị thông tin về chủ đề hình nền 1.2.2 Cung cấp thông tin về tên và mã số hình nền Web Form Hiển thị thông tin về tên và mã số hình nền 1.3.1 Cung cấp thông tin về chủ đề Logo Web Form Hiển thị thông tin về chủ đề Logo 1.3.2 Cung cấp thông tin về tên và mã số Logo Web Form Hiển thị thông tin về tên và mã số Logo 1.4.1 Đăng ký tài khoản Web Form Cho phép người dùng đăng ký tài khoản trên Website 1.4.2 Đăng nhập, thoát khỏi hệ thống Web Form Đăng nhập và thoát khỏi hệ thống Website 2.1.1 Nhận tin nhắn từ số dịch vụ Web Service Nhận tin nhắn từ số dịch vụ 2.1.2 Gửi tin nhắn đến mô đun xử lý tin nhắn Service Gửi tin nhắn đã nhận đến mô đun xử lý tin nhắn 2.2.1 Kiểm tra tin nhắn Proccessing Program Kiểm tra tính hợp lệ của tin nhắn - Nếu tin nhắn là hợp lệ thì tạo ra nội dung được yêu cầu cung cấp. - Nếu tin nhắn không hợp lên thì tạo ra nội dung thông báo lỗi. 2.2.2 Cập nhật tin nhắn vào hệ thống Proccessing Program Sau khi kiểm tra tin nhắn thì cập nhật tin nhắn vào cơ sở dữ liệu của hệ thống để tiện cho việc tổng hợp kết quả và tính cước. Có hai loai tin nhắn là thành công và không thành công 2.2.3 Gửi nội dung tin nhắn trả lại đến Mô đun gửi tin nhắn Proccessing Program Gửi nội dung tin nhắn trả lại đên Mô đun gửi tin nhắn để gửi cho khách hàng 2.3.1 Gửi tin nhắn đến số dịch vụ WebService Gửi tin nhắn cần gửi đến khách hàng đến số dịch vụ của nhà cung cấp sóng điện thoại 2.3.2 Cập nhật tin nhắn đã gửi vào cơ sở dữ liệu của hệ thống Proccessing Program Cập nhật nội dung tin nhắn đã gửi cho khách hàng vào cơ sở dữ liệu của hệ thống để tiện cho việc theo dõi và đối chiếu. Bảng 3.1: Chi tiết các chức năng hệ thống MVAS Mã hóa chức năng chi tiết của hệ thống MVAS STT Tên chức năng Mã chức năng 1 Cung cấp thông tin về chủ đề nhạc chuông F001.01.01 2 Cung cấp thông tin về tên và mã số nhạc chuông F001.01.02 3 Cung cấp thông tin về chủ đề hình nền F001.02.01 4 Cung cấp thông tin về tên và mã số hình nền F001.02.02 5 Cung cấp thông tin về chủ đề Logo F001.03.01 6 Cung cấp thông tin về tên và mã số Logo F001.03.02 7 Đăng ký tài khoản F001.04.01 8 Đăng nhập, thoát khỏi hệ thống F001.04.02 9 Nhận tin nhắn từ số dịch vụ F002.01.01 10 Gửi tin nhắn đến mô đun xử lý tin nhắn F002.01.02 11 Kiểm tra tin nhắn F002.02.01 12 Cập nhật tin nhắn vào hệ thống F002.02.02 13 Gửi nội dung tin nhắn trả lại đến Mô đun gửi tin nhắn F002.02.03 14 Gửi tin nhắn đến số dịch vụ F002.03.01 15 Cập nhật tin nhắn đã gửi vào cơ sở dữ liệu của hệ thống F002.03.02 Bảng 3.2: Mã hóa các chức năng 3.2.4. Thiết kế cơ sở dữ liệu Các bảng trong cơ sở dữ liệu SUBJECT_RINGTONE (Chủ đề nhạc chuông) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không SUBJECT_NAME VARCHAR (50) Không Không Bảng 3.3: Chủ đề nhạc chuông RINGTONE (Nhạc chuông) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không RING_NAME VARCHAR (100) Không Không RING_DATA VARCHAR (100) Không Không RING_FILE VARCHAR (100) Không Không RING_CODE VARCHAR (10) Không Không NUM_DOWNLOAD NUMERIC(10,0) Không Không DATE_UPDATE DATE Không Không Bảng 3.4: Nhạc chuông SUBJECT_IMAGE (Chủ đề hình ảnh) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không SUBJECT_NAME VARCHAR (50) Không Không Bảng 3.5: Chủ đề hình ảnh IMAGE (Hình ảnh) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không IMG_FILE VARCHAR (100) Không Không IMG_CODE VARCHAR (10) Không Không NUM_DOWNLOAD NUMERIC(10,0) Không Không DATE_UPDATE DATE Không Không Bảng 3.6: Hình ảnh SUBJECT_LOGO (Chủ đề Logo) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không SUBJECT_NAME VARCHAR (50) Không Không Bảng 3.7: Chủ đề Logo LOGO (Logo) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SUBJECT_TYPE INTEGER Không Không LG_FILE VARCHAR (100) Không Không LG_CODE VARCHAR (10) Không Không NUM_DOWNLOAD NUMERIC(10,0) Không Không DATE_UPDATE DATE Không Không Bảng 3.8: Logo SMS_TYPE (Kiểu tin nhắn) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SMS_TYPE INTEGER Không Không TYPE_DETAIL VARCHAR (200) Có Không Bảng 3.9: Kiểu tin nhắn SMS_IN (Tin nhắn yêu cầu) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID NUMERIC(12,0) Không Có TEL_IN VARCHAR(15) Không Không TEL_SER VARCHAR (15) Không Không FULLSMS VARCHAR (160) Có Không TIME_RE DATE Không Không ORDER NUMERIC(11,0) Không Không SMS_TYPE INTEGER Không Không SUCCESS BIT Không Không Bảng 3.10: Tin nhắn nhận SMS_OUT (Tin nhắn gửi khách hàng) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID NUMERIC(12,0) Không Có TEL_OUT VARCHAR(15) Không Không TEL_SER VARCHAR (15) Không Không FULLSMS VARCHAR (160) Có Không TIME_SE DATE Không Không ORDER NUMERIC(11,0) Không Không SMS_TYPE INTEGER Không Không Bảng 3.11: Tin nhắn gửi KEY_SCE (Từ khóa kịch bản) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có KEY_WORD VARCHAR(10) Không Không NAME_SCE VARCHAR (200) Không Không START_DATE DATE Có Không END_DATE DATE Có Không SCE_RULE VARCHAR(15) Không Không TEL_SER INTEGER Không Không LIMITED BIT Không Không Bảng 3.12: Từ khóa kịch bản PAR_SCE (Tham số kịch bản) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có ID_SCE INTEGER Không Không PARAMETER INTEGER Không Không NUM_VALUE INTEGER Không Không Bảng 3.13: Tham số kịch bản PAR_VALUE (Giá trị tham số kịch bản) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID_PARA INTEGER Không Có VAUE VARCHAR(20) Không Không PRE_RE VARCHAR(100) Không Không MID_RE VARCHAR(100) Không Không POS_RE VARCHAR(100) Không Không Bảng 3.14: Giá trị tham số kịch bản RESULT (Kết quả dịch vụ bình chọn) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có SCE_ID INTEGER Không Không ID_MES NUMERIC(11,0) Không Không PRICE_NAME VARCHAR(100) Không Không PRICE_VALUE VARCHAR(100) Không Không CUSTOMER_TEL VARCHAR(15) Có Không CUSTOMER_NAME VARCHAR(100) Có Không CUSTOMER_ADDRESS VARCHAR(200) Có Không Bảng 3.15: Kết quả dịch vụ bình chọn USER_INFO (Thông tin người sử dụng) Tên trường Kiểu dữ liệu Cho phép để trắng Khóa chính Ghi chú ID INTEGER Không Có USERNAME VARCHAR(32) Không Không PASSWORD VARCHAR(32) Không Không EMAIL VARCHAR(50) Có Không BIRTH_DATE DATE Có Không TEL VARCHAR(15) Có Không SERCRET_QUESTION VARCHAR(100) Có Không SECRET_ANSWER VARCHAR(200) Có Không ACOUNT NUMBER(13,0) Không Không Bảng 3.16: Thông tin người sử dụng Mô hình quan hệ giữa các bảng Hình 3.5: Cơ sở dữ liệu hệ thống Xây dựng cơ sở dữ liệu đã thiết kế trên cơ sở dữ liệu Oracle Hệ thống MVAS dự định sẽ xây dựng là một hệ thống lớn còn mở rộng trong tương lai. Hệ thống được xây dựng trên nền tảng ngôn ngữ lập trình java chính vì thế cơ sở dữ liệu được lựa chọn để xây dựng là Oracle 9i. Sau đây là một số so sánh với các cơ sở dữ liệu khác. TT Các Tiêu chí SQL SERVER DB2 ORACLE 1 Tính phổ dụng ở thị trường Việt Nam Cao Thấp Cao 2 Hệ thống đào tạo & Bảo hành - bảo trì - dịch vụ đi kèm TB Cao Cao 3 Quy mô dữ liệu (đạt hiệu quả cao) Thấp. Vài chục ngàn bản ghi . Cao. Hàng triệu bản ghi Cao. Hàng triệu bản ghi 4 Có công cụ phân tích & thiết kế ứng dụng Không Không Có ( Rất hiện đại) 5 Kết nối với Cơ sở dữ liệu Phải qua ODBC hayADO. Tốc độ truy xuất CSDL bị hạn chế Trực tiếp. Tốc độ tốt Trực tiếp qua SQL Net Tốc độ tốt 6 Platform (cơ sở hạ tầng) Kém Phát triển trên nền tảng công nghệ INTEL - WINDOWNT không ổn định Khá PC SERVER, AS400, OS2 Tốt Multi platform: NT, UNIX, PC SERVER RS/6000, SUN, HP... 7 An toàn và bảo mật dữ liệu Thấp ( Thông qua hệ điều hành WINDOWNT) Cao thông qua hệ điều hành OS400 Cao ( Cơ chế bảo mật tới từng bản ghi trong table) 8 Khả năng giải quyết các bài toán dữ liệu phân tán TB Cao Cao 9 Giá thành TB Có nhiều lựa chọn Có nhiều lựa chọn 10 Khả năng nâng cấp Thấp ( chỉ nâng cấp được cấu hình phần cứng) Thấp Cao ( nâng cấp được cơ sở dữ liệu mà không ảnh hưởng dữ liệu; nâng cấp cả phần cứng Bảng 3.17: So sánh giữa cơ sở dữ liệu DB2, MS SQL Server, Oracle 3.3. Xây dựng hệ thống MVAS 3.3.1. Xây dựng hệ MVAS-WEB Hệ thống MVAS-WEB là hệ thống Website được xây dựng trên nền tảng ngôn ngữ java, Tomcat WebServer và cơ sở dữ liệu Oracle. Khi sử dụng ngôn ngữ java mà cụ thể là các trang jsp xây dựng ứng dụng Web thì chúng ta có hai kiến trúc để lựa chọn sau đây: Kiến trúc 1: Kiến trúc 1 là đơn giản, một yêu cầu được gửi đến trang jsp hoặc servlet sau đó trang jsp hay servlet sẽ xử lý và trả lại kết quả yêu cầu. Kiến trúc này dễ xây dựng nhưng gặp khó khăn khi mà lôgic nghiệp vụ trở nên phức tạp. Hình 3.6: Kiến trúc 1 Kiến trúc 2: Kiến trúc 2 được sử dụng khá phổ biến hiện nay, nó còn được gọi dưới cái tên MVC (Model-View-Controller). Kiến trúc này giải quyết được rất nhiều vấn đề phức tạp mà kiến trúc 1 không giải quyết được bằng việc chia thành các phần ứng dụng rất rõ ràng. Phần Controller là Servlet, phần View là jsp và Model là phần logic nghiệp vụ. Tiêu biểu cho kiến trúc này là struts. Hình 3.7: Kiến trúc MVC Với 2 mô hình trên thì chúng ta ứng dụng kiến trúc 1 vào việc xây dựng trang hiện thị các nội dung cung cấp, còn kiến trúc 2 (MVC) vào xây dựng chức năng đăng nhập hệ thống và gửi nội dung từ trang Web. Hệ thống cung cấp thông tin nội dung xây dựng bằng các trang jsp kết hợp với java bin, còn hệ thống đăng nhập và gửi thông tin từ web được xây dựng bằng struts. Xây dựng Website cung cấp nội dung Hệ thống website hiện thị nội dung cung cấp bao gồm các thành phần sau: Trang chủ, ringtone.jsp, image.jsp, logo.jsp. Trang chủ: Mục đích giới thiệu những nhạc chuông, hình nền, logo mới nhất. Hình 3.8: Trang chủ hệ thống web ringtone.jsp: Mục đích là giới thiệu về nhạc chuông theo chủ đề. Hình 3.9: Trang web ringtone.jsp Màn hình chức năng nghe thử nhạc chuông từ web: Hình 3.10: Màn hình chức năng nghe thử nhạc chuông image.jsp: Mục đích là giới thiệu về hình nền theo chủ đề Hình 3.11: Trang web image.jsp logo.jsp: Mục đích là giới thiệu về logo theo chủ đề. Hình 3.12: Trang web logo.jsp Phần đăng nhập và gửi nội dung từ web vẫn nằm trong các trang web trên nhưng thêm phần đăng nhập và kiểm tra đăng nhập. Muốn gửi nội dung thì phải đăng ký là thành viên của website và phải đăng nhập hệ thống. Phần này bao gồm những trang chính sau: register.jsp Hình 3.13: Đăng ký tài khoản người dùng changeUserInfo.jsp Hình 3.14: Thay đổi thông tin cá nhân sendringtone.jsp Hình 3.15: Gửi nhạc chuông từ trên web sendwallpaper.jsp Hình 3.16: Gửi hình nền từ trên web sendlogo.jsp Hình 3.17: Gửi logo từ trên web 3.3.2. Xây dựng hệ MVAS-SMS Do chưa xin cấp được một số dịch vụ trên tổng đài SMSC của các nhà cung cấp sóng di động chính vì thế hệ MVAS-SMS sẽ được xây dựng mô phỏng bằng cách sử dụng phần mềm NowSMS Gateway làm SMS Gateway và điện thoại Nokia 6100 kết nối với máy tính qua cổng USB làm tổng đài SMSC ảo. Sau đây sẽ là chi tiết cụ thể các phần của hệ thống MVAS-SMS: NowSMS Gateway Cài đặt NowSMS Để cài đặt NowSMS thì trước hết cần download bộ cài từ địa chỉ web sau: rồi cài đặt theo hướng dẫn. Sử dụng NowSMS Thiết lập kết nối đến SMSC NowSMS đòi hỏi phải kết nối đến một SMSC để giao tiếp với mạng SMS. Một kết nối SMSC có thể là một trong các loại sau đây: GSM Modem – Một GSM modem hoặc một điện thoại di động kết nối với máy tính qua cổng COM, USB, hồng ngoại hoặc Bluetooth và được cài đặt modem driver thích hợp. Trong trường hợp này điện thoại Nokia 6100 được kết nối với máy tính qua cổng USB và được hiểu là cổng COM4 Hình 3.18: Kết nối điên thoại Nokia 6100 với máy tính thông qua NowSMS SMPP (Short Message Peer to Peer Protocol) – Một kết nối TCP/IP qua mạng internet hoặc mạng nội bộ tới dịch vụ hỗ trợ giao thức SMPP version 3.3 hoặc 3.4 UCP/EMI (Universal Computer Protocol / External Machine Interface) – Một kết nối TCP/IP qua mạng internet hoặc mạng nội bộ tới dịch vụ hỗ trợ giao thức UCP/EMI version 3.5 hoặc 4.0  CIMD2 (Computer Interface to Message Distribution, version 2) – Một kết nối TCP/IP qua mạng internet hoặc mạng nội bộ tới dịch vụ hỗ trợ giao thức CIMD2. CIMD2 thiết lập bởi các loại Nokia SMSC. HTTP (Hyper Text Transport Protocol, giao thức chuẩn cho “web”) – Một kết nối TCP/IP qua đường internet hoặc đường nối riêng tới dịch vụ chấp nhận gửi nhận tin nhắn SMS qua giao thức HTTP dựa trên phương thức “GET”. Chạy như một Web Service Trong môi trường Windows thì Service này sẽ tự khởi động cùng với hệ điều hành. Service này chạy ở địa chỉ mặc định là chúng127.0.0.1 và cổng 8800. Khi một request hợp lệ đến Service này nó sẽ thực hiện gửi tin nhắn tương ứng đến SMSC thông qua giao diên HTTP tương tự như phần mềm Kannel. Để chọn cho Service này chạy ta cần chọn trong tab Service của giao diện chương trình NowSMS như hình vẽ sau: Hình 3.19: Thiết lập WebService cho NowSMS Hỗ trợ 2 chiều SMS Đây là chức năng cho phép khi một tin nhắn được gửi đến thì NowSMS sẽ tự động gọi một chương trình hoặc một HttpRequest để xử lý tin nhắn đó và sẽ gửi trả lại một tin nhắn văn bản có nội dung là những gì chương trình đó hiện thị ra màn hình hoặc là response của HttpRequest. Trong đề tài này khi một tin nhắn được gửi đến nó sẽ gọi một lớp java để xử lý có tên là SMSProcess. Hình 3.20: Thiết lập chức năng gọi mô đun xử lý tin nhắn cho NowSMS Chương trình xử lý tin nhắn (SMS Process) Quy tắc xử lý tin nhắn có cú pháp: Các tin nhắn hợp lệ NHAC X: Tải nhạc chuông có mã số là X NHAC X Y: Gửi tặng nhạc chuông có mã số là X đến số điện thoại Y HINH X: Tải hình ảnh có mã số là X HINH X Y: Gửi tặng hình ảnh có mã số là X đến số điện thoại Y LOGO X: Tải logo có mã số là X LOGO X Y: Gửi tặng hình ảnh có mã số là X đến số điện thoại Y Nếu tin nhắn gửi đến là đúng các trường hợp trên thì gửi lại khách hàng nội dung tương ứng. Cụ thể như sau: Nếu yêu cầu là nhạc chuông đơn âm hay logo thì sẽ gửi lại cho khách hàng nhạc chuông đơn âm hay logo dưới dạng smart sms. Nếu yêu cầu là nhạc chuông đa âm hay hình ảnh thì gửi trả lại cho khách hàng một thông báo dưới dạng WAP Push. Nội dung yêu cầu sẽ do khách hàng tự tải về. Điều này đòi hỏi điện thoại của khách hàng phải truy cập được WAP thông qua GPRS. Các trường hợp còn lại tin nhắn bị coi là không hợp lệ. Các tham số đầu vào của chương trình SENDER: Số điện thoại người gửi REP: Số dịch vụ FULLSMS: Nội dung tin nhắn gửi đến Lập trình socket: Cần sử dụng socket để gửi yêu cầu qua giao thức HTTP đến NowSMS Gateway Service. Sử dụng socket với java: socket = new Socket(host, port); OutputStream os = socket.getOutputStream(); boolean autoflush = true; PrintWriter out = new PrintWriter(socket.getOutputStream(), autoflush); out.println(string); Trong đó host và post là địa chỉ và cổng cần kết nối qua socket, string là chuỗi yêu cầu cần gửi đến. Ví dụ string = “GET ? Data=" + Data + Submit = Submit + Query & Binary = 1 & PID = 0 & DCS = F5 & UDH=" + UDH + "&PhoneNumber" + tel Hàm gửi tin nhắn văn bản Tham số: tel: Số điện thoại người nhận text: nội dung tin nhắn văn bản cần gửi //Send Text message public static void SendTextSMS(String tel,String text){ Socket socket = null; try { socket = new Socket("127.0.0.1", 8800); OutputStream os = socket.getOutputStream(); boolean autoflush = true; PrintWriter out = new PrintWriter(socket.getOutputStream(), autoflush); out.println("GET ?=&PhoneNumber=" + tel + "&Text=" + text); out.println(); } catch (IOException ex) { System.out.print(ex.toString()); } } Hàm gửi tin nhắn WAPPush Tham số: tel: số điện thoại người nhận stringURL: chuỗi chỉ ra đường dẫn WAPPush tilte: chuỗi ký tự tiêu đề gửi kèm public static void sendWapPush(String tel, String stringURL, String title) { Socket socket = null; try { socket = new Socket("127.0.0.1", 8800); OutputStream os = socket.getOutputStream(); boolean autoflush = true; PrintWriter out = new PrintWriter(socket.getOutputStream(), autoflush); out.println("GET ?WAPSL=&PhoneNumber=" + tel + "&WAPURL=" + stringURL + "&Text=" + title + "&WAPSIACTION=signal-medium&WAPSIID=&WAPSICREATED=&WAPSIEXPIRES="); out.println("Connection: Close"); out.println(); } catch (IOException ex) { System.out.print(ex.toString()); } } Hàm gửi tin nhắn nhị phân Tham số: tel: số điện thoại người nhận Data: dữ liệu cần gửi typebirmes: loại dữ liệu cần gửi; 1: ringtone, 2:logo Nếu dữ liệu cần gửi là ringtone thì UDH = 06050415811581 Nếu dữ liệu cần gửi là logo thì UDH = 06050415821582 Khi gửi dữ liệu là logo thì có 2 tham số cần quan tâm đó là: Mobile Country Code (MCC): MCC của Việt nam là 452 Mobile Network Code (MNC): MNC của mạng mobifone là 01, vinafone là 02, vietel là 04 Mã nước và mã mạng có thể tra cứu trên internet. //Send Binary SMS public static void sendBinaryMess(String tel, String Data, int typebirmes) { Socket socket = null; try { socket = new Socket("127.0.0.1", 8800); OutputStream os = socket.getOutputStream(); boolean autoflush = true; PrintWriter out = new PrintWriter(socket.getOutputStream(), autoflush); if (typebirmes == 1) { //Send ringtone out.println("GET ?Data=" + Data + "&Binary=1&PID=0&DCS=F5&UDH=06050415811581" + "&PhoneNumber=" + tel); } else if (typebirmes == 2) { //Send logo String Data1 = new String(); //Data to send String MNC = new String(); //Nokia Network code if (tel.charAt(2) == '0') { MNC = "01"; } else if (tel.charAt(2) == '1') { MNC = "02"; } else if (tel.charAt(2) == '8') { MNC = "04"; } if (Data.length() == 260) { Data1 = "54F2" + MNC.charAt(1) + MNC.charAt(0) + Data; } else { Data1 = "3054F2" + MNC.charAt(1) + MNC.charAt(0) + "0A" + Data; } System.out.println(Data1); System.out.print(MNC); out.println("GET ?Data=" + Data1 + "&NokiaMCC=452&NokiaMNC=" + MNC + "&NokiaBitmapData=" + Data + "&Binary=1&PID=0&DCS=F5&UDH=06050415821582" + "&PhoneNumber=" + tel); } out.println("Connection: Close"); out.println(); } catch (IOException ex) { System.out.print(ex.toString()); } } KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN Kết quả đạt được Đồ án này đã thực hiện được những vấn đề cơ bản sau: Cơ sở lý thuyết để xây dựng các dịch vụ giá trị gia tăng trên điện thoại di động mạng GSM bao gồm: SMS, giao thức SMPP, SMS Gateway, WAP Xây dựng hệ thống MVAS cung cấp các dịch vụ nội dung như: nhạc chuông, hình nền, logo. Hệ thống bao gồm: hệ thống website và mô đun kết nối gửi, nhận và xử lý tin nhắn. Hướng phát triển Dịch vụ giá trị gia tăng trên di động là một trong những vấn đề đã, đang và còn phát triển mạnh mẽ trong tương lai. Đồ án này mới nghiên cứu được những lý thuyết, giao thức cơ bản để xây dựng dịch vụ giá trị gia tăng và xây dựng một chương trình ứng dụng cung cấp dịch vụ nội dung. Ứng dụng này còn có khả năng mở rộng trong tương lai và ứng dụng mô hình vào nhiều vấn đề khác. Các hướng phát triển tiếp theo: Xây dựng và hoàn thiện chức năng admin cho hệ thống. Chức năng này cho phép các nhà cung cấp nội dung có thể quản lý nội dung cung cấp của mình trực tiếp từ Website. Dịch vụ bình chọn qua tin nhắn sẽ là một dịch vụ tồn tại rất lâu và luôn hấp dẫn, tuy nhiên hiện nay khi muốn tạo mới một kịch bản đòi hỏi nhà cung cấp phải phát triển mô đun xử lý mới cũng như phải thêm cơ sở dữ liệu. Chính vì thế một hướng mới đặt ra là xây dựng một hệ thống cho phép tạo lập kịch bản từ trên website mà không phải phát triển mô đun xử lý mới. Việc tin nhắn có thể được gửi nhận từ điện thoại hay SMSC qua máy tính cho phép chúng ta xây dựng các ứng dụng khai thác các cơ sở dữ liệu có sẵn như: Hệ thống quản lý học sinh cho phép phụ huynh tra cứu và nhận kết quả học tập của con em mình qua tin nhắn. Khai thác các cơ sở dữ liệu có sắn của doanh nghiệp dựa trên việc gửi nhận tin nhắn. Xây dựng các ứng dụng thương mại, việc giao dịch thông qua gửi nhận tin nhắn hay truy cập WAP. Tìm hiểu xây dựng các dịch vụ giá trị gia tăng cho mạng điện thoại CDMA. TÀI LIỆU THAM KHẢO [1] SMS Forum. “Short Message Peer-to-Peer Protocol Specification Version 5.0” (www.smsforum.net) [2] SMS Forum. “Short Message Peer-to-Peer Protocol Specification Version 3.4” (www.smsforum.net) [3] Laxxuss. “Proffesional WAP 2000”. Wrox [4] www.nowsms.com [5] www.kannel.com [6] Nokia. “Smart messaging specification” [7] James Holmes “Struts: The Complete Reference” . McGraw-Hill/Osborne