A Future for Notes/Domino Developers

Collaboration & Messaging
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

At Lotusphere, on January 27, 2003, IBM Lotus revealed its Lotus Domino Toolkit for WebSphere Studio--a much awaited suite of utilities that helps clarify IBM's strategy for its Lotus Notes/Domino development platform. By introducing Domino Toolkit for WebSphere Studio, Lotus hopes to placate its loyal developers, many who have felt squeezed out of IBM's larger development strategies with J2EE on WebSphere.

At the same time, Lotus also previewed new Web Rapid Application Development (RAD) features that are designed to assist developers build collaborative applications without substantial knowledge of the Java programming language.

The Notes/Domino Toolkit for WebSphere Studio

At the heart of the Domino Toolkit for WebSphere Studio are a number of features to segue Domino developers toward the WebSphere J2EE environment:

  • Eclipse open-source platform: Instead of using the Domino Designer IDE, developers will access the features of the toolkit using the Eclipse open-source IDE, to give the toolkit the common look and feel of other WebSphere toolkits.
  • Custom Java Server Pages (JSP) tags: Developers will utilize custom JSP tags to access existing Domino data from within WebSphere Studio.
  • Reusable views, agents, and forms: The critical elements of Notes forms, views, and agents existing within Notes databases that have been deployed on a Domino server will be accessible in new J2EE applications. This will enable developers to transition existing Notes databases to WebSphere applications without substantial recoding in J2EE.

Removing Developer Confusion

The features provided by the toolkit clarify how IBM envisions the role of collaborative applications written within the Lotus Notes/Domino environment. For many within the Lotus developer community, IBM's past actions with WebSphere seemed to be sending mixed messages about Notes/Domino J2EE compliance. These Domino developers had been pushing Lotus to incorporate many J2EE features directly into the Domino Designer IDE, increasing the reach and breadth of their existing Domino applications out through the WebSphere Web Application Server (WAS). To understand how this confusion evolved, it's necessary to remember Lotus' past marketing strategies, before it was acquired by IBM.

A History of Notes Web Extensibility

Indeed, years ago when Lotus initially segmented its Notes product line into two separate functions (the Notes database function and the Domino WAS function), it was responding to the tremendous explosion of interest in the burgeoning Internet. That strategic rebundling of Notes leveraged the innate power and ease of Notes application development into powerful Domino Web HTML applications. It allowed Notes developers to quickly build comprehensive workflow applications with ease by using the Notes developer tools and then, with a modicum of configuration, translating those applications into HTML suites that could be automatically served across the Internet to Web browsers through the Domino server. This gave a significant marketing and productivity advantage to the Notes product line, and companies that needed quick, easy-to-develop applications served out to the Internet as Web pages embraced the concept: Domino-driven Web sites flourished, often to the consternation of Web masters who despised Notes' proprietary structure and the requirements of the Domino server.

However, IBM's backing of the Sun Microsystems Java language and the Java Virtual Machine (JVM), key building blocks to cross-platform Internet applications, immediately created a critical stumbling block for the Lotus Notes/Domino development environment.

The Problem with Notes/Domino

Notes/Domino uses--among its many tools--a proprietary internal language called LotusScript to power its applications. LotusScript agents are embedded directly within the IDE of the Notes Designer and every Notes database. This functionality drives the RAD cycle of Notes/Domino environment.

However, IBM has chosen J2EE as a cross-platform programming environment (under the brand name of WebSphere), and this created an evolutionary dilemma for the Lotus division: Should Lotus try to incorporate all the features of J2EE into its Notes/Domino IDE? Or should it make all Notes/Domino proprietary applications and databases accessible to external languages such as Java? What would be the benefits to either strategy? What would be the perils?

IDE Conflicts

Of course, the Domino developer community wanted Lotus to incorporate Java into the Notes/Domino IDE, and indeed Lotus' R5 of Notes/Domino began to implement that strategy, making many new Java object classes available to developers from within the Domino Designer. However, this strategic direction held a lot of tactical and technical problems, especially when the developer tried to implements non-Notes Java classes that existed outside the Notes/Domino domain.

Secondly, the resources needed to develop the Domino Designer--which is a high-level IDE--to mirror all the future capabilities of J2EE were daunting, even for a division backed by the power of IBM. Many J2EE functions could never be adequately implemented in a high-level IDE client like the Domino Designer, and many functions would be inappropriate in a workflow application suite.

Finally, advancing the Notes/Domino developer IDE was in direct conflict with IBM's strategy to devote R&D dollars to the Eclipse open-source IDE initiative.

Server Conflicts

There were other problems with this design blueprint, too. How was the Domino server--the server code that actually transformed Notes databases into HTML--going to coexist with the WebSphere WAS? Were the HTML transformation services to be encapsulated into the WebSphere WAS? If so, how would that affect IBM's strategic plan to keep WebSphere a "standards-based" WAS? Such an encapsulation of the Notes proprietary database functions would essentially drain the Notes/Domino product of its unique value within the marketplace, opening it up to imitators and competitors. On the other hand, somehow protecting an encapsulated Domino server within WebSphere would defuse IBM's strategic marketing goal to keep the WebSphere WAS open and standards-based.

Functionality Conflicts

Finally, one of the long-term goals of J2EE is to develop Java classes specific to workflow and collaboration--classes that might mimic and extend the power that already exists in the Notes/Domino product. These classes are still in development because the standards associated with their completion have yet to be enacted.

Now, if IBM backed the Notes/Domino environment to the exclusion of these long-term goals of workflow and collaboration standards, its efforts could be painted as a kind of proprietary wrangling to protect its own product. Yet, if it also ignored the demands of its loyal users and developers for J2EE functionality in the R6 release of Notes/Domino, the message would be clear to its customers: Notes/Domino--the jewel of the IBM Lotus acquisition 10 years ago--would be deemed dead, and new application development by customers would be seen as a risky strategic direction. Clearly, this was not the message that IBM wanted Lotus customers to hear.

Threading the Tactical Needle

For these and many other less obvious reasons, IBM Lotus chose to implement a toolkit strategy that preserves the vitality of past development efforts within Notes/Domino, while extending the Notes/Domino developer community toward IBM's WebSphere strategy.

Using JSP tags provided by Domino R6 and the toolkit, a WebSphere administrator will be able to tap into the HTML output that Domino delivers to the Web. This means that a Notes/Domino application output, in the form of HTML, will be useable from within the WebSphere WAS, without the R6 developer tinkering with pre-existing code.

All the customized forms, views, and agents that the R6 developer has created within Domino will also be accessible to the WebSphere administrator, enabling Domino applications to appear within a site hosted by the WebSphere WAS.

In addition, as a way to draw R6 developers toward the WebSphere Studio product line, IBM has provided some new RAD features. These features mimic some of the functionality that Notes/Domino developers have long appreciated in the native Notes/Domino Designer IDE. IBM hopes that, by making the toolkit and the WebSphere Studio products interface productively with R6, developers will get the message that the Notes/Domino Designer function is ultimately to be transformed and that the standalone nature of Domino applications themselves will be better managed long-term, using the WebSphere WAS.


IBM Lotus says that the Lotus Domino Toolkit for WebSphere Studio will be included at no additional cost in an undisclosed future version of Domino Designer 6. It will require both Domino 6 and WebSphere Studio V5 and will be shipped in a separate directory. According to IBM Lotus, the toolkit will require a separate installation process.

A beta version of Lotus Domino Toolkit for WebSphere Studio is available now at the Lotus Developer Domain. Final code is currently scheduled to be generally available with Lotus Domino Designer in Q2 2003.

IBM Lotus says that the pricing and availability for the new Web RAD features of WebSphere Studio will be announced at a later date.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..