3

We intend to design a system with three "tiers".

  1. HQ, with a single server
  2. lots of "nodes" on a regional basis
  3. users, with iPads.

HQ communicates 2-way with the nodes which communciate 2-way with the users. Users never communicate with HQ nor vice-versa.

The powers that be decree a Windows app from HQ (using Delphi) and a native desktop app for the users' iPads. They have no opinion on the nodes.

If there are compelling technical arguments, I might be able to beat them down from "decree" to "prefer" on the Windows program (and, for isntance, make it browser based). The nodes have no GUI, they just sit there playing middle-man.

What's the best way for these things to communicate (SOAP/HTTP/AJAX/jQuery/home-brewed-protocol-on-top-of-TCP/something-else?) Is it best to use the same protocol end to end, or different protocols for hq<-->node and node<-->iPad?

Both ends of each of those two interfaces might wish to initiate a transaction (which I can easily do if I roll my own protocol), so should I use push/pull/long-poll or what?

I hope that this description makes sense. Please ask questions if it does not. Thanks.

Update:
File size is typcially below 1MB with nothing likely to be above 10MB or even 5MB. No second file will be sent before a first file is acknowledged.

Files flow "downhill" from HQ to node to iPad. Files will never flow "uphill", but there will be some small packets of data (in addition to acks) which are initiated by user action on the iPad. These will go to the local node and then to the HQ. We are probably talking <128 bytes.

I suppose there will also be general control & maintenance traffic at a low rate, in all directions.

mjn
  • 35,561
  • 24
  • 160
  • 351
Mawg says reinstate Monica
  • 34,839
  • 92
  • 281
  • 509

3 Answers3

5

For push / pull (publish / subscribe or peer to peer communication), cross-platform message brokers could be used. I am not sure if there are (iOS) client libraries for Microsoft Message Queue (MSMQ), but I would also evaluate open source solutions like HornetQ, Apache ActiveMQ, Apollo, OpenMQ, Apache QPid or RabbitMQ.

All these solutions provide a reliable foundation for distributed messaging, like failover, clustering, persistence, with high performance and many clients attached. On this infrastructure message with any content type (JSON, binary, plain text) can be exchanged, and on top messages can contain routing and priority information. They also support transacted messaging.

There are Delphi and Free Pascal client libraries available for many enterprise quality open source messaging products. (I am am the author of some of them, supporting ActiveMQ, Apollo, HornetQ, OpenMQ and RabbitMQ)

mjn
  • 35,561
  • 24
  • 160
  • 351
  • 2
    I think you should have mentioned that you are the author of some of those client libraries. – Jeroen Wiert Pluimers Apr 08 '11 at 10:14
  • 1
    I think you should provide URLs for them :-) +1 & thanks. YOu have listed many option, but if you *had* to choose, then which would you choose? – Mawg says reinstate Monica Apr 09 '11 at 01:12
  • 1
    @Mawg: from the message brokers which are supported by Habari JMS Clients, I would recommend to take a look at Apache ActiveMQ. Commercial support available through Fusesource http://fusesource.com/, Fuse message broker is based on ActiveMQ. Two sample chapters (PDF) of the book "ActiveMQ in Action" are at http://www.manning.com/snyder/, a slideshow presentation is at http://www.slideshare.net/bruce.snyder/messaging-with-activemq-presentation. Second would be OpenMQ, a lean and solid product. The Habari client libraries are available from http://www.habarisoft.com/habari.html – mjn Apr 09 '11 at 07:58
2

Check out MessagePack: http://msgpack.org/

Also, here's more RPC discussion on SO:

ICE might be of interest to you: http://zeroc.com/index.html
They have an iOS layer: http://zeroc.com/icetouch/index.html

Community
  • 1
  • 1
entropo
  • 2,398
  • 15
  • 15
1

IMHO there are too little requisites to decide what technology to use. What data are exchanged, how often, what size? Are there request/response time constraints? etc. etc. Never start selecting a technology before you understand your needs deeply.