We aim to keep our Tech Talks relevant and interesting for our viewers. We simply want to provide an open forum to discuss and ask questions about key issues around API Management. So, in keeping with that spirit, our next subject for discussion will be Websockets and the excitement surrounding HTML5′s support for the WebSocket protocol. And I’m excited to have Layer 7 API Architect Ronnie Mitra as my guest for this highly-topical Tech Talk.

The hype around the WebSocket standard, which enables a type of bi-directional, socket-based communication not possible with conventional HTTP, has been steadily increasing over the last two years. As adoption of  WebSockets technology increases, API architects need to understand how they can use the protocol to build great APIs for mobile and Web applications.

In this Tech Talk, Ronnie will be discussing:

• The ins and outs of the WebSocket protocol
• The relationship between HTTP-based APIs and WebSockets
• Use cases that are a great fit for the WebSocket standard
• The challenges of securing a WebSockets connection

Of course, the discussion won’t be limited to just these topics. We also welcome any and all of your questions and comments. In fact, without them the spirit of Tech Talk Tuesday would cease to exist. So please start formulating your questions or comments and be sure to add the date to your calendar.

How to Attend
So be sure you click Add to Calendar in order to get the event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:

• livestream.com/layer7live
• facebook.com/Layer7/app_142371818162

To submit questions:

• Tweet using the hashtag #Layer7Live
• Email techtalk@layer7.com
• Check in & Chat through Facebook

And here are the full event details:

• Tech Talk Tuesday: WebSockets
  Tuesday September 18
  9am PDT | 12pm EDT | 5pm BST
  Add to Calendar

In the previous blog post in this series (Using WebSockets – Part 1: Minding the Gates), Ronnie Mitra talked about the promise of the WebSocket protocol, as well as some security aspects. In this post, I’ll talk about some of the details of the protocol and what they mean for those planning their own WS implementations.

The first thing to keep in mind is that WebSocket is a high-level protocol with its own registered schemes (WS: and WSS:). The specification describes it as: “… intended to be as close to just exposing raw TCP to script as possible.” This is very different from HTTP, which is “…  an application-level protocol for distributed, collaborative, hypermedia information systems.”

That’s good and bad news. It means you have almost the full range of TCP at your disposal. It also means you have none of the established constraints and conventions of the more detailed and focused HTTP specification. This has implications for both design and implementation of WS solutions.

Originally designed with Web browsers in mind, the WS protocol can also be implemented for mobile, desktop, and other stand-alone clients. There are quite a few checks and balances in the specification in order to make it easy (and safe) for browsers to switch from HTTP to WS conversations, all from JavaScript.

However, since many installed browsers do not yet natively support the WS protocol, these checks and balances are not always employed. Instead, WebSockets implementations often take advantage of browser workarounds and fallbacks, in order to support the real-time communications the WS protocol was designed to provide.

It’s also important to remember the specification states: “While this protocol is intended to be used by scripts in web pages, it can also be used directly by hosts [which] can therefore send fake ‘Origin’ header fields, misleading the server.” Implementations that will receive requests from non-browser clients should include additional checks to ensure these requests are valid.

Finally, as the protocol was designed to support real-time communications, it won’t scale in the same way HTTP does. Since the server will keep connections open to all active clients in order to track and broadcast content, servers will need to maintain (or persist) information about each connected client (including knowing when that client is no longer connected!)

If your current HTTP implementations rely on server-based session state, you may not see much difference in the scaling limits of WS. Remember though, the Web’s scaling success is largely based on HTTP’s ability to handle client requests without requiring server-persisted data. Also, some software and implementation patterns designed for HTTP will not work for WS.

Implementing WS is not for the faint-of-heart: it’s not yet widely supported on installed browsers; it uses a different implementation model; it takes more effort/resources to scale it up as services become popular. However, there are some good libraries for coding WS solutions and it can be relatively easy to get started on implementing WebSockets.

But be ready. If you experience great success, you’re likely to have a challenge on your hands!

One of the most exciting features introduced with HTML5 was support for WebSockets. The WebSocket protocol has been through a lot of churn over the last two years, with browser vendors desperately trying to keep pace with changes in the specification. Thankfully, the standard has now become stable enough to be utilized in enterprise projects.

The beauty the WebSocket protocol is that it lets an application seamlessly move from an HTTP/Web-based flow into a socket-based conversation and then back to a Web-based flow. In this way, it allows Web- and mobile-based applications to easily move from the traditional request-reply HTTP world into new forms of full-duplex, bi-directional communication.

We’ve seen a similar evolution in the past within the message-oriented middleware world. With the emergence of SOA and API, enterprises realized they needed new ways of moving data around and middleware technologies emerged that facilitated the movement of data in ways that were not possible with existing request-reply synchronous messaging infrastructures.

Traditionally, Web and mobile applications had to work hard in order to send or receive real-time data. Now, developers can use WebSocket to move data up and down the communication channel quickly and efficiently. This is like moving from an email client that requires you to constantly check for new mail to one that instantly alerts you when a new email arrives.

This style of communication will provide enormous benefits for applications that require messages to be passed quickly between the client and server.  Architects will have an easier time building applications with real-time messaging requirements, opening the door to some very intriguing solution designs.  Targeted notification systems, more-responsive UIs and even complex architectures such as massive grid networks built on top of the Web will be much easier to implement properly.

But, what’s missing from the WebSocket story is an effective way of minding the gates. The “black hat” guys already see WebSockets as representing a new attack surface, so organizations that are serious about providing reliable, scalable solutions will require some form of Gateway on the server side, to guard against security breaches.

To address WebSocket security, a Gateway must be able to enforce SSL handshakes, limit the number of connection requests, protect against payload injection attacks and enforce strong authentication methods – the same set of attack vectors that exist for SOAP/XML Web services and REST/JSON APIs.

That’s why I’m particularly excited about Layer 7′s recently-announced SecureSpan Mobile Access Gateway product. The Mobile Access Gateway extends Layer 7’s industry-leading technology for SOA and API in order to address mobile-specific concerns – and it includes a very secure WebSocket implementation.

In addition to the security benefits, the Gateway can be used to enrich or filter data in real-time. This opens the door to a new set of compelling use cases that includes data auditing, image watermarking and blacklist filtering – possibilities intriguing enough to stand on their own as justifications for implementing a WebSocket Gateway.

So, we’ve discussed what the WebSocket protocol is and why it’s so important to keep WebSockets secure. But how does all this fit into the exciting world of APIs that we’ve been focusing on in many of our recent blog posts? Our Principal API Architect Mike Admundsen will tackle this question next week, in our continuing series on this very important protocol.