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.

DEMO: http://soaui.componentart.com/ajax/datagridmessagebrowser/

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.

DEMO: http://demos.telerik.com/aspnet-ajax/grid/examples/clientbinding/defaultcs.aspx

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).

Regular JSON Web Service – Standard HTTP Request / Response Web Services

JSON Message Bus Service – Full Duplex Two Way Stream of Messages

I’ve written some nice flexible standards based implementations of various Base32 and Base64 encoding/decoding methods. These are designed to encode binary data to plain text, and decode the resulting text back to the original binary. Useful when you need to transfer binary data through technologies that only support text (such as including binary security tokens in URLs).

The code is available up on codeproject.com

Base32Url encodes with only the characters A to Z and 2 to 7. No hyphens, underscores, pluses, slashes or equals are used, making it usable as a URL token in almost all circumstances. Base32Url also supports custom alphabets. A custom case sensitive alphabet with only consonant (non vowel) characters can be used to ensure your tokens do not contain accidental profanities. The following is an example that avoids vowels, the letter L and has no numeric characters: BCDFGHKMNPQRSTVWXYZbcdfghkmnpqrs.

Base64Url is more compact than Base32Url and it is almost always usable as a URL token or file-name. The only non alpha-numeric characters Base64Url contains are the hyphen (-) and underscore (_) characters, neither of these need further encoding for use in URLs or file-names.

Base32Url (Encoder / Decoder)

The default mode for the Base32 encoder/decoder is Base32Url. This uses the standard Base32 alphabet encoding but omits padding characters and is case insensitive.
Supports standard Base32 with padding characters (=) per Base32 from RFC 4648.
Supports the Base32 extension / alternate alphabet z-base-32

Base64Url (Encoder / Decoder)

Based on the standard .net Base64 encoder
Uses the URL-Safe alternative Base64 alphabet from RFC 4648
This is not the same as Microsoft’s HttpServerUtility.UrlTokenEncode.

Further Information and Usage

There are other implementations of base32 encoding out there but I feel the code of this base32 implementation is much simpler (far less code involved in the bit shifting calculations).

The base64 implementation I have here is a little hackish, but a far better option than the one you get from Microsoft.

The result you get from HttpServerUtility.UrlTokenEncode is essentially base64url, but instead of truncating the padding, they append a digit (of 0, 1 or 2) indicating the number of padding characters removed.

Usage:

Base32Url.ToBase32String(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ

var b32 = new Base32Url(true); // Base32Url(bool usePadding)
b32.Encode(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ====

For more information about the standards involved please see rfc 4648 http://tools.ietf.org/html/rfc4648

Wikipedia also has good information. Please see http://en.wikipedia.org/wiki/Base32 and or http://en.wikipedia.org/wiki/Base64

// Get a double between 0.0 and 1.0 using a secure random number generator and the maximum fidelity of a double

var rndBytes = new byte[8];
RandomNumberGenerator.Create().GetBytes(rndBytes);
ulong uIntResult = BitConverter.ToUInt64(rndBytes, 0);
double doubleResult = (double)(uIntResult / (decimal)UInt64.MaxValue);

// Get a value between minValue and maxValue exlusive of max (like System.Random.Next(int minValue, int maxValue)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * (maxValue – minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);


// Get a value between minValue and maxValue INCLUSIVE (UNLIKE like System.Random.Next)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * ((maxValue+1) - minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);