HTML5 and Web Services – Get the Right “A” in your SOA

There is a growing trend in applications being built in HTML5 where the screens are built in HTML5/CSS3 and hooked up to data via services with JavaScript. From Bing to Amazon Kindle Cloud Reader and Angry Birds, the big boys are moving steadily in this direction for more than just their websites. Let’s not forget the much hypothesised pending PDC announcement regarding Windows8 and HTML5 (see buildwindows.com).

For a small inkling of what HTML5 can mean, I strongly recommend you check-out slides.html5rocks.com (in google chrome or safari).

The days of screens in HTML applications being pages generated by servers containing screen layout mark-up and data are nearly over, whether it’s your google/bing search results or social networking news feed, all this is happening over JSON web services.

While the UI control industry is still some way away from having polished products to support building these applications cheaply, there have been some interesting recent developments.

The move to HTML5 based UI brings with it some great new opportunities, and of course, just as many risks and challenges.

SOA UI Controls from ComponentArt and Telerik

Recently two of the biggest control vendors for asp.net web app controls have added some interesting client side service/data-binding. While neither of these quite gets to the full vision or potential of HTML5 UI, they certainly make some very positive steps in the right direction.

1) ComponentArt have released a suite of Silverlight and ASP.net “AJAX” (JSON) controls that data bind on the client side. You build and publish your service interfaces once, then connect Silverlight and HTML based controls to them. The ComponentArt implementation is somewhat limited in the services it can bind to, services need to be defined in specific ways for them to be useable without some custom client side code.

2) Telerik have added declarative client side data binding support for JSONP / ODATA (http://odata.org), you simply point your controls at ODATA data sources and configure the data-binding. The resulting HTML and javascript produced by Telerik takes care of the rest, pagination, filtering etc. etc. all happen client side.

One of the main shortcomings of this service based approach over HTTP is that there is inherently a two connection per client limit. For simply paging through a grid of data, per the examples above, this will not pose a problem, but as your interface becomes more advanced this two connection limit will really start to bite (as many developing in Silverlight have found).

WebSockets

Why should we care about WebSockets? Put simply, it’s all about throughput! Web-sockets authenticate once at the start, are full duplex and support message based communications; this means a significant increase in throughput is possible.

* Q – Query / Request, P – Processing / Latency, R – Response

Message based services over WebSockets truly have transformational potential for HTML5 UI web application development. The key of this transformational possibility, is that message based transport of client-server communication will support modern UI software design patterns such as MVP and MVVM directly in the browser.

Web sockets do come with hidden dangers for application developers though; there is a risk of turning back the clock, moving away from stateless web services, and bringing in a new era of unnecessarily long running client-server connections. With the right patterns and practices these pitfalls can be avoided of course. Web sockets could be kept open only for short bursts of communication, meaning services can still be stateless, web farms can still manage load on a per connection basis and users wouldn’t be tied to specific hosts for long periods. Hopefully as UI control vendors leverage this technology we will see patterns, practices and frameworks for the architecturally sound use of web sockets.

WebSockets are still somewhat a way off for most desktop targeted browser based applications (due to lack of IE support). Applications targeted at apple/android tablets/phones can certainly make use of this technology today.

Adapting Existing Services

Don’t panic! This does not mean throwing away your current web services, the ramifications of WebSockets on existing JSON web services are not as drastic as you might expect. In fact, the SOA design principles on current services should be maintained and continue to be used for new services.

All your existing services can easily be re-published via simple message bus endpoints. Silverlight and JSON web services are already inherently asynchronous so it is not a big change for your existing client or server side code. The message bus is just another type of transport for calling your existing services.

Your client would simply send its “request” messages to a message bus endpoint with a wrapper containing service destination information. In SOAP, the SOAP headers already contain all the information needed to achieve this. For JSON services, a simple wrapper object containing an endpoint URI and the request message body is all that is needed.

JSON Message Bus – Under the Covers

Looking at the specifics of this in JSON it is easy to see this is not a big leap (this sample is simplified to show a single http connection instead of two which would sometimes be possible, please note protocol details have also been simplified).