Rest back-end and UIs

We have been spending the last four months moving our Win32 stand-alone applications to a more service oriented architecture. This new back-end  can be scaled to handle a wide variety of  TV Broadcasting enterprises. It has been a major movement from us, as many domain logic that was previously hardcoded into the desktop applications is now implemented into this back-end and shared among all clients. The logic is customizable per client basis through an scripting system.

We have targeted two desktop operating systems, MacOSX 10.6 and WindowsXP+ (in this order). These led to a new problem: developing a front-end that would offer the most user-friendly experience to the end user. Cocoa and WPF were the best choices and Monobjc provided a nice bridge to handle the Cocoa interface through Net/Mono. Silverlight was the third choice to those interfaces that could be also used from the web. The RESTful back-end allows us to easily develop and deploy any user interface while maintaining full compatibility within the installation with other clients.

Compared to AJAX and HTML5, Silverlight was the most cost-effective technology for us as we are used to write .Net code and we could use a large .net library we have already developed. So we have software (desktop applications for video editing, video review and cataloging) that share a common back-end and offer a native interface through Cocoa and WPF and some Web applications using Silverlight that also target MacOSX and Win32 clients but are more suited for the Web.

This huge project has been fun and having the chance to take part in almost any part of the new architecture (I have designed and implemented  part of our back-end and also being in charge of evaluating and teaching  Cocoa/Monobjc).


Tracking the flow in the mesh of services

I’m currently worried on how our embrace of SOA and REST can take a big impact on our support team. In a world of closed entities where the boundary of the underlaying operation is well defined, a simple logging system is enough to track down the source of the problem. The failed operation is well confined inside an application scope, but on a service oriented architecture the message could have been propagated to other services. Tracking down the source of the problem definitively doesn’t seem to be trivial.

A central logging service is a good start. All message outcomes can be tracked into this service, which is a central shared point to look for answers. But what if your architecture is a large SOA implementation with a mesh of services? If a call to a service generates smaller calls to secondary services, the logging system is still insufficient. One could start reading log by log  in the hope to understand what was the outcome of each service call in order to get the whole picture, but the always-busy support team is not going to be happy with this.

I could think in a couple of simple solutions: one could be to propagate the id of the root message, the one that triggered everything, so that a query with this id to the logging system would return a list of all related message. Our we can scale this to not only track the root message but to propagate in each message (as embedded info into each message) the id of the previous message in the chain. A list of chained message can easily be looked up in our logging system as a list of log messages (of a list of services messages chain). This information should also be embedded into the event drive part of the system, thus all events should also track this chain of ancestor messages. With this approach we can easily visualize which message triggered a resource operation in another service, consequently allowing the technical support team to look and better comprehend into the flow of that certain execution path.

Our we can move to the next level: some sort of exception handling (in the SOA way)…