• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Communicating with non-java devices

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I'm looking at developing a server which receives and processes data from remote non-java-based devices over GPRS comms.
My initial idea was to have these devices poll a server for commands using HTTP Get requests, the response would have a file attachment containing XML based commands. Sending data to the server would be done via HTTP Post requests with attachments.
I considered writing a NIO based server but decided to use the benefits of appservers (hence HTTP based comms) rather than writing everything from scratch.
I've have looked around and most of the discussions regarding this are J2ME to J2EE based. Also the server will be communicating with 1000's of these remote devices.
I was wondering if my overall approach is suitable or is there a better way?

Thanks for your help
Noel
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would think that most of the work on the server would be to parse the xml attachment. That being true, I don't see much effort in just writing a server from scratch that reads and writes using sockets. Unless maybe you want an appserver that supports load balancing, fail over, and/or serves up other web resources.
 
Noel M OConnor
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had considered going the raw TCP way but I figured I'd let the server look after the message recognition and threading issues. I looked at the netty2 project and that seemed suitable but the lack of SSL (which may be needed in future) was an issue..

regards
Noel
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

...let the server look after the message recognition and threading issues



I agree the web server would look after threading issues(you wouldn't have to start a new thread after each socket.accept()). But message recognition? If your message is contained in the xml attachment sent to a web server then it must be extracted by custom code. There are off the self xml parsers but you don't have to run a web server to use them.
 
Noel M OConnor
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The plan was to send the data as data on an HTTP post. Once the data has been retrieved from the request it is passed to other elements for processing.
I figured that the app server would look after retrieving the request and I'd only have to worry about processing the attached data.
Mind you this is all theory, give me a couple of months and I'll know how much of this is practical...hopefully
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic