Hình 5. 3 Kết nối của Module SMS với SMS Gateway
Main program Sms Auto_run Config.txtcmd(s) Sms IM-CMD Auto_run(Sms) cmd.autorun(Sms) SMS Gateway Send(sodt, text) Service INTERNET Import Sms HTTP MODULE SMS ServiceService
Main Program
Là chương trình chính chạy đầu tiên. Import sms từ class SMS
SMS
Là class chuyển gửi các yêu cầu nhắn tin tới SMS Gateway trên giao thức HTTP, đóng vai trò như là cổng kết nối của Module SMS.
Auto_run
Là một luồng tự động chạy nhận biến sms từ Main program.
Đọc từng dòng của file config.txt lấy ra tên dịch vụ có chế độ tự động chạy. Gọi hàm cmd.autorun(sms).
IM-CMD
Là một giao diện (interface) cung cấp hàm chính auto_run. Các dịch vụ phải thực thi giao diện này.
Gửi thông tin về người nhận tin nhắn: số điện thoại, nội dung tin nhắn tới cho class
SMS thông qua hàm send(sodt, text).
Nhacviec
Là một dịch vụ của module sms, truy cập vào Internet lấy dữ liệu, thông tin về người nhận tin nhắn.
5.4.2. Tiến trình thực hiện
Chương trình chính khi khởi động sẽ tự động Import sms từ đối tượng SMS và truyền biến này cho Auto_run.
Tiến trình Autorun sẽ được kích hoạt trong chương trình chính. Khi khởi động, tiến trình Autorun sẽ đọc file config.txt. Trong file config.txt này sẽ liệt kê các dịch vụ muốn thực hiện chế độ chạy tự động.
Tiến trình Autorun sẽ lần lượt gọi dịch vụ này thông qua hàm autorun(sms). (là một hàm trong giao diện IMCMD). Với sms là một thể hiện (instance) của SMS. Hàm
auto_run của dịch vụ sẽ tự xử lý dữ liệu (bằng nhiều cách) sau đó gửi tin nhắn thông qua biến sms.
Đa phần các dịch vụ cung cấp chế độ chạy tự động (autorun) đều không tự động xử lý dữ liệu. Bởi vì nếu tự xử lý dữ liệu thì sẽ rất tốn tài nguyên. Vì vậy, việc xử lý và lưu trữ dữ liệu đều được thực hiện ở hệ thống bên ngoài (có thể làm một nhà cung cấp dịch vụ nào đó hoặc tự xây dựng các hàm cung cấp dịch vụ).
CHƯƠNG 6. CÁC DỊCH VỤ CUNG CẤP
6.1. Dịch vụ Chấp nhận/ Từ chối
Khi một người nào đó muốn thêm một nick của người khác vào danh sách bạn (FriendList) của họ (ví dụ người A muốn thêm người B vào danh sách bạn). Một tin nhắn từ TCat sẽ gửi đến nick của người B. Nội dung tin nhắn yêu cầu người B xác thực lại thông tin trên. Nếu người B chấp nhận nhận tin nhắn do người A gửi thì người B gửi lại cho TCat tin nhắn chấp nhận, nếu không muốn thì gửi tin nhắn từ chối.
6.1.1. Thiết kế CSDL
Trong phần thiết kế CSDL của chương bốn có một bảng là Friend. Trong bảng đó có trường ba trường Accept_Y, Accept_G, Accept_M. Các trường Accept_Y, Accept_G, Accept_M với ý nghĩa người bạn này có đồng ý nằm trong danh sách bạn hay không? Nếu người này đồng ý thì trường Accept_Y, Accept_G, Accept_M có giá trị là 1. Ba trường này tương đương với việc đồng ý trên Yahoo, GoogleTalk, Mobile. Nếu không đồng ý thì ba trường này sẽ có giá trị là 0. Mặc định giá trị đầu tiên là -1. Điều này có nghĩa là lần đầu tiên, nếu muốn nhận tin nhắn, người này phải xác nhận (vì ba trường đều khác 1). Giá trị -1 mang ý nghĩa chưa gửi tin nhắn xác nhận cho các nick đó.
Cơ chế này nhằm mục đích tránh tình trạng spam tin nhắn. Giả sử một kẻ xấu muốn lợi dụng TCat để spam tin nhắn cho một cá nhân nào đó. Nếu không có cơ chế yêu cầu chấp nhận hoặc từ chối này thì mục đích của kẻ xấu sẽ thành hiện thực.
Thêm một điều nữa trong bảng Friend, đó là việc một người chỉ được thêm một người khác vào danh sách bạn một lần. Điều này cũng giúp tránh tình trạng spam tin nhắn. Hình dưới mô tả mối quan hệ giữa hai bảng Friend và User
6.1.2. Hoạt động
Dịch vụ này muốn hoạt động tốt thì cần có sự phối hợp giữa các module IM, SMS với WEB. Cơ chế của việc này như sau.
Các module IM, SMS chạy phía Client tạm gọi là các con bot. Các con bot này cứ trong một khoảng thời gian t sẽ gửi yêu cầu lấy danh sách các nick cần gửi tin nhắn. Dịch vụ bên phía Web sẽ kiểm tra CSDL, nếu có bản ghi thỏa mãn (trường accept_y, accept_g, accept_m tương ứng với ba dịch vụ là Yahoo, GoogleTalk hoặc di động bằng -1) thì lấy nick tương ứng ra, đưa vào một danh sách. Sau đó gửi trả lại con bot danh sách đó. Con bot căn cứ vào danh sách nhận được sẽ gửi tin nhắn đến các nick trong danh sách. Nội dung tin nhắn là việc hỏi người sử dụng có xác nhận hay không. Theo mô tả trên thì dịch vụ chấp nhận/ từ chối này phải có một hàm auto_run dùng để kiểm tra các nick chưa được hỏi vì dịch vụ này thuộc dạng chủ động. Người được hỏi không tương tác trực tiếp với con bot.
Để xác nhận đồng ý nhận tin nhắn, người sử dụng nhắn tin lại với cú pháp sau:
/accept [nick trên web của người gửi]
Ví dụ, một người có nick là user1 trên trang web của TCat muốn thêm một người bạn có nick yahoo là friend_u1_yahoo. Sau khi thực hiện thao tác thêm bạn trên trang web, một lát sau thì người bạn có nick yahoo là friend_u1_yahoo sẽ nhận được một lời nhắn từ TCat yêu cầu xác nhận. Khi đó người có nick friend_u1_yahoo muốn đồng ý, chỉ cần nhắn lại tin như sau:
/accept user1
Cơ chế của việc này như sau, khi nhận được tin nhắn /accept user1. Con bot sẽ phân tích cú pháp của tin nhắn đó. Dịch vụ được gọi lên là dịch vụ accept và tham số đưa vào là user1. Con bot sẽ gọi dịch vụ accept trong thư viện dịch vụ tương ứng. Dịch vụ accept làm nhiệm vụ gửi một thông điệp theo giao thức HTTPS, thông điệp này thông báo cho WEB biết dịch vụ cần gọi, mã số của con bot và nick của người dùng ra lệnh thêm bạn. Việc còn lại là ở phía WEB. WEB sẽ thay đổi giá trị trường AcceptX và trường SendX cho phù hợp sau đó gửi trả lại một thông báo là quá trình thay đổi thành công hay thất bại.
/reject user1
Cơ chế của việc này cũng tương tự như việc accept. khi nhận được tin nhắn /reject user1. Con bot sẽ phân tích cú pháp của tin nhắn đó. Dịch vụ được gọi lên là dịch vụ reject và tham số đưa vào là user1. Con bot sẽ gọi dịch vụ reject trong thư viện dịch vụ tương ứng. Dịch vụ reject làm nhiệm vụ gửi một thông điệp theo giao thức HTTPS, thông điệp này thông báo cho WEB biết dịch vụ cần gọi, mã số của con bot và nick của người dùng ra lệnh thêm bạn. Việc còn lại là ở phía WEB. WEB sẽ thay đổi giá trị trường AcceptX và trường SendX cho phù hợp sau đó gửi trả lại một thông báo là quá trình thay đổi thành công hay thất bại.
6.2. Dịch vụ Người dùng tự định nghĩa
Sẽ rất tuyệt khi người sử dụng có thể tự tạo dịch vụ của riêng mình chỉ với vài thao tác nhỏ. Dịch vụ người dùng tự định nghĩa cung cấp cơ chế giúp người sử dụng tạo ra cho chính họ một dịch vụ đơn giản. Dịch vụ này sẽ có một giao diện phía web giúp người sử dụng thuận tiện trong việc thêm dịch vụ. Mã của dịch vụ là udef. Dịch vụ này thuộc kiểu dịch vụ bị động, có nghĩa là chỉ trả lời khi có yêu cầu từ người khác. Thực chất của dịch vụ này là việc lấy thông tin từ trang web do người dùng cung cấp, vì thế khi sử dụng dịch vụ này, yêu cầu với người sử dụng là cần có một ít kiến thức lập trình web. Có thể bằng ngôn ngữ nào cũng được. Và họ phải upload trang web đó lên một web site nào đó để cho TCat có thể kết nối đến.
6.2.1. Thiết kế CSDL
Bảng udef gồm các trường sau
- keywork: từ khóa cho dịch vụ của bạn. Từ khóa là duy nhất và không được trùng, người sử dụng có thể tạo nhiều dịch vụ, nhưng các dịch vụ phải khác nhau về từ khóa và phải khác từ khóa của người khác.
- Link: Liên kết cần kết nối tới. Khi tạo một dịch vụ theo kiểu người dùng tự định nghĩa như thế này. Người sử dụng cần có một liên kết đến trang chứa thông tin của họ. Hoạt động của dịch vụ này thực chất là việc lấy nội dung từ trang chứa thông tin đó và trả lại cho người yêu cầu dịch vụ.
Hình dưới mô tả mối quan hệ giữa hai bảng User và Udef
Hình 6. 2: Mối quan hệ User và Udef
6.2.2. Hoạt động
Khi đăng ký một nick ở WEB, người sử dụng vào phần dịch vụ người dùng để xem các từ khóa và dịch vụ của mình. Không hạn chế số lượng dịch vụ do một người sử dụng tạo nên. Vì thế một người sử dụng có thể có rất nhiều dịch vụ và các dịch vụ này có thể trùng nhau.
Khi tạo dịch vụ, người sử dụng cần tìm một từ khóa, từ khóa này phải là duy nhất và không trùng với ai khác. Tiếp theo, người sử dụng phải cung cấp cho TCat biết liên kết đến nơi cung cấp thông tin người sử dụng đã đăng ký. Chẳng hạn người sử dụng muốn tạo một dịch vụ có từ khóa là dichvu và liên kết cung cấp thông tin là http://mysite.com/ service.php. Khi đó người sử dụng cần điền vào ô trống Liên kết cung cấp thông tin là
http://mysite.com/service.php. Để dịch vụ hoạt động hiệu quả thì hệ thống cho phép hai bên tương tác với nhau qua các tham số. Các tham số này đề nằm trên giao thức http có kiểu GET cụ thể như sau
- Sender: cho biết nick người yêu cầu dịch vụ.
Như vậy việc phân tích các tham số truyền vào người sử dụng phải tự thực hiện ở file service.php của họ. Ví dụ cụ thể như sau, khi người yêu cầu dịch vụ yêu cầu dịch vụ
dichvu với tham số là hello world
/udef dichvu hello word
TCat sẽ gửi yêu cầu kết nối đến liên kết lấy thông tin
http://mysite.com/service.php?sender=nick&text=hello%20word
Dịch vụ hoạt động như thế nào? Khi người yêu cầu dịch vụ gửi yêu cầu /udef dichvu hello world. Các module IM, SMS chạy phía client (tạm gọi là các con bot) sẽ nhận được tin nhắn trên. Sau khi phân tích cú pháp của tin nhắn, con bot biết được dịch vụ yêu cầu là udef. Con bot sẽ gửi yêu cầu đến phía web thông qua giao thức HTTPS kèm theo một số tham biến như tên dịch vụ, mã số của con bot, nick gửi yêu cầu, từ khóa và text. Lúc này, WEB sẽ đọc từ CSDL ra liên kết lấy thông tin, tiếp theo web kết nối đến liên kết đó để lấy thông tin. Tất cả các thông tin lấy được WEB trả lại cho con bot. Con bot trả lời người yêu cầu dịch vụ bằng nội dung của thông tin đó.
Ở đây xuất hiện một điểm cần lưu ý. Việc Web kết nối đến liên kết thông tin hay WEB chỉ trả lại liên kết thông tin cho con bot là tốt nhất? Điều này không thể trả lời một cách ngắn gọn được mà phải tùy theo từng trường hợp cụ thể. Tuy nhiên theo tiêu chí của hệ thống là viết các dịch vụ càng đơn giản càng tốt, vì thế chúng tôi quyết định cho WEB đọc thông tin từ liên kết thông tin. Và cũng do thời gian có hạn nên chúng tôi chưa thống kê được hai phương pháp kết nối trên thì phương pháp nào tối ưu hơn. Tuy nhiên xét về tính bảo mật thì khi xử lý thông tin trên WEB trước, sau đó thông tin được mã hóa và truyền theo giao thức HTTPS xuống Client, việc này an toàn hơn so với việc chúng ta gửi trang lấy tin cho con bot. Nếu gửi trang lấy tin cho con bot thì sẽ không an toàn trong vấn đề bảo mật, vì khi thông tin đến được con bot. Con bot sẽ mở một kết nối đến trang web nhận được. Hacker có thể bắt gói tin và biết được địa chỉ trang web đó, ngoài ra hacker còn có thể làm sai lệch DNS, khiến cho con bot kết nối đến một trang web khác trong khi vẫn cứ tưởng mình kết nối đúng trang web. Vì thế, chúng tôi tạm thời sử dụng phương pháp cho WEB kết nối đến liên kết thông tin do người sử dụng cung cấp.
6.3. Dịch vụ Phiên dịch
Dịch vụ phiên dịch hay còn gọi là translate, đây là dịch vụ giúp người sử dụng dịch một đoạn văn bản, một từ hoặc thậm chí cả một tài liệu. Dịch vụ này của chúng tôi sử dụng lại dịch vụ miễn phí của Google là Google Translate.
Khi người sử dụng muốn dịch một đoạn văn bản nào đó, người sử dụng gửi tin nhắn sau đến con bot. Cấu trúc tin nhắn
/translate [ngôn ngữ hiện tại] [ngôn ngữ muốn chuyển đến] [đoạn văn bản muốn dịch]
Con bot sẽ phân tích cú pháp của tin nhắn gửi, sau đó gọi dịch vụ Phiên dịch. Dịch vụ này sẽ kết nối đến trang web translate của Google, đưa các tham số theo giao thức HTTP, sau đó nhận lại một đoạn văn bản. Con bot lúc này sẽ phân tích đoạn văn bản này bằng hàm json_encode(), lấy được các thông tin cần thiết sau đó trả về người sử dụng.
Ví dụ khi người dùng gõ lệnh:
/translate en vi hello world
Con bot gọi dịch vụ Phiên dịch lên, truyền tham số bao gồm: ngôn ngữ hiện tại là Tiếng Anh (có mã là en), ngôn ngữ muốn chuyển là tiếng Việt (có mã là vi), đoạn văn bản là hello world. Sau đó, con bot kết nối đến trang web cung cấp dịch vụ translate của Google là http://translate.google.com/translate_a/t sau đó truyền các tham số sau.
Values = {'client' : 't', 'text' : 'hello world','sl' : 'en','tl' : 'vi'}
GoogleTranslate sẽ trả về cho con bot một đoạn văn bản được mã hóa theo JSON. Dùng hàm json_encode() sẽ biến đoạn văn bản đó trở thành một mảng có cấu trúc như sau. - Nếu đoạn văn bản sau khi encode có kiểu là ký tự thì đó chính là chuỗi mà ta cần. - Nếu đoạn văn bản sau khi encode có kiểu mảng sẽ có cấu trúc như sau
[dịch nghĩa],[[giải thích],[ giải thích]]
Trong đó phần giải thích có cấu trúc như sau:
6.4 Dịch vụ Thời tiết
Dự báo thời tiết là một dịch vụ hay và cần thiết. Trên mạng cũng có một số trang web cung cấp dịch vụ dự báo thời tiết miễn phí. Dịch vụ dự báo thời tiết của chúng tôi sử dụng lại dịch vụ miễn phí của Yahoo là Yahoo Weather.
Khi người sử dụng muốn xem thời tiết của một khu vực nào đó, chỉ cần nhắn tin cho con bot với cấu trúc sau.
/weather [tên khu vực]
Con bot sẽ phân tích cú pháp của tin nhắn gửi, sau đó gọi dịch vụ weather. Dịch vụ này sẽ kết nối đến trang web Yahoo Weather, đưa các tham số theo giao thức HTTP, sau đó nhận lại một đoạn văn bản XML. Con bot lúc này sẽ phân tích đoạn văn bản này bằng, lấy được các thông tin cần thiết sau đó trả về người sử dụng.
Một bài toán khó đặt ra trong trường hợp này là việc YahooWeather lấy khu vực theo mã. Chẳng hạn Hà Nội thì có mã là VMXX0006. Nếu bắt người sử dụng nhớ mã này thì không hay. Vì thế, chúng tôi quyết định chỉ cung cấp dịch vụ dự báo thời tiết trong khu vực Việt Nam. Chúng tôi lập ra một bảng gồm hai trường (khóa và giá trị). Khóa tương ứng với tên tỉnh, thành phố. Giá trị tương ứng với mã tỉnh, thành phố đó (theo qui ước của Yahoo).
Ví dụ khi người dùng gõ lệnh:
/weather HaNoi
Con bot gọi dịch vụ Thời tiết lên, truyền tham số là mã thành phố ứng với tên thành phố. Sau đó, con bot kết nối đến trang web cung cấp dịch vụ YahooWeather,
http://weather.yahooapis.com/forecastrss?p=VMXX0006&u=c
Hai tham số p là mã thành phố và u là nhiệt độ được tính theo độ C. Yahoo sẽ trả lại một văn bản XML ghi đầy đủ thông tin thời tiết (sức gió, nhiệt độ, áp suât, dự báo ..). Công việc của con bot là phân tích văn bản XML, trả lại những thông tin cần thiết cho người dùng.
6.5. Dịch vụ Nhắc việc
6.5.1. Tổng quan
Để có thể sử dụng được dịch vụ thì người sử dụng phải có một tài khoản đã đăng ký với