This time last year, the message about Domino application development was very straightforward. Domino 9.0.2 was slated for Q4 2016, with the expectation that this would include open sourcing of not only XPages Extension Library components, but all XPages components. The XPages runtime classes would still be closed source, but things like DominoDocument datasources would be open sourced, so additional features could be added by the community and we would be able to understand how rich text is handled in the XPages world.
Fast forward one year and the message is less clear. On first reflection this may be confusing, and I have seen some calls for greater clarity from IBM. IBM do not tend to recommend one route or another, which has caused frustrations to be voiced in the past, and this may appear to be the same. Those of us who embraced XPages always felt frustrated that IBM never pushed customers more to move applications from Notes Client to XPages. After all, XPages was an infinitely better approach than traditional Domino web development – it avoided the hacky HTML and constructs required for Forms and Views ($$ViewTemplate etc), the editors did not encourage good JavaScript coding, UI was less tied to data (MVC was not encouraged, but multiple documents in a single view was promoted from the start), cross-browser support was greater, and multi-device support was available out-of-the-box. Although offline XPages use was never quite as good (XPiNC has quirks!) and redevelopment of Notes Client applications into XPages was never as easy as the sales pitches claimed, the benefits XPages offered meant more applications should have been converted than have. On the surface, this seemed another case of IBM choosing not to recommend one particular route.
But on further reflection, I think the message from IBM this year – namely, choice – is the correct one. There is no “one size fits all” for applications, the precise reason conversion tools did not move everything from Notes Client to XPages, the same reason migration options have not killed (and probably never will kill) the Domino market. The preferred option will depend on a reasoned assessment of each application and a review of the various merits of the alternatives. Let’s walk through them briefly, but bear in mind this is by no means comprehensive and would require more in-depth understanding of the technologies involved and cannot take into account your own particular applications.
Notes Client
At Intec, we still have a number of customers with Notes Client applications and for various reasons that will still continue. Customers may have decided Domino is not a strategic platform for the future (although we have seen some review and reverse that decision). Applications may continue in Notes Client either pending migration to another platform or because they can’t be migrated. In some cases, applications may be best suited to the Notes Client, either because browser or mobile use is not required or only for a tiny feature set, because they are used by a small set of people and it is not worth redeveloping, because they are too complex to redevelop, or because they are needed offline and work adequately as they are. For those who think offline is not a requirement, know that even in San Francisco last week there were locations outside the venue where network connectivity was poor and many places in UK where mobile network connectivity is unsatisfactory. It’s a situation that is not improving at anything like the pace required.
XPages
Just as many Notes Client application will not be redeveloped because they are satisfactory where they are, the same will be the case for XPages applications. XPages may not have been embraced in some areas but I have seen a large proportion of people embracing it in UK. I have delivered training on XPages for many years now with several courses delivered in the last few months. The strengths I listed above over traditional Domino web development are equally valid. The documentation, samples, videos, tutorials, community support etc is still better than some technologies I’ve tried to work with. The XPages Extension Library and add-ons on OpenNTF significantly enhance what was initially developed. (And for those who claim their company doesn’t allow them to use open source, newsflash, you not only can, you do: your Domino server includes millions of lines of code that’s open source and – if you ever install the “officially supported” Feature Pack 8 – it will even include lines of code by me.)
But XPages will still also be embraced because, although it has a big learning curve, it allows Domino developers to remain within Domino Designer, outside of which they may not be comfortable. Although there are criticisms, beyond DDE is a more challenging world with less provided out-of-the-box. I cannot number the amount of plugins I have added to Eclipse and regularly do each time I install a new instance. And that’s without database layers, servers and configuration, build management tools, etc. Installing Domino Designer and a Domino server for a development environment is considerably quicker, especially if you have configuration settings exported and a Widget Catalog defined with all the plugins you use.
Intec’s XPages courses – an introductory course and one on XPages and Java – will still be available and encouraged for the foreseeable future.
For many developers, XPages will still be a preferred environment, particularly if they have not embraced Java.
Application Modernisation Options
I can’t claim to be totally knowledgeable on the options announced at IBM Connect and timings / focus meant I was not able to become as fully aware. My current assumptions are far from set in stone and I would encourage anyone reading this to investigate further (there is a TLCC webinar on March 7th re-running the session from IBM Connect) and form their own opinions on the suitability of the options for their own business / customers and applications. But here is my current understanding.
Darwino
Darwino is the product I am most knowledgeable about. I think it’s obvious why this was highlighted by IBM (and not just because of esteemed developers like Phil Riand and Jesse Gallagher). Although it moves the data to another database (the samples use Postgresql), unlike some products it has never been pitched as a migration tool, one of its major strengths is replication. That is extended further for offline (hybrid web application) usage on mobile devices or desktop. It also uses tools to convert code for iOS and Android. The hybrid applications can be extended with proprietary, device-specific functionality for iOS and desktop (desktop would be a SWT container). The extent of functionality is significant for customising replication, managing authentication, switching the relational backend, JSON parsing, mail handling, preference handling, REST integration, filters, querying, scripting, server environment management (Bluemix, Azure, Tomcat, Liberty etc). Coding languages are Java for back-end and your preferred JavaScript framework for front-end.
This means it’s another learning curve for XPages developers, especially those who have never stepped beyond Domino Designer. I’ve tried getting it to work with a Java framework like Vaadin, but the inevitable conflicts between two frameworks that use the same language make it more than problematic. (XPages developers, when I’m talking about inevitable framework conflicts, think of the conflicts between jQuery and Dojo.)
The challenge is the landscape of JavaScript frameworks is so fluid that, unless you’re developing regularly, getting up to speed for a project is one thing, but staying up to speed for the next such project which may be months away is a very different thing.
Aveedo
We4IT’s Aveedo has been around for some time. It’s a product I’ve been aware of though I must admit I have not kept fully apprised of it. My understanding is it quickly give XPage access into applications through wizards. If my understanding is correct (and I may be wrong), it seems better suited to small, less complex applications or ones where read-only or simple XPages access is required.
Sapho
The Sapho tool demonstrated in the OGS is one new to most. I did not get a chance to investigate further, but the product’s main differentiator seems to be around integration with other data / services. My understanding is the company themselves are new to the Domino world and some of that is apparent in their solution. They also produced a slick demo of notifications being pushed to Watson Workspace, something those attending my OpenNTF Domino API session would also have seen done very quickly (100ms after a save) with functionality from ODA that is albeit currently very experimental. Watson Workspace integration is not difficult, and if it’s something customers are looking for, knowing the developers involved in the other two products I am sure it is something they will quickly add.
Other Products
The three above were those chosen to be highlighted by IBM but it’s worth being aware that they are not the only ones on the market that offer options for modernising applications.
REST
The major announcement was around REST access. There are some out-of-the-box REST services being delivered for core Domino, but I’m not sure how widely those will be used beyond Connections Cloud. This is the main new functionality IBM will be delivering that was not announced at IBM Connect last year. It’s disappointing but not surprising that this is related to PIM. There will be new templates, but I’ve yet to hear or see clarification of what they are, which client(s) they will support, and some may be official packaging of what has been available on OpenNTF.
SmartNSF
An OpenNTF project called SmartNSF was also announced as an option to speed up REST service development. Again, I’ve only briefly seen this and it’s still very much in beta. But it may be aimed more at allowing Domino developers to allow others to integrate with existing Domino data. I do not know if developers will be able to use Domino Designer Local Preview (currently the only free entitlement for Domino development) to test the resulting REST services, and if not it increases the need for IBM to address the availability of a local Domino server for developers. I am not sure how many developers are aware of Swagger or the OpenAPI Specification and how many will have the technical skills to write REST services in this way within the NSF. I suspect it is unlikely to appeal to non-Domino web application developers, who are already unlikely to use Domino Designer. I am not sure if the target audience will be people au fait with building a web front end based on those REST services. And I suspect Domino developers will not see much benefit for their careers in quickly exposing REST services for other developers to create the (non-Domino) web front-end. The use of a Domain Specific Language to construct the REST services may benefit Domino developers who have JavaScript web application development skills and want to quickly expose specific and validated REST services without coding in Java. But I’m not sure how widespread those are or will become.
Other REST Options
XPages developers may choose to continue to use options available in the Extension Library, because they are a more familiar environment.
My preference has always been using a REST servlet plugin, because it uses standard JAX-RS functionality and syntax, while also allowing some IBM libraries to be used for JSON parsing and web exception handling. That’s why I released (and documented) an OpenNTF Domino API REST servlet starter, to highlight all of those things. I’m in the process of converting that to a Maven project and template, which might make it easier for those who prefer that approach. (Although there will be more configuration changes, it will auto-build the Update Site required as output.) Also worth being aware of are recent blog post series by renowned Domino developers, Sven Hasselbach, who has previously been an IBM Champion and thankfully is very active in the Domino space again, and Jesse Gallagher. Others like Eric McCormick and Toby Samples are blog series I’ve found useful when developing REST services.
Web Applications with Domino REST
As with other options, developing a web application using Domino REST is not going to be appropriate for all applications or all companies. A web application using Domino REST is unlikely to be the best choice for offline usage. Similarly, it may be harder to “bolt on” functionality to an existing Domino web or XPages application with this approach. For those who have no current skills with JavaScript frameworks and no desire to build those skills, it may not be an appropriate strategic decision. Similarly, a consultancy building an application to deliver for internal support will need to consider whether the in-house development team have these skills, even if this is theor preferred approach.
But for companies or developers who choose to develop for other platforms or products like Connections Pink, this seems quite timely.
Even then, if you’re looking to build a web application using a JavaScript framework like React or Angular using Domino via REST, the big question is what that architecture looks like. Where is the application delivered? How is authentication handled (Domino or other)? What other elements make up the stack? How are scheduled processes / workflow managed? There are a lot of questions, many of which are not covered on blog posts. It’s not appropriate for people to look to IBM for answers here. This kind of guidance on options and best practice is for the community to be involved in. It’s an area that Intec will look to be involved in.
REST Easy – We Can Help You With Training!
REST is certainly a key area of focus for the coming year, which is why Intec have developed another technical enablement training course, this time specifically around REST, the tools available, smarter REST services using GraphQL, with an optional overview of tools and technologies for using those REST services.
Java Web Applications on Domino
Development using a Java framework other than XPages, something like Vaadin, is still as possible as it ever has been. I have blogged, both here and on Vaadin’s own blog, about development with that framework. And Stephan Kopp has also just released a beginner’s blog series. The better news is that the imminent release of Domino 9.0.1 Feature Pack 8 will bring Java 8 to the platform for use in Java web applications. Although the servlet container has not been updated (this may come with the OSGi update in Feature Pack 9, nothing confirmed yet, but IBM are definitely aware), it will enable developers to leverage the newly-released Vaadin 8.
This approach will appeal to those developers who are comfortable with Java, want to go beyond just XPages, but have no interest in JavaScript frameworks. After all, with Domino applications and projects typically being small, being able to use a single language for back-end and front-end has a strong appeal.
ApplicationInsights and Summary
The watch-word for this year is choice. But choice is meaningless unless it is informed choice. IBM also announced free entitlement for Panagenda’s ApplicationInsights coming, which will help give a more informed choice about a company’s application estate. But, as I’ve mentioned, the applications are just one aspect that will inform the right choice for the right application for a specific company. If a deeper understanding and assessment of the options is required, or additional training tailored specifically at developers who have limited experience beyond Domino Designer, business partners like Intec can also help out. Domino developers typically have a strong understanding of the business and its history, which should not be underestimated. I have previously created whitepapers about the challenges of migration away from Domino and it’s rarely as straightforward as people believe.
Hey Paul, I can assure you that we’ve already migrated and created also very complex apps with workflow and a lot of code with aveedo 😉
Great to know and thanks for clarification from someone heavily involved in the product.
Wonderful summary, Paul! I’ll start digging around a bit with SmartNSF, to see what I can do with it.