In the early '90s, many companies invested in traditional client/server architectures by building fat-client applications with rich graphics that offloaded legacy-system processing time.
GUI business applications presented lower runtime costs than the CICS applications they replaced due to reduced demand on the mainframe server. This fat client would handle all business logic and data validation and then commit data to the server.
The emergence of Java and the Web, however, prompted another major shift in thinking about building applications. With Internet-based technology, suddenly companies could extend their reach by delivering dynamic HTML in a browser to anyone with a Web connection. This new Web-enabled world thus reversed the earlier trend, and application development began moving business logic back to the server.
Many early adopters among the Fortune 500 migrated their legacy applications to a J2EE architecture, attracted to this emerging paradigm by the ease of deployment afforded by browser-based delivery of the presentation layer. For a significant number of these companies, however, the strategy backfired, as they increasingly ran up against the usability limitations of HTML, particularly for more complex GUI workflow, business calculations, or sophisticated graphics. What's more, browser-based front ends introduced performance inefficiencies as the application must make round-trips to the server to paint new views, a process that can be cumbersome because of the browser's inherent limitations in windowing and real-time graphics capabilities.
Today, Web services offers the promise of allowing Internet-based applications to interrelate in new ways, giving businesses a powerful new tool for collaboration. But a browser-based presentation strategy forces architects of these applications to make an unpleasant trade-off:
Either drastically simplify the presentation layer by distributing content over a greater number of screens, or
Meet the business requirements and deliver markedly slower performance, lower usability, and diminished functionality compared to the original mainframe applications that the new J2EE applications are designed to replace.
How can we deliver a new generation of user interfaces that enable us to leverage the cooperative power of Web services? As B2B becomes more mainstream, the network becomes the backbone of transactions, both within and among the enterprises.
The Webtop Solution
An emerging solution to this problem is the Webtop. The Webtop is a next-generation rich-client user interface, a hybrid Swing-based GUI front end that connects to the J2EE application server over the Internet (see Figure 1). Webtops bring the best of old-style client/server to the J2EE age, enabling rich end-user functionality that interacts with a remote server. Using technologies such as SOAP, the Webtop is responsible primarily for the presentation layer, relying on the application server for business logic and distributed transaction processing.
The Webtop represents a return to the n-tier distributed client/server model by offloading costly view management to the desktop. This distribution of power can significantly improve performance and the user experience. Not surprisingly, many companies, including DaimlerChrysler, Sabre, BMW, Amadeus, and Deutsche Bank, are revising their initial J2EE strategies to take advantage of this architecture.
Let's examine this architecture.
MVC and Presentation State Engines
Webtops are based on the Model-View-Controller pattern familiar to Java Swing developers. In this pattern, the model is an object representation of the business, the view is the canvas, and the controller sits behind the view to control the navigation between individual graphic widgets and value holders on the view (see Figure 2).
But Webtop client/server applications have complex user interfaces, and state is a key consideration. Therefore, immediately below the Swing UI is a navigation state engine known as a navigation controller. Less well known to Swing developers, it's responsible for the application workflow control of windows that run in the Webtop. Use of a navigation controller reduces coupling in the Webtop application since individual view controllers are not required to have knowledge of each other. This approach also allows views to be interchanged easily as new versions are rolled out, and allows you to alter GUI behavior based on user roles, an architectural feature that's highly desirable for applications that are in a constant state of requirements fluctuation.
Architects of these complex Java applications define navigation controllers so they operate in four directions (see Figure 3):
Up: To signal a view controller to open its view
Left or right: To signal collaborating navigation controllers to take control
Down: To request service from the application server (such as commit a transaction or request new objects)
The Webtop can be assembled with a single or multiple navigation controllers. When it's started, a primary navigation controller is instantiated, which then determines the state of the Webtop based on the last usage. Then the navigation controller messages the correct view controller and the Webtop picks up where the user left off. When exiting any particular view (from the view controller), the navigation controller must signal another controller to pop a view or it will request that the application server perform a transaction service.
There are several ways to implement this. The most common approaches are to either use a single navigation controller instance that has knowledge of all the GUIs or, for more complex applications, employ a series of navigation controllers, one for each Swing user interface. In this scenario, each Swing client uses an association manager with event listeners to determine who to pass control to when exiting a specific view. When using multiple navigation controllers, a central association manager mechanism can be used for registration.
Communication between the Webtop (outside the firewall) and the application server can be accomplished using the Simple Object Access Protocol (SOAP). Use of SOAP provides remote method invocation over HTTP. Because the Internet protocol does not guarantee delivery, architects should consider the latency of the production network on which the Webtop will communicate with the server. If latency or uptime is an issue, consider implementing SOAP with asynchronous messaging versus the more popular synchronous messaging. Implement an outgoing message type that is sent to the application server paired with an opposite message response to indicate that the transaction was successful. This type of messaging is common in telephony network management where servers are used for node provisioning, a remarkably similar model to Webtop management.
Application Management for Webtops
Companies that follow the Extreme Programming (XP) model benefit from the ability to revise applications rapidly as user requirements continue to change and evolve. The XP model involves iterating more frequently, producing a significant number of application updates. In the Webtop environment, we know we have to update the server and the client, a client that connects over the Internet.
Consider a Webtop environment for travel services automation deployed to thousands of independent travel agencies in North America. It's unlikely that travel agents in various geographic locations running on a Webtop would be expected to download new installer-packaged versions of that Webtop weekly - updates corresponding to server-side changes. Moreover, how would we deal with application failures that may be associated with a version changeover?
The browser experience offers an immediacy and seamlessness that can be emulated in the Webtop environment. When the user double-clicks a desktop icon to launch the Webtop application, he or she should be presented with the most current functionality available. The travel agent should open the Webtop and expect to have access to the current functionality on the server.
Deployment and Management Challenges of Webtops Webtop version management: Centralized control over who is using what.
Fault tolerance and monitoring: In the event of a critical failure of a 24x7 application, administrators must be notified automatically and centralized control must provide immediate rollback capability.
User authentication and access control: Centralized control of user authorization and access to the Webtop version.
Reporting: The more distributed applications are in production, the more important reporting becomes to provide information such as which users are running each version, how often, and when was the last connection time.
JAR-level differencing: Webtops are powerful but have a large footprint due to the size of the JAR files. The JAR is what changes most, so companies have sought out updating technologies that can compute the difference between JAR files from different versions of a Webtop application.
JRE management: Guarantee that the correct JRE version is associated with the version of the Webtop on the desktop; there can be no dependency on the user to ensure the JRE is present or correct.
The Webtop architecture, while powerful, introduces new challenges for companies that are adopting this approach:
The Internet is a pull-based system, and so application management platforms for Webtops must therefore be pull based. The emerging trend, proven by Fortune 100 early adopters, is to deploy software agents attached to the Webtop instance. Software agents provide remote-control capability since they execute according to a centralized policy server or deployment server cluster. This client-side agent administrator connects to the cluster to confirm application updates, user access, and authorization policies (see Figure 4). The agent will report information about the Webtop usage and health, including an immediate alert should the agent detect a critical failure. A centralized control console is usually included with a commercial pull-based deployment platform.
How is this performed? Software agents are typically implemented as headless lightweight software applications that perform tasks via remote control. The communication pattern between the agent and the server is sometimes called double dispatching. When the client agent is instantiated, it doesn't know what its behavior should be, even though there are obviously methods implemented on the agent. The agent connects to a server, describes itself, and requests instructions or tasks to perform. The server replies by providing a policy set that describes what the agent must do, which in reality is a subset of behavior the agent always had.
Webtop client agents operate similarly - they're programmed to download a rule set from a central server and execute the rules based on a time schedule specified in the rules. Rules or policies can be implemented in plain text files or as XML. The policy is specified using a standard protocol for network launching.
The most important aspect of the agent model for Webtops is its ability to dynamically update the Java classes and the JRE on the fly, as part of a version update. To accomplish this, the agent is configured as a wrapper for the Webtop, so what appears on the desktop as an icon is actually the agent and not the real Webtop. When the user invokes the Webtop, the agent is invoked and must then examine its policy on file for the Webtop. Each time the agent is in communication with the deployment server, it may receive updated policy information such as when updates should be performed and whether or not these updates are mandatory.
In the travel agency use case, the client-side agent would be configured by the deployment server for mandatory updating on startup of the Webtop. The Webtop agent would connect to the server over HTTP to confirm that the version of the Webtop running on the desktop is the correct version specified by the application administrator at the central location. If a new version has been placed into production, the deployment server is responsible for computing the class differences in all JAR files, plus the differences in files such as help files, graphics, and so on. The set of differences is cached on the server.
When connecting to the server, the agent must perform the following:
1. Verify that the user is authorized to access the Webtop and confirm that the version matches the production version specified as current on the server.
2. Download the set of updated class files in the JARs cached on the server and any additional files that must be updated, such as icons, graphics, and help files. Since the JAR differences are significantly smaller than the actual Webtop JARs, this procedure is performed quickly, even in low bandwidth conditions.
3. Open the corresponding JAR files of the local Webtop, update the classes that have changed, and re-JAR the files.
4. Confirm and/or download an alternate JRE if specified for the new Webtop version (this is specified by the application administrator).
5. Remove files that are no longer required for the alternate version.
6. Invoke the main start-up class for the Webtop and start the application.
What happens when a recently updated Webtop then fails in production? At best this is unacceptable in a B2B environment - a source of embarrassment. At worst, failure can take its toll on productivity and revenue. One of the more interesting capabilities of agent-based administration is an agent's ability to detect errors by monitoring the standard Java error channel. Developers know that all application exceptions should be handled, but the realities of today's development environments may not always permit.
Requirements are a moving target, and the advent of XP means more updates are frequently rolled out to users. Naturally, the probability of unhandled exceptions increases with the number of releases. Unhandled exceptions are an unfortunate reality in production applications, and when they occur, the Webtop becomes unstable or does not work. The software agent, by detecting the error, can immediately issue an alert to the administrator. This alert allows the production monitoring staff to take corrective action such as a rollback to a previous, more stable edition (if necessary, in the middle of the night) until a repair can be made.
Pull-based deployment marks a significant advancement in Java application management. Rollback or new version rollout can now occur seamlessly and without user intervention. When users start the Webtop, they're insulated from on-the-fly, background modifications to the Webtop code. Companies that have a large number of production applications with Webtop front ends have the option of deploying a single agent to manage all Java Webtops or deploying one agent per Webtop. Using the multiple agent strategy is arguably safer. The agents are small and should a single agent fail, it doesn't render all Webtops inoperative.
Some people confuse application management for Webtops with the popular install-packaging technology. While some installers now include auto-updating features, typically these technologies do not employ remote control agents; rather, updates are user-initiated. Moreover, the installers were not designed to compute JAR differences at the Java class level, or provide version management in high-availability production environments (as such, installers are a better fit for ISVs that update standalone applications periodically). These are critical features in Webtop management and serve as primary drivers for corporations moving forward with Webtops and application management platforms.
References Gamma, E., et al. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
Brown, K., and Shi, L. "Using the Distributed ICM architecture to achieve client-server independence."
Java Web Start:
DeployDirector (part of Quest Software):
Patrick Smith is director of DeployDirector product management at Sitraka (now part of Quest Software). With more than 10 years of software development experience, he has extensive expertise in the development and deployment of global software applications
employing distributed object technology and n-tier architectures.