Sự khác biệt chính giữa GET và POST

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 Tomca t 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.