There are so many arguments concerning the merits of one technology over another. And sadly most of these arguments are pointless because the perspective governing the arguments is unreasonably biased towards one or other technology.

For example, when we compare JavaSpaces with JMS, we do so from the perspective of what we’re used to with JMS. This means we consider a JavaSpaces-based equivalent using all the old patterns, approaches etc of JMS. Then we look at the results and pronounce that, in the best case, JavaSpaces is no better than JMS. How could it be better? You effectively constrained your non-JMS based technology to being used in a JMS based way.

Essentially, we frequently are engaging in what are apples and oranges comparisons believing they are apples and apples.

There are a number of side effects to this behaviour:

• It inhibits the rate of progress in our industry because we continue to design the same way and demand the same old features regardless of their suitability.
• By treating everything the same, all discussion of advantages is reduced to ‘ilities such as performance as these are the only remaining visible differentiators.
• The designs we use are rarely as good as they could be.

In general, to measure the true suitability of a technology to a problem one must solve the problem in the appropriate way for each technology we are considering rather than from the single standpoint of a technology we are already familiar with.

[Inspired in part by some bits of this posting and associated comments.]

Blitz has taken something of a back seat for a few months whilst I’ve been running around consulting, doing talks/presentations, evangelizing and taking a well-earned holiday.

Over the last couple of months I’ve been working with eTapestry who have some JavaSpaces stuff in their production environment. Amongst other things, we worked through some performance and architectural stuff but a key piece of feedback came in the form of a test which was showing up some problems in Blitz’s caching/indexing code.

I’ve been working on those issues for a while now and it’s lead to a significant simplification of Blitz’s core architecture with some useful performance benefits and a reduction in code-size.

I’ve also added some new features one of which is the ability to run user-specified code at boot-time. The user-code receives a copy of the Blitz proxy just prior to it being published via JoinManager into Jini lookup services. This neatly solves a common set of problems associated with initializing content in a JavaSpace and some other interesting issues. There’s also a much broader range of statistics available via programatic access covering number of dirty entries in cache etc.

I’ve upgraded to the latest version of Db/Java after working closely with Sleepycat on a bug found in a previous release which caused me to do a release of Blitz back-ported to a previous stable version.

At this point, I’m stabilizing the codebase, doing some profiling and some soak tests including the usual thrash tests and memory-leak detection routines. If things go well, I should have a new version out early in January.

Update: And it’s out - on New Years Day and in case you’re wondering, that’s just a happy accident, if I’d attempted to do it deliberately you’d still be waiting! It’s on SourceForge in the usual place and you should consider it alpha for a while - I have thrashed it but it pays to be paranoid…..

Still suffering from the marketing issues from way back when. Sadly, many a Jini evangelist still has vestigial aspects of the old marketing in their explanations. Time to clear the decks - here’s my Jini in a nutshell for techs:

• It’s about software services - doesn’t matter whether they run on servers, desktops, laptops, phones, toasters or anything else.
• Just because some piece of hardware uses Jini doesn’t mean that it must embed the entire Jini stack, support multicast etc.
• Jini services don’t have to be all Java.
• Services at compile time, know what other services they need to function - and it’s specified in a fashion that an IDE can reverse out for you (if I just had time to write the plugin).
• Services at compile time don’t need access to (via classpath etc) the stubs or proxies of the services they are dependent upon.
• Services can at runtime find the other services they need (without need for static naming strategies) at which point they receive the proxy or stub required to communicate with/use that service.
• The way in which services find each other is such that there’s no risk of the usual dependency loops where service y needs service x before it will start and vice versa.
• Jini Service deployment can be done in completely non-stop fashion - no restart of containers, web servers etc.

Once you’ve got your head around the above, you should probably get to grips with the Jini System Architecture which breaks down into three categories:

• Programming Model
• Infrastructure
• Services

All of which are covered in the overview section of the architecture document. Read the rest of the document and you’ll hopefully see that Jini systems aren’t like other kinds of system and require some new modes of thought.

Inspired by this from Fuzzy.

As we all know, there's an ongoing debate across mailing lists and the blogosphere about REST versus WS-*.

One of the key areas of discussion comes down to the assertion that only the web-technologies (as favoured by REST) can provide internet scale solutions. But does this really stand up?

The web is when all distilled a pile of cross-linked, navigable information with a standard set of operations. The thing is that these standard operations whilst apparently simple aren't simple come implementation time. This is because these simple operations against resources actually map down to a whole series of other operations. For example, let's say my Servlet based web-server receives a POST of some description. Some servlet must go away and perform the relevant associated operations, tweak a database, write a message to a queue etc to get some work done.

Thus, somewhere, at some point, your systems will have to do some hard work and that work must be made to scale. That is to say, you must for example, have scalable, transactional data-storage.

So then, Enterprises don't just need web-scale, they need web-site scale. That is to say, they must scale their internal systems to support the load they are placed under at the web-site.

Thus the question remains - how do we scale our services? And as demonstrated by the likes of Google and Amazon, the answer is not about REST it's about architecting systems that support horizontal scaling. Just check out this recent slide set from Dan Pritchett of eBay which, incidentally uses J2EE etc (it's also worth paying attention to how they scale their databases).

So am I anti REST? No, but I'm not pro either. REST has some admirable traits such as simplicity etc but those properties are generic targets we should all be striving for in our designs. And I think it's safe to say that few of those generic design centres have been a focus for WS-*. But for me, the real problem with the whole WS-* effort is that we haven't got enough distilled experience to:

1. Determine what standards if any, need creating.
2. Determine what the real problems and the optimal solutions might be so that we can standardize.

Experience comes first, then standards follow - not for the first time, our industry has tried to do it the other way around.

In summary, when comparing REST and WS-*, I don't think the web-scale argument really stands up as a justification for choosing one way or the other. But from a purist perspective, one can't help but notice that one of them seems to hit a lot more of the “right” design buttons than the other.

Tired of your job? Need to hire developers? Visit DZone Jobs: great people, great opportunities.

There is a saying “Don't flip the bozo bit” - I have a new one:

“Don't flip the Dalek bit”

That is to say, just at that point where you wish to “Exterminate!” the developer who broke the build, you should go get a cup of camomile tea and think happy thoughts for 30 minutes.

Tired of your job? Need to hire developers? Visit DZone Jobs: great people, great opportunities.

As noted in my previous blog entry, I talked at the inaugural Next Net meeting last night about the work I’ve been doing for Lone Crusader on top of Amazon’s EC2 and S3.

Thanks to all those who turned out and asked some great questions, including James Strachan (glad you liked my S3 locking hack!), Matthias Radestock from LShift, Adewale Oshineye from ThoughtWorks and the BetFair gang.

BetFair should also get a mention for supplying the beer and pizza.

Big thanks to Nigel Warren (NetCaboodle/Brunel University) and Ewan Silver (BetFair) for putting in all the organizational effort to get this started - looking forward to the next meeting already guys.

Finally, for those that requested a copy of the slides, you can find them here.

Technorati Tags: Jini, EC2, S3, Amazon, Next Net

Tired of your job? Need to hire developers? Visit DZone Jobs: great people, great opportunities.