What is Norman?
I have described it in the past as a distributed object server.This should not be confused with the standard use of the term object server, a Media object server, a server that distributes reports, files and similar objects to users in a network, rather a POCO object server, serving persisted, serialized objects to applications that may be used in a distributed way.
The name itself is an extension of NOrm (or Not an ORM). Whilst it has elements of an ORM at its core, they are purely there to support its own functionality. I am not intending to play in that space, and do not intend to be quagmired into debate. Norm became Norman, as Codeplex already had a project Norm.
So, when is an ORM not an ORM? When it's a jar. (that joke would probably work better if I was building this in Java :) )
For the last few years I have built a few systems that capture and organise relationships within metadata.
Originally this was when I was working for CA (formerly Computer Associates) and started working with a tool, acquired from the takeover of Platinum, called the Platinum Repository OEE (Object Enterprise Edition if memory serves). It later became the CA Advantage Repository for Distributed Systems without changing too remarkably (I offer the link for purely informative reasons, I no longer have any affiliation with CA and couldn't care less whether or not you are interested in the product). It was (and I assume still is) a wonderful tool to scan, organise and report metadata within an organisation, and capture all relationships and lineage within the metadata.
On the down side (this statement regards the tool as it stood 3 years ago) it was heavy, buggy and expensive. Scanners (to capture metadata from external systems) were not actively being built, and were shocking to write yourself (trust me, I built a few myself) with a horrendous reuse rule text format. Its asp based web reporting interface was also very simplistic, even by the standards of the day.
It was, however, fairly simple, if laborious, to configure and extend a metamodel which was the strength of the tool.
In my day I wrote a few extensions for CA ARDS, graphical modeling tools, scanners and front ends for a few clients, and many prospective clients who never quite made it to signing a contract, and grew quite fond of it, warts and all, and confess I would probably be happy to work with it again if it ever came my way.
CA tried to kill the product a couple of times, and last I heard (again this is old information and quite possibly inacurrate now) it had joined the ranks on 'Managed' product - a sort of retirement home category - though a quick glance at the CA site, they last released a Service Pack about a year ago, so they are obviously still supporting it.
Later I joined a company named Pelion, a Business Intelligence and Data Warehousing consultancy in Sydney and headed up their new Innovation department. There I set about building a similar metadata capture system to compliment, and act as the core metadata storage, for their modelling tools, which became the Pelion Solution Modeller (again the link is given for purely informative reasons). Unfortuately client project pressures meant I never got to complete the full data lineage configuration and reporting, and the tool's strength remained specification capture and modelling along with ETL and document generation.
Whilst I am very proud of the code I write at Pelion, and the Solution Modeller does what it does very well, one lesson I learnt after a while was that my architectural approach did not scale very well. There were three areas that concerned me.
- There was a large amount of boiler plate code that was required when adding new items to the model. Whilst Visual Studio snippets ameliorated a lot of the drudgery, it became evident that I needed to be less proscriptive.
- Originally it was intended to be a single user application. One consultant would take his or her laptop to the client, capture specifications, work on the project, then upload it to the central server.
- To gain the full advantage of the API around the metamodel, it required to be loaded in full. Whilst the amount of data required to do this was relatively small, we decided only to do this on the Winform clients, and not the web interfaces. As a result, all web pages requiring metadata would have to load it from the database independently. As all relationships existed only in code, this required a certain amount of domain knowledge and hard coding.
We did eventually create a metameta model to allow dynamic traversing of the meta model, and began to get solid gains out of it by providing dynamic meta data lineage reports, this was required to be updated by hand each time the metamodel changed, and eventually fell out of step with the model.
Inevitably, however, when projects got large, or the deadlines were imminent, it was quickly assumed to be a distributed application.
If more than one person worked on the model at a time, there was a classic 'last in best dressed' scenario when it came to saving work to the server. Due to the model having being based on strong and weak couplings of independent metaobjects, this could corrupt a model. Whilst this was annoying the few times it happened, it wasn't enough of an issue to warrant spending too much time and money to fix it.
Norman will be the framework to build what I wanted to CA ARDS to be, what I want to build at Pelion, and what ever it becomes.
It will be a robust .NET development framework to allow applications to be built that require object relationships to be defined and their lineage traversed dynamically, the product of a few lessons learnt.
I shall leave it at that for the present, I am tempted to describe further the specifications and requirements for the tool, however to do them justice, they probably need their own post.
Feel free to download the source code from CodePlex,
