Shashi Velur’s blog

I am very excited to receive my Google Wave Developer Sandbox account.

Google Wave is actually three layers - the Product, the Protocol, and the Platform. What I am seeing in the Developer Sandbox is actually the Product using the Platform and the Protocol.

After spending a couple of hours with Google Wave product, to say the least, I am amazed at it’s complexity and it’s richness as a comprehensive unconstrained communication platform. If we can conquer it’s complexity perhaps by using a simpler Google Wave Application, I wonder what this would become in a year.

I cannot help but compare Wave with the traditional communication channels. So, here it goes:

Wave vs. Wiki/Microblogging/Email/IM/IRC:

1. Wave messages live on the Wave server instead of the local client.
2. A complete history of each Wave as to who did what and when is maintained on the server and it can be replayed any time.
3. Google Wave is built on the Google Wave Federation Protocol is an extension to the core of XMPP.
4. Liveness: Editing a wave is immediately visible to other users as it is edited it. You can watch your contact edit a wave live.
5. Tagging and built-in search available.
6. The Wave platform supports two types of Wave extensions - Gadgets and Robots. This gives Wave a lot of potential, openness and richness.
7. Google Wave session is encrypted (https).
8. Google Wave is actually three layers - the Product, the Protocol, and the Platform.
9. The actual Google Wave UI seems to be very fast and responsive. But, is still very raw and unstable in a few areas. Some features seem to be disabled right now. This is understandable because the beta product is still possibly a few months away.
10. Google Wave is a web application and so only a browser is required. 

I was warned that IE 8 is not a supported browser. However, after I chose the option to continue, it worked. To be safe, I used Google Chrome 2.0

I plan to read, experiment and blog more about the Google Wave Platform, Protocol and Wave extensions in the near future.

Technorati Tags: Google Wave, Google Wave Developer Sandbox, XMPP

Web applications are the most common type of deployments on the application servers.

So, if OSGi is going to be a serious contender in the application server market, I would expect it to have great support for deploying web applications using WAR files. So, I looked through the existing documentation on eclipse.org and played with Equinox, Tomcat and Jetty. Here is what I have learned so far:

There are two ways to integrate Equinox’s implementation of OSGi into your server-side environment:

1. Embed your web application server within OSGi server
   • Native OSGi HTTP service implementation of Servlet API 2.4
   • Jetty-based implementation - Also requires the usage of the dynamic OSGi HTTP Service.
2. Embed OSGi server into your existing web application server
   • Equinox Bridge Servlet (Front controller servlet)
   • Dynamic OSGi HTTP Service using the Equinox Bridge Servlet

Option #1 means that the developer is forced to use OSGi HTTP Service. This is great for new web applications built from scratch. The user can programmatically register the servlets and add service listeners to listen for any events (if any one of these instances are started, stopped or updated, we are notified). But, this complicates the development effort required for making an existing WAR file work with this setup. Traditionally, Servlets have been considered “static” - They do not have to be installed/started/stopped dynamically. So, the “dynamic” OSGi HTTP service becomes an overkill in this particular case, IMO. The other disadvantage of this approach is that not all aspects of the Servlet spec are implemented here. For ex., Servlet Filters are not yet available in the native OSGi HTTP service implementation. I am not sure how clustering can be achieved here.

Option #2 uses the standard “Front-controller” pattern and uses the Bridge Servlet as a Front controller servlet. org.eclipse.equinox.servletbridge and the Servlet API are exported automatically to the underlying OSGi framework. So, the modules deployed in the OSGi server have access to the Servlet API to register/unregister servlets. This approach obviously uses the web.xml. So, you can add more servlet mappings for JSPs, if necessary. The other sub-options here revolves around using this Servlet bridge to provide the dynamic OSGi HTTP service.

So, I do not feel comfortable with both of the above options provided by Equinox OSGi implementations. Perhaps, other implementations might have better solutions.

No wonder the folks at SpringSource chose not to implement OSGi HTTP service in their SpringDM server platform for now. They support the standard WAR file deployment within their embedded Tomcat server. This seems like a pragmatic approach to me to support all the existing standard Web Application Archive (WAR) files.

Although I like the other dynamic services (Logging, Configuration, Event Admin Service, etc.) in the OSGi Service Compendium, I am not so sure about the HTTP Service, especially for existing web applications.

What do you think?

Technorati Tags: Equinox, Jetty, OSGi Compendium, OSGi HTTP Service, Servlet Bridge, SpringDM

This is awesome. I am excited to see the new browser wars. This reminds me of Netscape Navigator/IE 3.0 days..!

I hope this brings some much needed out-of-the-box-thinking of the whole browser-to-server interactions. Here is a good list of the feature requests by OpenAJAX Alliance.

In my career so far, I have written various types Rich-Client applications on Browser using various forms of HTTP tunneling for server interaction:

• Java AWT/Swing Applets: Custom Java serialization
• Flash/Flex: Flash Remoting/AMF/ASTranslator
• AJAX: XML-RPC, JSON

All of the above suffer from at least one issue that I know of. The browser client application has to poll to get server updates to the Clients. There is no server-HTTP-push. This leads to unnecessary complexity in the Client-side code (usually in JavaScript or ActionScript).

I hope there will be some sort of an effort towards raw sockets (or something similar but more powerful than XHR) for the browser with proper sandboxing for the plugins to reduce the security issues due to raw sockets. This means that JavaScript language might have to include some support for network programming too.

Another thing I really wish is a simple/powerful API on the Google browser to write new plugins and widgets.

Technorati Tags: browser wars, Google browser