There is one bit of all the current buzzwords that seems to be overlooked, like when people talk about Ruby being so productive for Web 2.0 style projects. It was part of my objection for the introduction of JAX-WS and a Web Server into Java SE 6 as well. Its the rise of async coding models.
Callbacks in JAX-WS are a great example of this, but so are lots of the dynamic elements being done in Web 2.0 and the eventing models of EDA. They require people to code in a non-linear model and require an environment that can handle threads sensibly and efficiently. Async isn't just a matter of "waiting for a request" because then you are blocking, its a matter of actually being able to trigger off a related piece of code when you get the request and then tie it back to what was originally happening and may still be happening.
Async is hard and yet all I've read so far on the web is lots of people going on about how great this new Async model is, without a mention of thread safety around. The rise of Async (and of technologies like BPEL that have Async baked into them) also makes an interesting question around the quality of developers and platforms required.
Ruby et al are all out for this world for professionals until they are thread safe, if you can't even get to that level then how on earth are you going to build ontop of it? So yup you can build something really quickly, then lob in a nice bit of async and you "sometimes" get random behaviour... nice Groovy on Rails could be a migration path for those folks of course as you get the benefits of a thread safe platform. Saying "it was okay when I tested it" isn't enough.
Async testing frameworks are going to be needed and greater use of languages (like BPEL) which include a way to clearly express async behaviour. Currently there isn't really much out there that can do the testing of async applications, paticularly around the Web 2.0 Javascript style model (oooo multi-threading Javascript... nice!). As SOA and Web 2.0 kick-off in a big way and people start using eventing and messaging models for their service interaction and then lob an async interface ontop of it these will cease to be seen as "cool" things and start becoming the biggest code mess IT has ever had the displeasure to create.
Remember Meyfroidt's Law, and start planning now for how you are going to make async easy for the masses.
Technorati Tags: SOA, BPEL, Java SE 6,Web 2.0,Service Architecture
4 comments:
What makes you think RoR doing Ajax callbacks is any less thread-safe than RoR doing regular HTTP callbacks?
What might be tricky about that scenario is the Javascript bit in browser, not what happens on the server (which is just plain boring HTTP request/response handling).
Oh but you're right about async being hard of course: we've talked about in the past.
SM
Oh and another thing. Ruby currently uses a cooperative multi-threading model, so life isn't quite as unpredictable in that world as you're implying.
Go pick on Java or C# instead. :-)
SM
Correct me if I'm wrong, but current RoR isn't actually thread safe even though it has a multi-threaded model. Java had a bug around memory management that was only fixed in Java SE 5 (and Doug Lea claimed he didn't understand the fix apparently!). Its a very hard area and people appear to have forgotten that.
I don't think Ajax callbacks are any more risky than standard HTTP callbacks, its just that Ajax can create quite a few more of them.
If you have to do Rails stuff, why not at least do Grails so its running on a safe platform :)
There may be concurrency bugs in RoR (it's software, right) but fundamentally it's thread-safe. If it wasn't then lots of highly-used RoR-based websites would break. Which they don't.
Grails is interesting... but RoR is nicer to use simply because of its Ruby foundation. Ruby allows you inside the language in a way you might think is very new. Except that the ideas are very old: Smalltalk and LISP should have set the world ablaze back in the 60s and 70s instead of damn BASIC and C (don't get me started on C++).
SM
Post a Comment