IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerWorks
AIX and UNIX
Information Mgmt
Lotus
New to Lotus
Products
How to buy
Downloads
Live demos
Technical library
Training
Support
Forums & community
Events
Rational
Tivoli
WebSphere
Java™ technology
Linux
Open source
SOA and Web services
Web development
XML
My developerWorks
About dW
Submit content
Feedback



developerWorks  >  Lotus  >  Technical Library
developerWorks



The LDD Interview

John Banks-Binici on Lotus Workplace Messaging


Interview by
Tara Hall


Level: All
Works with: Lotus Workplace Messaging
Updated: 04/01/2003

Related links:
Michael Harer on Lotus Workplace Messaging

John Banks-Binici on Domino and WebSphere integration

John Banks-Binici: R5 Messaging & Directories

IBM Lotus Workplace Messaging at a glance

WebSphere Developer Domain

DB2 Developer Domain


Get the PDF:
LWM_JBBinici.pdf(143 KB)
Get Acrobat Reader



Many of you have probably heard of IBM Lotus Workplace Messaging (a.k.a next gen mail), if not at Lotusphere earlier this year, then maybe in the press. There's a lot of buzz around Workplace Messaging, so to find out more about this new mail system from Lotus we talked with development manager John Banks-Binici about Lotus Workplace Messaging (LWM) features and the technologies that make up LWM.

Can you give me a technical overview of the architecture and the technologies behind Lotus Workplace Messaging?
The IBM Lotus Workplace Messaging system is designed to plug into an existing enterprise infrastructure. It integrates with a customer’s existing corporate LDAP directory and the way it is managed. It's designed to extend the capabilities of WebSphere Application Server 5.0 ND (Network Deployment) Edition by providing the email infrastructure necessary to supply Internet mail accounts to members of the corporate directory. It incorporates the IBM DB2 relational database as its highly scalable data store.

As for technologies, it's a standards-based SMTP service, so it integrates with any other standard mail systems. On the UI end, we offer the option of using a WebSphere Portal-based UI or a POP3 client, like Lotus Notes, WebSphere Portal, and Microsoft Outlook. And finally, we provide integrated administrative tools to administer the mail storage and the servers that are dedicated to the system. Administration can be done from the WebSphere admin console or via scripting languages like Python or JACL. WebSphere lets you plug in any scripting language that works with BSF (Bean Scripting Framework).

Can you tell me a little bit more about what the feature set will be for the 1.0 release?
I've discussed a little of that already, but I'll go into a bit more detail. The interface provides exactly what you'd expect from a mail UI. You start out with the basic Inbox, trash, sent, and draft folders, and you can extend those with personal folders. You can send/receive rich HTML messages, create attachments, and so on. We also provide a contacts feature, so you can maintain your own lists. The administrator can configure the system so that the name picker feature lets the user choose from a list of public address books.

As I said before, we have an administrative client that's integrated into the WebSphere admin console. For administration, of course, you can manage the life cycle of users—add and remove them from the system. An important thing to note is we're supporting this feature that we're calling "Just In Time Provisioning" that we're patenting. This feature essentially allows you to add users to an LDAP directory and have us automatically create accounts for them just in time. Lots of companies can claim to have that sort of feature, but they tend to do provisioning at the point when you add someone to their directory. Our technology allows us to do this with any LDAP directory and without an architecture that's based on synchronizing directories. We use the customer's LDAP directory as "our" only directory. So for example, if a user's name changes, the user has access to his account immediately after the directory is updated with the change. There's no waiting for a synchronization to happen.

Here's a scenario that paints the admin picture. On the first day of work at a company, HR typically adds a new employee to a directory and hands the new employee the key to his office and maybe a piece of paper with some standard instructions like the URL to the company portal. Many companies do things this way. The mere creation of that entry in the directory enables our product to automatically give this user an email Inbox, and that happens without directory synchronization. The admin doesn't even need to intervene to send the person a welcome message. That's automatically generated based on the user's profile. So, this message can contain all the information the user needs to start making use of his company's online assets.

John Banks-Binici

When I go through this scenario with admins, they're usually blown away because so much of their day is spent managing user accounts. And here's something that we should probably talk about more because the philosophy is that you pick the directory, you pick the tools to administer the directory. We're going to let you use those tools, we're not going to inject ourselves between you and that directory and say, "You can only do the things we've had time to code and everything else is something you do outside of us. And by the way, if that causes some kind of confusion, we're sorry, but we don't have a better answer." We have a much better answer.

It's a directory—it comes with its tools—and we're going to work with that as it was meant to be worked with. You administer it the way you always do. So when you come into our admin interface and you look at a particular user record and in the list of mailboxes that we have for these people, you won't see a lot of information in the record because we're not replicating that information from the directory. Instead, you'll see how much disk space the person is using, which user profile he's assigned—that sort of thing. We don't want to synchronize information with the directory, so we don't have a copy of it in our database. But the information exists in the directory, so we get that information when we need it.

Continuing on the basic feature list, obviously the admin UI allows you do the standard things to manage your mail services. We have the ability to monitor the system statistics with Tivoli performance viewer. For security, we've integrated with WebSphere security, so we support the standard mechanisms WebSphere Network Deployment edition supports, including solutions from Tivoli and also third-party plug-in solutions. The system also has disk quota enforcement. It has anti-spamming features, both connection-based configurations and real-time blacklists. And as I said before, the entire administration is scriptable, so you can easily manage large systems. There's scriptability of all the administration components using the WebSphere admin console, and there's AIX and Windows 2000 support.

You mentioned support for POP3. Any plans for IMAP?
Yes, we have plans for IMAP, and we'll be making a technology preview in our 1.1 release later this year. We've already begun that work, and it's coming along nicely.

Let's talk a little bit more about user account creation and how that's done. When you come from a Domino world, every mail file is a Domino database. How does that work in this new platform with this new technology?
What Domino does is to create a file called Your Mail File on a disk somewhere. Similarly, in DB2 a record gets created, and essentially, it's the shell of an account right inside the database. It's not really a mail file, it's relational data. This data is queried over SQL and filtered with a search query to return a given piece of information. We're really quite pleased with DB2's ability to handle our data in a very efficient and timely way. For example, DB2 data restore is clocked at rates of 100 GB per hour, which is quite impressive.

How does the system scale to accommodate more and more users?
Essentially, we have a design that incorporates the ability to partition messaging users into separate message stores (databases really). For example, you can have multiple instances of the mail application running separate LWM clients to make the best use of the horizontal scalability benefits of WebSphere. If you configured these instances to serve up the same message store, then these instances all know about each other and replicate global configuration information between each other, so they can cooperate. We call this set of cooperating services a "mail cell." You can use the mail cell concept as a building block to build larger systems. You can have a mail domain served up by one mail cell, or you can break up the mail domains into multiple mail cells. The concept is very similar to the concept of a Domino domain. By Domino domain here, I mean a set of Domino servers that share a single directory and replicated topology information.

Did you reuse any Lotus code to build Lotus Workplace Messaging?
We re-used design ideas. The UI did re-use portions of the iNotes Web Access interface. On the back-end, we have not re-used code. We've built the code from scratch, and we've pulled in other IBM technologies, such as WebSphere ND, Tivoli performance viewer, and so on to provide the missing pieces. The goal was to not re-invent the wheel. We wanted to build a messaging system that is a true component and works with all the rest of IBM's technologies so it can be used to build systems that are greater than the sum of its parts.

I saw a demo of Lotus Workplace Messaging, and there are a lot of similarities between it and iNotes Web Access.
From the UI point of view for release 1.0, it's meant to be that way. We had a design and some code already in iNotes, but we needed to simplify it a bit because we're shooting for a simpler UI. And we could re-use pieces that they've already done. In 1.1, we'll be totally integrated with WebSphere Portal 5.0, so it's evolving.

How do you ensure that people don't confuse your product with iNotes Web Access?
On the back-end there is no confusing it. From an administrator's point of view, it's obvious this is a new approach. The best example I can cite is there is no directory to administer, no Notes client ID files to worry about. It's all LDAP-based. This makes a big difference in what the administrator has to do. The user interface is also simplified, and the feature sets are geared towards customers who are trying to lower their costs. One way to lower costs is to remove administration overhead, so that's why we built the level of LDAP integration necessary to do the Just In Time Provisioning of accounts that I mentioned earlier.

Another way to reduce costs is to make explicit decisions about which features you're willing to support for your users. So in some cases where you had functionality such as calendar and scheduling, which is in iNotes, it's not in Lotus Workplace Messaging release 1.0. And when we add calendar and scheduling to Lotus Workplace Messaging release 1.1, the administrator will get to explicitly decide whether or not the user receives the service. We have a feature called User Policies that let you configure which set of functionality a particular user gets to use. You can point more than one user to that particular policy. So you essentially tailor the experience for that user in terms of what services he can access, what branding he sees, what welcome message he gets, and so on. And by doing that, as we add more and more functionality, you can control your training costs as well as other costs.

Let's talk a little bit about what users can expect in terms of security. You mentioned that it's built on the WebSphere security model.
We integrate with WebSphere's administration model for administrator security. We support the same administrator roles that WebSphere does for monitoring, configuring, and so on. As for end user security, whichever system and credentials you configure WebSphere to authenticate users with, we'll get the benefit of this authentication as a consumer later in the flow of the request. Let me describe how this works: When a user is authenticated, WebSphere constructs an authentication context for the user and hands over that security context to our application, so we can use it to make decisions. We just plug into the system in that respect. So if you're using Single Sign-On (SSO), for example, we can participate in that transparently. It's part of our strategy to integrate with existing components and not re-invent the wheel.

We participate in the process by providing "instance-level" Access Control Lists (ACLs) which enable users to grant other people access to their accounts. "Instance-level" means that we distinguish when UserA opens a URL like http:// myserver/mailapp, she accesses her mailbox , but when UserB opens the same URL and authenticates with his credentials, UserB accesses his own mailbox. So the URL doesn't explicitly contain the information which distinguishes whose instance of the mailbox is being accessed. We step in at that point and validate that the instance being accessed is authorized. We've designed these access controls into release 1.0 because it was essential to do it from the start and to build our performance work around that design. However, in release 1.0, we only let the owner of the mailbox log into it. We will expose the ability to edit these Access Controls Lists and let you grant other people access to your messages later this year.

Will the configuration be similar to configuration for iNotes Web Access?
At the core, it's not the same as we're not configured using the Domino Administrator client. At the outer level, the integration topics will be common for all mail systems. These are considerations that are more about what the site requires to feel safe and how firewalls are configured, whether or not they use reverse proxies, how they are designed to route mail, and so on. We make recommendations, but our goals is to fit in as a component with the essential configuration options you need. We simply need to work with whatever site decision you make.

Will you offer any migration tools in the first release?
Release 1.0 ships with the ability to create user accounts using the techniques we already discussed. This is enough for those unserved users who don't already have email accounts. Additionally, we're building tools to migrate your existing messages from your current mail product, and these will be available shortly after we ship release 1.0.

Is Lotus Workplace Messaging intended for the remote or mobile user?
It certainly allows you to access your mail from wherever you can get onto a Web browser. The client portion does not provide the ability to access your messages when you are disconnected from the network, but you could do so if you used a POP3 client to pull your messages to your laptop, for example. We're building on our capabilities over time, and our initial release is everything a shop floor worker will need, for example. Quickly over the next 12 months, we'll be more and more able to address the needs of power users.

In terms of SMTP, will Lotus Workplace Messaging have the same Domino feature set?
It will have many of the same features. We have a great new connection-based UI for configuring the level of security you want to enforce on various connections, and this was designed based on the feedback of many administrators who've struggled with this stuff. We provide the ability to do anti-spamming based on real-time blacklists. You will be able to configure relay and smart hosts to control the mail flow through the system. Release 1.0 contains all of the essential mechanisms you need to do SMTP mail in a manageable way.

I haven't heard very much about your admin client, so can you tell me a little bit about what people should expect?
Essentially, what we've done is extended the WebSphere admin console so that the outline control that's on the left side of the screen has control for Lotus messaging. There's the outline control and then you see these managed policies, managed accounts. If you try to manage accounts, you can get a listing of every mailbox that we have on the system. You can go in, check off one, and press delete, and it will be deleted. By deleting this account, you have not deleted an entry in the directory. For a Domino administrator, it's equivalent to just deleting an NSF file.

What plan do you have for directory support?
We're testing a number of different directories. Release 1.0 will explicitly certify Domino Directory and IBM directory. We are also using it with various other directories in our lab, like Sun's iPlanet directory. We have customers who are using it with Novell and Seimens. One other important thing we should tell you is that one customer we've been working with had a requirement that we work with two different directories, so you can configure Lotus Workplace Messaging to use a directory for authentication separate from the one we use for looking up email addresses and routing information. So for example, that customer has pointed us to its corporate directory where everybody gets added when they start from day one. It's a Siemen's directory. And they pointed us to a Novell directory where they want to have their accounts managed. We work in such a configuration.

The point is that we're not adding overhead; we're very flexible. Whatever the business processes in this company are, how they want to manage it, we're there to integrate as opposed to dictate. We don't come in saying this is the directory you have to use for example. So we're lowering the cost of integration.

Here's a screen of the Lotus Workplace Messaging Administrator client:

Lotus Workplace Messaging Administrator



You have another release coming out later this year and plans for other releases. What new feature are you most excited about and which do you think customers are most looking forward to?
Release 1.1 will be a fully integrated WebSphere Portal 5.0 application, and this will be important especially for customers who've chosen Portal and want to provide a common platform for the applications they're building. We're very excited about that, as the customers we've engaged so far view Portal as a high priority for them. This release will also contain calendar and scheduling functionality that administrators can optionally enable for their users. We'll also be unveiling a technology preview of our IMAP server. There will also be a lot of other goodies that I can't talk about yet.


ABOUT JOHN BANKS-BINICI
John Banks-Binici is a Software Development Manager working on Lotus Workplace Messaging Server. His previous experience includes managing the Notes/Domino mail and directory server teams throughout the development of Release 5. He was a server architect on the iNotes Web Access server. John left IBM Lotus for a year and a half to work at Netegrity Inc. where he was Director of Software Engineering working on SiteMinder Web Server Agent technology. He was hired back to IBM at the start of the Lotus Workplace Messaging project. John spends most of his free time trying to keep up with his three children and his wife and practicing finger-style blues guitar.






What do you think of this article?

    About IBM Privacy Contact