Web Apps Development - Clearing the mist

Web 2.0, Ajax, REST, HTML5, javascript, jquery, node.js, single page apps, backbone.js the list goes on. How are all of these relevant? how do they fit in? when to use what? I found myself asking all these questions and things kept on getting misty, till finally I decided to look at all these "trends" in a way they had naturally evolved. Here is a log of that realization...

HTML, servlets, JSPs, the grand daddies of web apps
Post the decline of windows based business applications, since the late nineties, the browser based web applications have served business requirements well. Typically server side technologies like servlets and JSPs/ HTMLs were the work horses of such applications. These web apps were very much page centric, with html based pages dishing out functionality, navigating to additional pages etc. The need for reducing complexity and controlling page flows centrally was naturally was felt

Enter JSF..
JSF with their server side component models and declarative flow logic were quite a hit. But navigating to pages over http at internet scales, meant a rather poor user experience as compared to say desktop applications. Could this pain be reduced if not removed...

Enter ajax...
Ajax brought with it the ability for browsers to asynchronously communicate with server sides. Partial pages could now be refreshed on demand, by using javascript to issue out ajax requests. The data gotten over an ajax request was often many times lesser than the entire html page going over the wire. As ajax got more popular and powerful libraries like jquery emerged, it became a very accepted thing to load the html, css, javascript etc in the browser and then merely get the dynamic portions i.e. data to be requested over ajax calls.Server sides also started catching up and providing interfaces that could be easily consumed by clients like HTML+javascript.

Enter REST...
Emergence of REST-ful architectures and REST webservices, only added fuel to this fire and increasingly mashups and web apps were consuming REST services and were getting more decoupled from the server sides

Emergence of mobile apps and devices...
The same REST services could be consumed not only by browser based clients but also by native apps like iOS and android. since all they needed was a capable HttpClient. Soon mobile apps were all the rage and it only a matter of time before people started comparing them with conventional web apps. Mobile apps, with their native code, seemed much more responsive and provided much better UX, as compared to browser based apps. Could we have a browser based app, that communicated with the server only when it needed data, rather than request the entire view (with data)?

Enter Single Page Apps 
In single page apps, all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions. The page does not reload at any point in the process, nor does control transfer to another page. Single page apps, optimize traffic between client and server, by going to server only for data input or output.This results in the role of the web server evolving into a pure data API or web service. Also, the UX is markedly improved since, unlike in page centric apps, views in UI dont travel across the wire. The notable cons, until recently were browser history, SEO to name a few. Everything said and done, the client sides and server side(REST services) are distinct.

Enter backbone.js and javascript frameworks explosion
With UIs increasingly getting built with client side technologies like HTML/5, CSS3, javascript, etc the complexity started moving over onto the client sides as well. To manage this complexity of maintaining, views, models in sync, view navigation logic, validations etc there was a dire need of frameworks and thus MVVM, MVC frameworks like backbone.js have started emerging out.Try having a look at sencha extjs to understand one more flavor of a pure javascript single page app framework

Enter node.js
Since the server side increasingly started becoming  a mere provider of REST services aka data, there was a need for simplifying server sides as compared to Java EE servers and also with the intention of making the server sides more scalable. hence the emergence of frameworks like  node.js

Enter full-stack frameworks like meteor
With node.js its very much possible to use javascript on server side and as a result, transparent client/server communication is possible, no longer do we need to develop web apps as strictly in client and server silos, we can reuse code such as validations across client and server and also using transparent client-server bridges/pub-sub, it is possible to write client javascript code to persist to a NOSQL database like mongodb. This simplifies the web application stack by order of magnitudes


Though the above stacks have been mentioned in evolutionary order, each has its own relevance no doubt and rather than picking out a winner or eventual winner, my attempt is to raise awareness about these options, so that the right tool can be used for the right job.


Cheers!

TryStack - Evaluate a Private IAAS Cloud at no cost

IAAS (Infrastructure-As-A-Service) public clouds like AWS and Rackspace are getting a huge amount of attention, no doubt. In the enterprise itself, private clouds based on OpenStack or Apache Cloud Stack, are also becoming quite popular.

I am sure, many like me, want to try their hands at using an IAAS style private cloud, without having to go through the hassle of installing private cloud on premise or using a paid IAAS public cloud like AWS.

Well, there is a good option for evaluating a private cloud stack like OpenStack completely online. Its called Try Stack. It runs a managed openstack environment.Its sponsored by donations from cisco, ubuntu, HP etc who want to popularize IAAS cloud computing.

Heres a quick rundown of how you can start using the hosted IAAS private cloud TryStack:

• Go to http://trystack.org/ and register onto their facebook group. For me the approval happened overnight
• You will get an email confirming above registration
• Then onwards you can login to the private cloud admin console using your facebook credentials

Following steps will  be familiar to people who have worked with private IAAS clouds like openstack or cloudstack

• Create a new security group opening up whichever ports you would like to access like TCP 22 for ssh, ICMP for pinging your instance, TCP 8080 for webserver access etc
• Create a new public-private key pair and download the private key for authentication into your instance
• Create a new instance choosing 
• template like micro, small, medium etc, 
• which OS to use: ubuntu, cirros, windows, etc are available in trystack
• the security group 
• key pair you created earlier
• additional volumes if required

• Check the instance boot logs, in the console, to ensure the VM instance was created all right

• Finally note the public IP, allocated to your instance
• Make sure you can ping your instance over the internet
• Use putty-gen to convert the openstack's private key .pem to .ppk format
• Use putty to ssh into your instance IP using the ppk private key
• You can also use winscp to login in to your spanking new VM instance

One warning: Since trystack is an experimental sandbox area, every 24 hours, your existing instances will be forcibly purged. 

Using Trystack, to familiarize yourself with using a full-fledged private IAAS cloud like openstack, is quite a painless experience and its free as well, you don't need to sign up with your credit cards.

Cheers!

Grails 2.3 released - provides out of box support for REST

Lets face it, REST is the undisputed king of content integration. Almost every major product, framework, supports exposing its user-consumable services over REST. The burgeoning popularity of mobile apps and thin client technologies, is also driving the adoption of REST. Part of its success is the ease with which REST services can be consumed. All you need is an Http client, no matter if you are developing UIs in HTML5/javascript, java, PHP, Ruby, Python, Android, iOS, etc... all the platforms have mature Http client libraries that can consume REST services.

Grails 2.3 which was released a few days ago, now provides out of the box support for exposing grails services functionality over REST. Grails was always very good at providing an easy way to write CRUD services based on its GORM/Hibernate based server side. The only sore point was its proprietary server side presentation technology in the form of GSP, which did not decouple the UI controllers sufficiently from the views. You still had developers driving GSPs, and making frequent and radically changes to UI (almost as if it were a mashup), were difficult.

But now...Grails can be used to develop service layers of an application, very rapidly and same services can very easily be exposed as REST interfaces, which can be consumed by a variety of clients including mobile clients.

Heres how...Getting started, is so easy even a novice developer could do this.

You can start by downloading the latest Grails 2.3 release.
Go about creating a new grails app as usual
grails create-app sample1

Create a new domain class
grails create-domain-class contact

Now annotate the class as shown below in bold:

package sample1
import grails.rest.*

@Resource(uri='/contacts')
class Contact {
        static constraints = {  }
String firstName;
String mobile;
String email;
}

Thats it, now just run your grails app with 

grails run-app

Congratulations! You have just REST-ified your domain class Contact.

You can perform CRUD operations like create, read, update and delete on your domain class Contact using the following REST URLs.

To fetch list of all contacts from DB use  

Http GET to  http://localhost:8080/sample1/contacts.json

To fetch a particular Contact information given its id = 101, use

Http GET to  http://localhost:8080/sample1/contacts/101.json   (where 101 is the id of the Contact)

To add a new contact

Http POST to  http://localhost:8080/sample1/contacts.json

with request body being a json like {'firstName':'Ganesh Ghag','mobile':'7776661110','email':'none'}

To update an existing contact with id = 101

Http PUT to  http://localhost:8080/sample1/contacts/101

with request body being a json like {'firstName':'Ganesh Ghag Updated'}

To delete an existing contact with id = 101

Http DELETE  to http://localhost:8080/sample1/contacts/101

While invoking Http verbs like GET and POST is fairly simple from an HTML, to be able to invoke PUT and DELETE, we will use cURL as shown below.

The sample curl script below, creates a new conatct, updates it, deletes it, just like a good test script should.

rem inserting a new contact

curl -i -X POST -H "Content-Type: application/json" -d "{'firstName':'From CURL1','mobile':'7776661110','email':'none'}" http://localhost:8080/sample1/contacts.json

rem updating a contact

curl -i -X PUT -H "Content-Type: application/json" -d "{'firstName':'From CURL Update 1'}" http://localhost:8080/sample1/contacts/1

rem deleting a contact

curl -i -X DELETE http://localhost:8080/sample1/contacts/1

rem getting all contacts after use case execution

curl -i -H "Content-Type:application/json" http://localhost:8080/sample1/contacts.json

Kudos to the Grails team for giving the REST features out of the box.

For more details please visit http://grails.org/doc/2.3.x/guide/webServices.html#REST

Building REST-enabled CRUD applications has never been easier!

Cheers !

Basics - One Time Passwords and Two Factor Authentication

Two-factor authentication requires the use of two of the following three authentication factors.

• Something the user knows (e.g., password, PIN, pattern);
• Something the user has (e.g., ATM card, smart card, mobile phone); and
• Something the user is (e.g., biometric characteristic, such as a fingerprint).

A clear explanation can be found on wikipedia:  http://en.wikipedia.org/wiki/Two-factor_authentication

The most popular and easiest way of implementing second factor in authentication is the use of OTP (one time passwords).

A one-time password (OTP) is a password that is valid for only one login session or transaction.
The most important shortcoming that is addressed by OTPs is that, in contrast to static passwords, they are not vulnerable to replay attacks.

There are also different ways to make the user aware of the next OTP to use.

• Some systems use special electronic security tokens that the user carries and that generate OTPs and show them using a small display. 
• Other systems consist of software that runs on the user's mobile phone (mobile apps)
• Yet other systems generate OTPs on the server-side and send them to the user using an out-of-band channel such as SMS messaging.

There are also well-known algos in this area such as HOTP = HMAC based OTP and TOTP = Time based OTP.

Some things to note:

• Use of hardware token genenators is more expensive
• Use of SMS channel requires the server sides to have capability to send SMS through reliable SMS gateways which may be paid options
• Use of mobile apps, often requires internet connectivity to the server

To further clarify the OTP options, I am providing a few self explanatory slides below:

--------------------xxx----------------------

-------------------xxx----------------------

Finally, there are several open source and paid providers of two factor auth and OTP solutions.Most of these require a custom authentication server as backend.

Open OTP     - http://www.rcdevs.com/products/openotp/

Lin OTP        - http://www.linotp.org/features.html

Phone factor  - https://www.phonefactor.com/how-it-works/overview.shtml

M-PIN          - http://www.certivox.com/m-pin/

and many more...

Also you can develop, a custom implementation using standard algorithms like HMAC for OTP

cheers!