Single Bank Platform: HTML5 and Actors
First a bit of a recap: There are in my view (as blogged previous) two sides (actually there could be more, but lets ignore that for this posting) to the Single Dealer Platform (SDP)/Single Bank Platform (SBP) – the internal sales persons view and the external clients view. There is of course an overlap from both of these from a User Experience (UX) perspective, for example being able to RFQ/RFS whether you are a client or a sales person. One of the main differences however is that as the sales you want to RFQ on behalf of a client. So where am I going with this. Well from a UX perspective there is considerable overlap, but there are also differences. Primarily the sell-side has concentrated on producing a “clients” SDP, however I believe we are now entering the next SDP wave, the “sales person” SDP. Interesting times 
Within Lab49 we often have the opportunity to trying out new ideas from a UX/technology perspective. Some of these ideas end up being part of real applications developed for our clients, other ideas never see the light of day outside of the Lab. The following screen shot is from one of Lab49′s internal projects. The User Experience (UX) never got past the wire frame stage. What’s interesting from this Proof Of Concept (POC) is that we’ve leverage HTML5 to build the UX – specifically using canvas in a few places. Since we’re in HTML5 land, not wanting to to assume we have the Adobe Flash player, an invisible Java applet, of similar installed we’re restricted to I believe two choice from a “pushed” prespective:
Now here in lies an interesting fact, if we had an improved network stack (think Adobe Flex, Microsoft Silverlight, Oracle Java) we could leverage certain streaming servers native protocol and offer the UI an improved “push” – lower latency etc.
One the server side, we’ve pushed into the Actor/Agent landscape – no surprise to any reader of my blog. In this particular scenario we’ve leveraged some of the common frameworks that I’ve blogged about before – Akka for example. Which in itself leads to an interesting thought. If you attempt to buy an off the self SDP/SBP your tied into various components. Today most business applications are part buy and part build. In the case of this internal project, and like almost every real world SDP we did a build for the UX, we “purchased” the streaming server, and we appropriately leveraged best of bred ideas/patterns to design a services layer that shielded us from the numerous back-end systems we’d have to integrate with.
The second screen shot is an improvement of something I blogged about earlier. This time from a sales persons perspective. Real-time alerting, business intelligence are all important in the sales view of the world. Think Complex Event Processing (CEP) and more from a technology perspective
Hi Matt,
What makes you think a ‘native’ protocol will perform better in terms of latency? It certainly isn’t the case with Liberator, all variations of connection types and protocols perform equally. Not necessarily the case with all servers, but there’s no inherent reason why it should be.
We have done sales front ends, or rather sales functionality in our front ends for trading on behalf of (TOBO). I agree it is definitely a key requirement.
Comet/Websocket – i’ve blogged about this before, WebSocket is just another technique in the Comet vendors toolbox. WebSocket with no fallback mechanism is no good, not for a number of years to come anyway.
“What makes you think a ‘native’ protocol will perform better in terms of latency?”
Martin my point here is that with a plugin based client ( Flex, Silverlight, Java etc.. ) the data passed between client and server can leverage the underlying network API’s supported. In comparison, within the context of an HTML(5)/Javascript client a typical Comet server implementation will use either long polling or the forever iframe ( and their derivatives ) to achieve the same thing. Both Comet approaches ( I exclude WebSocket for the moment as its coverage is limited) have their positives and negatives but neither are as efficient or effective as a dedicated networking stack decoupled from the browsers own communications. Furthermore, given that HTML(5)/Javascript lacks support of binary data types, simple structures ( price data for example ) must be sent to the client as strings. In comparison a client built around a plugin technology ( Flex, Silverlight, Java etc. ) can handle binary data types ensuring that what actually gets sent back and forth between client and server can be much tighter in structure and size. Unfortunately all these things impact latency.
I do know that some streaming server implementations simulate typical comet based communications for both HTML(5)/Javascript and plugin based ( Flex, Silverlight, Java etc.) clients. I also know of other streaming server implementations that utilise the most efficient communications path possible for each supported client type while decoupling messaging functionality from the underlying transportation of data. It would be fair to say that not all streaming servers are created equal.
You have a point with binary data, it can be encoded which will increase the size by maybe 20-30%. However, as you said, not all implementations are equal.. one product using comet techniques can be far better than others using more native approaches of course
Other than binary data types, i’m not sure there is much else you gain from a plugin based connection. A lot of the control and efficiency comes from the server sending data.
You don’t have quite as much control over knowing when the socket has gone away with some comet techniques, but that forces you to implement things to detect that better – something you might not bother doing when using a plugin based network api – up to the point you find out firewalls and proxies like closing one side of a socket and you don’t even know you lost your connection
“Other than binary data types, i’m not sure there is much else you gain from a plugin based connection”
There is so much more to be gained from a plugin solution.. Threads, Blocking IO ( when required ) .. and a general programming approach suited to enterprise class applications . These all have their own advantages over HTML(5)/Javascript based solutions.. I recognise the need for light weight web based apps of this nature but there clearly is a pecking order in terms of functionality, features and performance. Plugins, irrespective of tech choice, simply give you so much more.
I thought we were talking about an HTML5/JS application being able to use a ‘better’ transport mechanism. If you want to write the whole thing using a plugin then there is lots more to compare that could go on forever.
Put it this way, we used to use a plugin for communications, I don’t miss it
Good post Matt. Take a look at this one for some similar ideas: http://singledealerplatforms.wordpress.com/2010/09/28/%E2%80%9Cdifferent-users-one-framework%E2%80%9D/
Matt,
I agree that based on the network stack provided by the client-side framework (HTML, HTML5, Flex, Silverlight, Java, etc.) different optimized streaming protocols can be leveraged. Of course, choosing a streaming server that natively supports such different network stacks is recommended.
For example, with Lightstreamer we introduced native support for Flex AMF binary objects. We know of an SDP that used to send large XML structures with Lightstreamer and moved to optimized AMF objects.
But binary data has a potential drawback. As I mentioned in a AMF tutorial, in my opinion it is important to choose the right trade-off between using fine-grained fields and coarse objects. You could map each individual atomic piece of information to a field, thus using many fields and items (in Lightstreamer jargon), or you could map all your data to a single field of a single item. This applies to both text-based fields (where you can encode coarse objects via JSON, XML, etc.) and object-based fields (via AMF). Usually, going for fine-grained fields is better, because you let Lightstreamer know more about your data structure, so that it will be able to apply optimization mechanisms, like conflation and delta delivery. On the other hand, if you go for huge opaque objects, Lightstreamer will be used more as a blind pipe. But in both cases, you will still benefit from other features, like bandwidth management and dynamic throttling. And all the intermediate scenarios are possible too.
So before I reply further I want to say that Lab49 is vendor neutral. Over the last few years we (Lab49) used almost every single streaming server product available on the market (Lightstreamer, Kaazing, PUSH Technologies, Adobe LCDS, my-channels Nirvana, etc) for both client solutions, and for internal proof of concept (POC) solutions. In the Single Dealer Platform shown in this blog posting (an internal POC and nothing more), we used my-channels Nirvana for the streaming solution because it ticked the above box’s from a viewpoint of features.
So in summary, and to avoid this blog posting turning into a flame war, Lab49 is vendor neutral, we use the most appropriate streaming solution based on an assessment of the business application we are building.