Signs of Life @ Apache River

It is encouraging to see a spark on Apache River list.

I'd love to see a come back.

Tuple Spaces are addictive.

Emerging from the Google OSS Grid Haze

Looks like GridGain is emerging from their semi-silence:

GridGain Systems announced today availability of the first public release of GridGain project, an enterprise open source grid computing platform for Java. This release culminates 18 months of development and presents a software product with unique set of grid computing features, open source LGPL licensing and clear focus on high-performance Java-based development.

"Almost two years ago we set out to develop a technology that would change the enterprise Java grid computing landscape in much the same way Spring and JBoss have changed the J2EE market through simplification and focusing on a developer. Today we are releasing our project that is based on proven professional open source model, business and community friendly LGPL licensing, and the host of unique grid computing features", said Nikita Ivanov, founder of GridGain project.

Tangosol (now owned by Oracle) and others gave us the Java "Data Grid". Perhaps GridGain can give us the "Compute Grid" part. This is what we struggled with in looking at data grid/caching technologies - you still needed the compute part somewhere. Tools like Tangosol excelled in bridging the gap between J2EE performance problems due to data latency issues. But that is only 1/2 of the problem in terms of application grids. You still need to be able to easily add compute nodes to be able to scale.

Without a compute grid, you need to rely on things like JMS or other bits of J2EE. This is of course fine in an evolution approach - just doesn't seem to fit right in a new large system (at least for me).

Could this be an application grid without the Jini/JavaSpaces baggage? Don't know - certainly borrows some Jini features (code mobility). They know how to document things and have a roadmap and bits so that is a start ;) Message to Apache River: see I'm not kidding, the clock is going tick, tick, tick - the future is coming.

This should be interesting to watch.

Grid & the Web vs. JavaSpaces

Some of the grid computing concepts look awful similar to JavaSpaces. And the community appears to be thriving (as opposed to Jini/JavaSpaces which is not).

There are some OSS projects and a number of commercial vendors. Done properly, you can use many different languages and platforms (as opposed to just Java with JavaSpaces).

Perhaps it is better? Simpler or more complicated? Not as good, but good enough? What about associative memory? Grid + REST + XMPP + Atom? Something else? More locked in or less?

I do love the promise of the tuple space. I hope some day it makes it into the mainstream. I no longer think it will any time soon, sadly. There are forces out there that I do not understand that will continue to relegate it to the niche category of "high performance computing". Until there is a thriving community around it, few will embrace it. I hope this changes. I certainly will be watching.

5/13/2007 9:45 PST Updated some links.

Ahem Where are the Jini/JavaSpaces Bits?

Nice overview of JavaSpaces.

I likes it. I wants it. Really I do.

JavaSpaces is some of the best tech. I've had the opportunity to work with. Build a Generic Worker and tell me you disagree I dare you.

But, there is something wrong - I'm sure it is coming real soon now - that is what we keep hearing, but where are the bits? Where is the roadmap?

I said it a while ago. But the clock is going tick tick tick. It is May - it became a poddling in December/January. 5 months ... no bits, no roadmap?

One commercial proprietary vendor, a partially retired Pragmatic Dictator FOSS impl. and a very quiet maybe FOSS Apache project does not a thriving community make.

What gives? Does Sun want this to happen or do they want it to die? I just don't understand. I mean to offense - I'm new. But the current state of the community makes it very hard to want to invest in this technology - no matter how much potential it has.

I'm going to JavaOne a bit and am going to try to find out. I'll let you know how it goes.

Our Crazy Fugger

Patrick is our resident Crazy Fugger.

I understand him a little more each episode.

I agree with Edward Povazan: A whole parallel computing universe that I, having been on a C/C++/Java path, would not have been exposed to.

I don't know Smalltalk, but have had several enlightening conversations on it with Patrick. If history had played out a little different, we might all be building with Smalltalk.

For me, exploring JavaSpaces has been a bit like what I hear Edward saying - there are whole other worlds out there in software. Some good bits / some bad bits to be sure, but some of the things that didn't catch on in the mainstream certainly should have. There were reasons to be sure - some of them self-inflicted, but the calculus of what technologies make it and which ones fail is far from meritocratic.

Update: Fixing capitalization of Smalltalk from SmallTalk after being vigorously scolded by Patrick :)

Rubber Match

This week is the rubber match between the Space Men and the Flex Men at work.

We've covered a lot of ground in this phase of the project. A lot of it was fighting learning curves and getting infrastructure stood up. We spent a lot of time using Lean set based decision making on what technology we wanted to use. This was good in that we are more confident in our decision, but bad in that it cost time. The good news is we wouldn't have picked the technology we ended up with if we had used a traditional "place your bets early" approach. So it worked. Yay.

It is inevitable yet annoying that the first rev. of any piece of software has to pay the first rev. tax of standing up infrastructure, figuring out methodology, forming/storming/norming/hopefully-performing, and learning rapidly in general.

The team makes its choices (as Sarge would say) and lives with the repercussions. We made a lot of good choices luckily, but we certainly made some bad ones. The bitch of it is you never really know which choices were good and which choices were bad unless they were very right or very wrong. You are always left wondering what if we did this - what if we did that?

And so it goes - here comes the rubber match between the Space Men and the Flex Men. I am using this phrase incorrectly, but I felt like using it anyhoo, so so what!?. It really is the integration week. When we take a lot of reasonably well tested Jini/JavaSpaces code (unit, integration, and FIT) and try to integrate it with Flex code.

For better or worse, we split our small team into two - one focusing on the backend JavaSpaces side and one focusing on the Flex UI side. This was mostly due to fighting learning curves, but was also due to working styles and geography. We wanted to try a lot of things and splitting the team at the time seemed to be a way to cover the most ground with technology and methodology. We'll never know if this was a good decision. But we made our choices.

A team where everyone is skilled in all areas of the system is obviously best. But you can't just wave a wand and make this happen. You have to get there iteration by iteration choice by choice.

Wish us luck this week - the rubber match is going to hurt! :)

FIT Wiki = H.O.T. - & JBoss Rules + JavaSpaces = Smiles

Patrick and I had a rather long pairing session today.

We beat our rules module into submission. Turns out that JBoss Rules and JavaSpaces are a pretty good match.

Towards the end of the day, we had the unit tests passing and the integration tests passing. Then it was time for the FIT tests. They busted us proper. Our co-worker Ed was pretty pumped about this. Getting busted when you think you are done by tests you wrote at the outset of a development effort is a great thing. For us, it is one less thing that we will find out when we plug in Flex to our Jini/JavaSpaces back-end. That rocks.

And our FIT tests are plugged straight into our wiki. It is h.o.t.

We also have put JBoss Rules to work with JavaSpaces. It works quite well because it is POJO based and the compiled rules can just be put into the space as Entries. If that isn't h.o.t. I don't know what is. We have a generic worker that takes Entries out of the space & reads the appropriate rules files. It just asserts the Entries directly into the rules engine (they are POJOs too - Entry is just a marker). No XML marshalling / mapping madness etc. Just objects - neat!

JBoss Rules is not as sophisticated as some commercial proprietary rules engines, but appears to be more than adequate for lots of things.

Yay.

Pair Programming

So I have been a long time doubter of pair programming.

I just spent 2 - 1/2 days pairing with this man.

I have to say - I really enjoyed it. Part of it is that I just love slinging code and I became a technical manager of sorts (in addition to remaining a technologist dude) 7 months ago. Pairing is a great way for me to get my code fix. Even after 7 months of not slinging heaps of code, certain corners of my brain started turning off. It was great to dig back in and light those corners back up. I even came up with a good idea to simplify something and received my "space man merit badge".

Our small team has been experimenting with pair programming for those that want to. It has been very successful.

I think that some of it is the fact that we are dealing with so much new (at least to us) technology. Pairing is (obviously to me now) a great way to spread knowledge, learn, etc.

I certainly don't think that 8 hours of pair programming every day is appropriate - at least for me or probably most people. But it is clearly a great thing to do *at least* a couple times per week or some such. I guess it depends on your role etc.

Anyways, I love it when a long standing belief / opinion of mine changes. It helps me know that I am pushing myself outside of my comfort zone and pushing myself. One thing is obvious (or should be) about the world we all live in now. Those that stop learning are toast. If you aren't learning new things (e.g., about your domain, techniques (e.g., agile, lean, xp, etc.), technology, negotiating/people skills, hospitals/manufacturing) you are going to hit a wall. It is amazing how comfortable you get with this concept once you sign up with life-time learning. I am constantly amazed at how many people don't view the world this way.

Shallow vs. Deep Entry Models & Mapping

Ok so guess what - JavaSpaces isn't a silver bullet! Shocker.

I am fond of talking of two big problems I have had in the past with ESB style architectures: excessive mapping and issues managing state (active/transient state vs. steady state/long-lived storage).

The mapping you deal with in an ESB includes object to XML (OX) and object to relational (OR) and various object to object mappings. Update (few hours later) - forgot one: And if it is a message-centric ESB, active/transient state to your destination names (e.g., hierarchical Topic names).

It isn't surprising, but I'm finding that all of the same object to object mapping is still there with JavaSpaces + an object to object equivalent of OX.

The ESB systems I have worked on in the past had a canonical message format. All messages that bounced around the ESB conformed to this model. Some of the messages were small validations of particular data (e.g., address scrub). The main work flows, however, were large XML documents loosely following the ACORD XML standard (insurance industry XML guideline).

With JavaSpaces, the patterns you read about use distributed data structures. Instead of having a large Entry in the space you have many that are related to each other. You do this for transactional reasons, serialization reasons, flexibility reasons etc. Some of the objects I deal with are indeed very large. Doing a take on a large object only to navigate the object graph and flip a bit and do another write isn't performant or flexible.

So the "shallow" model (lots of small interrelated Entries) works great for UI input, address validation etc.

But there are also areas of the system (some key work flows) that would benefit from a canonical form - the "deep" Entry model. Rather than having each worker gather all the Entries up to make sense of them, you do this once and then write the deep Entry to the space and let various workers use it to walk it through a work flow.

But now you have to render it back to your UI that expects a shallow representation.

So the deeper I get the more I realize that JavaSpaces do not make the mapping angst I have encountered go away. The mapping is still there. It is certainly improved because it is object to object mapping that is easy to write unit tests for etc., but it is still there. Update (few hours later) And there isn't any active/transient state mapping to destination names so at least one is eliminated entirely :)

These same issues are also present with a distributed caching solution I believe.

Do I have this right or am I missing something?

People are Talking

People are Talking. Talking about JavaSpaces & distributed caching.

As my co-worker Ed would say, the future is coming!! And so when are the big boys going to notice that the future is coming? Hmmmmm.

Perhaps this technology will be in a few Plan B MRDs this year.

Did Cameron really say this:

Our reason for considering the introduction of JavaSpaces into Coherence is to allow programmers to use the spaces model and the JavaSpaces API to code parts of those transactions. While JavaSpaces is not an effective data management API (i.e. it's not good for replacing a database), it is an effective data processing API (i.e. it can easily be used for computational processing in a grid). So Coherence can certainly bring those two concepts together (data managed by a database and processed using a spaces approach).

Peace,

Cameron Purdy Tangosol Coherence: The Java Data Grid

Yes he did! He authenticated it with the "Peace" key!

Should be interesting to watch - perhaps embedding Blitz? Why don't you OSS Coherence while you are at it? People still need support. Look at JBoss.

Whilst

All you have to do is say whilst and you sound smart.

Why is it that Euro English appeals to me and Canadian English doesn't?

I guess it is just really Irish and English - English that I get a kick out of.

The best is how the Irish (at least the Belfastians I work with) say their filler word. Instead of "um" or "ugh" it's "em". To be globerly (neighborly), we here in Portland have started to say "em" as well. We also occasionally throw them a bone and say "dater".

01-FEB-2007 - Update misspelling per email from my dear mother: Subject: Spelling Correction on Your Blog

uh........em...............not "through" but "throw"

em...er....yer mom :)

xxoo

Distributed Caching != JavaSpaces

I have been talking about distributing caching and JavaSpaces lately.

While you can use JavaSpaces as a caching technology because a JavaSpace keeps stateful objects (Entries) in memory and can be persistent (i.e., survive a failure), it isn't necessarily the best alternative.

Conversely, while you could use a distributed cache as a service orchestration engine because it has an eventing model in it & you could hack master/worker on top of it, it probably isn't the best choice.

The combination of a good distributed cache and a good JavaSpaces implementation, however, may be a good combination.

There certainly is overlap & you have to be fairly deliberate in figuring out which tool you want to use for certain things, but it seems achievable.

A distributed cache is likely the best place to store reference data, hard to query data (e.g., from a mainframe), user session data, etc. where a JavaSpace is probably the best place to store transient conversational service state.

It is the combination of these technologies that allows you to avoid the dreaded work in process database.

More importantly, both technologies use Java POJOs rather then XML so you can avoid a lot of mapping complexity (certainly not all) within the core of a large application.

Anyway, I still have a lot to learn, but am beginning to settle on this distinction.

JavaSpaces sans Jini

Apologies to my new Jini friends. I am a neophyte.

I work with and have spoken with a number of people who say things like, "I LOVE the concept of JavaSpaces - I just don't want to bring all of Jini with it".

What they are really saying is they love JavaSpaces - TupleSpaces really, they just can't stomach the mobile code bit. These are not stupid people. Honestly, this includes me a lot of the time.

Most of these people lived through J2EE and wouldn't bet their job on auto-deployment of a .war file or .ear file work - why should we think something more complex (downloading the code) will not result in panic? I remember talking to BEA about their auto-deployment - some engineer said they had something like a 120 page spec on this functionality alone (and it still didn't work).

I could just send Dan Creswell an email, but I've heard this comment so often that I figured I would put it out here for all to see. I'm sure this topic has been discussed before - thing is it still is being discussed.

Dan, others, are we neophyte's just wimps for fearing mobile code?

How hard would it be to de-Jini JavaSpaces?

Is this completely out of the question, stupid, etc.?

For JavaSpaces to see a lot of mainstream usage 1 of 2 things needs to happen IMHO:

1. Educate the neophytes on the power of mobile code. Help them not fear it. Help them to convince their infrastructure and security groups that it is viable
2. Create a JavaSpaces sans Jini (really sans mobile code) version

Update 07-JAN-06 PM - I'm hoping that at the very least some education can occur via this post for me and other Jini neophytes. So I started this wiki page at jini.org.

Simplicity & Integrating with Less Code

I have been on a distributed caching & JavaSpaces kick lately due to the reasons listened here.

I was talking to my co-worker Erik yesterday and we concurred that one of our biggest goals is to come up with an architecture that is as simple as possible and requires the least amount of code.

Coming from my experience with SOA of various flavors and EDA, I have been on many projects that wrote way too much code. The more code the more defects. This is what is so appealing to me about JavaSpaces and potentially distributed caching (e.g., memcached, Tangosol Coherence) (or some of both). In the core of an application it is possible to use these layers as your service orchestration tier as well as your transient data store. This is very appealing as you skip a significant amount of OR and OX mapping which saves heaps of time and defects.

The JavaSpaces API itself is extremely seductive. Lifted from here:

• write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space.
• read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space.
• take: Works like read, except that the matching entry is removed from the space and returned as the result of the take.
• notify: Takes a template and an object and asks the space to notify the object whenever entries that match the template are added to the space. This notification mechanism, which is built on Jini's distributed event model, is useful when you want to interact with a space using a reactive style of programming.
• snapshot: Provides a method of minimizing the serialization that occurs whenever entries or templates are used; you can use snapshot to optimize certain entry usage patterns in your applications. We will cover this method in detail in a later article.

With the addition of JavaSpaces05, there is collection based (i.e., bulk) read, take, and write.

The integration patterns possible with this API are very powerful. Master/Worker, distributed, highly scalable data structures, etc.

It appears that with certain distributed caching vendors, you can achieve some semblence of these patterns, although I am not convinced of that yet, and the associative nature of JavaSpaces (i.e., you use templates containing objects with what you are looking for in a space to find it) is just amazingly seductive.

Love it or hate it, JavaSpaces comes with Jini. To a newbie like myself, Jini takes some getting used to. The whole mobile code bit tends to make people who have lived through J2EE classloader hell nervous. But there are those who say it works fine in Jini. It is a different paradigm and this makes people very nervous.

Maybe what is needed is a mix of J2EE (specifically servlet, JMS, JMX MBeans), distributed caching, and JavaSpaces. Maybe you can use JavaSpaces for both caching and service orchestration. Maybe you should use all of Jini. Maybe there is something else.

From previous lessons learned around persistence in EDA, I am 100% convinced that we need some sort of flexible transient data store (no work in progress database - I beg you!). I see that today as being some form of a persistent distributed cache that requires very little if any mapping code. I also have seen the power of asynchronous integration and SEDA and am not about to give up on it. JavaSpaces and Master/Worker appear to give me that. What other ways are there? Maybe things that I would have considered anathema a year ago like sending objects through JMS for the eventing layer isn't really that awful? I do know that I do not want XML at the core of a brand new system again - again way too many defects with mapping etc. Too slow, too lame. Sure, at the periphery to integrate with services that require it, but never again in the core of the system.

Lots of thinking results in lots of blather . . .

Bottom line, I want this to be as simple as it can be and I want to write as little code as possible. Oh and it should scale like the dickens, be simple to specialize, maintain, etc.

2007 Predictions

I promised last week to post some predictions for 2007.

Here goes . . .

1. Even the day coders will run screaming from WS-*. The battle is won; we night coders killed it because we didn't want to be controlled by vendor-pires and it is fundamentally flawed technology. Sadly, even though I believe that it is dead, it will take 2 more years before the industry echo chamber comes to terms with it. Software vendors who are heavily invested in WS-* will spend 2007 doing two things: one last gasp at making WS-* happen and quietly writing their Plan B MRDs.
2. REST usage will increase in lieu of WS-*, but it won't unseat messaging and other middleware.
3. People will settle down a tad about Ajax. It's great and all, but I've been seeing more and more botched impls. Like just about everything, its just a tool not a dogma.
4. XML will finally be considered one tool in the tool chest just like every other technology. Development teams will only use XML where it actually adds value and not force it into places where it does not belong.
5. The virtualization march will continue.
6. Distributed Cache and JavaSpace usage will accelerate as more people grok the power of this architecture style.
7. Apache River will breathe new life into Jini/JavaSpaces. Both will see lots of new interest and implementations. 2007 will be a "rebuilding year" (as they say in sports) - 2008 will be the big year for a Jini/JavaSpaces come back. Someone from Sun will formally apologize to all the people maimed by J2EE in 2009 and acknowledge that they should have marketed Jini as a service technology from the beginning (ok just kidding that isn't going to happen).
8. The Open Source patent war will begin in earnest.
9. Community Source Software will slowly start to take off in industry verticals as more executives grok the possibilities and come to terms with the fact that they are already sharing industry vertical software with their competitors; they just don't have access or any control of the source code. Look for a success or two in 2007 which will set the stage for a pandemic by 2009.
10. Even more smart people will start blogs or at least start reading blogs which result in even more transparency and open collaboration between software vendors, customers, and consultants and ultimately better software, more innovation, and less waste.

Alright, that is all I have . . . mostly just a bunch of blather, sorry. I am very excited about 2007. Should be an exciting year to say the least.

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.

Apache River

Apache River is a new Apache podling (incubated project).

This should be fun to watch.

2007 is going to be fun I think.

"River" is a good enough name - I like it, but then again, I love rivers