As promised, Gruple has moved from Googlecode to Codehaus. You find it’s new home here: http://gruple.codehaus.org.
All the documentation has been ported. There are new mailing lists. The source is now in a Git repository. And the 1.1.1 distribution is available from the distro site. Everything is (or should be) linked to from the main page.
Thanks to everyone who commented or helped.
I had almost given up on Gruple because I had no idea if anyone was using it. But it turns out I need it so badly myself that I got a second-wind and implemented transactions. I released v.1.1 yesterday and then realized with horror that it had serious bugs. After a frantic morning, I’ve got Gruple v.1.1.1 out and I believe (pray) those bugs are addressed.
That is not to say that I’m completely confident there are no bugs in Gruple as it stands! I have noticed occasional bad behaviour, the sure sign of a concurrency time-bomb somewhere. I’ll keep doing my best to track it down, starting with adding concurrent unit tests with the help of GroboUtils. If you use Gruple and have any problems please do let me know.
Finally, Gruple will be moving to Codehaus fairly soon (it’s approved, but there is work to do.) This will give it greater exposure. I’ll be switching to a git repo, because that just seems to be the thing to do (and I hate SVN with a passion anyway.)
Now if only I could get someone at Terracotta and SpringSource to work on supporting Groovy in the Terracotta product, I’d be laughing. And so would you.
I’d like to announce the first release of Gruple, a tuplespace implementation for Groovy (and Java, of course.) Release 1.0 is an *in-process* space only, meaning that it can be used to co-ordinate and synchronize threads, but not separate processes. It’s intent was to add one more tool to the toolkit for making concurrent programming simpler. (A remote space, allowing co-ordination among separate processes and/or nodes is on the roadmap, but not near the top.)
You can find the project at http://gruple.googlecode.com
After downloading and building the source (there’s an ant buildfile to make it easy enough), please read the Demos page for some instant gratification. 😉
Please enjoy it, and I appreciate any feedback (including bug reports!)
Happy concurrent programming!
Actors are a popular way to write concurrent & distributed programs. Immutable messages are passed between actors which do the required processing, avoiding the difficulties inherent in sharing data among threads/processes.
Tuplespaces (best exemplified in current times by JavaSpaces) are a way to decouple cooperating processes by using pattern-matching to share immutable and persistent data objects.
Many distributed algorithms can be modelled as a flow of objects between participants.
Or, if you prefer, substitute “parallel” for “distributed” and “messages” for “objects”.
So what do you get if you combine the pattern-based communication of tuplespaces with the message processing paradigm of actors? Loosely-coupled actors.
Actually, as I see it, you get two things:
In both cases, a (hopefully) better way to write concurrent programs.
To the best of my knowledge, no one has tried this yet.
Note: I wrote a longer piece on this topic yesterday with more explanation and references. For those wanting a little more…
In April I wrote the following to a colleague after reading ZDNet’s article on the announcement of LiveMesh:
I have absolutely no respect for Ray Ozzie as an architect. Everything he’s ever created has been overcomplicated shite only an architecture astronaut could love. Seeing the current confusion over “what *is* this thing?” doesn’t give me much hope he’s going to change that pattern this time around.
Since I got the term “architecture astronaut” from reading Joel Spolsky it was a happy circumstance to find that he has a similar (though wittier) opinion of Ozzie’s LiveMesh:
Windows Live Mesh is not just a way to synchronize files. That’s just the sample app. It’s a whole goddamned architecture, with an API and developer tools and in insane diagram showing all the nifty layers of acronyms, and it seems like the chief astronauts at Microsoft literally expect this to be their gigantic platform in the sky which will take over when Windows becomes irrelevant on the desktop. And synchronizing files is supposed to be, like, the equivalent of Microsoft Write on Windows 1.0.
It’s Groove, rewritten from scratch, one more time. Ray Ozzie just can’t stop rewriting this damn app, again and again and again, and taking 5-7 years each time.
And the fact that customers never asked for this feature and none of the earlier versions really took off as huge platforms doesn’t stop him.
By the way, here’s the “insane diagram” I assume Spolsky’s referring to. Or maybe it was this one.
What’s the lesson here? Well, for one thing, that when Steve Jobs put a bullet in OpenDoc, he did the right thing. What other astronomical architectures would be better put out of our misery?
Leigh will have plenty to say later on about why we’re so stoked about our new product, ucaster. But first I want to say a little bit about why we built the tecnhnology behind the product in the first place.
In a nutshell, it just bugged me that every computer and every device was not actually a node on the Web. Despite the fact that personal computers in particular are more than powerful enough to act as web servers, the physical and logical topology of the Interent as deployed relegates most devices to being web clients only.
The Web 2.0 phenomenon has improved the capabilities of lowly web-clients, allowing them to contribute content as well as consume it. This is a great thing, and I don’t mean any insult by saying that by itself it just isn’t enough.
I wanted a Web that was end-to-end. Where every device could provide as well as consume web services and content. Where every shared resource had a resolvable URL.
Just because your laptop or your phone don’t have the full power and connectivity of the “great server cloud in the sky” there’s still plenty you can do with them if they’re able to join the network in an active capacity.
So that’s what we set out to do. Our first product, ucaster, is intended to be the easiest method ever invented for publishing your own content on the web. If you can drag files from one folder to another, you’re an expert user already. There are no servers in between you and your friends (or colleagues) with web browsers viewing your content. We don’t upload anything anywhere, we don’t replicate anything anywhere. You own your own stuff. You control who sees it and when. We’re just flinging packets around to make that possible.
I hope you enjoy the freedom. We certainly do.
Cross-posted from the official oponia networks blog
I came across this presentation on Super-Peer Architectures today. I haven’t had time to read it in full, but it looks stuffed with useful data. It will especially appeal to anyone interested in the architecture of Skype. A list of the authors’ other publications can be found here and here.
Google is a “global technology leader”, the tech company to watch in the 21st century; and Amazon is an online retailer—so 1999. Right?
A casual perusal of the blogosphere and IT news sites would seem to suggest such a consensus. Amazon gets occassional kudos for its web services initiatives like the Simple Queue Service (SQS), the Elastic Compute Cloud (EC2), Alexa Web Services, and it’s Simple Storage Service (S3)—though many wonder why they’re spending so much money on something apparently not core to their business (something like $2 billion so far, according to a CNET News article).
But when people think of strategic technology leadership and innovation, they generally think Google, not Amazon. There’s no shortage of hype about Google becoming “the web platform that powers much of what people do online”, the “Microsoft-killer” with its very own OS (this one is particularly absurd), and “the locked-in platform on which web applications and services are all built.” These are only a few selected examples of which there are countless others on any given day.
Now there’s no denying that Google has a lot of smart employees and a lot of cool technology. However, little of that truly innovative technology does anyone but Google any good. For example: the Google File System is by all accounts way cool, but noone outside Google is ever likely to benefit from it. And their expertise in such hardcore tech neither directly generates any revenue, nor builds any profitable relationships with users, advertisers, or partners. An MIT Technology Review article, What’s Next For Google quotes a couple of employees claiming: “Google’s leaders believe that the company’s expertise in infrastructure—knowing how to build and operate those 250,000 servers—constitutes a competitive advantage more important than APIs or standards.” Uh oh…
Amazon, on the other hand, has apparently made a commitment to turn their technical know-how and serious real-world experience into a profit centre. Since it costs so much money to develop the kind of high-performance, highly-distributed, fine-grained Service Oriented Architecture for their own operations, it makes sense to monetize it. As this ACM Queue interview with Amazon’s CTO Werner Vogels (who also maintains the personal blog All Things Distributed) makes clear, these people know as much as anyone about how to make composite web services actually work on a massive scale. And they realize that this is a strategic asset with real growth potential. As Vogels says: “I think our biggest success has been that Amazon has become a platform that other businesses can benefit from.” And: “We see Amazon.com as part of the larger Internet ecosystem, and we want to stimulate innovation wherever possible.”
Contrast this view with the recent kerfluffle over Google’s abandonment of its SOAP-based search API. The issue here has nothing to do with the technical supremacy of AJAX over SOAP, and everything to do with the fact that—despite its self-description as a “global technology leader”—Google makes 99% of its revenues from advertising (did you know they own a radio advertising subsidiary?) With such a business model, only eyeballs matter. Machines and software processes cannot view ads, cannot be influenced by branding messages, and do not make purchasing decisions. For Google to become the sort of web services platform so many people seem to expect, they’d have to radically change their business model. As it is, there’s absolutely no advantage to Google doing anything other than forcing more and more human eyeballs to view more and more ads. Having worked in advertising for several years (I’m in recovery now, thanks!), I know as well as most that doing so requires making decisions that are directly counter to the interests, needs and wishes of your customers and users (no matter how much account directors may protest that consumers actually want what’s being shoved down their throats.)
So, to end this long-ish rant, don’t look to Google to provide any real technology leadership anytime soon (cutesy AJAX email interfaces really aren’t going to change the world—sorry.) Instead, consider what you might call “The Long Tail of Web Services”: “Ultimately, Amazon wants to build up a massive partner network of tens of thousands of third-party outfits, ranging from corporations to developers and even hobbyists. ‘I’ve always thought that high-volume, low-margin businesses are more defensible,’ Bezos said.”
Coming soon: a tutorial on running a network of JXTA super-peers on Amazon’s Elastic Compute Cloud.
Update: there’s a new, related post, here.
