I've written a lot on the efforts in converging web and desktop applications (Adobe Air, Mozila Prism, Silverlight, JavaFX, Google Gears etc.). Now Google ups the ante with the introduction of its new webkit based browser - dubbed Chrome (You can see a comics explanation of its main concepts/features).

Let's do a quick recap before taking more about Chrome. Basically we see all the major players trying to blur the lines between desktop applications and web applications (a.k.a. Rich Internet Applications) some players are on the offensive (Adobe, Google) and some on the defensive (Microsoft, Sun) but the direction is identical. The web oriented companies understood that RIAs are becoming more real application and not "just" web pages. They also understand they need presence on the desktop for easier accessibility and better acceptance by users as a "serious" applications. Furthermore, the fact the applications become more serious and more mission critical, along with the fact that they can (and are) be used on-the-go where disconnects occur, the need for occasionally connecteness becomes more apparent. This is where smart-clients have a lead and technologies like Gears are trying to catch-up.

Now,in my opinion, Google makes a bold move to change the rules and re-define the playground - if webapss need to run on the desktop, let's make the browser the new desktop.
What makes me say that? because it is focused on application (see the comics),because the browser runs each tab in its own process, because it has a process monitor, because it is a link on the google home page...


From the chrome "OS" point of view we can look at javascript,HTML etc. as the IL (bytecode in java speak) on which the application run. This makes cross-compilers like GWT and the good side of MS Volta (vs. the bad side) the next abstraction layer. I expect these will be more significant in the future

Anyway, you can see for yourself if you download it now from www.google.com/chrome


 

As I was going through my RSS list (which I publish as a linkblog) I noticed Reginald Braithwaite's post on the metaobject protocol. Reginald says

The bottom line: Languages like Java give you an object protocol: There is one way to do things with objects and classes and interfaces, period. Anything else, like adding generics or annotations, must be done outside of the language, it must be done by the creators of the language.

Languages like Common Lisp and Smalltalk give you a meta object protocol: You can decide for yourself how to do things with objects, classes, interfaces, generic functions, whatever you want. You don’t need to wait for a committee to try something different.

What's nice is that a couple of posts later I noticed a link by Harry Pierson to an attempt by Jeff Moser to port OMeta to the .NET world and to enable the very "meta object protocol" Reginald mentios. Here are the opening bits from Jeff's post (go read the rest):

What if programming language implementations were object-oriented? What if you wanted to change one itty-bitty part of your favorite language? Say you wanted to add an exponentiation operator (^^). How hard would it be?

Wouldn't it be nice if you could "subclass" a language like C# and then add 5 lines of code to make it work and then use it? What if you could add Ruby-like method_missing support in 20 lines?

What if you could conceive of a new language and start experimenting with it in production code in an hour? What if it leveraged your knowledge of existing frameworks like .NET?

Also check out the code Jeff posted so far (on CodePlex)

 

Unless you've been living under a rock, you probably already heard about the MS offer to acquire Yahoo. While it is Microsoft who is poised to acquire Yahoo (Microhoo) it seems that it is part of the greater move of Microsoft towards moving into Internet based service - all the "live" initiatives along with the "Software + Services" moniker.
I tend to agree with Nicholas Carr who recently published an article in the Financial Times where he talks about how Gates leaving MS marks the end of the desktop era. In fact looking for the above mentioned reference I saw another article Carr wrote for Forbes where he says it even more bluntly

"One important message is this: Software is becoming a media business. The Net is not only a universal medium, a distribution channel for words, sounds and images. It is also turning into a universal computer--the machine we use to run software and store data."

You might also want to check out  a presentation a few of my colleagues  and myself has prepared about half a year ago where we talk about the same phenomena - Called the "Future of Home Computing" (5.5Mb).


In this sense the Microsoft - Yahoo merger (if it will follow through) will result in Yahoosoft a company which is focused more on the internet aspects rather than the more traditional (some would say legacy) desktop aspects of Microsoft.

It is also interesting to note in this sense that while winning the web search (and the related ad-revenue) is something Microsoft is very interested in.  The eyes of Microsoft (and Google for that matter) are on the next battlefield - mobile search. While there are something like 305 Million broadband subscribers worldwide the number of mobile phones sold just in the last quarter of 2007 was larger (334 Millions) and the total of mobile phones worldwide is in the billions... An added bonus here is that Google is yet to take over this market (thought it of course moving in that direction with things like the android platform and location based search and services)

 

David J. DeWitt and Michael Stonebraker are at it again. There was a lot of buzz on the internet after their previous post (here is what I had to say about it).
Their first point on the new post tries to counter the claim that MapReduce is not a database so it shouldn't be judged as one. They claim that it isn't a matter of apples and oranges but rather

 " We are judging two approaches to analyzing massive amounts of information, even for less structured information."

The problem with that is they continue from there to define a problem in database terms and then show how MapReduce will not be as good as a database in solving it - well, duh.
The fact that isolated queries may run better in a pre-indexed database should come as no great surprise. As I noted in the previous post on the subject - MapReduce can be used to create the appropriate index or partition the data into smaller chunks that would be easier to use to answer the type of queries David and Michael mention.
As Mark Chu-Carroll explains Map/Reduce and databased don't solve the same kind of problems

Also what happens when the database is constantly updated ?!  - I don't mind how scientifically accurate are the measurements that say database scale like no other things. I am more comfortable with the empiric experience by companies like Amazon, Diggs, Google and ebay who found they have to shard their data to support their scalability needs and not use distributed transactions/distributed databased.

 

Sam Gentile comments about my attempts to define SOA (Part I, Part II, more to come..) and says that

"That's all well and true, but any definition of SOA must encompass the business drivers and business reasons, as SOA is not really about technology. It is about a better alignment of business and IT through business processes and services. The goal is to create a dynamic, more Agile and Dynamic IT that can respond quickly to new business opportunities and threats by quickly assembling new capabilities from putting together composite applications (and even Mash-ups) from reusable business services..."

I am sorry Sam, but I beg to differ, not about the importance of business drive behind implementing SOA, but about what SOA is. The culprit, in my opinion, is terminology overloading

 SOA is, as I said in the above mentioned post and numerous other times, is first and foremost an architectural style - as an architectural style it offers several architectural benefits and poses several architectural constraints. This has nothing to do with business drivers. it has to do with defining components, relations, attributes on relations and components as well as constraints. Now you can take those set of rules and use (or misuse) them as you like, in the context of a subsystem, single project, a product line or  an enterprise - this is your choice.

Applying SOA, on the other hand, has everything to do with the business . I'll take Sam's post word for word but instead of using the word SOA, I would prefer using the term SOA initiative. An SOA initiative is the effort of applying SOA in a wide context for an enterprise, aiming to increase the alignment of IT and the business etc. I would have to say though,  that in my experience, such an effort would rarely use SOA alone. It would also include other distributed architectural styles that also help with decoupling and loose coupling like EDA and REST to name a couple.


By the way, SOA has nothing to do with technology either. You can implement SOA using WS-*, Atompub, MSMQ, CORBA just as much as you can implement REST with quite a few technologies, it so happens that WS-* is a common implementation technology for SOA, and that HTTP is used as a common implementation technology for REST but both styles live independently of the technologies.

 

Microsoft uses the "live labs" to release all sorts of test balloons. Sometimes we get really nifty stuff like Photosynth or SeaDragon. Unfortunately, sometimes we get stupid not so bright ideas like Volta.

Ok, so what is Volta? Here's what the project's homepage has to say (emphasis mine):

" The Volta technology preview is a developer toolset that enables you to build multi-tier web applications by applying familiar techniques and patterns. First, design and build your application as a .NET client application, then assign the portions of the application to run on the server and the client tiers late in the development process. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together.

Developers can target either web browsers or the CLR as clients and Volta handles the complexities of tier-splitting for you.  Volta comprises tools such as end-to-end profiling to make architectural refactoring and optimization simple and quick. In effect, Volta offers a best-effort experience in multiple environments without any changes to the application."

The idea sounds very compelling - I kid you not. So what's the problem?

The first issue is that, as a platform/framework (MS would say factory), Volta tries to accomplish too much. On the one hand Volta is another go at the web/desktop convergence trend. On the other hand it is supposed to be a solution for "painless" tier-splitting. Both of these tasks are very heavy. My opinion is that the Single Responsibility Principle (while originally defined for objects) applies here. And Volta should choose one thing and try to excel in that.

What's more disturbing to me, is the automatic handling of the "complexities of tier-splitting". Here's another excerpt from the Volta site which further explains the "tier-splitting" concept:

Objective

We have an application that runs in a monolithic environment, say the browser. We want parts of this application to run in other environments, such as servers. We don’t want to litter the application with plumbing code.

Rationale

The standard techniques for distributed applications infuse our code everywhere with information about what parts run where. This makes the code hard to change. Typically, once we make these decisions we can’t change them because it is too expensive. However, environments, requirements, and performance profiles change and we’re stuck with applications that can’t adapt to new realities. We need to separate the concerns about what the application does from the concerns about where parts of the application run.

Without Volta, we are forced to decide where code runs before we know everything it is going to do, in particular before we know the communication frequencies and delays. Development methodologies force us to make irreversible decisions too early in the application lifecycle. Volta gives us the means to delay decisions until we have adequate information to base them on.

Recipe

Volta tier splitting automates the creation of the communication plumbing code, serialization, and remoting. Simply mark classes or methods with a custom attribute that tells the Volta compiler where they should run. Unmarked classes and methods continue to run on the client.

We may base our decisions about tier assignment on any criteria we like, such as performance or location of critical assets and capabilities. Because Volta automates boilerplate code and processes for dispersing code, it is easy for us to experiment with and change assignments of classes and methods to tiers.

Wow, Agile development at its best, allowing us to postpone architectural decisions,  that just sound too good to be true. Well, the problem is that it is too good to be true. Abstracting the network out, and providing location transparency without thinking about the  implications of distribution is the reason "distributed objects" failed. e.g. Here is what Harry Pierson (DevHawk) had to say about distributed objects:

"...back in 2003, mainstream platforms typically used a distributed object approach to building distributed apps. Distributed objects were widely implemented and fairly well understood. You created an object like normal, but the underlying platform would create the actual object on a remote machine. You'd call functions on your local proxy and the platform would marshal the call across the network to the real object. The network hop would still be there, but the platform abstracted away the mechanics of making it. Examples of distributed object platforms include CORBA via IOR, Java RMI, COM via DCOM and .NET Remoting.

The (now well documented and understood) problem with this approach is that distributed objects can't be designed like other objects. For performance reasons, distributed objects have to have what Martin Fowler called a "coarse-grained interface", a design which sacrifices flexibility and extensibility in return for minimizing the number of cross-network calls. Because the network overhead can't be abstracted away, distributed objects are a very leaky abstraction.

So here comes Volta and tells us just put a [RunAtOrigin] attribute on the code you want on another tier and if you don't like that you can change it to another place in your application and what not. Note that the notion that you can automate some or maybe even all of the distribution "boilerplate" code may be viable. The problem is in the premise that you can seamlessly move that boundary around. There's a fundamental  difference between tiers and layers. Tiers should be treated as a boundary .Volta designers do talk about Security but they seem to forget a few of the other fallacies of distributed computing...

 

While everybody and their sister is busy celebrating the release of VS2008. A more interesting* release happened today - The first community release of Ruby.NET (version 0.9). This is another step in the languages trend I discussed here a few weeks ago.

The release is said to have a lot of improvements however, Ruby.Net  isn't running Rails just yet. Hopefully we'd have that soon. Another thing I would love to have is to use Ruby's testing frameworks like Mocha to test .NET classes (which already works for Java and JRuby). Well I am off to test that now :) - you can do that too, if you download the bits

By the way, you may also want to read the paper discussing the design of Ruby.Net (by Wayne Kelly and John Gough who started this project)

---

*my blog - my opinions :)

 

Back in April I wrote how Adobe AIR (then it was still called Apollo) marks the beginning of the invasion of the web clients into the desktop. Later I wrote about the Java and .NET counterattacks (JavaFX and Silverlight) and then I wrote about Google's answer when Google Gears was announced.

Well Mozilla "Prism" demonstrates that even simple steps can help make this transition.
The main idea behind Prism is to "integrate web-applications into the user desktop experience". Behind this fancy statement we have a very simple solution - the ability to add a a desktop/start/quicklaunch shortcut to any web application (or page for that matter)and have that show in a window that is configurable so that it doesn't waste pixels on irrelevant stuff for the applications (like navigation buttons, address bar etc.) - which makes it better then just adding a shortcut yourself. Simple and elegant. Here's what my Google reader looks like with Prism:

If you want to start using it, you can just download the prototype for Mac OS X, Linux, and Windows.