by Travis Koch
One of the most significant trends for Web developers recently has been the rise of the internal Web, or intranet. Among Web development tools, Java is in a unique position to take advantage of this trend, given its portability, object-oriented implementation features, and wide base of support across platforms and vendors.
This chapter discusses how Java can be used to enhance corporate intranets, identifying some specific opportunities and potential problems that do not exist for applets destined for a public Web page.
Java is also an ideal tool for developing enterprise management tools, such as remote monitoring applications. This chapter also includes a high-level discussion of SunSoft’s enterprise management strategy, Solstice, and how it integrates with Java’s new Management API.
The intranet might be better described as an internal, enterprise-wide World Wide Web site that is not accessible from the public Internet. The intranet is based on the same technology that caused the proliferation of World Wide Web sites all over the Internet. This proliferation continues but now includes intranets, as more uses for Web browsers are found behind corporate firewalls.
With the enhancements to HTML and CGI as well as the introduction of Java, JavaScript, and other Web development tools, Web pages have gone beyond being simple documents and become client applications. Web pages that allow a user to access and/or manipulate a database on the Web server make the browser into a database client. Web-based intranet applications are currently being used in the place of groupware and workflow applications, such as Lotus Notes, as well as in the distribution of documentation, where it is still particularly efficient.
As a Java programmer, if you know your applet is targeted specifically for an intranet page, you can take advantage of available information about the runtime environment when designing and implementing the page.
The question of whether to use Java ahead of other Web development tools depends entirely on the situation. Java is a powerful tool, but it’s not the most efficient or appropriate solution for every problem that a Web developer faces.
The tasks you’re typically required to do in an intranet can all be accomplished using other Web development tools, such as CGI, HTML forms, and/or JavaScript. Java, JavaScript, CGI, and others all enhance a Web site’s functionality and ease of use. There are a few reasons that we would use Java ahead of other methods, but in many cases, Java is overkill and should be saved for when the overhead is justified.
CGI is a server-side solution. This eliminates the need for browser support but has the server doing all of the processing for all of the clients. Processing in a Java applet occurs on the client side, freeing up the server to do other things.
JavaScript, like Java, does all of its processing on the client side, requiring browser support. With JavaScript, your code is embedded in HTML comments, making it visible to anyone who hits the page. More importantly, JavaScript makes code reuse and maintenance more difficult.
For example, suppose you have an input validation routine written in JavaScript which is used on several pages. This would likely be accomplished by simply referring to a single JavaScript file from each of the HTML pages that required the routine. The requirements change, and the routine must now be modified in some, but not all, of the HTML pages where it is used. With Java, a class library could be created, and a new class could be written which simply “extends” the current one. This allows the programmer to reuse the same copy of previously written code. Because of that, a bug fix or modification made in the superclass cascades down to each of the subclasses automatically.
Similar code maintenance in JavaScript would most likely involve much more redundancy as the legacy code is simply cut and pasted into a new script file and modified there. Redundant code leads to inconsistency as modifications in one copy must be replicated in all others. Alternatively, the same results could be achieved with a partial rewrite of the original JavaScript file. It would need to be modularized into several smaller files. In either case, the OO nature of Java makes it far easier to maintain a consistent and bug-free intranet.
JavaScript and CGI have roles to play in enhancing Web pages and, in many cases, will be more complete and preferable solutions. However, Java allows you to write portable, reusable code that remains proprietary, more or less concealed in bytecode, and enjoys broad support from the major vendors. Its current array of features and extensibility mean that Java will likely be the preferred solution in more and more situations for developing both Internet and intranet Web sites.
Java provides a standard, object-oriented, portable way of creating network applications. It can be used in Web pages as applets but can also be used within an application. In other words, you can build a class library that can be used for applet and application development.
In this section, you learn how the differences between the private intranet and the public Internet might affect how you design and implement a Java applet.
By and large, programming an applet destined for the intranet will involve the same caveats and considerations as it did for applets being produced for the Internet. There are subtle differences, however, that provide some additional opportunities and, at the same time, create potential problems.
The most obvious differences between the intranet and Internet is the gap in our relative knowledge of what you are dealing with in either case. You know or can find out most of what you need to know about the intranet you’re developing for. This is not true in the case of the Internet. Any programming design and implementation for the Internet should accommodate low-end hardware, all possible platforms, slow network connections, and varying color depth. Such implementation may even involve translating the pages into multiple languages. When developing within an intranet, it is still important to be accommodating, but most intranets are small enough to allow a somewhat narrower focus.
In general, the average corporate intranet can count on relatively high bandwidth access to machines within its own LAN and have a small variety of hardware/OS platforms. This situation allows a certain amount of customization in how Java applets and applications are implemented.
A large applet must be downloaded to the client machine before it can be executed. On a high bandwidth LAN, you can make use of HTML pages that are many kilobytes in size. Users hitting the same page on a slower link will spend most of their time waiting for the applet to download. Designing an intranet on a high bandwidth LAN/WAN allows you to use Java in more places, and add more features to each Java applet or application. Knowing that your page will not be sent over a line with less than 10Mbps throughput means your free to make it work as designed without being handcuffed by size restrictions.
Typically your knowledge of the network environment extends beyond bandwidth to include the hardware/OS platforms being used. If you know what operating systems you’re serving, and how powerful the average machine on the LAN is, you can tailor the intranet to take advantage of its own capabilities. Having multiple applets on a page or many threads executing at the same time has many advantages. However, it may demand so much in terms of client side processor speed as to make it impractical with low-end machines.
In rare circumstances, an intranet can be so large that its network topology doesn’t differ perceptibly from that of the Internet. As a rule, however, intranets tend to be relatively less heterogeneous environments, with higher bandwidth and more secure access to on-line information. This situation provides opportunities for us to do things in Java that are not always feasible on the slower, less-trusted, and more heterogeneous Internet.
The intranet is likely to be operating behind any firewall or gateway and is designed to provide, not prevent, access to information. Within the intranet itself, you can provide several levels of security. Standard HTTP servers can be configured to allow or deny access to specific domains or IP addresses. Similarly, HTTP servers or CGI can be used to provide password protection over parts of the intranet. Secure Socket Layer (SSL) technology can be used to encrypt data being transferred between client and server. Java can serve all of these purposes, and in doing so encapsulate all of the security-related components of your system into a single code base. Simplifying the security system minimizes the number of flaws which could potentially lead to security violations.
In this section, I identify a few areas where you can take advantage of Internet/intranet differences and discuss some techniques for doing so.
In this case, you are assuming that you have more bandwidth to take advantage of on our intranet than for Internet applications. This is generally true but may not hold in all cases. In any event, network bandwidth is a known commodity on an intranet, whereas the users who hit your public Internet page may be doing so on very slow network connections. Using large applets will effectively shut such users out.
More and more large corporate intranets include areas of high bandwidth connected to more remote sites with lower bandwidth lines. For example, a company could have offices in New York and London connected via a noisy satellite link. Locally each can count on having relatively high bandwidth. However, connections from one office to the other will have much slower data rates. This problem can be alleviated somewhat by mirroring data on either site.
Java applets could also be mirrored and launched locally. That is, HTML pages should reference local Java classes limiting transatlantic traffic to data only. This type of socket connections won’t be allowed within a Java applet by some browsers. In this case, other means of sharing data such as NFS or CGI must be used.
Within a higher bandwidth network you will be able to do things with your intranet applets that were not practical on most Internet connections. For example, bandwidth on a typical LAN will allow options such as video teleconferencing and shared whiteboards, which are not feasible over links with speeds slower then about 10Mbps.
Because the entire applet must be sent over the network to the client machine before it can be executed, the size of our applet can now be larger. This means you will be able to increase the functionality of any single applet by simply adding code to provide the additional functionality you require. Also, this situation makes it feasible to send more data to the client computers and spread the processing load out away from the server.
On large systems with many users, the amount of time the server spends processing requests from its clients can become very significant. A Java applet does all of its processing on the client side, freeing up the server to do other things. This can be accomplished with Java applets and further enhanced by taking advantage of new interfaces provided in Java 1.1. The ability to have the client do its own processing can be applied in a number of ways.
An example of such an application might be pages that perform complex database queries and then display the result. This type of application is very popular and allows us to illustrate a number of techniques in pre- and post-processing of data.
With a server-side solution such as the CGI form, mistakes entered by the user are not detected until the entire form is submitted for the server to validate and process. Java may be used to do complex input field validation on the client side. These validations ensure that any data transmitted is correct and, at the same time, frees the server from having to do the validation, thus reducing network traffic and server processing. However, for simple field validation at the client side, JavaScript might be a more efficient solution.
The Web page could also include a Java applet that maintains a local copy of a searchable index. The processing required for a complex database query can be significant. This would allow a large portion of the work involved to be done by the client, leaving the server to retrieve the appropriate records.
Once the data has been retrieved from the server, Java can be used to present the data in a way that is far more descriptive than a report containing columns of raw data. Using Java on the client side, the data could be displayed in the form of a graph or bar chart. Sophisticated graphing capabilities are now built into Java with the Management APIs introduced in Version 1.1.
Another example could be an application which that the users to run “what if” scenarios on numeric data. If implemented in Java, the work is done entirely on the client machine.
Setting aside, for a moment, your focus on Web-based applications, it is important to note that client/server applications that perform groupware, workflow, or network-monitoring tasks on the intranet can be ported to Java.
Aside from issues already discussed, porting an existing application to Java provides an opportunity to make the application more modular and easier to maintain. Java’s object-oriented nature allows for easy modularization of both the client and server portions of an application.
In porting a server, it may be advantageous to look for portions of the server that may be run as part of the client, thus passing processing from the server to the client. Porting not only simplifies code maintenance by having a single code base for all platforms, but it also reduces support costs. By using applets, support staff can upgrade every client machine on the network—regardless of hardware/OS platform—by installing a single copy of the applet on the server.
Web pages that use Java applets can be slow to download and slow to run. Intranet pages can generate many hits through the course of a business day. Therefore, small improvements in performance can significantly effect overall productivity. This section is a brief discussion of some performance considerations for both downloading the applet and executing it on the client machine.
In spite of the additional bandwidth in most LANs as compared with typical throughput on some Internet connections, the sheer number of hits an intranet home page is capable of generating enough to make network traffic a consideration. Minimizing size and optimizing the code when designing an applet will help cut down on the amount of traffic on the intranet. Users may have to look at a page several times a day, everyday. For this reason, the efficiency of the applet and the location of its data is a consideration. The applet itself should be cached by the browser.
Just-in-Time (JIT) compilers can speed up the execution speed of the an applet considerably. Having the system administrator provide browsers that have a built-in JIT will allow you to support slower processors.
The most talked about Java security issue has to do with downloading applets from untrusted hosts. At first glance, you might think that intranet security would be simplified by the lack of such a concern. Unfortunately, because of the presence of internal firewalls and the additional levels of access sometimes required inside a corporate intranet, intranet security can actually be more complex than that of a public Internet site.
Intranets most often provide several levels of access to information. Typically, the entire intranet is shielded from the public, and within the private intranet, several levels of access might exist. Management, human resources, and other groups might have special access beyond the general corporate access. These issues can be dealt with on a rudimentary level with HTML/CGI solutions.
The best security in an open environment such as a Web site is to use encryption. With the new encryption classes offered in Java 1.1, you now have the opportunity to make use of public-key encryption for classes and data that are transferred over the network. With built-in encryption methods, this potentially complex task becomes relatively trivial using Java.
One example of where such encryption might be useful is in allowing access to a database of confidential documents. Many companies digitize the resumes of current and potential employees in order to store them online. This gives human resource managers a powerful tool with which to perform automated searches for particular skill sets and education and/or experience levels, among other things. The information itself, however, is confidential and should be offered only to those who require access to it. If you use a Java applet to query this database, you could not only force authentication from the user before allowing access, but you could also encrypt data being transferred and leave it unreadable to anyone who might “sniff” the packets as they traverse the system.
Netscape Navigator implements security measures on top of Java’s. This means that Netscape may prevent your applets from running, not because of bad code, but because they do things that the browser doesn’t allow. For example, in the rare event that you have an applet that needs to create a socket connection from behind a firewall and this firewall doesn’t allow external DNS information to pass, Netscape does not allow you to create the socket connection. Workarounds can usually be found in these circumstances but, as a last resort, you might have to get around this restriction by using a less secure browser.
This is just one of the latest potential problems. As new versions of Netscape and other browsers become available, these types of problems will remain an issue for developers.
To this point, you’ve learned how Java can be useful in helping to present intranet content. Java can also be useful beyond intranet content and can actually play a significant role in how an intranet site is maintained and administered. Java’s platform independence makes it an ideal tool when developing applications for numerous client platforms.
It only makes sense to build client-side monitoring tools and other components of an enterprise-management system using Java. Developing a system this way makes the creation of a complete, centralized, and enterprise-wide network management system feasible.
Enterprise management really means enterprise-wide network administration, which is becoming increasingly complex. The corporate network environment is no longer tied to a single vendor, let alone a single platform. More and more, corporate intranets are multidomain, multiprotocol, multiplatform systems. They contain hardware and operating systems from a number of different, competing vendors. This situation creates administrative overhead that can easily make the cost of owning such networks prohibitive for all but the largest and most profitable organizations.
Subsidiaries of the major network server vendors, namely IBM, HP, and Sun Microsystems, are announcing software that will provide system administrators with the ability to manage their networks remotely in spite of differences in hardware, operating systems, vendors, or even network protocols. Sun’s entry into this market is Solstice. Solstice is a collection of software tools for enterprise management. Solstice Workshop, as part of this overall strategy by SunSoft, will allow rapid development of these types of applications in Java. It is written entirely in Java based on the Java Management APIs.
The Java Management API is among the new additions to Java 1.1. It has been designed to allow easy integration of Java applications with its Solstice Enterprise Manager software. The API also offers new user interface components and protocol interfaces. This will no doubt prove useful beyond applets for network management and into distributed application development.
The Java Management API implements a style guide to promote standard user interfaces for enterprise management applications. The extensions to the current Java Abstract Window Toolkit (AWT) package provide a set of user interface building blocks that conform to this style. These new items are in turn combined to produce what SunSoft calls power components. Among the power components are a help subsystem, graphing and charting capability, hierarchy browsers, and multicolumn lists, to name a few.
By extending the Java AWT, the learning curve for someone already familiar with Java programming is brought down considerably. The new class is called the Admin View Module (AVM). This module offers a widget set that is designed to allow developers to build administration tools for heterogeneous network environments that conform to the style guide.
The Java Management API includes many other useful interfaces (the following is not a complete list):
Using the Java Management API gives you the capability to create sets of utilities with a consistent look and feel that are different from other Java applet/applications. The utilities are automatically portable to any Java-enabled platform.
This section is a brief discussion of SunSoft’s enterprise management suite: Solstice.
Solstice and tools like it are designed to reduce the cost of administration on a large, heterogeneous network, allowing corporate intranets to grow in complexity. Other design goals include scalability and flexibility to avoid premature obsolescence. This will open up more opportunities for cross-platform development tools such as Java.
Solstice is an integrated package that provides applications for each component of an enterprise-management system. Enterprise management, as defined by SunSoft, is comprised of the following components:
Solstice provides software tools to fulfill each of the enterprise-management components, as well as an overall system of managing the network. In order to support a multiplatform environment, Solstice requires a standard and well-known interface with the clients. Solstice supports multiprotocol environments with a layered, object-based design.
Solstice is developed around the Solstice Enterprise Manager, which provides the management platform from which a large heterogeneous network can be administered. SunSoft promises enterprise management from anywhere on the network to anywhere on the network, including remote execution of administration software on network clients.
Solstice currently provides a means of accomplishing all of the enterprise management tasks mentioned above and others. Support for platforms beyond Sparc and Intel versions of Solaris, however, is thin. SunSoft has committed to integrating the Solstice enterprise-management system with the Java Management APIs. This process has begun and will be accelerated by third parties as the demand for such services increases.
Solstice products support Simple Network Management Protocol (SNMP), the Internet’s standard management protocol. The layered design makes it easy to drop in other protocols without affecting the rest of the code base.
Given the design goals for Solstice, Java is an obvious choice for developing client-side applets, which are automatically portable without giving up functionality. The current plan is to build complex collections of tools using Java. These collections will make the client and server side portable and maintain a consistent interface from platform to platform. The development of Java-based Solstice has begun and will no doubt accelerate with improved development tools such as the Solstice Workshop.
The Solstice Workshop is designed to allow rapid development of distributed network management applications. It’s based on the Java Management APIs; the Java Workshop; and a small, relational database. The Java Workshop provides a Web-based development environment for creating Java applets/applications. The integration with the Java Management APIs allows development of portable administration tools in Java.
Figure 46.1 shows an example of the type of information that can be accumulated and how it can be manipulated using tools developed with the Solstice Workshop. This particular example illustrates that you can maintain information about a user’s accounts on numerous servers and modify that user’s account information from the same central location, thereby disabling all accounts held by a certain user throughout the entire enterprise at one time, from one location. Previously this required system administration on a number of operating systems, usually costing the time of multiple system administrators.
A user management applet programmed according to the Java Management API User Interface Style Guide.
The code to maintain the database would be JDBC API calls. Much of the database maintenance could be automated. An application on the server could pole each node of the network, gathering information on everything from hard drive space to router traffic. The following is a brief discussion of the components of the Solstice Workshop.
The Java Workshop is a collection of Java applications that allow Java development on any Java-enabled platform. This workshop is an integrated environment that includes all of the tools you would expect to see in Borland’s IDE. Unlike Borland, however, because Sun’s Java Workshop is done in Java, the workshop is instantly portable to other platforms. The browser is the only user interface developers need to learn.
In the Java Workshop, you are able to edit source code, compile applet/applications, and run them. The Build Manager, which compiles your code, generates hyperlinks to compile time errors. The environment also includes a debugger that traces multithreaded applications.
Project and portfolio management tools are also included in the package. The Java Workshop contains tools for keeping track of source files, class hierarchies, and a repository of classes using the Project Manager and Portfolio Manager components.
Visual Java, the GUI builder for drag-and-drop graphical user interface design is also included as part of the Java Workshop. Visual Java allows you to lay out your user interface and generate Java code to integrate with the rest of your applet/application.
Solstice Workshop also integrates a simple ODBC/JDBC compliant relational database. This database is intended to be used to store administration and configuration information in a centralized repository. Client applets could be written to automatically update information about themselves or trigger alarms, raise flags, and so on. The administrator would then have a snapshot of the entire system in one place, but it would be accessible from wherever the management platform is located at that moment.
Using Solstice Workshop will improve SunSoft’s progress in achieving its design goals for Solstice. And because SunSoft is using the Workshop, the quality of the environment itself will no doubt be increased.
The current versions of the applications included as part of the Solstice package represent fairly mature technology. SunSoft has made the protocols and server interfaces well-known in order to encourage third-party development of client-side Solstice applications. Companies such as Cisco Systems and 3Com have already begun to develop network management software in Java using Solstice Workshop. Network management applications developed in Java will integrate easily with new or existing network management software such as Solstice.
Regardless of specific development tools being used, when writing an applet that is known to be destined for an intranet, certain things you know ahead of time will change the way the applet is eventually implemented..
Java can be a powerful tool in the administration of even the largest and most complex intranets. Combined with an overall enterprise-management system, such as Solstice, the cost of maintaining an intranet drops to allow the formation of increasingly large and complex networks.
| Previous Chapter | Next Chapter |
|Table of Contents | Book Home Page |
| Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company
