In the Java world there is a common interface specification for storing content, the java content repository (JSR-170). A content repository is a kind of object database specially made to store, retrieve and search hierarchical data. In the Microsoft .Net environment so far we had only one de facto standard, the SharePoint Data Store, a proprietary, closed source system. To alleviate this problem Portal File System, the content repository of Sense/Net Portal Engine TNG was born. It is a .Net based, open source content storage system, the foundation we build our applications on.

One may ask why do Enterprise Content Management (ECM) systems need specialized storage systems, and why don’t they use general purpose ORM tools (NHibernate, Gentle.Net, etc) or the file system.

The reason is simple. ECM systems have many characteristics and requirements in common. They:

• store documents with metadata in a tree structure,
• provide granular access control to content,
• offer services to search and filter large amount of content,
• solve versioning of content, and the list could be much longer.

For a list of services offered by Portal File System check out a previous post of my colleague.
These services require the capability from the storage system to define constraints on the stored information. As a result the file system of the operating system is ruled out.

In a typical EMC system there are hundreds of different content types, forms, lists, etc. An ORM tool would create hundreds of different tables for these “different” objects. Filtering through them would be very slow. (Imagine this situation: Dear ECM System, show me the contracts and ISO documents that I have permissions for and that were approved by the head of the Financial Department between 2006 and 2007. I can wait, I’ll have a coffee break anyway.) ORM tools are ruled out too.
So we arrive to the realm of specialized content repositories. When we started to work on Sense/Net Portal Engine TNG, we already had several years of experience with Object Store, our previous content repository. It was the building block of Sense/Net Portal Engine 5.5 and had very similar capabilities to the Data Store of Microsoft SharePoint Server 2003. With PFS we tried to improve on the previous version.

The main areas we concentrated on are:

• a general query interface with the possibility of complex queries (e.g. show me the documents that were created by the subordinates of the director of a department),
• database provider model (PFS is database independent through providers, currently it works with Microsoft SQL Server 2005 and newer, but Oracle support it almost done as well, later we will also create a MySQL version)
• unlimited number of properties for content types, lists (the database and the database  provider sets the limit actually)
• speed and efficiency improvements.