Skip to main content

The iPhora Journey - Part II - Domino, the Little Engine that Could

The iPhora Journey - Part I  - Reimagining Domino

We have been working with Notes and Domino since 1995, back when it was still called Lotus Notes. The name "Domino" did not come into the picture until a few years later when the Notes server was renamed. Our company, ReCor, provided computer-based training Notes and Domino, and our course offerings included training for application development, administration, and end-users. After the early 2000's, demand for new installations of Notes and Domino began to decline, along with the demand for training. 

At this point we decided to start a new company, one that focused on IT Support and application development, but with an emphasis on Domino. This is how Phora Group began. Our initial problem was that all of our customer contacts were for training, and while the ReCor customer base was extensive and included many very large companies, those customers were already supported by either internal staff, IBM, or IBM Business Partners. Therefore, our focus had to be on new customers and figuring out what new customers needed.

Our new customers tended to be smaller than what we were used to, but there were many of them and we did not have to contend with internal IT and development staff. We created a digital workspace -- although that term did not exist then -- called the Integrated Business Framework and this was a Notes client-based solution. It included a number of standard modules, including CRM, sales order, inventory, technical support, project management, workflow, and others. As our customer base grew, we added more modules to provide support for an ever-increasing range of business functions.

Over time, support and scalability became a problem because each new module meant changes to the design of multiple databases to accommodate the new features. This is because all modules had to be selectable from within any other module. We resorted to using features like embedded views, which soon became a nightmare to manage.  Moreover, the Notes client is something of a UI beast, and it is extremely difficult to create the kind of user interface that non-Notes users expect. Customers had already become familiar with UIs from other software and even from web applications. For a long time, Chris Blatnick maintained a blog called "Interface Matters" where he described different approaches to improving the look and feel of applications running on the Notes client.


During that time, we created some exceptional Notes client interfaces like the one above, but each one required a massive amount of work. With traditional Notes development, the UI elements and business logic are contained within the form and the data is stored in a document, and the integration between form and document is so complete that it is almost impossible to conceptualize one without the other. Not only that, but there is no centralized place within a form for the UI and logic. They could be in a set of Action buttons or hotspots or agent calls or even in events, such as the QuerySave event. Some code might run on the client and some on the server.

With the rise of web applications, XPages was introduced as the preferred method to take Domino applications to the web. However, XPages was still dependent on complete integration between form and document, an approach that became more and more cumbersome to maintain.

This binding between the form and the data may have worked in the Notes client, but that is not how modern web applications are designed and the linkage makes it extremely difficult to apply the latest web technologies to Domino. It became clear -- at least to us -- that the link had to be severed in order to move forward.  Separating the form and the data allows the developer to more easily create the UI and manage the data. It also means abandoning the Notes client. For us, all applications would now be web applications. This was a watershed moment.

We started by experimenting with an API-driven model rather than the client/server model used with the Notes client. All interaction between the web client and Domino server would be through server-based agents. This was easier to maintain and made the data more manageable. 

This leads to the obvious question of why use Domino if the focus is only on web applications? There are plenty of platforms out there that are faster, newer, more web-centric, and in many cases open source. For example, you could design a web application using a combination of Nginx/Express/Node/MongoDb. So why use Domino? 

First, it is important to look at the essential components of a web application:

  • User and Data Security
  • Web Engine
  • Business Logic
  • Database

As we mentioned in part 1 of this blog series Domino excels at:

  • Data Security
  • Master-to Master Replication
  • Integrated Web Application Server

If we went with the Nginx/Express/Node/MongoDb combination, there would be no built-in user security or data security. It would fall upon us to create it. With the current climate of hacking and malware, we would need an entire staff to develop and maintain just the core security features. With Domino that core security responsibility is handled by HCL, which means that we don't have to spend precious resources creating and maintaining that security infrastructure,. Not only that, the Domino security model is already highly granular, including user-level, database-level, document-level, and even field-level security. No competing web database technologies have anything similar.

Domino also includes an integrated web application server, which frees us from having to create all the code that is necessary to connect the different components: web server to security infrastructure to database. Domino brings all that is needed into one cohesive platform that can literally be run on even the smallest of server. Because of Covid, we downsized our offices and the server box pictured was our operational Domino server. In many cases, a single-server Domino web application is fully sufficient for a small businesses. It represents a complete solution.



If you have ever shopped for a house, you would have probably heard the phrase "good bones" used to describe a certain property. This refers to an older house that may have some appearance/image issues but is solidly built. Well, Domino is like that. It may not the first choice that springs to mind for a web platform, but it has great bones. It is the little engine that keeps on chugging.

So, is it possible to take what Domino has to offer and transform that into a modern web application platform? Can we extend the Domino access and security models to provide an even more secure platform focused exclusively on web access? Could we implement a new vision for Domino, a vision that includes:

  • Web API-based with JavaScript SPA
  • JSON-based application engine
  • JSON-based database
  • Flow-based processing engine
  • Graph API
  • Security fidelity even higher than what Domino provides
  • Portable to other platforms

So that was our quest. Taking Domino from the Little Engine that Could to the Little Engine that Can.

Next time, The iPhora Journey - Part 3 - Creating an Integrated UI Framework.


Comments

Popular posts from this blog

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework There are many ways to create the user interface (UI) for a web application. The HTML page could be created on the server and then pushed out. It could be static with the data generated on the page by the server with JavaScript, providing a more dynamic experience, or the server could generate new HTML content to update portions of the web page. XPages or PHP are good examples of this. Another method is to have the web page partially generated by the server and have JavaScript build the rest of the HTML by pulling data from the server via an API. This is the approach used in the Single Page Application (SPA) model. In all cases, it is still dependent on the web server technology being using.  As mentioned previously in this blog, XPages is dependent on complete integration between form and document, which e