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:
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:
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.
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
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)
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.
Comments
I liked your article that demonstrates how IBM Domino can be a very powerful and flexible platform to build MODERN applications. We need more people like you to promote Domino as a GREAT solution.
Just a question about your article: to me, it seems odd to put every apps data in a single NSF, for various reasons:
1. Performance: we know that Domino views are slow, hence, having more documents in an NSF does seem to be a winning strategy => the performances will decrease proportionnally with the number of deployed apps and stored data. Domino is very good at handling multiple small NSF, and less good at managing huge NSF.
2. Maintenance: back-up & restore of 1 huge file is more difficult that managing multiple small files.
3. Reliability: in case of db corruption, every apps and every customers will be impacted at the same time. It also prevents from restoring the file of ONE customer if needed, without impacting everyone else.
4. Limitation: from what I'm aware of, the total amount of stored data can't exceed 64Gb. This can't scale well, and anyway, the NSF will become slow and inefficient much before this limit.
This is only my opinion according to what I used to experience as a Domino developer, but of course, I might be wrong.
By the way, great article! Thank you.
Best regards,
David.
Note: I tried to register for a demo on your Phora Group website, but the submit button just emptied the form and nothing happened. I've tried twice. Did it send my request?
Your iPhora menu also points to an error 500, you should have a look: http://www.phoragroup.com/iphora.html