SBA & EDA Lessons Learned

I am still getting my head around SBA (Space Based Architecture)/distributed caching patterns.

I have a ways to go, but the more I read about it (blogs, docs, specs, etc.), talk about it with my insanely smart co-workers, and do stuff with it (hands on) the more I like it.

Like most humans, my mind works quickest when I can associate concepts. As I have mentioned before, I see a lot of parallels between SBA and EDA - specifically Message-Centric EDA. Last Spring, I did a series on lessons learned from an implementation of what I consider Message-Centric EDA. I'm going to pick out a few notable differences that I have noticed so far that makes SBA extremely appealing to me.

1. Content Based Routing
   Content Based Routing, Itinerary Based Routing, any service orchestration you can think of other than frightening things like BPM/BPEL are all achievable with SBA. And its done by using the state of your objects, not Topics, XML and all the complexity and angst that comes with it.
2. Choose Topics over Queues
   SBA wins hands down. Instead of mapping your system into using Hierarchical Topic Names including event types and states you put objects into the space and the state of the objects drives the service orchestration (take, notify, etc.). It's insanely simple. This eliminates 2 mappings: system state to Hierarchical Topic Names and Object to XML (and back). In a large system, this results in heaps and heaps of complexity eliminated.
3. Persistence
   No XML shredding in SBA, the space fits the transient data solution I mentioned. It can be configured to be persistent/reliable & in some implementations mirrored, clustered, etc. Getting relational databases out of the transient state business is great for simplicity / flexibility / maintainability / scalability. Again, one less mapping to deal with - only persist to long term storage at well defined states (again based on your objects, not a serialized XML version of them).

SBA basically turns messaging patterns upside down. The patterns are similar, just simpler in SBA. At first look, the SBA versions seem better. Perhaps the grass is greener, perhaps not.

The right answer is probably all of the above / both SBA and EDA. The really hard part is figuring out where to use which in building loosely coupled cohesive systems.

Update 29-DEC-2006 I was inspired thinking about this further on the walk to work this morning . . . I mention complexity and mapping above. Things like object to XML (and back) (OX), system state to hierarchical Topic names (and back), object to relational db (OR), Object to XML (Castor, JAXB, etc.), XML to relational db (XML shredding). Why do you care about all this? I'll tell you why you do. Not having this cruft in your system results in:

1. Hundreds of conversations and meetings that you will not have sorting this mapping out
2. Many design decisions / design details you won't care about
3. Thousands of unit tests you won't write
4. Hundreds of defects that you won't file, ponder, fix, and unit test

Update 07-FEB-2007 Appeasing the "then" vs. "than" police.

Update 22-JUL-2007 As this page is linked to from a Wikipedia page on Space Based Architecture, and gets a fair amount of referrals, I think that I have a responsibility to temper my original comments with what I believe today. I continue to have high hopes for Tuple Spaces, JavaSpaces, and SBA. In my opinion, however, there are not enough viable alternatives today. This is very important to me. I am watching with great interest what will happen with Apache River prior to making any further investment in this technology.

Jini/JavaSpaces & Distributed Caching

We are taking a gander at some space / cache technology and looking at ideal ways to do service orchestration with it in the architecture.

I am fortunate enough to work with Patrick Logan and he has some good questions. He worked for Gemstone a while ago so he knows their are opportunities to hurt oneself if one chooses unwisely.

I like JMS enough, but it has its issues. If there is a better, simpler way to do service orchestration I'm all ears.

Master/Worker with spaces might work. What else?

I like location transparency. It’s neat.

Update 27-DEC-2006 Just tickling your RSS reader - some good comments on this post. Please chime in if you have an opinion. I am becoming fascinated with this topic. There are a lot of parallels between SBA/distributed caching and EDA service orchestration models. I'm spending some time getting my hands dirty trying to get my head around it better.

SBA trumps EDA?

We are taking a look at some architectures for a next generation of a critical system at work.

I am a fan of EDA - Event Driven Architecture. I posted about it a bit here.

Its nice and all, but it is not without its problems. It certainly has a role to play in any architecture. But the last time I built one, I ran into some problems as detailed in my series linked to above.

Does SBA (Space Based Architecture) simplify things even more? For one thing, it minimizes "legacy" XML which is certainly a good thing. And the location transparency is mind boggling. Makes things like Sonic's shared subscriptions look quaint.

Just when you were happy that web services are finally dead, there is another shift. And if you are still talking about web services, well . . . sorry.