The Architect

A Technical Architects Thoughts

June 25th, 2012

Good PDF into the world of FX options and Structured products. Provides history and gives an idea into the complex maths involved:

And lets not forget this from good old investopedia:

June 12th, 2012

For those who are keen to understand more about swaps, worth reading the following:

Will help with basics, but leads onto more complex areas.

March 1st, 2010

For those of you who don’t now what Nirvana is, Nirvana is a a low latency platform (middleware).  It is a middleware technology that securely and quickly streams real-time data between server and client/s.

Nirvana supports three messaging paradigms:


Publish/Subscribe is an asynchronous messaging model where the sender (publisher) of a message and the consumer (subscriber) of a message are decoupled, the two share a common topic or channel. The publisher publishes data to the channel. The channel exists with the Nirvana realm server. As messages arrives on a channel the server automatically sends them onto all consumers subscribed to the channel. Nirvana supports multiple publishers and subscribers on a single channel.

Message Queue

Like Pub/Sub Message Queues decouple the publisher or sender of data from the consumer of data. The Nirvana realm server manages the fan out of messages to consumers. Unlike Pub/Sub only one consumber can read a message from a queue. If more than one consumer is subscribed to a queue then the messages are distributed in a round-robin fashion.

Peer to Peer

Peer to Peer provides a direct communications path between an instance of a service and the client requiring access to the service. The Nirvana realm server brokers the relationship between the service and the client and in doing so becomes transparent as messages pass through it.

Flex Native Interface

The Nirvana Native Communication Protocol will soon be available for Flex, removing the overhead of composing and decomposing data from some kind of String representation.  The advantage is that now Byte Arrays will be transported (much leaner and therefore faster), which enables developers to take advantage of frameworks such as Googles Protocol buffers.  Microsoft Silverlight has always had the native implementation, but soon Adobe Flex will compete on the same level.  A cut down version of the Flex Native interface should be available by the end of Q2 2010.

March 1st, 2010

I have been looking into middleware solutions as a push mechanism between server and client.  One of the aspects that I had to consider was latency.  Hence it was important to find a lean technology agnostic transport format.  Most server-client platforms use a serialization technique to serialize into a leaner data format, and then de-serialize on the receiving end.  So in my search for a technology I now had to consider speed of serialization.

Many languages offer native serialization APIs, but when serializing the data using the native API, Metadata about the class is serialized into the output too.  I needed to find a technology that would serialize only the data values and not the additional Metadata about the object serialized.

I also needed to identify the best data format to serialize to.  XML (SOAP), strings and data dictionaries are common data formats, but a Byte Array is far more efficient, and is the proper serialization format when dealing with a client and server platform that are built on the same technology.

I came across two technologies ‘Google Protocol Buffers’ and ‘Apache Avro’:

Google Protocol Buffers

Protocol Buffers is a serialisation format with an interface description language developed by Google.  It is available under free software, open source license.  Protocol Buffers design goals are emphasized performance and simplicity.  It is a language and platform neutral technology that is an extensible mechanism for serializing structured data.

It works by you defining how you want your data to be structured via proto files, which are simply structure text files.  Once you have decided the structure in your proto file, the proto executable is called on it, and a generated class (Adobe Actionscript 3, Java, C, C++, Python) is produced.  The class can be generated into multiple different technologies, which means the class can be generated for the client and server technologies.  Thus securing a data contract (which is type safe) between the two.  The protocol buffer technology provides the ability to update the data structure without breaking deployed programs that are compiled against the old format.

Protocol buffers claims it takes between 100 to 200 nanoseconds to parse.   As the overhead of the data structure is not needed in protocol buffers, only the object fields’ values is serialized.  Protocol buffers will find the most compact serialisation technique for a particular data type (always primitives), and only serialize fields that are not null.

Apache Avro

Avro is another very recent serialisation system.  It provides rich data structures that are compact, and are transported in a binary data format.

Avro relies on a schema-based system that defines a data contract to be exchanged.  When Avro data is read, the schema used when writing it is always present.  Similar to Protocol Buffers, it is only the values in the data structure that are serialized and sent.  The strategy employed by Avro (and Protocol Buffers), means that a minimal amount of data is generated, enabling fast transport.

The schemas are equivalent to protocol buffers proto files, but they do not have to be generated.  The JSON format is used to declare the data structures.


I ran a few benchmark tests and concluded the following: The distinction to be made between the two comes down to implementation, extensibility and compatibility.

Implementation: Protocol Buffers was a much cleaner implementation than Avro.  Avro was messy with limited availability of online resources.  Avro uses a JSON object in string form to represent a schema. Defining an Avro schema is cumbersome and difficult to maintain; as well as increasing the risk of runtime errors when the structure wasn’t quite right.  The contract is not type safe, and it becomes very easy to set values against object fields of the wrong type.  Such errors can only caught at runtime, rather than compile time.

Google’s Protocol buffer does not have such complexities.  Protocol Buffers prompts the coder as soon as an error is reported through the protocol buffer compiler.  Protocol Buffers allows null able fields (something that Avro doesn’t), which means that when protocol buffers is serializing, it will ignore fields that are null, and thus reduce the overhead of serializing irrelevant data (unlike Avro).

Winner – Google’s Protocol Buffers

Extensibility: Google’s Protocol buffer provides a much richer API for defining a data contract than Avro. Below is a list of features available to Protocol Buffers and not Avro:

  1. Declare nested types
  2. Define requires, repeated and optional fields
  3. Specify default values on fields
  4. Declare enumerations and set a fields default value from it
  5. Multiple message types in the same document
  6. Import other proto files
  7. Declare a range of field numbers in a message available for third party extensions (Extensions)
  8. Nested Extensions
  9. Define services

Winner – Google’s Protocol Buffers

Compatibility: Avro is only compatible with C, Java and Python, and hence restricts client technology candidate options, although they do plan for other technology languages.

Protocol Buffers is compatible with C, C++, Adobe Actionscript 3, Java and Python.  As there is a C++ version is available, Microsoft Silverlight and WPF is therefore compatible with Google’s Protocol Buffers, but there are projects to port a Protocol Buffer compiler to C# and other technologies.

Winner – Google’s Protocol Buffers

January 31st, 2010

Its best I quote the creator (Jens Halm of the Parsley framework to explain contexts an scopes.

Jens Halm:

In Parsley 2.0 every child Context simply shared the message router with its parent Context. This way messages were always dispatched globally. An approach that may turn out to be too simplistic for large and modular applications where a loaded module, a window or a popup may wish to create its own local messaging context while still being able to inject objects from the root Context or dispatching selected messages globally. The scope feature introduced with version 2.1 offers that flexibility, allowing to dispatch into a subset of Contexts only.

In the new default scope setup for Parsley 2.1 there is a global scope that is created for each Context that does not have a parent (usually only the one root Context created at application startup) and then shared will all children of that Context (including grandchildren of course). Additionally each Context will create its own local scope which will not be shared with its children.

Finally you can also create your own custom scope when neither global nor local messaging is the right choice. This may be the case when you create a large AIR window for example. The root window component may create a Context with the root application Context as a parent but then also a few child Contexts for parts within that window. If you then want to setup a messaging scope for that window only you need a scope that spans multiple Contexts but still is not global.

The window scope is a custom scope that exists side-by-side with the two default scopes. Now how do you instruct the framework to create that scope? This has to be done for the root Context of the scope, in this case the two root Contexts for the two window scopes.


What I have done is to demonstrate the use of scopes in the following example I wrote.

Each Local Box has its own context, and is either added directly as a child to the main context or added as a child to a container context with a custom scope defined.  Click the buttons to see events being dispatched and handled in specified scopes.

The code is also available for your download.

January 27th, 2010

Recently I have been making the transition from PureMVC to Parsley, and have found many parallels regarding de-coupling and separation of concerns.

Just to provide some brief background:

PureMVC is essentially an observer Pattern.

  • The Model is a collection of proxies that proxy a data model.
  • The View is a collection of mediators that Manage the visuals (usually Components or mxml views).
  • The Controller is a collection of stateless commands that usually feed results from a remote call to a proxy or manage an update in a view through a proxy result.
  • Views and Proxies are referenced through a facade, that at its core is a singleton (e.g. facade.retreiveProxy(MyProxy.Name) as MyProxy);
  • Communication happens through a notification buss, where a dispatch of a notification will initiate a command, or activate a handler in a mediator.
  • A Proxy can issue a notification but not handle one.
  • A Command is instantiated through the dispatch of a facade registered command to notification.
  • A Mediator can issue and respond to notifications it has been told to respond to.
  • Parsley is an IOC Container and Messaging Framework

    As it is a Dependancy Inject pattern, it is a style of object configuration in which an objects fields and collaborators are set by an external entity. Parsley achieves this through allowing the coder to specify a configuration that holds information about what is to be injected and what message handlers may exist. But the code base of a project would be decorated by Injection tags, or Message tags.  There is NO direct coupling to the framework.    But the most noticeable difference between the two frameworks is the dependancy that exists on the PureMVC framework.

    PureMVC is a framework where you are constantly extending classes or implementing interfaces from the framework itself, thus leaving the project completely dependant on the framework, making it difficult to re-factor if a better framework were to come along.

    For example a command in PureMVC would have all this code to contend with:

    public static const MY_NOTIFICATION:String = "myNotification";

    // Facade declaration

    facade.registerCommmand(Notification.MY_NOTIFICATION, MyCommand);

    //Command Declaration

    public class MyCommand extends PureMVCSimpleCommand {

    public override function execute(notification:INotification):void {

    var med:MyMediator = facade.retrieveMediator(MyMediator.Name) as MyMediator;

    var proxy:Proxy = facade.retrieveProxy(MyProxy.Name) as My Proxy;


    med.presentationModel = proxy.presentationModel;



    In the example above the code is heavily coupled to the framework, and is not easy to reuse as it uses specific class implementations ignoring the benefits of polymorphism.

    The same is achieved via the following in Parsley:

    // for the sake of demonstrating polymorphism

    Presentation Model implements IModel

    MyView implements IView

    // The configuration for the current context


    (parlsey:Object type={PresentationModel}/)

    (parlsey:Object type={MyView}/)

    (parsley:Object type={MyCommand})

    (MessageHandler method="execute" scope="local"/)



    public class MyCommand {


    public var model:IModel;


    public var view:IView;

    public function execute(event:DataEvent):void {


    view.model = model;



    The parsley example does a number of things well:

  • It makes the command itself reusable by implementing the interfaces specified.
  • The config can specifici any model or view to be injected as long as they implement the specified interfaces
  • The code’s simplified.
  • Apart from a couple of tags it is not coupled to the framework.
  • A lot of code is cut out, and it is even possible to scope the code down further from this example.
  • It handles the event provided by flex not a third party communication strategy.
  • The handler is called based on the event Type (you can specify it via the event name using a selector, but I prefer to do it via typing)!
  • The event is handled in the local context, thus being ignored by the global context of the application.
  • PureMVC does indeed do what it says on the tin, but in order to do so a huge dependancy is built on the framework itself, and a lot of code is needed to setup your application.  There is a danger with Parsley that a not so experienced developer could strongly couple models and views together as there is no clear convention like PureMVC, but on the flip side it is extremely easy to avoid as the object dependencies are not applied until specified by an external container.  And there is no reason not to keep the views and models separated with parsley.

    The Parsley framework is largely based on the excellent reflection framework (SpiceLib) available from, which makes the injection model not only possible but also possible to extend.  Jens Halm (creator of SpiceLib and Parsley), makes it easy for developers to extend the framework via a clear documentation and supplies the source code as well.  If a developer wanted to create a new Tag for some kind of injection and is not sure how to go about it, just look to the online documentation and the code for the Parsley library.


    It was a pleasure to have developed with PureMVC over three years, and the supporting documentation is the best I’ve seen.  Before Parsley existed I had to choose a framework for my developers in a previous role, and amongst its then competition Cairngorm it was an easy choice.  It clearly separated models from views and dealt with many good coding and architecting principles.  But there is an expensive future cost; unfortunately a huge dependancy is built on the framework, it would be mammoth task to re-factor away from PureMVC should you find something better or PureMVC is no longer supported.  PureMVC does provide a mechanism of reusing your code, but is diminished by the fact that it is easy to create mediators, proxies and even commands that are to specific to the context that they are intended for.  It has recently added the ability to allow communication between modules via its new pipe library, but its extremely cumbersome to use and almost impossible to debug.

    Parsley as a framework is impressive, as it manages to IOC ;-) itself away from the developers code base.  If in the future I need to migrate to a different framework, I only need to change the tags or manipulate the configuration to work with the new framework; but 95% of the code base does not have to change.  The developer is not forced to inherit or implement from the framework itself.  As a result of a decoupled framework there is no reason why this could not be used in congestion with other frameworks.  But Parsley unlike many other frameworks provides a clear and intuitive messaging buss.   Parsley also takes into account the the context of an application area, and enables the developer to dispatch or handle an event in the scope of a local context, parent, custom or global context.  This provides a communication mechanism between different parts of your application, using flex’s own event api.  For example when dealing with modules, each module will have its own individual scope, but can communicate with each other via a custom scope which contains the context of each module.  Parsley is powerful in terms of what it allows the developer to do using the clear approach of IOC.  There are almost no dependancies in the structure, and it facilitates a lot of functionality with very little code.  Classes can be reused using the injection framework and polymorphism, with a minimal effort.