Monday, November 13, 2017

When your Tool is a Hammer, Everything is a Nail, Transformation of Domino - Part 2

The recent announcement by IBM to continue the development and support for the IBM Domino platform indefinitely was great timing for part 2 of this series. This series is about the direction that we are taking Domino. This journey has taken more than five years with many different designs and experiments to get to where we are in our iPhora technology. You can find Part 1 of this series here

There are many tools and solutions out there from many vendors for "Modernizing" a Notes application. But what does that really mean?  In most cases, that means replacing the Notes application interface with a Web interface and making a better UI experience for the user.

But for us application modernization is not just about the front-end but also but how the data is collected, managed, stored and processed. How it integrates with outside third-party services. Most Domino application modernization leaves the data untouched in the same structure. XPages mimics the Notes application environment for a Web client versus a Notes client. This approach allows data to remain in place as it was defined.  But as we all know, it also leaves a lot of useless code, views and wasted resources. 

We wanted a defined framework, that allowed us to create applications more consistent with how the majority of modern Web applications are built but at the same time utilize the best parts of Domino. We are not just interested in "Modernizing a current Notes/Domino application" but building new enterprise applications that utilizes the key advantages that Domino uniquely has.  Before we go any further lets look at what a Web server environment normally consist of. It may include:
  • Web server
  • Identity/Authenication server
  • Load balancer
  • Cluster manager
  • Mail server ( for notifications )
  • API server
  • Integration server
  • Application server
  • Database server
One of the best things about IBM Domino is that all these different type of server components that you need is all bundled into one single server package. This is great for many, but it is also its Achilles heel. This tight integration also creates problems. Any changes to the design of one these server components require changes in the other server components. As a result, each of the server components may not be optimal. That means that IBM Domino is a jack of all trades but not the best of anything. For many that is more than enough. However, for scalability, extensibility and future competitiveness this is bad. If IBM Domino is to be competitive, you need to reevaluate the approach on how applications are built on Domino, but at the same time understand how to utilize the best features found in Domino but not in other platforms.  

Majority of Notes applications have a one to one database relationship with each having different views,  forms and etc. Over time they all have different design approaches. Some developers break out the application to multiple databases some not. The design varies from application to application. A typical Domino application has all the business logic and data wrapped into a single database regardless of whether you are using XPages, traditional Web application, Notes Application, and whether we are using REST API with JavaScript or generating the Web application using XPages. 

We wanted to separate out the different server components and depending on our need replace those components will newer components that may utilize different technologies not found currently in Domino. This would allow us to Dockerize Domino easier in the future. By breaking up the server components, we can now look into replacing these components with other technologies that have better performance. For example, Nginx as a Web server has much higher performance than what Domino could ever be, the API server could be replaced with a form of Node/Loopback.io.

So in a typical iPhora installation there is a fix number of designated Domino databases each serving as an individual server component that makes up the iPhora server.  A base installation includes:
  • Web Server (Generates the UI interface) 
  • API server ( generates all the RESTFul APIs)
  • Database server (JSON-based data store)
  • File Database Manager (Manages all the files stored on the installation)
  • Application server (contains all the business logic)
  • Identity Server ( contains all the profiles and users info and works with the Domino Directory)
So regardless of the type of application or how many applications you have, you have the same number of databases, unless you exceed the limits of a Domino database which we have not encountered yet. So an application is no longer represented as a single database, but a collection of business logic, UI components, and APIs. It may seem to be a waste initially, but as you build more and more applications, you do not need to allocate more and more databases.  The individual databases collectively provides the framework for your application to draw from. Our typical application is now a series of MVC views, JavaScript/CSS files, additional APIs, if needed, and business logic files.  All applications must follow a strict design pattern for both front-end and back-end which also allow us to have different developers working on the front-end and the back-end.

Security is our top priority not shear speed like other platforms. Regardless of who you are, users only have read access to the Web server database and the API database when access any application. All the rest of the databases, users have no access include administrators. CRUD is a definite NO NO. Users regardless whether they are only readers or administrators should NEVER have direct access to the data. Strict access control of data is done through a gateway with low level administration only done using our Notes-based client application.

One of our biggest challenges was transforming the Notes document database into a JSON-based data store similarity found in MongoDB or CouchDB. We used CouchDB as our design model, but discovered that we needed our own approach. We will discuss this is part 3.










No comments: