IBM's Lotus Software this week announced that Java 2 Enterprise Edition will become the middleware platform for its Notes and Domino family of collaboration software, including Sametime instant messaging and conferencing, and QuickPlace virtual workgroups. In addition, Lotus said it will reengineer its software as a set of components, such as in-box, calendars and group scheduling, that can be blended into business-process applications running on the J2EE platform, most notably IBM's WebSphere. Al Zollar, general manager of Lotus Software, sat down with Network World Senior Editor John Fontana Tuesday to discuss the implications of the coming changes.
- An infrastructure perspective
- The messaging wars
- The next version of Domino
- Is this a move from a Domino application development environment to another platform?
- Effect on the Notes client
From an infrastructure perspective, how does this J2EE strategy change things for enterprises working with Domino? Will it change things?
You have to step back and look at this based on the way the industry has evolved. When Notes and Domino were first created, there were not a lot of standards for the middleware buried inside of the Domino server runtime. I'm talking about the database, the directory structure, the security model and the development tools. All those things were handcrafted as an integrated solution.
Advertisement: |
Well, what has happened since then? Lots (laughs). We have far greater standards around database technology, directories, security and around this notion of a server-side programming model, J2EE, with all the various functions, such as Java Beans, Java Servlets, Java Server Pages. All of that stuff has come together now as a coherent infrastructure that can be leveraged by somebody to deliver a collaborative solution the way that Lotus does.
From a historical context, all we have done is said, 'Here is where we'll get our plumbing in the future.' In the past, we built our own plumbing. We handcrafted it. In the future, we are going to get our plumbing from the evolution of the Web infrastructure surrounding J2EE. We are going to leverage the WebSphere, DB2 and Tivoli capabilities we have inside IBM.
So Domino becomes a set of components that work on that layer of plumbing?
Yes, it becomes a set of capabilities. [For example] I've got to have an in-box, a corporate in-box, and maybe a personal in-box. The in-box is a feature that will have calendaring, scheduling and this ability for rapid application development. The ability to make developing an application-like function as easy as file or database is new. We'll be carrying Domino's capabilities forward into this J2EE world.
Will there be two separate Domino camps? Will you have your traditional Domino for the mail side and traditional Domino functions, but have others who will pull off into this J2EE world and look at Domino as a set of components?
I understand your question, but I come at it a bit differently. If you look at our current customer base, half have applications on top of the Notes and Domino infrastructure, while the other half pretty much use it as an e-mail, calendaring, scheduling kind of system. If you were to talk to one of those customers who develop apps, you might think they are describing a different product than the customer who is using it for e-mail. But in fact, it is the same product, and we have to carry that forward.
Have the messaging wars evolved into being a collaboration-component war?
The seat wars are over. Now, it's really about value, in terms of how do I take this existing infrastructure - since most customers have made their messaging decisions - and get the most value out of it in terms of reduced cost of ownership and better return on investment? And then, how do I leverage it into new things? Again, we think the total cost of ownership is really just a story of hard-core infrastructure engineering, server consolidation, bandwidth balancing, improved compression algorithms and utilization of the network. That is all we are focused on in terms of giving customers better cost of ownership.
You were cautious about revealing how far along you are in developing this next generation of Domino, but is the WebSphere version of Domino coming after Version 6? Will Version 6 have some pieces that push it toward the J2EE platform?
The way you should look at this is that we set ourselves an engineering roadmap and we are going to get as much of that done in the next turn of the crank as we possibly can.
How long does it take to turn the crank?
It's a big crank (laughs). I would certainly expect us to have code in customers' hands in 2003 - code that they can touch and feel, and that begins to be a reality to them. We are going to get as much of it done as we can, but we have not picked the cutoff points in terms of how much and when.
Will enterprises begin to see those pieces roll out as add-ons to R5 or Domino 6?
We will have our next turn of the crank, and there will be the Domino capabilities that we are providing that are post-Domino 6. They will have as much of this as we can jam in.
Is this shift really a move from a Domino application development environment to another platform?
That is a very good question. Customers have to have a corporate in-box, they need a corporate group scheduling system, and they want a rapid application development scenario that is really very simple and is not into the heavyweight professional programming model that most of the J2EE tools aim at. You can almost think of this as simplified forms and templates on top of J2EE. The actual app serving and the engines delivering the J2EE content will be leveraged off WebSphere, the relational store will be leveraged off DB2 and the capabilities are going to be created by Lotus.
What happens to the Domino object store? Does that get sucked into DB2?
The Domino object store will be around for a long time. It is a capability that will remain because there are a lot of applications deployed by customers that depend upon it. But especially with the XML technology that is coming into databases, the XML semantics that are now evolving, it is almost tailor-made for the kind of object store that we need for these kinds of collaborative applications. The store of the future is going to be around this relational technology with XML semantics.
Does the Notes client go away at some point, or does it morph into something else?
We have been around the industry for a long time, and we have seen very few things really go away. There will be a community of people as far out as I can see that really want the Notes client as the preferred way of accessing their infrastructure. Now will more people want an increasing diversity of client access alternatives? I think so. But we are going to commit to solving the needs of people who prefer the Notes paradigm, if you will, for accessing the functions that are essential to their business.
It seems when you go from this client/server-based infrastructure to this standards-based Web infrastructure that the obvious client seems to be the browser?
Yes, the browser will be a very strong client alternative and as I said, more people will begin to use those client alternatives - browsers, wireless devices, PDAs, phones, portlets. These portlets will exist inside of browsers and inside of phones, but there are a lot of people whose brains are wired to the Notes client. They are going to want to continue to use that because they have figured out how to get a lot of productivity out of it. That user experience is what we want to preserve as we go forward.
RELATED LINKS
