I commented in my previous post on the fact that working with message brokers can lead to tensions where we’re forced into letting the broker do more than we’d like.
I suspect that the bigger the list of features provided in a single broker the greater the probability we’ll be forced to comply with (and attempt to work around) undesirable models and behaviours that aren’t core to our requirements. Thus under certain circumstances a specific solution that addresses one core problem whilst asserting a minimum of additional constraints can be more attractive than a jack-of-all-trades solution.
It also occurred to me that brokers might not be the only piece of software to exhibit this characteristic. RPC systems tend to suffer similar problems having a tendency to tightly bind endpoint addressing, transport and argument marshalling. I also wonder if these issues contribute to some of the backlash against the behemoth that is an RDBMS implementation. For example whilst we might like our RDBMS to look after our data, we might not wish to put up with the querying, concurrency, deployment and management models it also asserts even with a myriad of configuration options.
Technorati Tags: architecture, design, technology
Entries (RSS)
just trying to understand the point being made in here.
are the “javaspaces” products a good fit in those certain circumstances?, especially, in extreme data manipulation applications?.
Hello,
I can imagine using Javaspaces to help implement the co-ordination part of extreme data manipulation but I wouldn’t imagine using them to hold or transport the data itself unless the chunks of data are small (I wouldn’t use a JavaSpace for passing around huge log files).
Generally, if I advocate the use of a JavaSpace it will be with a specific context and I’ll present some analysis. I appreciate some of the vendors in this vertical like to portray their software as being very broadly applicable in all sorts of “extreme” circumstances and thus it can be confusing.
The above was not intended as a JavaSpaces piece just a line of thinking I’d been pursuing in respect of “do it all” type products, their inherent flexibility problems and how that impacts architecture, design and code.
HTH,
Dan.