Công nghệ Java - J2ME

 lập đúng để bảo đảm 
các gateway trung gian xử lý response đúng đắn. 
Client nhận HTTP response và giải mã application response chứa trong đó. Client có 
thể thiết lập một hoặc nhiều đối tượng và thực hiện một số công việc trên các đối 
tượng cục bộ này. 
Thiết kế định dạng thông điệp (Message Format) 
Cách định dạng application request và response là tùy thuộc vào lập trình viên. Các 
lựa chọn rơi vào hai cách sau: 
Một cách là dùng định dạng nhị phân. Các thông điệp nhị phân có thể được đọc và 
ghi sử dụng các lớp DataInputStream và DataOutputStream trong gói java.io. 
Trên thực tế, sử dụng các thông điệp này đạt được hiệu quả trao đổi bởi vì tải được 
rút gọn. Chú ý rằng để tiết kiệm không gian, các thông điệp phải thỏa mãn tính tự 
miêu tả (self-descriptive). Do đó, định dạng của thông điệp phải được biết cả ở client 
và server, và do đó chúng gắn chặt với nhau. 
Cách khác là sử dụng Extensible Markup Language (XML). Trong khi nền tảng J2EE 
cung cấp rất nhiều hỗ trợ cho XML (đặc biệt là trong Web service), thì đặc tả MIDP 
không yêu cầu hỗ trợ XML, mặc dù các nhà phát triển có thể thêm hỗ trợ XML vào 
ứng dụng MIDP bằng cách kết hợp các thư viện bổ sung. 
Để phân tích và xử lý tài liệu XML, các nhà phát triển có thể lựa chọn nhiều cách thực 
hiện, bao gồm hai mô hình xử lý phổ biến, Document Object Model (DOM) và Simple 
API for XML (SAX). (SAX và các bộ phân tích dựa trên sự kiện khác thích hợp hơn 
DOM khi áp dụng cho các thiết bị di động với bộ nhớ và tốc độ xử lý bị hạn chế). Các 
thư viện RPC dựa trên XML cũng được cung cấp, bao gồm các bộ phân tích dựa trên 
đặc tả Simple Access Object Protocol (SOAP). 
Tuy nhiên khi sử dụng định dạng XML, ngoài việc chi phí cho kích thước và băng 
thông, còn có chi phí không nhỏ về bộ nhớ, xử lý và lưu trữ. 
Liên quan đến truyền thông điệp, ta có các vấn đề sau: 
Liên lạc an toàn (Communicating Securely) 
Các client MIDP có thể dựa vào một số cơ chế giống các cơ chế dùng để hỗ trợ liên 
lạc an toàn giữa các ứng dụng J2EE và các client trình duyệt Web. 
Server ứng dụng J2EE và nhiều thiết bị MIDP hỗ trợ HTTP trên Secure Sockets Layer 
(SSL). Các thiết bị MIDP sử dụng secure HTTP để xác thực với server và tiến hành 
trao đổi an toàn với server đó. Khung kết nối tổng quát (Generic Connection 
Framework) trong MIDP cho phép người lập trình mở kết nối secure HTTP chỉ đơn 
giản bằng cách gọi phương thức Connector.open() với URL bắt đầu bằng https. 
Để xác thực ở phía client, các MIDP client dựa vào việc xác nhận do ứng dụng quản 
lý, có thể dựa vào cơ chế tự đăng ký. Nói cách khác, MIDP client gởi thông tin ủy 
nhiệm (ví dụ như tên đăng nhập và mật khẩu) đến ứng dụng J2EE, và ứng dụng sẽ 
xác nhận các thông tin này, có thể bằng cách sử dụng cơ sở dữ liệu. 
Quản lý giao tác 
Nền tảng J2EE hỗ trợ giao tác theo nhiều cách. Các nhà phát triển có thể quản lý 
giao tác một cách thủ công sử dụng Java Transaction API, hoặc dựa vào server J2EE 
để quản lý các giao tác đó một cách tự động. Enterprise bean thông thường có thực 
hiện giao tác, nhưng các thành phần nghiệp vụ trong tầng Web cũng có thể thực 
hiện giao tác. 
Khi thiết kế một MIDP client, nhà phát triển nên quan tâm đến việc giao tác không 
thể trải qua nhiều HTTP request (Các client trình duyệt cũng bị ảnh hưởng bởi giới 
hạn này). Nếu một request xác định bất kỳ hoạt động nào yêu cầu một giao tác, thì 
các hoạt động được xử lý như một đơn vị nguyên tử; trước khi trả về response, tất cả 
các hoạt động đều đã được thực hiện, hoặc không có hoạt động nào được thực hiện. 
Do đó, nếu một MIDP client muốn hoàn lại một request, thì nó không thể đưa ra một 
rollback trong request kế tiếp, bởi vì request kế tiếp sẽ nằm trong một ngữ cảnh giao 
tác khác. Thay vào đó, ứng dụng phải sử dụng một giao tác bù (compensating 
transaction) để hoàn lại request đó. 
Quản lý lỗi 
Khi server J2EE không thể thực hiện request cho MIDP client, nó cần phải thông báo 
điều này cho client. Mặc dù chương trình của server có thể sử dụng cơ chế quản lý 
ngoại lệ của Java để xử lý lỗi cục bộ, nó không thể sử dụng cơ chế này để thông báo 
lỗi cho MIDP client khi liên lạc trên mạng. Nói cách khác, lập trình viên không thể cài 
đặt một khối try-catch trong mã client để bắt trực tiếp ngoại lệ được ném ra từ 
server. Thay vào đó, họ phải tổ chức một cơ chế thông báo lỗi vào giao thức truyền 
thông điệp của họ. 
Một cách là dành một phần cố định trong mỗi response của ứng dụng cho một mã 
trạng thái thể hiện là request của ứng dụng có thành công hay không. Ví dụ, khi sử 
dụng truyền thông điệp nhị phân, hai byte đầu tiên có thể dành cho mã trạng thái số 
nguyên. Khi sử dụng HTTP, các nhà phát triển ứng dụng có thể dùng mã trạng thái 
của HTTP response để thể hiện thành công hay thất bại ở mức truyền thông. Ví dụ, 
mã trạng thái của 200 (“OK”) có thể dùng để chỉ thành công, trong khi mã trạng thái 
500 (“Internal Server Error”) có thể dùng để chỉ thất bại. 
Các chiến lược về trình diễn (presentation) 
Người dùng tương tác với ứng dụng càng tập trung và trực tiếp, thì người dùng càng 
có dễ dàng sử dụng. Điều này có ý nghĩa đặc biệt quyết định cho các ứng dụng 
không dây do màn hình hiển thị và khả năng nhập liệu của các thiết bị di động bị hạn 
chế. 
Các nhà phát triển có thể sử dụng một vài chiến lược để làm cho các ứng dụng không 
dây có kết nối mạng tăng tính hữu dụng hơn: thực hiện kiểm tra ở phía client, cung 
cấp biểu thị diễn tiến, cho phép ngắt các hoạt động, và cá nhân hóa ứng dụng. Ta sẽ 
nghiêng cứu các chiến lược này. 
Thực hiện kiểm tra ở phía client 
Việc kiểm tra nhập liệu ở phía client là một phương thức tốt để giảm việc gọi đến 
server. Xét một form đặt hàng, có các trường thông tin thẻ tín dụng. Một MIDlet có 
thể không thể kiểm tra thông tin này một mình nó được, nhưng chắc chắn nó có thể 
áp đặt một số phương cách kiểm tra đơn giản để xác định thông tin đó có hợp lệ hay 
không. Ví dụ, nó có thể kiểm tra tên chủ thẻ không thể là null, hoặc chỉ số thẻ phải 
có đủ các con số. Nếu dữ liệu nhập được qua các bước này, client sẽ chuyển chúng 
đến server. Server có thể xử lý các công việc phức tạp hơn, ví dụ như kiểm tra số thẻ 
tín dụng đó có thật sự thuộc về chủ thẻ hay không hoặc chủ thẻ đó còn đủ tiền hay 
không. 
Bằng cách thực hiện việc kiểm tra nhập liệu ở phía client, các MIDlet có thể tránh 
việc liên lạc không cần thiết đến server. Các MIDlet có thể chủ động hơn để tránh 
việc nhập liệu không hợp lệ. Ví dụ có thể giới hạn việc nhập số điện thoại bằng cách 
sử dụng trường nhập ràng buộc số, do đó các số điện thoại không phải là số sẽ 
không thể được gởi đến server. 
Cung cấp biểu thị diễn tiến (process indicator) 
Bởi vì các hoạt động kết nối mạng tốn nhiều thời gian, ứng dụng nên cung cấp cho 
người dùng một thông tin phản hồi về diễn tiến của hoạt động đó. Ví dụ có thể đưa 
ra một hoạt hình hoặc gauge để biểu thị diễn tiến. Biểu thị diễn tiến này dùng cho 
các hoạt động kéo dài, ví dụ như khi download danh sách các trường trên mạng. 
Cho phép ngắt hoạt động 
Cho phép người dùng có khả năng ngắt các hoạt động kéo dài giúp họ giữ việc điều 
khiển ứng dụng. Các biểu thị diễn tiến có thể có thêm một nút nhấn ngừng. Biểu thị 
này sẽ lắng nghe sự kiện của nút nhấn ngừng, và khi nhấn nút ngừng màn hình hiển 
thị sẽ ngay lập tức chuyển sang màn hình trước đây. 
Cần chú ý rằng, không phải tất cả các hoạt động đều có thể dừng. Ví dụ, không nên 
dừng việc tạo một tài khoản người dùng trên server và lưu lại trên client. Hai công 
việc này nên thực hiện như là một hoạt động chung hoặc là không thực hiện cả hai. 
Nếu hoạt động bị ngắt, sẽ có thể dẫn đến sự không thống nhất giữa dữ liệu của client 
và server. 
Cá nhân hóa ứng dụng 
Khái niệm cá nhân hóa (personalization) chỉ khả năng một dịch vụ thích ứng với 
thông tin mà nó biết về người dùng. Thông thường, nhiều thông tin của người dùng, 
chẳng hạn như địa chỉ, mã ZIP, hay màu sắc ưa thích, sẽ không thay đổi từ phiên 
làm việc này sang phiên làm việc khác. Bởi vì các dữ liệu này là ổn định, ứng dụng có 
thể dùng nó để cá nhân hóa việc sử dụng của người dùng. 
Việc cá nhân hóa một dịch vụ là có lợi vì hai lý do sau: 
Nó giảm việc yêu cầu nhập liệu. Người dùng sẽ chán nếu phải nhập đi nhập lại các 
thông tin này mỗi lần sử dụng dịch vụ. 
Nó sẽ rút ngắn dòng chảy công việc (workflow). Người dùng có thể nhập thông tin tài 
khoản vào lần đầu, và client sẽ giữ lại thông tin đăng nhập của họ. Trong các lần sử 
dụng sau đó, người dùng có thể lựa chọn tự động đăng nhập mà không phải qua màn 
hình đăng nhập. 
Trong khi trạng thái phiên làm việc có thể xem là thông tin tạm thời, thì dữ liệu cá 
nhân hóa sẽ có tính bền vừng. Lưu dữ liệu bền vững này ở đâu là tùy vào người phát 
triển ứng dụng. 
Khi quyết định lưu trữ dữ liệu cá nhân hóa, các nhà phát triển phải xem xét các câu 
hỏi sau: 
Dữ liệu cá nhân hóa có thường xuyên ảnh hưởng đến client request không? Ví dụ, 
ứng dụng đặt vé sẽ liệt kê các rạp dựa vào mã vùng của người dùng. Server lưu trữ 
mã vùng này, do đó client không cần phải gởi lại mã vùng mỗi lần nó gởi yêu cầu. 
Tuy nhiên cũng nên cho phép người dùng có thể bỏ qua mã vùng này, ví dụ khi họ 
sang thăm một vùng khác. 
Thông tin cá nhân hóa có khả năng sử dụng giữa nhiều loại client hay không? Ví dụ, 
người dùng sử dụng ứng dụng đặt vé trên điện thoại di động có thể muốn truy xuất 
cùng ứng dụng đó qua Web. Khi đó, họ có thể muốn dữ liệu cá nhân sẽ có sẵn để 
tránh việc nhập lại nó qua Web. 
Quyết định nơi để lưu dữ liệu cá nhân hóa không phải luôn luôn là một quyết định 
lựa chọn một trong hai. Dữ liệu cá nhân hóa có thể được lưu chồng ở cả client và 
server. Khi dữ liệu cá nhân hóa được lưu chồng trên cả client và server, ứng dụng có 
thể cần phải có thêm một số tính năng để đồng bộ hóa dữ liệu này. Các nhà phát 
triển được khuyên là nên cân nhắc đến chi phí của việc thực hiện các tính năng này. 
Find best mobile with best price
www.thongtinmobile.com