Monday, May 23, 2011

Practical SOA Building Blocks


I'll make this short. This post is not a theoretical discussion of what SOA is. This is a practical guide to the core physical components required to build a "traditional" SOA-based ecosystem.

I believe there are three basic components required - a Service Container, a Broker and a Process Engine.

A Service Container is used when implementing business logic to expose as a service.
A Broker is used to connect to legacy business logic through mediation, routing or transformation.
A Process Engine is used to coordinate two or more services into a process and expose that as a composite service.
We put these together in different combinations to build out the specific business processes we need. Needless to say, what we run on these components should be reusable, so their interfaces need to be generic, yet extensible. Good data design is required for this.

Wednesday, May 18, 2011

The Return of JavaScript


Hardly had I begun to play with Node.js when a friend pointed me to this news item about JavaScript being used to run Linux.

Déjà vu all over again.

Some months ago, after the perceptible pall that descended on Java with the Oracle takeover of Sun, a group of tech enthusiast friends of mine opined that the time was ripe for a new technology. Java was now legacy. It would continue to grow and influence, of course, but its glory days were over. Java had been a shooting star under Sun. Under Oracle, it was now a cash cow. The next paradigm shift would therefore have to come from a new technology altogether. Much as we might pride ourselves as technology futurists, we only struggled to pierce the veil. We spoke about Android, cloud computing, NVIDIA processors and Web 3.0, but none of us imagined that the revolution would come from an established and very familiar technology.

JavaScript is as old as the web, and born close on the heels of Java, which explains its confusingly similar name. (Well-meaning managers at leading technology companies were known to discourage programmers from writing JavaScript because they heard that the corporate firewalls were configured to block Java applets. Microsoft evangelist Stephen Jeffries even ruined a perfectly credible sales pitch for Microsoft technology in 1999 by claiming to have written "some Java scripts", which were inferior to his company's offerings, of course.)

Naming confusion aside, not many will remember that in the early days of the web (circa 1995), Netscape not only had a browser (the legendary Navigator), but also a web server, a directory server, a certificate server and many other components of a web-based ecosystem. JavaScript was a Netscape invention, and the Netscape web server could run Java servlets as well as JavaScript code. There was an attribute that could be used with the "script" tag in HTML, which was "runAt = 'server' ". JavaScript running on the server - imagine that!

But that initial innovation died out shortly after. JavaScript became a purely client-side phenomenon. Other languages, notably Java and PHP (and ASP in the Microsoft world) took over the server side.

The next time I heard of JavaScript running on the server side, it was in the context of WSO2's highly innovative Mashup Server.

Server-side JavaScript was still a rare phenomenon, and had the faint aroma of a toy system to boot. After all, serious software was written in Java. JavaScript was at best useful to demonstrate clever ideas. It wasn't production strength.

Now along comes Node.js with its innovative thesis about how to do I/O right. Ryan Dahl explains the philosophy in a way that appears obvious in hindsight. When you see the numbers he puts up comparing the CPU cycles for different levels of I/O, it becomes extremely clear that it's criminally wasteful of computing resources to wait on disk and network I/O.

L1 cache: 3 cycles
L2 cache: 14 cycles
RAM: 250 cycles
Disk: 41,000,000 cycles
Network: 240,000,000 cycles

Node.js boasts a single event loop which, combined with its absolute refusal to block on any external I/O operation, allows it to scale up to ridiculous levels of concurrency. Add to that the simplicity, flexibility and familiarity of the JavaScript language, and the runaway popularity of Node.js becomes understandable. I'm personally blown away.

Even Ryan Dahl, its inventor, struggles to explain what Node.js is (beyond the obvious fact that it's a bunch of libraries on top of Google's V8 JavaScript virtual machine). That's because Node.js is nothing less than a new platform for innovation. It's clay in the hands of a new generation of developers, and fascinating new products (Node.js modules and frameworks) are emerging.

I think one of these will be a rich GUI library to rival the offerings from Adobe. It will be possible to build extremely flexible and lightweight client apps with rich user interfaces very soon. Web forms will soon seem clunky, because we can soon have web applications without web forms.

Another phenomenon that Node.js will enable is peer-to-peer systems. I believe we've outgrown the synchronous request-response behaviour of the traditional web. Something new and big is coming soon.

So move over, Java. Here comes JavaScript.

Tuesday, May 03, 2011

The Magic of Node.js


A while ago, Google came out with a high-performance JavaScript engine called V8. This is what powers the Chrome browser.

Now along comes an Open Source project called Node.js (or simply Node) that wraps V8 with networking capabilities, enabling some very cool JavaScript-based servers (HTTP or TCP) to be written with just a few lines of code. Servers written for Node are non-blocking and multi-tasking without having to be multi-threaded (the demo below explains more), which also makes them very fast and scalable. This is server-side JavaScript at its best.

This hour-long demo is worth watching. I haven't been so amazed since I saw Scott Davis demonstrate Groovy at JavaOne 2009.

The only downside (not to me, though ;-) is that Node currently only works on Unix-like systems (Linux, Mac) and not yet on Windows. You also have to compile from source (no binaries yet), which is not a big deal because you only have to type "./configure". "make" and "sudo make install" one after the other in the main directory once you've unzipped the tar.gz file using "tar zxvf node-VERSION.tar.gz".

Refcards has a reference card for Node.js.

There are some great possibilities here, such as when you combine this with E4X.