Transport Interface Diagram


A copy of this uml diagram will be made available in the next source distribution

Transport Namespace

This namespace's focus is providing developers with an extensible, robust design for the Acquire-Modify-Persist pattern. Traditionally, this pattern is used to propagate data between data stores, but the intention here is to have the pattern open-ended and flexible enough that anything can be considered an end-point.



The connector interface defines the contract that an end-point must implement in order to work within this pattern. As long as the implementation provides the required functionality, anything could become an end-point for the pattern. The most obvious class inheriting this interface will be the DatabaseConnector and will make use of the DataInterface class provided in the Nvigorate.Data namespace. Notice that the connector is not required to actually contain all source needed to read and write data to the store, it can just be a simple wrapper around a pre-existing interface.


IFormat plays a very critical role in this pattern because it not only defines a particular format which the data may exist in at any given time, but it also facilitates the translation between itself and other formats. The current idea is to perform this translation by having all formats capable of presenting their data in Xml. This way, each format can translate itself to and from Xml, making all formats interchangeable. I'm currently exploring alternatives to this approach simply because working with Xml as a universal format could create performance problems.


IAutomaton is a generalized way to describe an object capable of automating the runtime configuration of another object. In this specific example, the suggested use is to have configuration files which the IAutomaton instance reads and then applies to the targeted object (in this case, the IConnector instance). This allows for things such as switching data stores without having to recompile, something that can not only make configuration far easier, but also make a much more robust system.


In order to allow the developer a simple way to have complete control over the processing which takes place on the data as it's passed throught the IChannel instance, IProcess gives a unified approach to create small, abstract processes which perform a set of steps against the data provided and pass the results back. By putting IProcess implementations into IChannel's process pipeline, the developer can change or adapt the pipeline during runtime.


IChannel is the interface that calls are actually made against. Applications making use of IChannel implementations will act against configurable channels designed to process and move the data between end points. IChannels tie all the previous interfaces together and work the entire thing as one contiguous, but highly flexible piece.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.