I wouldn't necessarily say that the state has to be local - I was thinking more along the lines of memcached or Velocity or the like. You certainly could use messaging for all aspects of your system - it's definitely possible. For me, I've found the read/write split to be helpful thus far, and the use of web services/distributed cache/etc... for reads gives me a great deal more flexibility when it comes to complex querying scenarios, especially those circumstances where the data set would be too large to cache locally. Standard disclaimer - YMMV :)
On Tue, Jun 16, 2009 at 2:52 PM, Victor Kornov<[email protected]> wrote: > Yeah, Matt is dead on, local state is going to be important. There are cases > where you can avoid explicit messaging. Just check local state (distributed > hash) if info is available. If yes -> display, not -> 404 & one way message > to get that data. On startup this info can be loaded to local state using > special "GetDataOnStartUp" message. So 404 is a failure case scenario when > local state is empty for some reason. > But local state takes resources, so you can't have everything in there, > especially for custom reporting scenarios. In this case you still need to do > explicit messaging. If you are going to use messaging I'd avoid RPC style > services, be it SOAP or REST. I mean, why services for reading & messages > for "writing"/commands, when you can easily do both through messaging? > P.S. I forgot to say it's all just my humble opinion ;) > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
