Thanks for all your help. The desktop apps I work on have connections to multiple back end servers often though a single message broker, some generic protocols, some proprietary and essentially it aggregates across all of them all, plenty of processing / transforming and essentially providing data to services that GUI components run off.
So I'm thinking camel can help because the number of generic problems I see, for example bursting messages, aggregating data across multiple connections + dealing with threading / consuming etc. Also some of the problems I come across that are difficult to deal with, primarily make enhancements. So one coming up is changing the sources for information, so for a service polling a web server for updates to a new server to subscribe for updates. There's definitely an interesting mix of event driven and data processing. What I see lacking in the apps I work on and what I like about camel is seeing defined routes where data flows and how it changes over the route. To understand the data flows in systems I work on you pretty much have to go to the connection class and chase through the code finding what processing its doing and what event interfaces it has, who implements listeners / whats listening to them, what processing they doing etc. Its questionable how well this was designed but I am thinking camel may be a fit to help structure the backend sub-systems hauling the data from which I think the gui can run off of more event driven services. Definitely not thinking camel for use in the gui / events. Does that make any sense? I'm very fresh to camel / figuring out when I can use it / what situations its best for. The pojo links look interesting and should do the trick. Will play some more. Thanks! -- View this message in context: http://camel.465427.n5.nabble.com/Desktop-applications-tp5753788p5753831.html Sent from the Camel - Users mailing list archive at Nabble.com.
