The Keene View on Web 2.0, Ajax and SaaS

In February, WaveMaker introduced the first visual development environment for Ajax applications. Today, we have taken another big leap forward in productivity, by launching WaveMaker 4, a point and click development platform capable of creating a fully deployed Ajax application in just 9 mouse clicks!

I'm not talking about some proprietary hairball here - in 9 clicks, WaveMaker takes you from a blank screen to a fully deployed Ajax application complete with Postgres Plus database connectivity and running on a standard Tomcat/Spring/Hibernate server.

With WaveMaker 4, we choose 4 areas where we wanted to be best in class. Those areas are:

1. Lowest learning curve - WaveMaker 4 is the easiest way to start building Ajax applications.
   
2. Highest productivity - our WYSIWYG Ajax studio delivers best in class productivity for basic business applications.
   
3. Sheer beauty - our Dojo-based Ajax client produces jaw-dropping user interfaces.
   
4. Easiest mashup tool - nobody delivers a better mashup tool for web services Java classes and databases than WaveMaker.
   

Over the next few days I will address each of these areas and talk about how we achieved our goals.

Ajax Learning Curve - WaveMaker Stomps Dreamweaver

WaveMaker exists to democratize web development. With WaveMaker, you can point and click your way to a running web application in just 9 clicks and without a single line of programming. We believe this will appeal to two kinds of developers: Java developers who don't want to muck with Javascript, and non-expert developers who want to avoid as much coding as possible period.

For Ajax client development, Eclipse, Netbeans, Aptana and Dreamweaver are all good tools, but require you to be a Javascript (or Flex) expert to build a web application, something that many Java developers would like to avoid. On the SaaS side, products like Coghead and Force.com have a low learning curve, but require you to use their proprietary language, architecture and hosting to just get started - a steep trade-off for ease of use.

How easy is it? Let's walk through the 9 click scenario:

Point and Click Ajax - How To Build an Ajax Application In 9 Clicks

Click 1: create new project. Start the WaveMaker studio. Note that it runs in a browser - note further that WaveMaker studio was built in WaveMaker, a pretty good indication of the power of the tool itself. Note that just for fun I am running WaveMaker in the same browser where I am writing my blog post - just because I can :-)


Click 2: import database (Model). WaveMaker can import the database schema information from Postgres or any other major database, thanks to our underlying use of Hibernate. WaveMaker comes with a schema editor, so you can actually create your database schema within WaveMaker as well. Importing the database gives you the Model part of a model-view-controller architecture.


Clicks 3, 4, 5: create application template (View). Open page designer, open template chooser, drag application template onto WaveMaker canvas. Templates are collections of pre-styled widgets that can give you a full UI in a single click, including a template that inserts a standard search box, list data grid and detail live form. Creating the widget layout gives you the view part of the model-view-controller architecture.


Click 6: create live variable (Controller). Our live variable will hold database customer information. WaveMaker uses a model-view-controller architecture that greatly simplifies the development of web applications. The Live Variables are the controller elements in WaveMaker's model-view-controller architecture. LiveVariables automatically update themselves when the underlying data changes, allowing the widget to be concerned only with data display and creating a clean separation between the Model and the View elements in the architecture.


Click 7: connect customer data to grid. WaveMaker provides an intuitive interface to connect the customer live variable to the data grid. Have you noticed that within the studio you get live data into your widgets? This means that the application is actually running while you design it, eliminating the typical build-compile-run-debug time suck. Is that the coolest thing ever or what?


Click 8: connect selected customer item to customer edit form. WaveMaker exposes the currently selected item as a data source that you can provide as input to the Live Form. The Live Form is data aware, so it automatically configures itself with the appropriate editors to support the underlying data schema, including auto-configuring drop-down selects to set foreign key relationships - seriously cool stuff!

Click 9: press run to deploy your application onto the built-in Tomcat server.


Presto - while any other Ajax developer is still waiting for Eclipse to load, you have built and deployed a complete web application. Give yourself a hand, and give the WaveMaker engineering team a hand to while you're at it!

Postscript

Our celebration launch included some very cold vodka shots and a group pose with the company mascot, a surfboard. Derek claims that if you chill the vodka enough and drink it in one gulp you won't get a hangover. I was not able to confirm this claim - maybe we just need a better freezer!

Labels: AJAX, Coghead, DreamWeaver, EnterpriseDB, Postgres, wavemaker tutorial

For cloud computing to take off, there need to be tools available that enable a developer to build and deploy an application without having to download anything to their desktop. This requires an on-demand development tool that sits on top of the cloud and provides a development Platform as a Service (PaaS).

There are two paths that a vendor can take to create a development platform for cloud computing: cloud-first or tool-first.

• Cloud-first approach to PaaS: first build a cloud platform, then build a development tool that runs on top of it. This is the approach pioneered by Force.com and followed by Coghead and Bungee Labs.


• Tool-first approach to PaaS: first build a development platform that is host-able tool (e.g., studio runs in a browser), then "push" that platform into the cloud. This is the approach taken by WaveMaker.

For Force.com, it made a great deal of sense to take the cloud-first approach. SalesForce.com already had a robust cloud platform and expertise in building proprietary development tools to create their CRM application. There was also no requirement to make Force.com work on any other cloud, because SalesForce is aiming to be the only cloud you will ever need for all your enterprise apps.

For most software vendors, however, the cloud-first development process has distinct disadvantages. First of all, it puts you in the data center operations business, which requires a very different DNA than software development. Next, it makes development itself difficult, because the cloud adds a level of indirection and complexity to all development tasks. Finally, you will be forced to do cloud port eventually to get to a SaaS cloud people want to deploy on, like Amazon EC2 or Google App Engine (assuming they ever exit the Python ghetto).

A tool-first approach to PaaS development is much more straightforward. You start by creating a host-able development studio (pretty much rules out Eclipse plugins) and do your build and test on standard hardware. After you have build a solid product, you add multi-tenancy to the studio and customize deployment for your cloud of choice (or use a partner like Elastra to do the deployment and administration for you).

A final oddity of the cloud-first vendors is that they have all delivered proprietary development platforms. This provides a "roach motel" level of lock-in - your logic and data can checkin, but just try moving them to another RIA or Ajax platform! Again, SalesForce can throw its 500-pound gorilla weight around and make the Apex language successful. It is hard to imagine, however, that 5 years from now people who have learned the Coghead language will be in more demand than, say, Java developers.

Labels: Bungee Labs, Coghead, force.com, paas, platform as a service, WaveMaker

I had a great conversation today with one of my blog-heros, Jeff Nolan. Jeff recently finished a stint as the CEO of Teqlo, a pioneer in hosted tools for building Enterprise 2.0 applications. Others in this space include Coghead and Bungee Labs.

The nirvana we are all shooting for is a world where developers can assemble useful business applications with minimal coding or scripting. The idea is to take simplify certain tasks that are hard to do with code (e.g., visual assembly of page layouts, hooking controls to services) without making it harder than normal to do the things that will always have to be done with some sort of logic. The reality to date has fallen short of this nirvana.

We identified 5 reasons that Enterprise 2.0 apps today often fail to live up to the hype:

1. “Slowest man sets the pace.” Chaining together service calls to build applications creates bottlenecks where the slowest service call tanks the performance of the whole application.

2. Look but don’t touch widgets. Although this is changing (see here for the latest on Google’s pub/sub widgets), the vast majority of widgets can’t exchange data. This allows for an infinite variety of cute clock and horoscope widgets, but a paucity of useful business functionality in widget form.

3. Web service alphabet soup. There are a number of web service standards and even within a standard there are few rules for how the standard should be applied. This means that creating widgets to integrate web services is unexpectedly time consuming.

4. Still too darn hard. The world of widgets and building AJAX apps is still far too complicated for the typical end user developer. Current state of the art tools still require a knowledge of IDEs, standards and languages far beyond the grasp of casual developers.

5. Service throttling. At ActiveGrid, we have found that a number of web services like Google Maps are easy to mash-up for demo apps but much, much harder to use for doing real work. Given that Google has to pay for all the servers, it is easy to see why they would want to encourage people to use their web services in non-intensive ways.

Jeff believes a big market lies in creating “people, place, thing” applications like project management and time tracking. I would add that the killer app is tying Internet data presentation and collection with email workflow – sort of an updated Lotus Notes.

The market and the tools are evolving quickly, so in six months the landscape will look fundamentally different. For now, however, the vision of idiot-proof assembly of Enterprise 2.0 apps using rich business widgets has yet to be fully realized.

Labels: ActiveGrid, Bungee Labs, Coghead, Enterprise 2.0, Google Gadgets, Jeff Nolan, Teqlo, Web 2.0