Take a peek under the hood of IBM Workplace Collaboration Services and learn about the layers that make up Workplace Collaboration Services, including IBM WebSphere Application Server and IBM WebSphere Portal.
Long-time users of IBM Lotus Notes and Domino (especially those using them for more than just email) know full well the richness of functionality and the power of the platform for creating all kinds of collaborative applications. Many Notes/Domino fans are not, however, sure what benefits they can derive from combining the power of their Domino-based applications with IBM's J2EE (Java 2, Enterprise Edition) frameworks and product offerings. Some people are still not sure what the real differences are among the three major J2EE products: IBM WebSphere Application Server, IBM WebSphere Portal, and IBM Workplace Collaboration Services. (There are many IBM product offerings under the Workplace umbrella; this article focuses on Workplace Collaboration Services and on the architecture on which it is built).
The purpose of this article is to explain how these three J2EE products are actually layered, one upon the other (Workplace Collaboration Services on WebSphere Portal on WebSphere Application Server) to form a coherent whole. We also present an overview of how Lotus Domino might integrate with each of these layers and what the different problems are that you might solve with each type of integration.
Furthermore, although most people think about server-side integration when talking about Lotus Domino and J2EE, we hope to sketch out how the Notes client will evolve over the next year or two to become a J2EE rich client as well.
Technical Foundation: J2EE and WebSphere Application Server
Let's start with a question many people are embarrassed to ask: What is J2EE? It is a specification owned by Sun Microsystems for a Java-based platform or framework on which people run Web-oriented applications. J2EE is not a product (although many vendors, such as IBM, have implemented products that conform to the spec). It's definitely not a religion -- it's a tool, which is sometimes appropriate to use.
The whole idea of J2EE is to provide a vendor-neutral (and therefore, system-independent) way of hosting Web applications. It gives you an application meta-model (meaning, a set of components and tools that you use to build applications) and a platform consisting of a bunch of services that help you run your application, expressed as a set of Java APIs.
The platform is architected to provide performance and scalability to the applications that you host on it. Performance is fairly obvious: You want the applications that run on a J2EE foundation to perform well. Scalability is a little bit trickier, but it generally means that you have ways of adding load to the system (for example, add more users or increase the traffic flow) without seriously degrading performance or response time. How does J2EE in general, and WebSphere Application Server in particular, achieve this? Take a look at Figure 1, which provides a high-level architectural view of a basic J2EE application server.
The diagram looks a bit overwhelming at first, but the major components are circled in different colors to show you how the big picture can be broken down into more easily explainable pieces.
The green circle on the left-hand side, enclosing the boxes labeled Applet container and Application client container, represents the client side of the system. These two boxes connect to the Web Container box via HTTP and SSL arrows, indicating that Java clients (either stand-alone Java applications or browser-based applets) use the HTTP wire protocol to communicate with J2EE platforms. It's the platform's job to translate specific application URLs into application component "addresses" and to route the commands properly.
The actual business components that developers write are shown circled in orange. JavaServer Pages (JSPs) and servlets are directly addressable with URLs. They typically process inputs of various kinds, perhaps querying some backend system for data, and then renders a result back to the requesting client, often in HTML or XML formats. JSPs and servlets run in the context of a Web Container, and a collection of these--together with image resources, other Java classes (JavaBeans), and possibly configuration settings--form what's known as a Web application.
Enterprise JavaBeans (EJBs), the other type of J2EE business component that is programmable by developers, is a bit of a different beast. It does not run in a Web Container, but instead requires hosting in an EJB Container. Without going into all the myriad differences between them and their Web application counterparts, suffice it to say that EJBs are oriented toward managing database transactions and toward reading from and writing to relational databases. Applications that combine Web components (JSPs and servlets) with EJBs are known as Enterprise Applications. While you can certainly have an application comprising only JSPs and servlets, EJBs require either a JSP or a servlet to invoke them. Unlike the arrows connecting Web clients to the Web Container, the arrows connecting the Web Container to the EJB Container do not represent HTTP protocols. Instead, a different, more complex, session-oriented wire protocol named IIOP is used (Yes, this is the same IIOP transport that the Domino CORBA classes use).
Finally, the blue circle shows the common API services layer that all major J2EE application server products support. Each of the boxes in this layer represents a standardized Java API such as the following (not a complete list, of course):
- JNDI (Java Naming and Directory Interface) is used to locate servers, directories, and other shared components on the network and to interact with them.
- JDBC (Java Database Connectivity) is a Java version of the more familiar ODBC. It is used to submit queries and read results from relational databases.
- JMS (Java Messaging Service) is another API that is used to implement reliable message queues between components or processes. IBM's MQ, for example, has a JMS interface to it.
To create your business application, you write JSPs, servlets, and/or EJBs as appropriate (or get any of a number of tools, such as IBM's Rational Application Developer, to help you generate these components). You then deploy your components in a package to the application server. Once there, it responds to URL invocations (JSPs and/or servlets) or to IIOP requests (EJBs) to perform work.
The WebSphere Application Server platform allows these components to perform well (though, of course, some of the burden is on the developer to write efficient code) by supplying lots of application services (database connections, directory services, message queues, and so on). This relieves the application developer of having to supply code for these services himself and makes application components more portable to other implementations of J2EE because all these services are standardized.
Additionally, WebSphere Application Server is architected so that your application can also be scalable. What does this really mean in practice? If our application (plus the platform on which it runs) is sensitive to external load (that is, more users), we can unblock CPU bottlenecks by distributing pieces of our application across multiple computers without recoding any of the components.This is perhaps the biggest value of an architecture like J2EE; that is, you can, for example, put your JSPs and servlets on one computer and your EJBs on another. The connectivity is all managed by WebSphere Application Server; your code does not have to change at all. Thus, tuning for scalability (again, assuming an appropriately coded application) becomes an administrator task, not (primarily) a developer task. Of course, using too many computers for an application will impose a network overhead load, so you must be careful, and there is no one-size-fits-all answer.
This brief summary of what IBM WebSphere Application Server is and how it provides application benefits in terms of performance and scalability is important because WebSphere Application Server is the foundation layer of both IBM WebSphere Portal and IBM Workplace Collaboration Services as we shall see.
What does this mean for Lotus Domino? This is a complicated question, and we have written (or co-written) many articles on various aspects of it. The short (and in some ways inadequate) big-picture answer is that correctly combining the rich collaborative application functionality of Lotus Domino with the speed and scalability of WebSphere Application Server can be a big win. Lotus Domino, for all its great power and richness in workflow, programmability, data integration, and rapid application development, sometimes (for various reasons) just cannot handle exceptionally large application loads. Web agents, in particular, are vulnerable to very high levels of activity because each URL invocation causes the agent to be loaded anew into its target language interpreter (LotusScript, Java, @function, and so on) from the NSF. By contrast, JSPs and servlets in WebSphere Application Server are loaded once, and then the code remains resident in the Web Container's Java Virtual Machine. Concurrent requests are simply invoked on separate Java threads.
The implication is that should you have a situation in which your Domino Web application (which likely is primarily using Web Query Open and Web Query Save agents for its business logic) is not performing well under load you may benefit by recoding some of your Web Query Open/Save agents as servlets running on WebSphere Application Server. Of course, you don't lose important Domino functionality by doing this; you can just continue to use the Domino Java classes.
Bottom line: Integrating Domino Web applications with WebSphere Application Server makes sense if you have performance problems. When we get to WebSphere Portal and Workplace Collaboration Services, you'll see that integrating Lotus Domino with these products solves very different problems.
WebSphere Portal layer: Aggregate UI and device independence
Whereas WebSphere Application Server is all about performance and
scalability, WebSphere Portal, in contrast, is all about user
experience (what we used to call UI). The major value-adds of WebSphere
Portal are that it:
- Brings many application user interfaces (UIs) together in one browser window. This is referred to as UI aggregation.
- Allows personalization in that each Portal user can customize his own screen layout, how much space each application uses on the screen, and where they sit.
- Provides a single sign-on capability, so that (once configured) the user signs on only one time to the Portal, and the Portal figures out how to log into each individual back-end application.
- Provides a large degree of client device independence. Any given application can be exposed both for a PC/browser client and for a hand-held device such as a Palm Pilot without needing special rendering code in the application itself.
- Enables applications co-resident in the Portal to see each other and to exchange data (to a somewhat limited extent due to security concerns). This is often referred to as "on-the-glass integration."
Where do portlets come from? Many are available for free (some are not free) from the IBM Workplace Soluations catalog. If you don't see what you need there, your next easiest step is to use one of the portlet builder tools available from IBM as well as other vendors. These tools provide a no-code interface that lets you describe what you want your portlet to do, and then it builds the code for you.
If this still doesn't meet your needs, you can use IBM Rational Application Developer, IBM's Eclipse-based development environment, to write your own portlet. Rational Application Developer comes with a Portal test environment and a lot of built-in tools and wizards to help ease the task of portlet building.
The nice thing about the portlet model is that each application can still pretend that it owns all the screen real estate. The job of the portlet is to provide a hook to the backend application and deliver a rendering (typically HTML or XML) of that application to WebSphere Portal, which then figures out where to put it on the screen.
Figure 3 shows an extension of the J2EE diagram depicted in Figure 1 with the Portal layer on top (actually on the side, in this case) and with, as one example, a Domino Web Access portlet accessing a Domino server to provide a rendering of the user's email. The WebSphere Application Server / J2EE diagram has been shrunk down and turned sideways with a Portal layer between it and the client laptop.
Once again, what does this mean for Lotus Domino? WebSphere Portal comes with several in-the-box portlets for exposing Domino NSFs to the Portal interface. Plus, you can use the IBM Portlet Builder for Domino to create and deploy your own wrappers for your Domino applications (or buy one of a number of third-party portlet builders).
Integrating Lotus Domino with WebSphere Application Server can solve performance and scalability issues, whereas integrating Domino applications with WebSphere Portal is a UI thing. You do it to bring your Domino applications into the Portal environment and to reap the benefits of UI aggregation and device independence.
This is an important distinction because doing something for the wrong reason only causes trouble. You wouldn't integrate a Domino application with WebSphere Portal to solve performance problems just as you wouldn't integrate a Domino application with WebSphere Application Server to gain a portal interface.
Workplace layer: Packaged applications and rich client
How do you get from Portal to IBM Workplace Collaboration Services? The
answer is by layeringâ. The easiest way to explain it is to say that
Workplace Collaboration Services (and related Workplace products, such
as Workplace Services Express) is a set of applications implemented on
top of WebSphere Portal. In many ways, Workplace Collaboration Services
is a Portal application. However, whereas WebSphere Portal is oriented
toward browser and hand-held clients, Workplace Collaboration Services
also includes a rich client installed (or provisioned) from the server
part of the product to users' desktops. This rich client, called
Workplace Managed Client , also plays an important role in combination
with the next major release of IBM Lotus Notes, code-named Hannover, as
we shall see below. The key packaged applications that Workplace
Collaboration Services delivers on top of the Portal framework include
(this list is not meant to be exhaustive):
- Activity Explorer
- Workplace Document Management
- Workplace Web Content Management
- Instant messaging and Web conferencing (essentially a re-hosting of Lotus Sametime on the Workplace framework)
- Team Spaces
- Email (The Workplace Messaging email product is not meant to replace or compete with Notes mail; it is meant for a different audience. Plus, any portlet that can run in WebSphere Portal will also run in Workplace Collaboration Services.)
Workplace Managed Client
One big difference
between the two Workplace products is that Workplace Services Express
is browser (and hand-held) oriented, while Workplace Collaboration
Services also gives you the option of deploying IBM Workplace Managed
Client. Users of Lotus Notes already know about rich clients and some
of the benefits they provide. Until Workplace Collaboration Services
and Workplace Managed Client came along, though, the J2EE platform had
no rich client on which to deploy applications. Workplace Managed
Client is quite different from Lotus Notes in many ways, for example:
- Workplace Managed Client is based on the Eclipse open-source framework. Eclipse was originally a developer environment, but it has been put to new use as a client framework. Add-on functionality in Eclipse is implemented as one or more plug-ins, Java programs that occupy space on the screen and provide user interfaces to various things. (Sound suspiciously like a Portal?)
- Workplace Managed Client is a managed client, in that the applications and features that each user sees in the client UI is controlled (or provisioned) by the server. The Workplace administrator decides which individuals or groups get which packages, applications, or updates in their copy of the Workplace Managed Client. When users log into the Workplace server from their Workplace Managed Client, new code can be downloaded automatically. This provisioning feature vastly simplifies deployment of client-side code.
- As hinted above, the Workplace Managed Client user experience is quite similar to that of WebSphere Portal except that it's not just a browser. The Workplace Managed Client UI contains an embedded browser, of course, but it also contains a series of productivity editors or tools, including a word processor, a spreadsheet, and a presentation / slide show editor. These editors provide most of the word processing and spreadsheet functionality most people need on a day-to-day basis. They can read Microsoft Office files, but instead of saving data in proprietary file formats, the Workplace editors use XML.
The Workplace Managed Client thus becomes much more than just a browser window with a bunch of applications in it. It lays the foundation for true composite applications by taking integration on the glass to the next level. Workplace Managed Client is a programmable client -- you can write your own Eclipse plug-ins, and you can use the Workplace Managed Client APIs distributed by IBM to enable client-side components (whether they be traditional portlets, Notes-based applications, or custom-coded plug-ins) to communicate with each other and share data (with appropriate security, of course).
This kind of client-side functionality both incorporates Lotus Notes (with full support for replication and off-line use) and goes beyond it. The Eclipse UI is customizable and extensible in ways that Lotus Notes never was. Would you like a custom UI for a calendar view? No problem, write your own plug-in viewer and hook it into the Workplace Managed Client event model. Would you like something special to happen when users send email? No problem, write a custom event handler. (Of course, you need to be a Java programmer). What does this mean for the future of the traditional Notes client? Is it going away? Absolutely not. Is IBM Workplace replacing Lotus Domino? Absolutely not. In fact, the two platforms are evolving and merging in important ways that take nothing away from the Notes/Domino functionality we all know and love.
Evolution of the Notes and Workplace rich clients: Merger of equals
Today, the Notes client and the Workplace Managed Client look like two
vastly different things. This situation naturally leads to all sorts of
speculation about which one will "win" and whether or not people will
be forced to migrate applications from one platform to another.
The good news is that this situation is only temporary. The two client platforms (Lotus Notes and Workplace Managed Client) will actually be merging together in the next major release of the traditional Notes client, code-named Hannover, after the city in Germany where the product was first announced. Hannover is truly innovative: It's still Lotus Notes underneath, but the entire UI has been re-hosted on the Eclipse open framework, making Notes components first-class players in the composite application client space. Furthermore, Notes components will be provisioned from either a Domino server or a Workplace server.
What this really means is that by upgrading to Hannover, customers will also gain the benefits of the Workplace rich client--including portal interface, server-management/provisioning, extensible UI--while it's still Lotus Notes. Moreover, because it's still a real Notes client underneath the Eclipse wrappings, all your existing Notes/Domino applications will continue to run unmodified in the Hannover environment.
Of course, traditional stand-alone Notes and Domino configurations will continue to be offered by IBM. No one will be forced to adopt the new Hannover client against their will. The benefits of the unified rich client, though, are huge, and we predict that most customers will find the transition smooth and the results very empowering.
Different layers, different benefits
Why IBM
Workplace then? It's worth repeating (if only because there has been so
much confusion about this over the past couple of years) that IBM Lotus
Notes and Domino are not going away.
The J2EE foundation technology embodied in IBM WebSphere Application Server provides a fast, scalable platform onto which organizations can deploy applications. By integrating Lotus Domino with WebSphere Application Server, you can unlock some of the performance bottlenecks inherent in high-volume Domino Web applications without losing any of the rich collaborative functionality that Lotus Domino provides.
The Portal layer on top of WebSphere Application Server provides personalized desktops on which knowledge workers can organize their workspace as they choose and bring all their important applications into one place with integration on the glass of their data.
The IBM Workplace layer on top of WebSphere Portal gives you a series of prepackaged applications, the ability to expose existing Domino applications in a Portalized environment, and powerful new administrative options for provisioning. Furthermore, Workplace Collaboration Services now provides users with the Workplace Managed Client that further enhances the on-line work experience. The recently shipped version of Workplace Managed Client supports a plug-in for Lotus Notes 7. The next major release of Lotus Notes will actually be a merger of the traditional Notes client with Workplace Managed Client, yielding powerful enhancements of both. This is not at all a replacement of Lotus Notes with Workplace Managed Client rather it's a merger of equals that make both better.