Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

First off some background info

My company has a software as a service model where people log onto our servers and do work. In order to support that application we have a utility application that lives on the client machine, and copies binary data from our servers to their machines.

The first iteration of this software polled the database and then generated the information on the client side. This approach was done away with because we thought there where some fundamental flaws

  • Polling the database to see if any work had to be done
  • Opening up our SQL port to the world
  • Pulling all the data from the database and generating it on the client side.

Our second iteration of the software generated the data on one of our servers and sent it on to the client via the Java Messaging Service. The advantages being seen as

  • Event Driven
  • No polling
  • SQL port is closed
  • Data is not being generated over the WAN

The above is to illustrate the approaches we've used in the past.

The problem that we have is that our clients often have poor connectivity to us (packet loss, poor response times etc) JMS was supposed to handle that as it should reconnect when the line comes back up but this doesn't always happen.

What are the best approaches to deal with poor client connectivity?

EDIT

To explain what I mean about JMS not working as expected.

My expectation of JMS is that it works reliably. What I mean by this is that if a line goes down, or is losing packets, or misbehaving in any other manner that the JMS implementation will continue to try send the message until it succeeds.

As an example I see on an almost daily basis a JMS queue with consumers attached, yet no messages being sent or received, restarting the client normally resolves the issue.

I can speak about more specifics, however for the sake of this conversation lets leave JMS out as potential answer

EDIT 2

I wanted some other possible solutions to my problem, but the general consensus seems to be that my current one (JMS) is the best.

So here are 2 of my current cases where I am having issues with JMS

Case 1

Client connects to the queue succesfully sends and receives multiple messages, after a variable time (between several hours and several days) the client no longer receives any messages. The main queue shows the consumers connected, but the client never receives the messages. The resolution is to restart the client application

Case 2

The client never connects to the queue. The client continually tries to reconnect but the reconnection always fails. The resolution for this is to try again in a few hours

Our setup is fairly simple

  • One public server
  • OpenMQ
  • The clients are low volume, ranging from 10 messages a day to a 1000 messages a day
  • Clients never initiate a 'message conversation', the queue initates and the clients reply
  • Messages are small, all pure text, no binary data
  • config is as follows:

    connectionFactory = new ConnectionFactory();
    connectionFactory.setProperty(ConnectionConfiguration.imqAddressList, connectionURL);
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectEnabled, "true");
    connectionFactory.setProperty(ConnectionConfiguration.imqPingInterval, "30");
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectAttempts, "-1");
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectInterval, "30000");
    
share|improve this question
    
"this doesn't always happen"? What does this mean? What's really going on? What did you expect? What did you build? What tests have you run? What failure modes are you observing? –  S.Lott Apr 19 '11 at 11:23
    
@S.Lott my trials and tribulations with JMS are a story in itself, for simplicities sake I'd just prefer to leave it out as a possible solution –  Tim Sparg Apr 19 '11 at 12:45
    
@Tim Sparg: Without specific problems, issues, errors or diagnostic information, we can only guess randomly at potential things you haven't already tried. –  S.Lott Apr 19 '11 at 12:47
    
Many organisations use JMS with great reliability and success. I'm not saying it's the answer for you, but I'm surprised you're having that many issues with it. AMQP is another option if you want wire protocol locked down –  Martijn Verburg Apr 19 '11 at 14:13
    
Without know the amount of data, the type of data and the frequency of data it's hard to recommend anything. Can you elaborate? –  Martijn Verburg Apr 19 '11 at 14:14

1 Answer 1

RESTful. JAX-WS supports it.

...In the web services world, REpresentational State Transfer (REST) is a key design idiom that embraces a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URLs. Web service clients that want to use these resources access a particular representation by transferring application content using a small globally defined set of remote methods that describe the action to be performed on the resource. REST is an analytical description of the existing web architecture, and thus the interplay between the style and the underlying HTTP protocol appears seamless...

Architects and developers need to decide when this particular style is an appropriate choice for their applications. A RESTFul design may be appropriate when...

share|improve this answer
    
Thanks, I will investigate this –  Tim Sparg Apr 19 '11 at 15:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.