Systems Administration

Digg This!

Page 2 of 3   « previous page   next page »

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."

IBM WebSphere Portal is, in fact, a WebSphere Application Server application. It's a collection of JSPs, servlets, and EJBs that is deployed on your WebSphere Application Server configuration (other Portal products work similarly on their respective application server platforms). The Portal code allows developers to implement (or deploy off the shelf) an individual portlet for each backend application type. Portlets are actually just specialized servlets, and their job is to access a particular backend application (a Domino database, a Web site, Domino Web Mail, whatever it may be) and to provide a rendering of that application to WebSphere Portal. The Portal then aggregates all such renderings into the multi-pane screen that the user sees. Figure 2 shows an example of a Portal screen in a browser with some example portlets.

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.)

Both Workplace Collaboration Services and Workplace Services Express are implemented as WebSphere Portal applications, and you can integrate Lotus Domino "on the glass" with both in just the same way you would do it with WebSphere Portal; that is, build, buy, or get off-the-shelf portlets to wrapper your existing Domino applications (as in the example in Figure 3 above).

Page 2 of 3   « previous page   next page »