One of the announcements from HCL at ICON UK was that their partnership with IBM had expanded since the HCL Factory Tour to include work on additional products, one of which is Websphere. Historically the word “Websphere” has often grated with Domino developers, because it seemed that Websphere was the preferred app dev environment over Domino. But with the resurgence of Domino this year, I don’t think Domino developers are as worried about the Websphere vs Domino discussion.

It’s unclear what HCL will be doing or what the direction for the product is. But I’ve been vaguely interested in it for a while under its lightweight version Websphere Liberty, formerly Websphere Liberty Profile. Daniele Vistalli introduced me to it through his work on CrossWorlds and since then an open source version called Open Liberty has been released.

It was my experience with CrossWorlds that piqued my interest in the announcement. I have used Domino for a while to run OSGi-wrapped applications built with the Java framework Vaadin. It’s okay, but the servlet container in Domino is an older version that has limitations. It also means running through the HTTP stack, which is HTTP 1.1. There are also hoops to jump through for hot reloading of code changes.

More preferable was developing on Websphere Liberty, using a servlet filter, the relevant jar files and a local Domino server to connect across. Because Liberty was more up-to-date in the JavaEE elements it offered and could also be administered from Ecipse, it was a great fit for Java development against Domino. The only problem I’ve ever had was that often I could only talk to the local Domino server if it wasn’t running. And if I was using a Notes Client instead, it could only run as the logged in user and I think, again, Notes couldn’t be running. It seemed like a limitation in access from multiple processes.

With the announcement at ICON UK, I wonder if this should be the preferred way forward for Java development against Domino. It is more consistent with the Node.js architectural approach – an external web server talking via gRPC with Domino as a NoSQL datastore. And if you’re looking at alternative Java frameworks – Vaadin, JSF, PrimeFaces – there is no reason to target Domino’s HTTP stack for the web server. Moreover, Liberty offers a wider variety of authentication methods. The missing elements Java developers would need are also ones that will need to be addressed for Node.js development too – mapping alternative authentication methods to Domino, managing Domino document datasources, images, attachments in Rich Text Items, scalability of management of Document / View Entry collections. All that would be needed would be a Java SDK or preferably Maven (or Gradle) repo that wraps the relevant Notes jars to provide easy startup. It’s not rocket science to copy the jars, but just like Node.js developers expect npm modules, Java developers expect Maven or Gradle repos. Of course Liberty wouldn’t be able to run XPages applications, but it’s a debatable point whether it should (or could). But this would be an interesting idea to float for those wishing to use Domino as a datastore but move away from XPages to other Java frameworks.

1 thought on “IBM Domino, HCL and Websphere”

  1. I have believed for a while now that part of the IBM goal is to position Domino as a NoSQL datastore as a way of increasing acceptance/market share. Authentication is an issue, but I would think you’d be able to create some kind of SAML module in NodeJS to leverage what’s already in Domino to get an authenticated session.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.