Transition from POM to CDM

Among the many things that we do at the Copernica R&D department is the transition to a new object model. Our software has (of course) a layered architecture in which the user interface, the data storage layer and the object model are all seperated. The current data layer in this setup is called POM which stands for Publisher Object Model. But this is about to change.

This object model sits in between the data storage level (both relational and NoSQL databases that hold the actual data) on the one hand and the web based user interface and the SOAP API interface on the other hand. This object model ensures that our design team and SOAP API users can use a nice and easy to use programming interface without having to access databases directly, and that the data in the databases stays in a consistent state at the same time.

In the POM data model we have defined all sort of classes (for example profile, template, document and mailing) with appropriate methods and properties. For regular Copernica users this object model stays completely under the hood, but for users of our SOAP API these concepts do come to the surface. And for privileged partners who have direct access to the source code these concepts matter of course too.

Transition to CDM

At this very moment we are however slowly replacing our POM object model with a new data model which we call CDM. CDM stands for Copernica Data Model and does basically the same as POM does now - but better. We have already moved basic concepts like accounts, users and licensing information from POM to CDM, and we will eventually move everything away from POM to CDM.

The reason for doing this is because we run into problems with the performance and usability of POM, and because we're not completely satisfied with the way POM works. But what does this mean for our end users? I will answer some of the questions that have been asked.

There are no consequences for users that only access Copernica via the web interface. Copernica will keep on working as it does now. The changes are only internal to the software and will not influence the way Copernica works.

We will process all frequently used SOAP API calls in the same manner during and after the transition to CDM as that the calls are now handled by POM. This is especially true for often used SOAP methods like the methods to create or update profile information. We will install compatibility layers to ensure that the calls are processed in exactly the same way as before.

But the Copernica SOAP API has thousands of methods, some of which are not even publicly documented. Most of the methods even never appear in our log files and have probably never been used by anyone apart from our own test scripts . Think of API calls to change the label on a button in a web form. For these sorts of (almost) unused methods we will not try as hard to maintain compatibility. If the consequence of the transition to CDM means that such an API method suddenly needs an extra argument or that the format of the answer is different than before, we will make an announcement of that to notify anyone to update their API scripts in time, but we will not install any compatibility layers for it.

They can be big. After all, we're in the process of replacing the middle layer, on top of which the user interface is built. But the number of partners with access to this middle layer is very small, and we will notify them in time when big changes are imminent.

This is a very good question indeed. The advantage of having an object model with a well defined API is that as long as you keep the API the same and only change the implementation, you do not have to worry about other programs and scripts that could break down because of the changes you make. But the point is, we do not only want to change the implementation, but want to add and remove some concepts too that would anyhow require incompatible changes to the API. For example we will eventually remove features like collections and subprofiles and replace them with other features as multidimensional databases and unlimited deep nesting of profiles. These changes require such big changes to other code outside the object model as well, that it is easier to build with a new object model from scratch and change the user interface, than it is to keep the old code fully compatible.

We are not in a hurry. It took years to build the current object model, and it could take years before all features and all code has been moved to CDM. Code in POM that works stays in place until we need to make such big changes to it that it is easier to move it to CDM.