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.

Mobile Code vs. Mobile Data

As I am trying to learn more about Jini and specifically mobile code, I came across this blog post at discipline and punish.

For almost a decade now we've been steadily marching towards mobile data. For many, distributed computing is summed up by the motto: it's just data. But it's interesting to note that, with the (re)(re)emergence of Grid Computing, mobile code is poised to make a comeback. While mobile data allows for a lot of dynamicity in the consumer-side, it's mobile code that lets you deal with major dynamicity on the service-side. When you have dozens (or hundreds, or thousands) of nodes constantly coming and going then highly mobile services really start to pay off. The JINI guys are certainly on to something and question of which approach scales better is far from settled. I suspect in the future we'll rely heavily on both distributed computing styles.

Sounds about right.

Also Dan Creswell is helping to educate me - thanks Dan!

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.

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

2007 Predictions Starting

Here come the 2007 predictions. Who doesn't like these? Perhaps we need another round of blog tag on that ;)

Patrick Logan has one that I'd like to see come true. I'd at least like to see a good hard look at it. I've lived web services, ESB, EDA, and they all have their issues. I'm sure Jini/JavaSpaces has its as well, but perhaps the best of all of them is the right fit (ok REST not web services).

As the industry comes to term with the failure of WS-* we can either start over and reinvent things again or perhaps take a look back at some of the technology that should have been front and center to begin with.

I will post my prediction next week.

Jini Red Pill

My point is, that all this JBI/BPM/Web Services/'Lets Ra-ra-ra about RoR' is what you get and what you accept when you take the Blue Pill, so the thing is why don't you have a go with something different, could be anything (for those that have never tried Jini but have even a slight interest in SOA, have a look it doesn't bite). Follow your enthusiasm, you'll never know where it might take you. Take a chance - take the Red Pill

I like all references to the (now) eternal Red Pill. I loves the Red Pills. They keep me spry and handome.

I also like all things and people that are wise enough to diss JBI/BPM/Web Services in one sentence. Now that is a skill.

Mind you I have heaps to learn about Jini and JavaSpaces. Just saying I like this sentence.

All I know is WS-* is dead, REST doesn't cut it for (a lot of) the stuff I do, and I know enough already about the problems with ESBs and Messaging. I want some new problems to deal with. Or at least I want to fix a couple problems. No idea where it will go at this point.

I will say that I am going to be really pissed at Sun if Jini does turn out to be great. I mean I lived through 5 years (5 years!!!) of J2EE - all of it - even CMP!! If Jini is heaps better and Sun put me through that misery just because they totally botched the marketing campaign around Jini then I'm going to be a little upset.

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.