In Sockets, Messages and the Pub Sub Paradigm: Approaches to Streaming I discussed various techniques involved in streaming data to a browser. There are many products available making use of these techniques to solve a broad variety of problems, but due to their unfocussed target user base they all leave a fair amount of development in areas that may be outside of the expertise of the people using the product.
The core domain subsystems and infrastructure required is often overlooked or severely under estimated when a project starts. This development needs to be well designed, well written and well tested, which will not be the case if there are time pressures to deliver these under estimated stories, which could result in project failure.
The techniques described in the last article all have advantages and disadvantages, but they are only giving you low level APIs which do not meet the high level requirements of a real business solution. Some products are aimed at specific markets, and to solve more specific and real problems, they do a lot of the work for you. The ultimate case of this is where the product is just installed and is a turn-key solution suitable for your customers, the end user. This is the difference between an API to build a product, and just buying a finished product. The problem with a finished product is you may lose your competitive advantage – what value are you adding by providing a service that uses the same product that is also available elsewhere? The product might not do exactly what you want either – maybe you had to compromise on a few features that you initially were looking for.
So what is the answer? You want to avoid spending time and money on developing the same things that others have already developed in your space, but you still want the freedom to create a solution that is differentiated from other end solutions and to add business value using the expertise you have. You want something that is specific to your domain, but still gives you the freedom to add value to the final solution, and to concentrate on adding that value. You want something that means you don’t have to worry about developing and testing infrastructure than others have done before you.
Domain Driven Design talks about domain languages. Providing APIs and components that make use of the language of the target domain can lead to a better understanding by the users. A domain language can help a lot, but a good domain model can save a huge amount of development. Products that provide domain specific models and languages allow you to concentrate on your business, your expertise and providing the best solution for your customers.
The diagram above illustrates the layers of an end solution. At the bottom you have generic infrastructure, this ranges from hardware and operating systems to streaming/messaging systems described here. The middle layer is the interesting part, it contains the often under estimated subsystems and infrastructure that is specific to your domain. This means all the ground work and boilerplate code you always have to write to support your solution before you get to the interesting parts. The top of the pyramid is where you want to be focussing your efforts, this is where your expertise in your domain comes in, where you can make your solution different and better than your competitors.
Conclusion
Generic products using the streaming techniques previously described are great for a wide audience. The simple socket or message based products can be used for all kinds of solutions. The next level, the object based systems, can allow you to develop solutions quicker in some cases, but can often lead to tight coupling between client and server.
So where do you go next? Domain specific frameworks. If you are looking for a product to build a solution and you think that what you are doing is not totally unique, then there may be a domain specific framework that will get you to market a lot quicker than a generic product.
This is the approach we have taken with Caplin Xaqua, our single dealer platform for trading. Our APIs relate to pricing, trading and permissioning, rather than generic messaging. The APIs give you access to domain models and functionality, so you can very quickly integrate with your trading system. Caplin Trader, our Ajax front end built on Caplin Xaqua gives you a configurable and extensible GUI, again with domain specific APIs, models and display components.