This article assumes that you have heard about at least two branding words: Eclipse and WebSphere. Eclipse is a tool and client platform technology, while WebSphere is more of a server-side middleware platform. In this article, you will learn about the amazing things you can achieve when you use these technologies together to deliver end-to-end solutions.
Rich-client application refers to to a thick desktop-based application, while thin-client application refers to a Web-based application. Historically, rich clients are hard to deploy and maintain; on the other hand, the thin clients are not as UI-rich and responsive as the thick/rich client.
Thus, two competing technology segments now vie for the same developers. Web applications still have strong advantages, especially with the advancement brought along by technologies such as AJAX and Web 2.0. At the same time, a rich client front-end is better fit for some categories of applications. Some examples are Bank Teller applications or Call Center applications. In these cases, applications typically have some of the following characteristics:
- They are mostly internal, intranet applications, targeted for hundreds or a couple of thousand users.
- They have very stringent look-and-feel requirements for UI, including appearance of fonts, colors, and widgets
- They demand navigational efficiency and responsiveness, with possible short-cut keystroke, because they are used by power users working all day.
- These applications typically have a very large data set and display a high information density per screen. They normally maintain large session data at the client side, which improves performance.
- They integrate with desktop and other desktop applications well.
- They are normally workflow or collaboration type of applications and the abilities to work offline and task-switch are pretty important
In cases like these, building a rich Web front-end for your stakeholders is not the answer when thick-client functionality is what you really need. Rich and thick client is here to stay, and research firmsâ data confirms the growing acceptance of new generation of desktop client; a Giga group report, "Return of the Rich Clients" (see Resources), predicts that in the next three years browser-rich clients will grow by 350%, stand-alone clients by 250%, while HTML will decline by 50%.
Once you indeed escape the RIA craze and opt for a practical thick-client solution, where do you go from here? Answer: You choose a RCP that will handle the work for you. Essentially, the RCP concept brings a framework to the world of Java desktop applications, just as all the Web frameworks have done for the J2EE/Java EE world. If you are not new to Java nor been asleep for a long time, you must know that the popularity of Eclipse is at all-time high, and the Eclipse Rich Client Platform (RCP) is becoming the de facto framework for Java desktop clients.
While the Eclipse platform is designed to serve as an open tools platform, its architecture allows you to build just about any client application with its components. The minimal set of plug-ins needed to build a rich client application is collectively known as the Rich Client Platform. As Figure 1 shows, the Eclipse Rich Client Platform consists of the following components: Eclipse Runtime with OSGi (Open Services Gateway Initiative), SWT (Standard Widget Toolkit), JFace and workbench UI.
Figure 1. The Eclipse Rich Client Platform
Eclipse RCP uses a small footprint runtime. The latest Eclipse 3.2 RCP runtimes drop has only 9MB.
While it is small, it has lots of neat features to help you develop your next desktop Java application.
There are many benefits to use a client side framework as Eclipse RCP:
Many people use Eclipse RCP because it allows them to quickly build a professional-looking application, with native look-and-feel, on multiple platforms, allowing them to focus on their value-add, thanks to the great SWT technology.
Eclipse RCP developers also appreciate that the components that form RCP are of high quality, are actively maintained, and are open source. They often discover after the initial adoption of RCP that there are many other Eclipse components available for reuse (e.g. Help UI, Update Manager, Cheat Sheets, Intro, etc.).
Some Eclipse adopters have also discovered that the inherent extensibility of Eclipse allows them to build not only a closed-form product, but also an open-ended platform (like the Eclipse IDE) in their own domain.
In Eclipse, integrating completely independent components is easy. Views from independent components can easily share the workspace. So it is a natural choice to use
Eclipse RCP has a client side application integration platform, where SWT, WEB, Swing, Visual Basic, ActiveX, and native applications can all coexist.
Eclipse RCP gives you a solid foundation to build your next killer rich client application. But it doesn't address some important features required by some advanced desktop applications. For example, security (include both authentication and authorization), offline capability, and deployment. Thatâs where the IBM managed client middleware technologies can help.
Figure 2: Managed Client Container
In Figure 2 above, managed client services are based on OSGi and service management framework (SMF) to provide independent life-cycle management of services and application inside the JVM. Platform management is built on top of that, and enables on-demand management of applications ranging from passive distribution to active, intelligent management using the SyncML protocol.
The access services layer extends backend programming model and APIs out to the client. So you can host Web applications, database applications, Web services, and more right here at the client container. It also allows access to e-business applications, service and data. It supports both connected and disconnected operations.
Interaction services offer support for different types of clients: browser-based HTML, WML, JSPs/Servlets/Portlet, or fat GUI client like SWT or Swing.
Collaboration services is a framework to build advanced real time collaborative applications.
From a product point of view, WebSphere Everyplace Deployment for Window and Linux (hereafter referred to as WebSphere Everyplace Deployment) offers everything you need to develop solution applications, and includes all the interaction services, access services, and the base core managed client services and platform management from the diagram above. IBM Workplace Managed Client (hereafter referred to as Workplace Managed Client) builds on top of WebSphere Everyplace Deployment and adds collaboration capabilities to support rich collaboration.
So, if you are developing Eclipse RCP application, you can potentially choose from one of the three stacks: base Eclipse RCP, IBM WebSphere Everyplace Deployment or IBM Workplace Managed Client.
Eclipse RCP, WebSphere Everyplace Deployment and Workplace Managed Client are IBMâs desktop application strategy. It establishes the foundation for the next generation of client software. Some upcoming IBM software products are already taking advantage of this exciting client middleware stack. Some examples are:
Lotus Sametime Connect 7.5: Instant Messaging (Figure 3)
Figure 3. Lotus Sametime Connect
Hannover: Next Release of IBM Lotus Notes (Figure 4)
Figure 4. Next Release of Notes
We have talked about the client side frameworks available to develop new applications for the WebSphere platform. But what exactly is the WebSphere platform?
WebSphere is IBM's integration software platform. It includes the entire middleware infrastructure.
Traditionally when we talk about WebSphere, we meant WebSphere Application Server, which has been a Java application server platform based on Java EE standard APIs and Specifications. But WebSphere is increasingly becoming an integration platform based on open standards, such as Web Services, BPEL, SCA, SDO, etc. WebSphere Process Server, which is based on WebSphere Application Server and the WebSphere Enterprise Service Bus, provides the foundation for service-oriented, modular applications, and supports the application of business rules to drive applications that support business processes.
WebSphere Application Server supports a full range of open standard programming interfaces. From a J2EE point of view, WebSphere Application Server fully supports J2EE 1.4 APIs:
- JDK 1.4, EJB 2.1, Servlet 2.4, JSP 2.0, JMS 1.1, JDBC 3.0
- JAX-RPC, SAAJ, Web Services for J2EE, JAXR
- Java Authorization Contract for Containers
- J2EE Management (JMX) 1.0, J2EE Deployment 1.1
- J2EE Connectors 1.5
In addition to open standards support, WebSphere Application Server and WebSphere Process Server also have API extension support for advanced application requirements, and new emerging open standards for SOA:
- Programming model extensions, which includes asynchronous beans, work area, dynamic cache, ObjectGrid and more
- WebSphere platform messaging: WebSphere Application Server supports asynchronous messaging through the use of a JMS provider and its related messaging system. The service integration technologies of IBM WebSphere Application Server can act as a messaging system when you have configured a service integration bus that is accessed through the default messaging provided.
- Service Component Architecture (SCA): SCA provides an open, technology-neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security.
- Service Data Object (SDO): SDO complements SCA by providing a common way to access many different kinds of data
From a client application point of view, WebSphere Application Server and WebSphere Process Server host a variety of components and resources. Some of them include:
- Web Services
- Servlet/JavaServer™ Pages (JSP™)
- Enterprise JavaBeans™ (EJB)
- SCA Components
- Service Integration Bus Messaging Resource
- Messaging Resources
- Data Access Resources
- BPEL Processes
The above services are accessible through different protocol and transports. We will be focused primarily on the following transports:
- SOAP/HTTP, SOAP/JMS
- RMI, RMI-IIOP
Traditionally, WebSphere platform client applications mostly have been Web-based applications running inside WebSphere or some other application servers. They are mostly servlet, JSP or portlet based. They work great for lots of customer scenario and requirements. But as we discussed in previous section, some type of applications just won't work well as Web applications, no matter what kinds of Web technologies are used. So there is a need to make WebSphere platform services more consumable to standalone applications.
Furthermore, if we look at the well-established server platforms, most of them have tightly integrated rich desktop client platform, whether it is the IBM Domino, Window Server or SAP platforms.
With the advent of Eclipse RCP, enterprise applications with an RCP front-end and J2EE middleware backend seem to be an attractive combination. And indeed, we are starting to see some commercial products based on this architecture. One example is the IBM Sales Center for WebSphere Commerce (hereafter referred to as Sales Center)
As you can see from Figure 5, the Sales Center acts as a client application talking to a back-end WebSphere Commerce Server, which is built on top of WebSphere Application Server. The communication protocol used is SOAP/HTTP.
Figure 5. Sales Center Client/Server Architecture
Benefit of Using Eclipse Rich Client Interface
The Sales Center leverages the catalog, order management, promotions and merchandising capabilities of WebSphere Commerce to provide your contact center representatives with the functionality they need to service and up-sell your cross-channel customers. It enables the speed and productivity required for high volume contact centers via a customizable, high-performance user-interface designed for productivity and multi-tasking.
Figure 6. IBM Sales Center for WebSphere Commerce
Its key features include:
- Rich-client, high-performance user interface.
- Eclipse-based solution for easy customization.
- Leverages WebSphere Everyplace Deployment for Windows and Linux.
- Full application installed on client machine
- Centralized client administration, deployment and updates
If you have worked with WebSphere Application Server before, you know how important the JNDI naming repository is to the application server. In a lot of situations, you might need to browse the JNDI name tree, either to understand applications or debug application problems. There is a command line namespace dump utility in WebSphere Application Server, but I want a more graphical and user-friendly interface. Thatâs why I decided to write an RCP application to explore the JNDI tree. It uses just the Eclipse RCP framework. It has only one view named JNDIExplorer (Figure 7). But you can see how much customization you can do to the look and feel with this framework, thanks to the Eclipse plug-in architecture. Internally, it uses JNDI API to talk to WebSphere Application Server naming service to retrieve information.
It is a nice little utility to work with in a lot of situations. You can run it stand-alone without a Web server, without the hassle of installing onto a Web server. You don't need to deploy to lots of end users. So it is good use-case for a desktop-client application.
Figure 7. Sample RCP Application
We have discussed in this article why you should seriously consider Eclipse RCP as a viable and attractive option for developing some types of WebSphere platform client applications. The WebSphere platform provides proven server-side technologies, while Eclipse RCP is popular client-side framework. Making some of your enterprise services hosted in WebSphere servers consumable to Eclipse RCP client will result in better performance, better interaction, and happier end users.
It's Not Over Till the Fat Client Sings
Eclipse Rich Client Platform
Eclipse RCP Tutorial on developerWorks - Part 1
Eclipse RCP Tutorial on developerWorks - Part 2
Getting Started with WebSphere
WebSphere Everyplace Deployment
IBM Workplace Managed Client