Lập Trình Di Động

TRUNG TÂM ĐÀO TẠO CNTT HBC VIỆT NAM

Chiêu sinh các khóa tin học chuyên đề Nhằm đáp ứng nhu cầu đào tạo chuyên sâu đối với một số ứng dụng chuyên ngành trong lĩnh vực đồ họa đa truyền thông và mạng máy tính của các cơ quan, công ty, xí nghiệp, đơn vị kinh doanh và của sinh viên tại Hà Nội, TRUNG TÂM TIN HỌC ĐẠI HỌC KHOA HỌC TỰ NHIÊN – ĐẠI HỌC QUỐC GIA TPHCM tổ chức chiêu s...

Ngày 16/11/2012 tới, thuê bao trả sau MobiFone có thể truy cập Internet, gửi và nhận email bằng dịch vụ data trên máy bay với mức cước 49.000 đồng/100 KB đầu tiên và 4.900 đồng/10 KB tiếp theo.



Dịch vụ chuyển vùng quốc tế trên máy bay cho phép các thuê bao trả trước và trả sau của MobiFone gọi, gửi SMS lướt Internet trên một số chuyến bay. Ảnh: Minh họa. Nguồn: Internet.

MobiFone vừa cung cấp cho các thuê bao trả sau của mình dịch vụ gọi điện thoại trên máy bay với mức cước 69.900 đồng/phút (bao gồm gọi hoặc nhận cuộc gọi) và 15.900 đồng/SMS (miễn phí nhận SMS). Ngày 16/11/2012 sắp tới, thuê bao trả sau MobiFone có thể sử dụng dịch vụ lướt Internet, gửi và nhận email bằng dịch vụ dữ liệu trên máy bay với mức cước 49.000 đồng/100 KB đầu tiên và 4.900 đồng/10 KB tiếp theo. MobiFone cho biết, các thuê bao trả trước cũng sẽ được sử dụng các dịch vụ trên từ ngày 1/1/2013.

MobiFone cho biết đây là dịch vụ chuyển vùng quốc tế trên máy bay cho phép các thuê bao trả trước và trả sau của MobiFone đã đăng kí sử dụng dịch vụ chuyển vùng quốc tế thành công thực hiện gọi, nhận và gửi SMS, lướt Internet trên một số chuyến bay của các hãng hàng không có cung cấp dịch vụ này.

Dịch vụ chuyển vùng quốc tế trên máy bay đang được MobiFone triển khai trên hàng trăm chuyến bay nội địa và quốc tế với các hãng hàng không: Air New Zealand (New Zealand), BA (British Airways-UK, Etihad Airways (UAE), Libyan Arab Airlines (Libya), EgyptAir (Egypt), Oman Air (Oman), Qatar Airways (Qatar), Royal Jordanian Airlines (Jordan), Saudi Arabian Airlines (Saudi Arabia), TAM (Brazil), Emirates (UAE).

MobiFone còn cho biết, vì lí do an toàn của chuyến bay, các thuê bao được yêu cầu không sử dụng điện thoại di động trong thời gian máy bay cất và hạ cánh. Khi máy bay đạt độ cao ổn định, phi hành đoàn hoặc màn hình trước mặt sẽ hiển thị thông báo thời điểm thuê bao có thể sử dụng dịch vụ.

Hiện MobiFone là mạng di động đầu tiên cung cấp dịch vụ lướt Internet trên máy bay. Trước đó, VinaPhone mới chỉ cung cấp dịch vụ gọi điện thoại, SMS chứ chưa có dịch vụ lướt Internet trên máy bay.

Theo ICTNews

Mời tham dự hội thảo Android - Đỉnh cao Công nghệ - Việc Làm hấp dẫn
8H30 thứ 7 ngày 20/10/2012
Tại TRUNG TÂM ĐÀO TẠO CNTT HBC Việt Nam
(Nhà D15, Đường Cốm Vòng, Dịch Vọng Hậu, Cầu Giấy, Hà Nội)

Hội thảo lập trình Android tại Hà nội.!! Bạn là người yêu thích công nghệ.? Bạn muốn lập trình ứng dụng Android trên điện thoại theo phong cách của mình? Bạn muốn có một việc làm hấp dẫn, thu nhập cao? …………………….. Hãy đến tham dự hội thảo với chủ đề “Lập trình Android Đỉnh cao Công nghệ - Việc làm hấp dẫn” Để khám phá công nghệ trên...

Android - Đỉnh cao Công nghệ - Việc làm hấp dẫn
Bạn là người yêu thích công nghệ?
Bạn muốn lập trình ứng dụng Android trên điện thoại theo phong cách của mình?
Bạn muốn có một việc làm hấp dẫn, thu nhập cao?
……………………..
Hãy đến tham dự hội thảo với chủ đề “Lập trình Android Đỉnh cao Công nghệ - Việc làm hấp dẫn” Để khám phá công nghệ trên nền Android, do TRUNG TÂM TIN HỌC ĐẠI HOC KHOA HỌC TỰ NHIÊN – ĐẠI HỌC QUỐC GIA TP. HCM duy nhất tại Hà Nội.
Đến với Hội thảo Các bạn sẽ được:
- Giao lưu, đối thoại với các Chuyên gia hàng đầu trong lĩnh vực lập trình Android về xu hướng phát triển ứng dụng trong thực tế.
- Gặp gỡ và tiếp cận với các nhà tuyển dụng hàng đầu về Lập trình viên Android.
- Phương pháp lập trình căn bản trên nền ứng dụng Android.
- Bốc thăm nhận những phần quà giá trị.
- 100% quà tặng cho các bạn nữ khi tham gia hội thảo nhân dịp 20/10
Thời gian: 8h30’ Ngày 20/10/2012
Địa điểm: TRUNG TÂM ĐÀO TẠO CNTT HBC VIỆT NAM
Nhà D15, Đường Cốm Vòng, Dịch Vọng Hậu, Cầu Giấy, HN
Điện thoại: (04)3553 5737 – 3553 5738 Website: www.hbcvn.com
(Gọi điện hoặc nhắn tin đến số 0986 099 368 để đăng ký tham gia chương trình)

Lập trình cho điện thoại di động J2ME - Phần 7 (Lập trình Web Service với MIDP)
Bằng cách chỉ dùng kết nối HTTP client nghĩa là server không thể thiết lập liên lạc với thiết bị ngoại trừ bằng cách hồi đáp một request. Một MIDlet HTTP client thông thường sẽ dùng cả hai phương thức HTTP GET và POST.

Đặc tả MIDP 2.0 phát biểu rằng cả HTTP và HTTPS bắt buộc phải được hỗ trợ.

Thân của thông điệp HTTP

Thông tin gởi trong thân thông điệp HTTP request và response đơn giản là một luồng byte. MIDlet và servlet chọn kiểu định dạng thông tin để mã hóa các byte này.
Thân của thông điệp SOAP/HTTP

Các điểm cuối dịch vụ Web dựa trên SOAP trao đổi các thông điệp SOAP với nhau. HTTP là một cơ chế mặc định dùng để truyền thông điệp SOAP. Thông điệp SOAP chứa dữ liệu theo định dạng XML. Thông điệp XML có thể dùng cả UTF-8 hay UTF-16 để làm bảng mã và mã hóa.

Khái quát về dịch vụ Web (Web service), SOAP và WSDL

Thuật ngữ “Dịch vụ Web” (Web service) nói đến truyền thông ứng dụng-đến-ứng dụng (application-to-application). Một dịch vụ Web đơn giản là một dịch vụ trên Internet có khả năng được truy xuất thông qua giao diện theo khuôn dạng sử dụng các giao thức Internet chuẩn như HTTP.

World Wide Web Consortium (W3C) định nghĩa dịch vụ Web như sau:

Một dịch vụ Web là một hệ thống phần mềm được nhận dạng bằng một URI (Uniform Resource Identifier), mà các giao diện chung và sự gắn kết của nó được định nghĩa và mô tả bằng XML. Định nghĩa của nó có thể được nhận ra bằng các hệ thống phần mềm khác. Các hệ thống này sau đó có thể tương tác với dịch vụ Web theo phương cách được mô tả trong định nghĩa của nó, sử dụng các thông điệp theo XML được chuyển bằng các giao thức Internet.

Hai đặc tả quan trọng về dịch vụ Web là Ngôn ngữ mô tả dịch vụ Web (Web Services Description Language – WSDL) và Giao thức truy xuất đối tượng đơn giản (Simple Object Access Protocol – SOAP). WSDL được dùng để mô tả một dịch vụ Web đã được triển khai. SOAP được dùng để định nghĩa định dạng của thông điệp được trao đổi giữa các điểm cuối (thí dụ như client và server) của dịch vụ Web trong suốt quá trình hoạt động của dịch vụ Web đó. Một dịch vụ Web có thể tự đăng ký ở một nơi đăng ký thích hợp (ví dụ bằng cách cung cấp mô tả WSDL của nó) để client có thể nhận ra nó. Các tiến trình này được gọi là quá trình đăng ký và nhận biết dịch vụ.

Java, Web service và SOAP

Lĩnh vực dịch vụ Web đang phát triển nhanh chóng. Tại thời điểm này Ủy ban công nghệ Java (Java Techonology Community) đã xây dựng phiên bản đầu tiên của Java API cho RPC dựa trên XML (Java API for XML-based RPC – JAXRPC) cho J2SE. Một gói tùy chọn cho dịch vụ Web trên J2ME cũng đang được xây dựng.

Đặc tả MIDP 1.0 và MIDP 2.0 không xác định bất kỳ hỗ trợ nào cho XML hay SOAP. Các nhà phát triển MIDP muốn sử dụng XML hay SOAP thường phải sử dụng các thư viện bên ngoài. Điều này rất bất lợi vì mỗi MIDlet phải chứa các thư viện này. Các thư viện như vậy thường khoảng 25 đến 50 KB (kích thước file .class). Điều này có khả năng sẽ làm giảm không gian cho ứng dụng MIDlet.

Luận án này được phát triển bằng các thư viện mở KXML và KSOAP. Một vài thư viện XML và SOAP khác nhắm đến thiết bị J2ME cũng có thể dễ dàng được tìm thấy, và có thể được sử dụng theo phương cách tương tự.

Tối ưu hóa truyền thông Client/Server cho các ứng dụng di động
Ứng dụng di động client/server

Ngoài các ứng dụng chạy đơn trên thiết bị di động không cần tương tác với tài nguyên bên ngoài, còn có nhu cầu một môi trường phân tán với client có nhu cầu liên lạc với server sử dụng kết nối IP. Ta sẽ xét một số vấn đề điển hình về liên lạc client/server có thể phát sinh trong quá trình kết nối giữa Java 2 Platform, Enterprise Edition (J2EE), nền tảng server và MIDlet. Tiếp theo sẽ so sánh các giao thức khác nhau, có thể được dùng để phát triển các loại ứng dụng phân tán này.

Ngoài ra, lập trình viên có thể sử dụng thêm các tầng trừu tượng giữa giao thức chuyển vận, dựa trên HTTP, và chính ứng dụng để xây dựng một kiến trúc linh động có thể được tối ưu hóa. Với cách tiếp cận này, giao thức chuyển vận được chọn có thể được chuyển đổi tương đối dễ dàng mà không cần phải hiệu chỉnh logic của ứng dụng.

Ở đây ta sẽ dùng một proxy servlet để có thể nâng cao hiệu quả của các ứng dụng di động client/server.

Trên thực tế, vô số ứng dụng Mobile Information Device Profile (MIDP) không chỉ chạy trên các thiết bị di động, mà cũng có truy xuất đến server, và do đó thể hiện một ứng dụng phân tán. Nhiều ứng dụng di động chỉ thật sự hoạt động khi kết nối đến server. Kết nối có thể “luôn luôn mở (always on)” hay chỉ mở khi ứng dụng cần liên lạc với server. Sử dụng cách tiếp cận phân tán, ứng dụng di động có thể truy xuất đến các cơ sở dữ liệu ngoại, vì những công việc quá phức tạp đối với khả năng hạn chế của thiết bị MIDP có thể được chuyển đến cho một server mạnh hơn. Do đó, lời giải cho ứng dụng di động doanh nghiệp chỉ có thể thực hiện thông qua tương tác giữa J2EE và Java 2 Platform, Micro Edition (J2ME). Tuy nhiên, trong quá trình trao đổi dữ liệu giữa server và client di động, cần phải quan tâm đến các vấn đề liên quan, đặc biệt là các vấn đề liên quan đến hiệu suất truyền tải và xử lý dữ liệu trên thiết bị.

Đối với giải pháp doanh nghiệp dựa trên công nghệ J2ME, cần phải quan tâm đến sự hạn chế của cả kết nối mạng và tài nguyên của thiết bị, không giống như môi trường thông thường của máy tính cá nhân với kết nối mạng cố định. Điều này có nghĩa là nhà phát triển nên lường trước được các khoảng thời gian trễ dài trên băng thông hạn chế. Hơn nữa, bất kỳ trong tình huống nào cũng không nên cho rằng thiết bị di động luôn luôn có kết nối. Về tài nguyên, ta phải đối mặt với vấn đề khả năng tính toán hạn chế cùng với khả năng lưu trữ tương đối của thiết bị. Do đó, trước khi phát triển một ứng dụng phân tán cho client di động, ta cần phải xem xét kỹ các yếu tố trước khi chọn giao thức, bởi vì quyết định này có thể có ảnh hưởng lớn đến hiệu suất của ứng dụng.

HTTP là một giao thức liên lạc client/server lý tưởng cho ứng dụng Java di động. Đối với mỗi đặc tả, thiết bị tương thích MIDP 1.0 phải hỗ trợ HTTP. Các giao thức khác như TCP hay UDP là tùy chọn. Bởi vì không phải tất cả thiết bị MIDP đều hỗ trợ truyền thông socket hay datagram, do đó triển khai HTTP trên thiết bị di động cho phép tối ưu khả năng chuyển đổi giữa các thiết bị từ các nhà sản xuất khác nhau. Mặc dù một số thiết bị, như Nokia 6800 hỗ trợ kết nối socket, nhưng để tương thích tối đa, nên sử dụng HTTP làm giao thức trao đổi giữa client và server.

Một lợi điểm khác nữa là giao thức HTTP được hưởng truy xuất không lỗi (trouble-free access) thông qua tường lửa. Bởi vì server và client di động hầu như được tách biệt bằng firewall, HTTP không cần phải cấu hình thêm. Mặc dù vậy, ta cũng nên qua tâm đến các rủi ro bảo mật có thể có khi mở kết nối HTTP ra thế giới bên ngoài. Java cung cấp API lập trình mạng, hỗ trợ giao thức HTTP 1.1. Ta dễ dàng tạo ra các request GET, POST, và HEAD trong ứng dụng Java.

Các loại giao thức khác nhau

Bây giờ ta đã chọn HTTP làm giao thức chuyển vận, vai trò của người phát triển là phải quyết định định dạng thông điệp để trao đổi dữ liệu giữa server và client. Nền tảng J2ME không đưa ra các cơ chế đã được chuẩn hóa như Java Remote Method Invocation (RMI) và Java API for XML-based Remote Procedure Call (JAX-RPC) (vốn rất tốn tài nguyên), người phát triển phải tự mình định nghĩa định dạng và lớp truyền thông trên lớp chuyển vận HTTP. Có nhiều sự lựa chọn, ta sẽ xem xét chi tiết dưới đây.

Chủ yếu có hai cách định nghĩa định dạng thông điệp: Một là định dạng thuần nhị phân, được tối ưu hóa để bảo đảm hiệu suất cao nhất. Hai là định dạng phức tạp dựa trên XML, ví dụ như SOAP, cung cấp khả năng đọc và khả chuyển cao, nhưng hiệu suất rất kém, đặc biệt là với các thiết bị di động với băng thông và tốc độ xử lý hạn chế. Người phát triển phải đối mặt với thử thách là phải lựa chọn giải pháp tốt nhất cho ứng dụng. Về cơ bản, kích thước của giao thức tăng tương ứng với khả năng tự mô tả, do đó làm giảm hiệu quả truyền thông trên mạng điện thoại di động băng thông hẹp. Tăng khả năng human-readability, thì đồng thời cũng gia tăng các định dạng dựa trên XML, cũng như hiệu suất tính toán để phát sinh và phân tích các thông điệp đến.


Hình 2. Biểu đồ so sánh các giao thức liên lạc khác nhau

Định dạng nhị phân độc quyền (Proprietary Binary Format)

Định dạng này có khả năng linh động cao và có thể được phát sinh một cách dễ dàng. Nó có thể được gởi bằng HTTP GET hay HTTP Post request đến một server J2EE, ví dụ như Tomcat của Apache Software Foundation.

Sự khác biệt chính giữa GET và POST request là với HTTP GET, tất cả các tham số hay dữ liệu được chuyển đến server được chứa trong chính địa chỉ URL. Điều này có nghĩa là ta có thể gọi trực tiếp các thủ tục của server từ xa thông qua URL và các tham số của nó. Tuy nhiên, để chuyển các tham số, ta bị giới hạn bằng định dạng văn bản đơn giản với độ dài các tham số bị giới hạn bởi kích thước lớn nhất của chiều dài dòng request của máy chủ Web. Ví dụ, trên server Web Tomcat, kích thước tối đa mặc định của dòng request được đặt là 8190 bytes và có thể được thay đổi.

HTTP POST thích hợp hơn đối với việc truyền lượng dữ liệu lớn hay thậm chí dữ liệu nhị phân từ thiết bị di động đến server, bởi vì dữ liệu được gởi đến server độc lập với URL. Việc này có ưu điểm là lượng dữ liệu không bị hạn chế, như trong trường hợp của phương thức GET. Trên Java, việc này có thể thực hiện bằng cách mở một luồng (stream) tách biệt, trên đó có các phương thức cần thiết của Java cho streamù. Do đó ta có thể truyền dữ liệu nhị phân đến server mà không gặp vấn đề gì. Dữ liệu trao đổi giữa client và server có thể được tổ chức hoàn toàn bằng các luồng.

Ưu điểm chính của việc liên lạc dùng định dạng dữ liệu nhị phân trên HTTP là hiệu suất truyền cao và kích thước phần tải (payload) cô đọng. Mặt khác, khuyết điểm của nó là nó không có tính tự mô tả (self-descriptive), và điều kiện tiên quyết là phải biết trước định dạng, ở cả hai phía client và server, trước khi có thể bắt đầu phát triển ứng dụng. Điều này dẫn đến vấn đề là bất kỳ thay đổi nào đến định dạng thông điệp phải được nhất quán giữa client và server. Ngoài ra, với sự gia tăng số lượng các thông điệp không tương tự nhau mà server cần phải xử lý, mã chương trình trở nên phức tạp.

Sự tuần tự hóa đối tượng

Một cách tiếp cận hay để khắc phục các khó khăn này là sử dụng các đối tượng được tuần tự hóa. Ngoài các kiểu dữ liệu chuẩn được hỗ trợ bởi các phương thức đọc và ghi trong các lớp luồng, ta có khả năng thực hiện tuần tự hóa các đối tượng bất kỳ để việc truyền dữ liệu giữa client và server được dễ dàng. Vấn đề là MIDP 1.0 không giống như môi trường hoàn chỉnh J2SE, mặc định MIDP không hỗ trợ tuần tự hóa (serialization) và phản ánh (reflection) đối tượng. Do thiếu một cơ chế tổng quát, mỗi lớp phải đưa ra sự thực hiện tính năng này theo cách của riêng mình.

Tuần tự hóa có được thông qua một giao diện phù hợp đòi hỏi đối phải cung cấp các phương thức cần thiết cho việc tuần tự và giải tuần tự nó. Cần chú ý là các lớp với cơ chế tuần tự độc quyền của nó phải hiện diện với các phiên bản giống nhau ở cả hai phía client và server.

Trao đổi thông điệp bằng XML

XML thể hiện định dạng thông điệp tự mô tả. XML không yêu cầu bắt buộc phải triển khai một giao thức RPC giống như SOAP dựa trên XML. Nhà phát triển có thể chỉ xây dựng định dạng thông điệp phù hợp dựa theo cơ sở của XML để thực hiện việc trao đổi dữ liệu giữa client và server. Ưu điểm có tính quyết định của XML là nó đã được chuẩn hóa và do đó có tính khả chuyển cao. Hơn nữa, nó dựa vào văn bản, dữ liệu có cấu trúc có thể được mô tả theo phương cách có tính tự giải thích (self-explanatory). Trong lĩnh vực doanh nghiệp, XML đã chiếm được ưu thế so với các giao thức thông điệp khác chủ yếu là do sự hỗ trợ tốt của nền tảng J2EE.

Ngoài việc truyền lượng dữ liệu lớn hơn khi dùng XML cũng như tăng thêm phần dư thừa của XML, ta còn gặp vấn đề khác với các thiết bị di động. Trong khi nền tảng J2EE hỗ trợ XML, thì môi trường MIDP 1.0 không cung cấp hỗ trợ tích hợp nào cho việc phân tích XML. Các giải pháp dựa trên XML cần phải bao gồm bộ phân tích XML trên MIDP client. Mặc dù có nhiều bộ phân tích mã nguồn mở, chẳng hạn như NanoXML, TinyXML, hay kXML, có thể được dùng cho mục đích này và đã được thiết kế để sử dụng tối thiểu tài nguyên, tuy nhiên dù sao thì vẫn yêu cầu không gian lưu trữ trên thiết bị, vốn thường rất ít để chia sẻ.

Ở đây ta sử dụng KXML của Enhydra, bởi vì nó chỉ chiếm 21 KB bộ nhớ.

Để phân tích tài liệu XML, cần phải có thêm bộ nhớ và khả năng tính toán tương ứng. Trong hầu hết trường hợp, thông điệp XML lớn hơn nhiều so với thông điệp nhị phân – chủ yếu là do tính dài dòng của định dạng XML.

Nén nhị phân XML

Định dạng WBXML giúp giảm kích thước tài liệu XML một cách đáng kể, trong đó định dạng văn bản của tài liệu XML được chuyển sang một dạng nhị phân. Định dạng này cũng được dùng để chuyển các trang WML, kích thước được giảm xuống rất nhiều bằng cách thay các thẻ, thuộc tính, và các giá trị thông dụng bằng một tập các thẻ bài (token) có thể cấu hình được. Cũng hoàn toàn giống như việc mã hóa và giải mã các thông điệp trong thiết bị WAP được thực hiện thông qua một WAP gateway, việc liên lạc giữa thiết bị MIDP và server J2EE cũng có thể tương tự. Bộ phân tích đảm nhận việc mã hóa và giải mã thông điệp một cách phù hợp, bộ phân tích phải hỗ trợ WBXML. Ví dụ, bộ phân tích KXML của Endydra hỗ trợ giao thức này và cho phép truyền dữ liệu một cách hiệu quả giữa client và server. Server đương nhiên cũng cần phải hiểu định dạng WBXML. Một cách thay thế là, việc liên lạc phải được xử lý thông qua một proxy hay một WBXML gateway.

XML-RPC

XML-RPC là một giao thức truyền thông điệp cực nhẹ cho phép thực thi các thủ tục từ xa trên mạng thông qua HTTP. Client gởi một thông điệp XML thông qua HTTP POST đến server để phân tích. Một thủ tục nội của server trả về kết quả là response, cũng ở dạng một thông điệp XML, trả về cho client.

Do đó XML-RPC có được các ưu điểm của XML. Nó xây dựng rất ít tính năng, cho phép xác định và truyền các kiểu dữ liệu giống như các tham số để triệu gọi các thủ tục từ xa theo cách tiếp cận trung lập nền (platform-neutral). Phạm vi của định dạng chủ ý càng nhỏ càng tốt bằng cách giới hạn sáu loại kiểu dữ liệu gốc (primitive): int, boolean, string, double, datetime và base64 và hai kiểu liên hợp (complex): struct và array. Điều này làm cho giao thức đặc biệt thích hợp với các ứng dụng J2ME và kết nối mạng điện thoại di động băng thông hẹp.

Nhược điểm ở đây, cũng giống như với XML, là nền tảng J2ME không cung cấp bất kỳ hỗ trợ tích hợp nào cho XML-RPC, và nó cần phải dựa vào các gói bổ sung như KXM-RPC của Enhydra để triển khai ứng dụng trên thiết bị. Gói KXML-RPC được xây dựng trên nền của KXML và chạy khá tốt với chỉ 24KB tài nguyên thiết bị bao gồm KXML. Các mã nguồn liên quan của XML-RPC cũng cung cấp cho việc cài đặt điểm liên lạc tương ứng tại server. Một ví dụ của nó là Apache XML-RPC dựa trên nền tảng Java của Tổ chức phần mềm Apache (Apache Software Foundation), có thể được áp dụng với Tomcat Servlet engine.

SOAP

Simple Object Access Protocol (SOAP). Đầu tiên Microsoft phát triển giao thức này cùng với Useland để đáp ứng nhu cầu của các nhà phát triển muốn phát triển các ứng dụng phân tán với các công nghệ của Microsoft. SOAP và các phiên bản trước của XML-RPC có cùng nguồn gốc. Tuy nhiên, không giống như SOAP, XML-RPC đã được cải tiến và không gia tăng tính phức tạp. Việc định nghĩa phức tạp giúp cho các giao thức mở rất linh động, điều này giải thích vì sao nó là chuẩn trong thực tế cho việc gọi hàm từ xa bằng XML trên HTTP.

Đáng tiếc là, với các nhược điểm vốn có của lĩnh vực di động, nó dẫn tới nhiều dữ liệu thừa mà không luôn luôn cần đến, nhưng chiếm nhiều tài nguyên. Đặc tả giao thức hiện tại là 1.2 và ngoài tập tính năng của XML-RPC, nó cung cấp các tính năng thêm như tính quan tâm không gian tên (namespace awareness), cơ chế định kiểu dữ liệu, và việc truyền dữ liệu header bổ sung. SOAP cũng có cùng mặt hạn chế, J2ME không cung cấp bất kỳ hỗ trợ nào cho nó. Các client cần hỗ trợ SOAP cần phải tích hợp trong các chức năng của ứng dụng. Trên đầu cuối client, một giải pháp là dùng Enhydra ME project-kSOAP. Tuy nhiên, gói kSOAP yêu cầu ít nhất 41 KB bộ nhớ, là một gánh nặng cho ứng dụng trên thiết bị.

Trong trường hợp này, ta phải bảo đảm bộ nhớ và băng thông yêu cầu có thể thỏa mãn. Đương nhiên server cũng cần phải hỗ trợ SOAP. Phía server thì có nhiều giải pháp, có thể dùng dự án mã nguồn mở Apache SOAP (cũ) hoặc dự án Axis mới hơn, Axis nên dùng cho các dự án mới. Axis cũng thuộc Apache.

Tối ưu hóa bằng Proxy

Ta đã khảo sát nhiều tùy chọn khác nhau cho việc trao đổi dữ liệu client/server thông qua HTTP. Tùy thuộc vào mục đích của ứng dụng, ta có thể quyết định sử dụng giữa giao thức nén theo ý mình với các giao thức linh động nhưng dài dòng đã trở thành chuẩn được sử dụng rộng rãi. Nếu ta muốn kết hợp các ưu điểm của các phương pháp đối lập này, thì có một giải pháp khá thú vị – sử dụng một proxy server hoặc một gateway giữa MIDP client và server J2EE. Như ta đã đề cập ở trên, thông điệp XML có thể được nén thông qua WBXML gateway.

Tương tự như vậy, ta cũng có thể thực hiện một proxy cho giao thức độc quyền, chuyển nó thành giao thức chuẩn như XML-RPC hay SOAP. Nhờ vậy, dữ liệu được chuyển từ MIDP client đến proxy bằng một giao thức nhẹ chẳng hạn như một giao thức nhị phân hay WBXML, để tối thiểu hóa kích thước thông điệp và tận dụng tốt hơn băng thông hạn chế. Proxy, đến lượt nó, đóng vai trò như một client đến server J2EE và dịch request của giao thức nhẹ đó thành giao thức dựa trên XML của server và ngược lại.

Dùng proxy, ta có khả năng kết nối ứng dụng đến một server đang tồn tại với sự giúp đỡ của giao thức được tối ưu hóa, ví dụ server đó có thể đang hỗ trợ SOAP hay XML-RPC. Điều này có ưu điểm là khả năng liên kết và hiệu suất đều được nâng cao. Mặt khác, cần phải xem xét một vấn đề là sự gia tăng độ phức tạp của toàn bộ hệ thống sẽ gây khó khăn cho quá trình phát triển ứng dụng.



Hình 3. Mô hình mẫu dùng Proxy

Nguồn: www.tincntt.com

http://www.tincntt.com/

Lập trình cho điện thoại di động J2ME - Phần 5 (Lập trình mạng)
1. Lập trình mạng

Mạng cho phép client di động gởi và nhận dữ liệu đến server. Nó cho phép thiết bị di động sử dụng các ứng dụng như tìm kiếm cơ sở dữ liệu, trò chơi trực tuyến… Trong J2ME, mạng được chia làm hai phần. Phần đầu tiên là khung được cung cấp bởi CLDC và phần hai là các giao thức thật sự được định nghĩa trong các hiện trạng.

1.1 Khung mạng CLDC tổng quát (Generic CLDC Networking Framework)
CLDC cung cấp một khung tổng quát để thiết lập kết nối mạng. Ý tưởng là nó là đưa ra một khung mà các hiện trạng khác nhau sẽ sử dụng. Khung CLDC không định nghĩa giao thức thật sự. Các giao thức sẽ được định nghĩa trong các hiện trạng. Hình 1 biểu diễn cách mà khung CLDC làm việc:

Hình 1. Khung mạng CLDC tổng quát

Kết nối mạng được xây dựng bằng phương thức open() của lớp Connector trong CLDC. Phương thức open() nhận một tham số đầu vào là chuỗi. Chuỗi này dùng để xác định giao thức. Định dạng của chuỗi là:

protocol:address;parameters

CLDC chỉ xác định tham số là một chuỗi nhưng nó không định nghĩa bất kỳ giao thức thật sự nào. Các hiện trạng có thể định nghĩa các giao thức kết nối như HTTP, socket, cổng truyền thông, datagram,… Phương thức open() trả về một đối tượng Connector. Đối tượng này sau đó có thể đóng vai trò là một giao thức xác định được định nghĩa trong hiện trạng.

Connector.open(“ :

;”);

Một số giao thức ví dụ (nhưng không được hỗ trợ bởi CLDC hay MIDP):
Socket: Connector.open(“socket://199.3.122.21:1511”);

Comm port: Connector.open(“comm:0;baudrate=9600”);

Datagram: Connector.open(“Datagram://19.3.12.21:1511”);

Files: Connector.open(“file:/filename.txt”);

MIDP hỗ trợ giao thức HTTP:

HTTP: Connector.open(“http://www.sonyericsson.com/”);

Trả về một đối tượng Connection

Ví dụ trên minh họa kết nối socket, cổng truyền thông, datagram, file và HTTP. Tất cả các kết nối mạng đều có cùng định dạng, không quan tâm đến giao thức thật sự. Nó chỉ khác nhau ở chuỗi chuyển cho phương thức open(). Phương thức open() sẽ trả về một đối tượng Connection đóng vai trò là lớp giao thức (ví dụ. HttpConnection) để có thể sử dụng các phương thức cho giao thức đó. J2ME chỉ định nghĩa một kết nối là kết nối HTTP trong MIDP.

1.2 Các lớp giao diện kết nối (Connection Interface Class)

Dẫn xuất từ lớp Connection là nhiều lớp giao diện con cung cấp khung kết nối mạng. Các giao diện khác nhau để hỗ trợ các loại thiết bị di động khác nhau.

c = Connector.open("datagram://192.365.789.100:1234"); // Chế độ client

1.3 Kết nối HTTP

Hiện trạng MIDP hỗ trợ kết nối HTTP phiên bản 1.1 thông qua giao diện HttpConnection. Hỗ trợ GET, POST, HEAD của HTTP. Yêu cầu GET (GET request) được dùng để lấy dữ liệu từ server và đây là phương thức mặc định. Yêu cầu POST dùng để gởi dữ liệu đến server. Yêu cầu HEAD tương tự như GET nhưng không có dữ liệu trả về từ server. Nó có thể dùng để kiểm tra tính hợp lệ của một địa chỉ URL.

Phương thức open() của lớp Connector dùng để mở kết nối. Phương thức open() trả về một đối tượng Connection sau đó có thể đóng vai trò là một HttpConnection cho phép dùng tất cả các phương thức của HttpConnection.

Một kết nối HTTP có thể ở một trong ba trạng thái khác nhau: Thiết lập (Setup), Kết nối (Connectd), hay Đóng (Close). Trong trạng thái Thiết lập, kết nối chưa được tạo. Phương thức setRequestMethod() và setRequestProperty() chỉ có thể được dùng trong trạng thái thiết lập. Chúng được dùng để thiết lập phương thức yêu cầu (GET, POST, HEAD) và thiết lập thuộc tính HTTP (ví dụ. User-Agent). Khi sử dụng một phương thức yêu cầu gởi dữ liệu đến hay nhận dữ liệu về từ server sẽ làm cho kết nối chuyển sang trạng thái Kết nối. Gọi phương thức close() sẽ làm cho kết nối chuyển sang trạng thái Đóng. Hình 3 minh họa các trạng thái kết nối khác nhau:

Hình 3 . Các trạng thái kết nối HTTP

Lưu ý rằng gọi bất kì phương thức nào liệt kê ở trên (ví dụ. openInputStream(), getLenght()) cũng sẽ làm cho kết nối chuyển sang trạng thái Kết nối.

1.4 Ví dụ HTTP GET

Phương thức HTTP GET cho phép lấy dữ liệu từ server và là phương thức mặc định nếu không xác định phương thức trong trạng thái Thiết lập.

Ví dụ thực hiện một kết nối HTTP GET cơ bản:

void getViaHttpConnection(String url) throws IOException {
HttpConnection c = null; InputStream is = null;
try {
c = (HttpConnection)Connector.open(url); // Mở kết nối HTTP
is = c.openInputStream(); // Mở Input Stream, mặc định GET
type = c.getType();
int len = (int)c.getLength();
if (len > 0) {
byte[] data = new byte[len];
int numBytes = is.read[data]; // Nếu biết chiều dài
processData(data);
} else {
int ch;
while ((ch = is.read()) != -1) { // đọc đến khi nào gặp -1
stringBuffer.append((char)ch);
}
processBuffer(stringBuffer);
}
} finally {
if (is != null) is.close();
if (c != null) c.close();
}
}

getViaHttpConnection() nhận một chuỗi là tham số đầu vào, đó là địa chỉ địa chỉ URL chuyển cho phương thức open() của lớp Connection. Phương thức open() trả về một đối tượng Connection đóng vai trò là một lớp HttpConnection. Phương thức openInputStream() sẽ làm cho kết nối chuyển sang trạng thái Kết nối. Vì không có yêu cầu phương thức nào, kết nối sẽ mặc định là một kết nối HTTP GET.

Phương thức getLength() sẽ trả về chiều dài của dữ liệu gởi từ server. Nếu biết được chiều dài, thì biến len sẽ chứa chiều dài dữ liệu và ta có thể đọc toàn bộ khối dữ liệu. Nếu không thì len sẽ chứa giá trị -1 và dữ liệu phải được đọc từng ký tự một cho đến khi gặp đánh dấu cuối file (-1). Phương thức processData() và processBuffer() xử lý dữ liệu đến từ server. Khối lệnh cuối cùng sẽ đóng tất cả các kết nối không quan tâm đến có lỗi từ khối lệnh try ở trước hay không.

1.5 Ví dụ HTTP POST

HTTP POST cho phép gởi dữ liệu đến server. Dữ liệu gởi đến server qua phương thức GET chỉ giới hạn là dữ liệu chứa địa chỉ URL. Phương thức POST cho phép gởi một luồng byte đến server. Phương thức HTTP POST thực hiện theo cách tương tự với phương thức HTTP GET.

Ví dụ thực hiện một kết nối HTTP POST:

void getViaHttpConnection(String url) throws IOException {
HttpConnection c = null; InputStream is = null;
OutputStream os;
try {
c = (HttpConnection)Connector.open(url); // Mở kết nối
// Thiết lập phương thức POST
// trong khi vẫn ở trạng thái Thiết lập
c.setRequestMethod(HttpConnection.POST);
// Mở luồng output stream và chuyển sang trạng thái Kết nối
os = c.openOutputStream();
// Chuyển đổi dữ liệu thành luồng byte
// và gởi đến server
os.write(“Data Sent to Server\n”.getBytes());
int status = c.getResponseCode();
// Kiểm tra status
if (status != HttpConnection.HTTP_OK) throw new IOException(“not OK”);
int len = (int)c.getLength();
// Giống như ví dụ HTTP GET:
// Kiểm tra length và xử lý tương ứng
} finally {
// Đóng kết nối giống như ví dụ HTTP GET
}
}

Như ví dụ trước, phương thức postViaHttpConnection() nhận tham số đầu vào là một chuỗi là địa chỉ URL được chuyển đến phương thức open() của lớp Connection. Phương thức open() trả về một đối tượng Connection đóng vai trò là một lớp HttpConnection.

Kết nối bây giờ ở trong trạng thái thiết lập và phương thức yêu cầu được đặt là POST bằng phương thức setRequestMethod(). Tất cả các thuộc tính khác phải được thiết lập trong trạng thái này.

Phương thức openOutputStream() sẽ làm cho kết nối chuyển sang trạng thái Kết nối. Phương thức write() và flush() sẽ gởi dữ liệu đến server.

Đoạn mã còn lại giống như phương thức GET. Luồng input được mở, chiều dài của dữ liệu được kiểm tra, và dữ liệu được đọc toàn bộ khối hay từng ký tự một tùy vào chiều dài được trả về. Khối lệnh cuối cùng sẽ đóng kết nối.

1.6 Triệu gọi CGI script

Cả hai phương thức GET và POST có thể được dùng để triệu gọi CGI script (Common Gateway Interface script) và cung cấp dữ liệu nhập. Ví dụ, một MIDlet có một form cho người dùng điền dữ liệu, sau đó có thể gởi dữ liệu kết quả cho server để CGI script xử lý. CGI script có thể được triệu gọi giống như phương thức GET và POST. Tên của CGI script và dữ liệu tham số nhập có thể chuyển trong địa chỉ URL. Nếu cần gởi thêm dữ liệu cho server, thì có thể dùng phương thức POST.

Ví dụ các tham số được gởi là một phần của URL:

url = http://www.asite.com/cgi-bin/getlocation.cgi?location+name=abc&zip=12345

Trong ví dụ trên, địa chỉ URL có thể được chuyển như là một tham số giống như phương thức getViaHttpConnection() ở ví dụ trước.

1.7 HTTP Request Header

Như ta đã nói trước, HTTP request header phải được thiết lập ở trạng thái Thiết lập bằng phương thức setRequestMethod() và setRequestProperty(). Phương thức setRequestMethod() dùng để thiết lập các phương thức GET, POST, hoặc HEAD.
Phương thức setRequestProperty() dùng để thiết lập các trường trong request header. Ví dụ có thể là “Accept-Language”, “If-Modified-Since”, “User-Agent”.
Phương thức getRequestMethod() và getRequestProperty() có thể được dùng để lấy các thuộc tính trên.

2 Wireless Messaging API

J2ME chứa hầu hết các cấu hình và hiện trạng, kết hợp với nhau để định nghĩa môi trường thực thi Java hoàn chỉnh cho các thiết bị có tài nguyên giới hạn. Tuy nhiên, đôi khi, cần phải có gói giao diện lập trình ứng dụng (Application Programming Interface – API), có thể chi xẻ bởi các ứng dụng chạy trên các hiện trạng khác nhau. J2ME định nghĩa API như vậy là các gói tùy chọn (optional package), là một tập các lớp và các tài nguyên khác có thể được dùng kết hợp với hiện trạng.

Cũng giống như các thành phần của J2ME, các gói tùy chọn được định nghĩa là yêu cầu đặc tả Java (Java Specification Request – JSR) thông qua Java Community Process. Một trong những gói tùy chọn đầu tiên cho J2ME là JSR 120, bộ API nhắn tin không dây (Wireless Messaging API – WMA), dùng để gởi và nhận các tin nhắn văn bản hoặc nhị phân ngắn trên kết nối không dây.

WMA dựa trên khung kết nối mạng tổng quát (GCF).

Các tin nhắn được gởi và nhận với WMA được gởi trên các mạng không dây của điện thoại di động và các thiết bị tương tự khác, có thể là GSM hay CDMA. WMA hỗ trợ Short Message Service (SMS) và Cell Broadcast Short Message Service (CBS). Mặc dù tin nhắn WMA tương tự như datagram, WMA không sử dụng giao diện datagram được định nghĩa bởi GCF, giao diện này dùng cho kết nối UDP. Thay vào đó, WMA định nghĩa một tập giao diện mới trong gói java.wireless.messaging.

Để gởi hoặc nhận tin nhắn, ứng dụng trước hết phải tạo một instance của giao diện MessageConnection, sử dụng GCF connection factory. Địa chỉ URL chuyển cho phương thức java.microedition.io.Connector.open() chỉ định giao thức sử dụng (SMS hoặc CBS), và số điện thoại đích, cổng, hoặc cả hai. Ví dụ, đây là những URL hợp lệ:

sms://+417034967891
sms://+417034967891:5678
sms://:5678
cbs://:5678

URL trong hai dạng đầu tiên mở kết nối client, ứng dụng kết nối đến một server với địa chỉ thiết bị và cổng chỉ định. Nếu cổng không chỉ định, sẽ dùng cổng nhắn tin mặc định của ứng dụng. Dạng URL thứ ba mở một kết nối server trên thiết bị, cho phép ứng dụng đợi và hồi đáp tin nhắn đến từ các thiết bị khác. Dạng cuối cùng cho phép ứng dụng lắng nghi tin nhắn broadcast từ người điều hành mạng.

Sau đây là một ví dụ đơn giản tạo một kết nối SMS client:

import java.microedition.io.*;
import java.wireless.messaging.*;
....
MessageConnection conn = null;
String url = "sms://+417034967891";
try {
conn = (MessageConnection) Connector.open( url );
// thực hiện công việc gì đó
}
catch( Exception e ){
// xử lý lỗi
}
finally {
if( conn != null ){
try { conn.close(); } catch( Exception e ){}
}
}

Để gởi tin nhắn, sử dụng phương thức MessageConnection.newMessage() để tạo một tin nhắn rỗng, thiết lập payload của nó (dữ liệu văn bản hoặc nhị phân để gởi), và triệu gọi phương thức MessageConnection.send():

public void sendText( MessageConnection conn, String text )
throws IOException, InterruptedIOException {
TextMessage msg = conn.newMessage( conn.TEXT_MESSAGE );
msg.setPayloadText( text );
conn.send( msg );
}

Gởi dữ liệu nhị phân cũng hoàn toàn tương tự:

public void sendBinary( MessageConnection conn, byte[] data )
throws IOException, InterruptedIOException {
BinaryMessage msg =conn.newMessage( conn.BINARY_MESSAGE );
msg.setPayloadData( data );
conn.send( msg );
}

Dĩ nhiên, có giới hạn lượng dữ liệu có thể gởi trong một tin nhắn. Thông thường, tin nhắn văn bản SMS bị giới hạn đến 160 hoặc 70 ký tự, tin nhắn nhị phân bị giới hạn đến 140 bytes.

Nhận tin nhắn thậm chí còn đơn giản hơn: Sau khi mở một kết nối server, ứng dụng gọi phương thức receive() của kết nối, phương thức này sẽ trả về tin nhắn có trong cổng đã xác định. Nếu không có tin nhắn, phương thức sẽ đứng (block) cho đến khi có tin nhắn, hoặc cho đến khi có một thread khác đóng kết nối:

import java.io.*;
import java.microedition.io.*;
import java.wireless.messaging.*;
MessageConnection conn = null;
String url = "sms://:5678"; // không có số điện thoại!
try {
conn = (MessageConnection) Connector.open( url );
while( true ){
Message msg = conn.receive(); // blocks
if( msg instanceof BinaryMessage ){
byte[] data =((BinaryMessage) msg).getPayloadData();
// thực hiện công việc gì đó
} else {
String text =((TextMessage) msg).getPayloadText();
//thực hiện công việc gì đó
}
}
}
catch( Exception e ){
//xử lý lỗi
}
finally {
if( conn != null ){
try { conn.close(); } catch( Exception e ){}
}
}

Để bảo đảm tính ổn định của chương trình, việc gởi và nhận thông điệp nên giao cho một thread riêng đảm nhận.

Nguồn: www.tincntt.com
http://www.citd.edu.vn/Vietnam/Home/index.php/hethong/ngon-ng-lp-trinh/2158-lp-trinh-cho-in-thoi-di-ng-j2me-phn-5-lp-trinh-mng?lang