Arguments for the obsolescence of Domino are simply not credible. Until wired client/server IT infrastructures are replaced by distributed peer-to-peer networks of wireless mobile computing devices Domino has a place in the server room. If Domino were to go away before then, Microsoft would get another 80 million users for Exchange. The architecture of a future technology that could make Domino obsolete will probably look a lot more like the Groove client on a PDA-sized wireless computer than it will look like WebSphere.

Since Domino is an application server, it probably doesn't make sense to bring WebSphere to the party to build a workflow application in a company using Domino as their IT infrastructure. Time and again I've seen customers trying to do things with Web technology when they have Domino sitting in the server room. Too many Domino customers fail to leverage their investment and spend more on solutions that they could build and deploy for less using Domino.

Web technology and application servers are clearly not the right answer for every IT problem. In the last few years the entire industry has suffered from the "only tool syndrome." When the only tool you have is a hammer, every problem begins to look like a nail. Now that the Internet mania has died down, hype is once again less important than reality. Thankfully the software industry can focus again on giving customers what they want and enabling customers to succeed in concrete and measurable ways (rather than on technology for technology's sake).

Customers that successfully exploit Domino are tremendously capable. Using only IT staff resources Domino customers deliver amazing functionality to business users, often including dozens of business applications and automation of data processing to meet a wide range of requirements. There is no more capable, more flexible rapid application development solution focused on in-house IT on the market today.

Integrating Domino and WebSphere
To end the Domino versus WebSphere debate there would have to be not only a clear difference between where WebSphere is focused and where Domino is focused but also no overlap. Borderline cases where either Domino or WebSphere could be used are the reason why there has been ongoing Domino versus WebSphere debate.

In these cases there is no clear-cut answer. To arrive at what's best for the customer both technology and non-technology factors have to be taken into account. Where features of the two products and the solutions they're appropriate for substantially overlap are exactly where we need to look to develop a sensible integration model.

Replacing the Domino Servlet Manager
Perhaps the most obvious idea is to replace the Domino Servlet Manager with a version of WebSphere that integrates directly with Domino. Today, integration can be achieved in either direction by making calls from a Java servlet running on either Domino or WebSphere to a servlet running on the other product. This is very crude as an integration model and doesn't facilitate portable servlet development. It also doesn't address EJB (Enterprise Java Beans) integration. An application server must have both a servlet container and an EJB container.