0

I am working on designing a new platform for a certain type of application. These applications will mainly exists on both iOS and Android devices. One of the main requirements in these applications is that is syncs real time data and is secure. My thought went directly to using some kind of queuing protocol using sockets. The restrictions on the server is that it would have to be written in either Java or PHP. However, the clients are unrestricted. Like I mentioned, mainly iOS (Objective-C) and Android (Java) devices.

Should I implement something like ActiveMQ or Tibco, or should are there any other solutions that might be better to use?

Best regards,
Paul Peelen

Paul Peelen
  • 10,073
  • 15
  • 85
  • 168
  • RSS via HTTPS and 10second timer? –  Jan 05 '11 at 08:05
  • What do you mean by real time? What is an acceptable delay? 10s, 1s, 100ms, 10ms, 1ms, 100us? – Peter Lawrey Jan 05 '11 at 08:16
  • For security: RSS or any other HTTP protocol is not preferable. In my opinion a socket connect is more secure. For delay: 1-5s. The question: What is the best solution to transport real-time-data between the server and the device (both ways)? – Paul Peelen Jan 05 '11 at 08:34

2 Answers2

1

Option 1:

RSS message format via HTTPS and T second timer.
HTTPS is cryptographic transfer protocol over SSL sockets (also used by e-banking).

Option 2:

REST via HTTPS and T second timer.
Is it a good thing for a custom rest protocol to be binary based instead of text based like Http?

Option 3:

Kicking HTTP server, php and using SSL sockets in Java.
http://stilius.net/java/java_ssl.php

Community
  • 1
  • 1
1

The best way is using RESTful API over HTTP. People that say that sockets is more secure than HTTP usually do not really understand what are they speaking about (nothing private, man. Only business!)

HTTP is a transport protocol that works over TCP sockets. So, HTTP is also sockets. What gives you security is encryption of what you are sending. SSL is the answer. User HTTPS to make your application secure.

Now about queuing. Queuing is needed to decouple delivery of information and its processing. This is preferable in your case because processing may take time and you do not want to block the sender (mobile device) while server is processing the data. I'd suggest you to use open source implementation of messaging broker (like ActiveMQ, RabitQ, Qpid etc). Tibco is perfect but it costs some money. And if you are going towards Java messaging broker implement your server in java too and user JMS API that is supported by all messaging brokers.

I hope this helps.

AlexR
  • 114,158
  • 16
  • 130
  • 208
  • Thank you for your answer. I find it very usefull. You are right about the HTTP stuff. The only think I am concerned about from the client side is that the client (in theory) can listen to the trafic send from its device and thereby know how the API looks like. A socket implementation can encrypt this better I believe, right or wrong? The last thing I want is for people to figure out how the API works and send me dummy data which will lead to false data. – Paul Peelen Jan 05 '11 at 09:25
  • (1) You (and I and anyone) cannot encrypt data better than SSL does; (2) hackers can hack everything including your proprietary protocol. REST is standard and easy-to-implement. If you want to make it more secure protect it with password, i.e. send login using HTTPS post, then use the API within authenticated session. – AlexR Jan 05 '11 at 09:56
  • Allright, thats true. Then there only remains one thing though... using REST (Soap or hessian) the client is responsible for the receiving and fetching of data. I can't have this either... the client should be updated by the server on new info, so for that I am thinking of using an que. Encypt that (if possible) with 128 bit keys encryption (I have to find out how). – Paul Peelen Jan 09 '11 at 22:57