I'm looking for some design tips here. Here's the basics. Thick client written in .NET talking to a host server through Webservices that needs to be "continually updated".
Obvious choice would be to use ActiveMQ and the .NET client library, subscribe to an appropriate topic/queue, and live happily ever after. To be blunt, that simply isn't going to happen. Just close your eyes and think of England, it's not in the cards. Rather, we're going to have to Poll the server regularly to get our changes. But that doesn't mean that we cannot post our updates to a queue/topic, and then leverage that on the web server to send the updates to the client when they call. So, here's my thinking. Every time the client calls the web server. it connects to the JMS server using a Durable Subscription. It then slurps down all of the pending update messages (or some max number of them), then forwards them down to the client and disconnecting from the JMS server. The problem is that we don't have any real sense of transactions here. There's no obvious way to make sure the client actually recieved and processed those changes that the server forwarded to it. One thought was that when the client requests an update, it includes a timestamp representing the "last time" it got an update, which would be the timestamp of the last message that it got. Then, when the server is fetching messages from the JMS server, it would simply ACK the ones that are before that timestamp, and then simply discard them. But for the current messages, it would not ACK or Commit them, and leave them on the server. Another thought is that after the client does a refresh and update, it "commits" the request by sending a "Ok up to *timestamp*" and the server then refetches and discards those older messages. Either solution requires fetching the messages twice from the JMS server. So, with my limited knowledge of ActiveMQ and JMS in particular, is that a good solution? Is there some functionality that would make this more efficient? I can't see any way to get around using the durable subscription. Overall, I'm thinking of having a small JMS cluster (for reliability moreso than performance) backing the web services tier, then the app tier funnels update events in to the JMS cluster. Can ActiveMQ be gateway with Oracle Queues, so that, say, a stored procedure can post an update event to an Orcale Queue that then forwards it in to ActiveMQ? Thanx for any thoughts on this. Regards, Will Hartung ([EMAIL PROTECTED]) -- View this message in context: http://www.nabble.com/Design-Guidance-t1447633.html#a3910797 Sent from the ActiveMQ - User forum at Nabble.com.
