Most Read This Week
Java Industry News
Java: Dèja vu All Over Again
Java: Dèja vu All Over Again
May. 1, 1997 12:00 AM
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
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
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?
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
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
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
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads