Page 1 of 3   next page »

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.

Page 1 of 3   next page »