HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Explaining Java computing to a group of business people reminds me of explaining client/server to a similar group just five years ago. In fact, I realize that they are the same people. The same business people, the same business problems - trying to cut costs by implementing an architecture that promises to make remote users more productive.

Client/server computing was supposed to free users from the limits of mainframe-based computing. In theory, client/server was supposed to create a community where people can share information and leverage the power of the desktop PC. Using UNIX servers and supplanting "Big Iron," the client/server revolution was born. The trouble was, client/server was too complicated and just too hard to implement.

The computing boom of the late '80s left corporate America supporting multiple computer platforms. PCs, Macintoshes and various flavors of UNIX systems were spread throughout organizations, from accounting to design to engineering. It was up to the application vendor or, in some cases, the in-house development team, to port different versions of the client to each platform. Even if there was only one target platform, there were various types of networks to consider. Was it a Novell network? A LAN Manager?How about Banyan Vines? There was also the issue of updating client applications. This left techs from MIS running from machine to machine at 2:00 AM with a floppy disk in one hand and a donut in the other. In the end, client/server was a good way of disseminating information, but the pains sometimes over-reached the gains.

Then came Java...

Darwin would have loved Java. Where heavy client and a light server fail, Java seems to be Mother Technology's answer to the next generation of client/server computing. Based on an accepted network architecture, client model and ubiquitous support from platform vendors, Java seems to be the client/server answer for the 1990s and beyond.

Java: Riding the Hype-wave to Standards
The advent of Web-based technology has done something that standards organizations haven't been able to do and what UNIX was supposed to do - create a set of standards that the computing industry and customer base can agree on. Java provides an architecture that is hyped in industry periodicals, TV Guide and Newsweek alike. CIOs and CEOs are being asked about "going to the Web" at golf courses, wedding receptions and family reunions.

In the past, client/server depended on various network and server configurations. The question now is, "Can my browser get to the Web server?" The pressure is now on the network-operating-system providers to comply with web standards. Support of TCP/IP has become a standard to which every network vendor must adhere to be considered in today's Web-centric buying climate.

With a network that is more or less stable and supporting an application, all that is necessary is a standard development platform. Like the network, applications have achieved another level of abstraction. It is no longer necessary to write code to Windows NT, Windows 95, MacOS or Motif. Java has brought us to the point where code can - with some care - be written once and run anywhere.

Ubiquitous support for Java - whether using browsers from Netscape, Microsoft and others or for Java-aware operating systems such as JavaOS for Sun's JavaStations - makes Java the premier language for client development. Java is the right choice for many development projects because of its cost-saving potential. Java's ability to be dynamically downloaded and the lower support costs that NCs provide can cut costs for many organizations.

Choices To Be Made
While Java has eliminated some variables from application design, it has added others. Designers are facing new parameters. What is the target desktop? Should the client be thin or fat? What kind of network connection does the client have? Is the connection fast or slow? Is the network diversified or homogeneous?

What are the clients going to be that will access the applications? If you use computers such as PCs or UNIX workstations as legacy computers, you have a certain amount of flexibility. These machines can support "fat clients." You should plan applications and architectures to take advantage of the added resources that these clients supply, such as "unlimited" local memory, available local storage, local printing, a local and central management hybrid and support for native methods on the client.

In contrast, the new class of Network Computers (NCs) can support only a thin client. With NCs, the client machine probably has less than 32 megabytes of memory, no local storage or printing and relies on central management for storage and applications. Because these client machines run on the JavaOS, the client must be 100 Percent Java. This limits methods of data access and connectivity for these thin clients.

You're Ready For Java, But is Your Network?
Even if you build the perfect client application for your users and have a powerful server, your application could still fail if your network isn't up to the challenge you are going to place on it. The type of applications that can be created hinges on the capacity of the network on which they run. Although there are many types of networks and network topologies, they all can be classified as fast or slow.

A fast network - such as a LAN, T3, T1 or 2X ISDN - runs on digital signals, allowing for a high volume of data traffic. Utilizing this type of network gives an application the luxury of high throughput, low latency of data and a minimum of error correction overhead. Fast connections allow a throughput of 128KB per second or greater. In contrast, slow networks are usually either analog or low-volume digital connections such as dial-up, 56K leased or 1X ISDN lines. Slow connections cause higher latency of data and the use of analog lines results in a greater percentage of time spent on re-transmission and error correction.

Network speed is important for any application. An application that maintains a persistent connection to the server to retrieve and update data will, of course, benefit from a "wider pipe" of data. But even if the application is strictly downloaded and run, the time it takes to download the applet can be measured in tens of minutes versus tens of seconds when using a modem rather than a fast, digital T1 connection.

Even with fast networks, other factors can cause a slowdown in traffic and a change in application architecture. Multiple routers that perform packet switching from different network protocols can cause bottlenecks that slow even the fastest network hardware. This problem can be minimized by choosing an application architecture that performs more calculations on the server, thus minimizing the number of large data packets transferred between the client and server. Care also should be taken when designing for longer periods of latency and more round trip delays.

"Typing" The Application
Before selecting an architecture, a few questions must be answered about the target application. What type of application is it going to be? Will it be an application that is functional in nature, such as a word-processor, or a content-oriented one, such as a real-time data analysis tool? What is the ancestry of the application? Is it a new application or an update of an existing one?

Functional applications rely mostly on client-based logic. Because most of the data is supplied by the user, functional applications are more tolerant of a network connection's varied performance. For functional applications, the server is used for application distribution, access control, data storage and printing functions. Applications such as word-processors, calculators and end-user order entry are part of this group.

Content-based applications rely on server-based information and the network to communicate that information in a timely manner. In content-based applications, the client supplies the interface for the user to access centrally located data. This data may be centrally located for the purpose of collaboration or copyright protection or due to volume constraints. Such applications require predictable performance levels from the server and network. Content providers can utilize this type of application to "rent" data and analysis tools. Examples of such of applications are numerical, statistical or real-time analysis, on-line analytical processing (OLAP) and access relational database-management system (RDBMS).

A new project gives a developer the maximum amount of options. There are many client/server options that you can use. The client and server can be pure Java, allowing for platform independence on both sides of the application. The client also can be Java with a Java Database Connectivity/Object Database Connectivity (JDBC/ODBC) server side. Or the client could be Java with a CORBA Object Server as the back end. The choices are more limited for existing applications, but there still are a number of options. The main decision is whether to port the application or split the application and do a partial port. If the application is already client/server, the server section can be reused and the client section can be rewritten in Java. If the application is a pure client side application, the client can be moved to the server and a Java applet can be created to act as a light interface to the original application. Lastly, the whole application can be ported with a total rewrite.

Picking The Architecture
Different architectures lend themselves to different application types. While a simple downloaded Java applet doesn't necessitate a complex network connectivity architecture, split functional and content-based Java applications require that certain decisions be made. Four different architectures that can be used are a straight JDBC implementation, Java Remote Method Invocation (RMI), CORBA or a custom approach.

Utilizing JDBC for database connectivity enables the Java applet to "talk" through the JDBC application programming interface (API) to a JDBC Driver, which in turn can talk to either a JDBC-Net Driver, a JDBC/ODBC bridge or a custom database driver. Any of these implementations require either native code on the client, as with a JDBC/ODBC bridge or the custom database drivers, or the use of a middleware server on the network for conversion to native DBMS instructions.

While JDBC leverages ODBC (which is common and has reasonable and understood security), it requires more control over the client environment. This control can either be native code on the client, eliminating some portability, or a middleware layer on the network, which may not be available on every network. JDBC allows for accessing large views of database tables. This, although needed for some applications, makes having a high-performance network a necessity.

A Java RMI architecture is one in which both the client and the server application are written in Java. Using this architecture, the client locates an RMI "service" reference from an RMI registry on IP port 1099. The client hands the request through a stub process to a remote reference layer that handles the semantics and translation for transport to the server. The request is sent through the server's remote reference layer, and then through an application skeleton to the Java service where it is processed and the result sent back to the client using the same method.

The benefit of an RMI implementation is that it is pure Java on both the client and server, has virtual transparent remote objects and methods, can be used through firewalls and supports multithreading. On the other hand, the application must be developed from scratch and deal with security issues. It also provides little control over network traffic. The use of interpreted code adds one more layer of complexity, which can reduce performance.

Utilizing Java in conjunction with CORBA allows the client to access a portable object resource broker (ORB) core to leverage multiple servers. A CORBA implementation gives an application a true "state-of-the-art" client/server architecture with access to existing CORBA objects. However, CORBA is still an emerging technology that needs a robust network and has little firewall and proxy support.

Finally, a custom client/server communications model uses a pure Java client to communicate to an application server using either HTTP requests or a socket protocol connection. In this architecture, "to-the-metal" communications work to minimize the network traffic between the Java client and, in most cases, the native code server application. This method can be used to minimize the infrastructure on the client and optimize performance for the given application. The downside of this implementation is that it takes more effort than other architectures, relies on underlying security between the client and server and requires synchronization between client and server.

The solution and architecture that is chosen for a given application must reflect the network that it will be running on. Industry pundits are currently saying that "the network is the computer." If it is, solutions must be chosen and architected for each network style. Dial-up connections will not be able to perform heavy, real-time analysis well and T3 lines are going to be underutilized by people who use them to check their bank balances. So, if you are walking around your local computer store and are looking for client/server-based Java solutions, make sure it's labeled something like this: Java-Client/RMI-arch/Java-Server/Mult-protocol-Network/Multiple-Client-Platform/Real-Time-Data-Access

About the Author
Robert L. Mattson is theTechnical Marketing Manager at Applix Inc, where he is responsible for communicating and integrating the technical vision of the company. Applix is a leading vendor of applications and tools for the Intranet, Customer Interaction, and Real Time Decision Support markets. Prior to Joining Applix, he held various technical and marketing positions at Interleaf, NovaSoft and Pacer Software.

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.