One of my responsibilities @MailVision is the development of CMS - Client Management Server solution. To make a long story short its responsible for distribution and management of mobile VoIP clients for various Mobile platforms such as Symbian, Windows Mobile, Windows, iPhone, Android, Blackberry and more ...
The management part of VoIP clients requires communication between the clients and the CMS server and this is what I will talk about in the current post. The communication had to be lightweight from the bandwidth point of view since usually mobile clients communicate with the server over cellular data links and bandwidth there is rather costly. Another requirement is that the protocol could use secure links (such as TLS/HTTPS) due to nature of data passed between server and the client.
Each platform has its own development language and different implementations of standard and non-standard communication protocols and during past year or two I needed to integrate with all of them. Everything started from Web Services (I know some folks hate it) because it is a default communication protocol between the CMS and its Flex based GUI, so it was only natural to use webservices.
That was the theory at least, webservices worked out of the box only with the Windows based client while failed miserably on Symbian platform. It appears that default webservices toolkit that comes with Nokia has a very llimited support of structured webservices, it does not support inheritance and other data structure available in WSDL. For example it supports enums but list of enums is a total different thing, it crashes with a loud BOOM noise. To overcome we have created a simplified version of objects we expose using webservices, just for the use of Symbian phones and the problem was solved (it took lots of time to understand what exactly Symbian does not like and it was not an easy task). Since then we have switched to GSOAP on the newer Symbian phones which seems to support webservices much better, but still its a pain in the ...
Next platform that was needed to be supported was Windows Mobile. There we used GSOAP with the simplified layer and it worked without any significant problems ... The only problem is that no one uses Windows Mobile these days :-)
iPhone was next in line and webservices is a complete nightmare on iPhone OS so it was decided that another protocol should be selected which support will be acceptable by both Java server side and iPhone client side. After some research I've have selected Hessian as a leading candidate and indeed it took only several days to introduce a Hessian doorway on the server side and two more weeks to support it on the iPhone.
Lets make a headcount, till now server supports webservices and hessian.
We go on. One the MailVision solutions is a WebLynx (which was covered in this blog before) and it also had to be integrated with the CMS. Whats different about this integration is that its not client-server protocol but rather server-server protocol since WebLynx is also a Java based server. Since I learned to dislike webservices by then I decided to look for alternative which appeared in form of Google Protocol Buffers combined with Apache Mina. Its a great best of breed for the type of communication we required and several days later and couple of PB descriptor files the solution was ready and performance tests showed great results.
Headcount - Webservices, Hessian and Protocol Buffers.
Android. In order not to re-invent the wheel we decided to use good old Hessian which proved to be not a complicated task (nothing to do from the server side since it was already written :-) )
No change in the headcount.
Blackberry. The Java version in the Blackberry devices is J2ME on steroids but its very limited. Using Hessian there as we did on other platforms is troublesome and complicated since it misses the required language functionality such as introspection and reflection which are in the core of Hessian. Microhessian is not enough for our needs. Back to drawing desk. After trying different approaches and inspecting existing J2ME implementations the best candidate was JSON which was selected at the end. JSON over HTTP(S) answered the bandwidth/security requirements.
Final headcount till now - Webservices, Hessian, Protocol Buffers and JSON.
More to come :-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment