The first section of this chapter is a note on the history and evolution of protocol and content handler architecture within Java. The second section discusses protocol handlers—their definition, potential applications where they can be used as a very effective and powerful design and implementation tool, and general guidelines for writing your own protocol handlers. The third section of this chapter discusses the same issues for content handlers.
The Alpha version of Java had a standardized API for handlers. This was possible because the only Java-enabled Web browser at that time was Sun’s own HotJava. Within HotJava, Sun had full control over the architecture and deployment of handlers—both standard handlers as well as custom user-designed handlers.
Beginning with Java Beta, however, Sun is evolving the Java API, including the protocol and content handler APIs, with the objective of integrating it with other vendors’ Web browsers, including Netscape Navigator. The next chapter provides examples of code written to illustrate protocol and content handlers using the latest release of the JDK.
This section starts with a definition of protocol handlers. We then examine dynamic protocol handlers in the Java language, followed by a discussion of potential application scenarios. This section concludes with a set of guidelines for designing and implementing protocol handlers in Java.
In the context of client-server software design, a protocol is a predefined set of sequences in which information is exchanged between the client and the server software. It is the common language that they have been designed (by the programmer) to use to communicate with each other.
A protocol handler is a piece of code that is used (both by the server and client programs), to perform the function of shuttling data to and from the server and client applications. In the read mode, protocol handlers listen for incoming data on a network connection, verify if the data sequence conforms to the predefined protocol, and if it does, pass the data on to other parts of the program. In the write mode, they shuttle data in the opposite direction.
In conventional languages like C and C++, protocol handlers have to be designed and integrated into the system architecture up front, along with other components of a client-server system. This means that when the protocol has to be changed for business or engineering reasons, the handler and other related parts of the client and server systems have to go through a complete implementation and release cycle. This limits the shelf life of the handler and thereby the return-on-investment of the implementation effort.
The Java language eliminates all constraints of static design on protocol handlers and their deployment in client-server systems. Unlike a static/frozen protocol handler in conventional languages, a protocol handler in Java has the following elements of dynamism:
The following features of Java make this possible:
Given these two Java language features, you can easily make protocol handlers dynamically loadable, given that you design and implement the handlers as a Java class hierarchy.
Detailed guidelines for exploiting the previous Java features to construct dynamic protocol handlers are presented in a later section (Guidelines for Designing Dynamic Protocol in Java). In the next section, we’ll explore application scenarios where dynamic protocol handlers are a powerful and even necessary design mechanism.
In this section we examine some client-server application scenarios where dynamic protocol handling is shown to be much more effective and powerful than traditional static handler design.
Most Web browsers can handle the http, FTP, gopher and other popular Internet protocols. In addition, some browsers can handle secure/encrypted protocols. Let’s say, for example, a browser vendor or the W3O (the organization that sets and arbitrates standards for the World Wide Web) makes some changes to an existing protocol or creates a new protocol. Any such new development triggers a new cycle of product design and implementation and distribution of new browsers. Users are also forced to keep abreast of announcements and releases, periodically download new browsers, and install them on their machines.
Therefore, any change or improvement in a Web protocol forces the entire industry and the user community to swallow the change whole. This problem can be solved by using dynamically loadable protocol handlers.
A commonly used protocol for secure data transmission on the Web is HTTPS. A standard Web URL such as http://someserver.com/info.html will initiate a nonsecure network connection between the server and the browser. A secure server URL such as https://someserver.com/secretinfo.html, however, will cause both the browser and the server to encrypt or scramble all transactions. Of course for this to work, both the browser and the server have to be “aware” of this protocol and incorporate the actual protocol code.
Now imagine that the federal government comes up with a new standard for secure financial transmission, called (for example) HTTP-FED and expects all Web browsers and servers to incorporate the new protocol. This would require
Going through this change can be tiresome, expensive, and error prone, especially when the technology is rapidly changing and evolving. This problem can be alleviated by separating the design of the browser (and the server) from that of the protocol and making the protocol dynamically loadable. This is very easy to do in Java, as opposed to other conventional languages such as C or C++.
To make a product, such as a Web browser, automatically protocol-adaptive to the previously mentioned hypothetical new protocol HTTP-FED, a designer needs to
When the browser user tries to access a URL with the new HTTP-FED protocol, the browser will see that it does not understand HTTP-FED. This will cause the Java-implemented part of the browser to access the “Home” server and automatically download the new protocol handler. All this will be transparent to the user.
A rapidly emerging technology in the Internet arena is the ability to conduct financial transactions on the Internet. The scope of this technology includes home banking, online shopping, online bill payment, and so on. The theory is that, using a Web browser, you will be able to conduct any sort of transaction that involves the transfer of money. The reality of implementing this, however, is a bit more complex.
There are several industry groups and individual companies that are involved in creating protocols and standards for online financial transactions. Each is interested in having some or all of their favorite proposals gain pervasive acceptance by the industry and end users. Because most of us pay for almost anything we do, there is a lot of money to be made in being a primary enabler or carrier of these transactions.
While the industry players fight it out, what is the best product design strategy to follow, from the perspective of the following users of this technology:
In the short run, the standards and protocol situation is going to remain fragmented and rapidly changing.
Given the shifting sands of online transaction technology, the best bet is to design applications that are immune or adaptive in relation to multiple and emerging protocols and standards. Again, the only way to do this is to implement dynamic protocol handlers in Java.
Imagine that you are in charge of designing the protocols for a networked multiplayer electronic game. Such games enable multiple people to participate in a game session through a network.
Such games are usually designed as a client-server system, with
To make the example concrete, let’s assume you are designing some sort of a wagering game, which requires players to make a wager before each move. The person who makes the move wins or loses money depending on whether the move was good or bad within the rules of the game.
This means that for every move, the protocol for this game has to carry information about (among other things)
Now, for an interesting twist to this scenario, let’s say you wish to allow your target consumer to try the game before he or she buys it. This means you would have to distribute two versions of your game: a paid licensed version that allows actual wagering and financial transaction, and another free version that allows people to play but not actually wager and exchange money. Depending on whether the player is using a free version or paid version of the client, the protocol code in the client has to transmit or block wagering information during the game session.
If you were coding the game in C or C++, you would have to distribute physically two separate versions of the game—one with a fully functional protocol and the other with the wagering part of the protocol turned off. This would create the overhead of two separate tracks of the product-cycle that spans coding, documentation, maintenance, advertising, distribution, support, and maintenance mechanisms.
If you implement your game in Java, you can merge the two product-cycle tracks and implement a fully automated try-before-you-buy mechanism. This is accomplish by doing the following:
Then, when the user runs the client program and connects to the gaming server, the server can authenticate the client for a valid license code and send the appropriate protocol code—the fully functional version for licensed clients and the wager-disabled version for unlicensed clients.
It is pretty obvious that the Java-based implementation with dynamically loadable protocol handlers is much cleaner and effective than a C- or C++-based implementation with no such flexibility.
From the earlier application scenarios, you might already have a good idea of how to go about designing a dynamic protocol handler and how to deploy it within a client-server application.
Here is a set of guidelines that will help consolidate the ideas and provide a strategy for implementing Java-based dynamic protocol handlers in diverse design situations.
Much of what has been said for protocol handlers in the previous section also applies to content handlers. Thus, some material here is similar to material in prior sections. There is, however, a fundamental difference between content and protocol handlers that becomes clear as we go along.
The Internet is used to exchange diverse types of data—images, plain text, audio clips, executable programs, and so on. Each type of data is encoded in a specific format. Common examples of such encoding formats include, among others
Such encoded data is targeted for consumption by one or more applications on users’ computers. Content Type, also sometimes called MIME Type, specifies what format the data is encoded in and what class of applications can potentially consume this data. Using this information, a client program such as a Web browser or an e-mail reader can collect incoming data and spawn an appropriate module of internal code or an external “Helper” program to consume the data.
In the context of a client-server software system, a protocol is a predefined set of sequences in which information is exchanged between the client and the server software, while content type specifies the exact nature and format of the data being transmitted through the protocol. The content type is physically a part of a protocol sequence and is often transmitted in the header portion of the protocol. The protocol header might include other information such as the length (in bytes) of the data. All this information is used in tandem by the recipient program to decode and use the data.
A protocol handler is a piece of code that is used (both by the server and client programs) to perform the function of shuttling data to and from each other. A content handler is a piece of code that kicks in after the protocol handler has done its job. The content handler either directly consumes the incoming data or spawns an external application to use the data.
In conventional languages such as C and C++, content handlers, like protocol handlers, have to be designed and integrated along with other components of the system. This means that when a data-encoding format changes, or a new content type has to be supported for business or engineering reasons, the entire application has to go through a complete implementation and release cycle.
The Java language eliminates the need for tightly coupled and static design of content handlers and their deployment in client-server systems. Unlike a static/frozen content handler in conventional languages, a content handler in Java has the following elements of dynamism:
Just as with protocol handlers, the following features of Java make this possible:
Given these two Java language features, you can easily make content handlers dynamically loadable if you design and implement the handlers as a Java class hierarchy.
Detailed guidelines for exploiting the previous Java features to construct dynamic content handlers is be presented in the “Guidelines for Designing Dynamic Content Handlers in Java” section a little later in this chapter. In the next section, however, we’ll explore application scenarios where dynamic content handlers are useful and even necessary.
In this section we explore some client-server application scenarios where dynamic content handling is shown to be much more effective and powerful than traditional static handler design.
Most Web browsers can handle a limited set of content types, such as HTML, Plain Text, GIF images, and so on. When a Web browser cannot itself handle a particular data type, it calls an external “Helper” application to handle it.
E-mail and news readers can only display plain ASCII textual data. All MIME data types attached to the e-mail or news article have to be saved on disk to be handled later by another program.
For the purpose of the following discussion, we’ll refer to Web browsers, mail readers, and news readers collectively as browser programs (they all let the user “browse” information coming through the Net).
In all the previous cases, the browser program has to do one of the following:
What if neither of the above is true? What if the incoming content type is totally new, so that neither the browser program understands it nor can an external program use it? Well, so far the solution using conventional languages has been this:
Each such new development triggers a new cycle of product design, implementation, and distribution of new browser programs so that the new features can reach end users. Also, with each new release and new sets of features, applications tend to bloat and consume more hardware resources. Users are also forced to keep abreast of announcements and releases and must periodically download new browser and helper programs and install them on their machines.
Thus, any change or improvement in a content type forces the entire industry and the user community to scramble to keep up. This problem can be solved using dynamically loadable content handlers.
Let us imagine the MPEG committee comes up with a new MPEG-encoding format called MPEG-2000, and expects all browser programs to understand and render this new format correctly. This would require
Going through this is a chore. As with protocol handlers, this problem can be alleviated by separating the design of the browser from that of the content handler, and making the content handler dynamically loadable. This is very easy to do in Java, as opposed to other conventional languages such as C or C++.
To make a product such as a Web browser automatically adaptive to the hypothetical new MPEG content type
When the browser tries to decode data that is encoded in the new content type, the Java-implemented part will access the same server where the data came from and automatically download the appropriate handler. All this will be transparent to the user.
The concept of dynamic content handling can be extended to several other application domains. A generic potential application domain is to use content handlers to mediate “computing-resource-for-rent” type applications.
Let’s say a hypothetical company, TronGlut, Inc., has an enormous array of powerful computers, and a hypothetical compression technology researcher—Dr. Pix—has invented a new compression algorithm. This algorithm is very advanced, but requires enormous computing power to test. Thus, Dr. Pix contracts with TronGlut, Inc. to send test data (such as images, sounds, and text) and algorithms to TronGlut’s computers, which will run the algorithm and return compressed data to Dr. Pix.
In this scenario, Dr. Pix will host the data and host the corresponding handler code (the compression algorithms to be tested) on a server. TronGlut’s computer runs an automatic browser-type application that sequentially accesses uncompressed data and corresponding handler code from Dr. Pix’s server. After running the handler on each data item, the results are e-mailed back to Dr. Pix, who evaluates the results visually and algorithmically with another browser.
From the earlier application scenarios, you may already have a good idea of how to go about designing a dynamic content handler.
Here is a set of guidelines that will help consolidate the ideas and provide a strategy for implementing Java-based dynamic content handlers in diverse design situations:
In this chapter, we examined the concept of dynamically loadable protocol and content handlers in Java. With specific application scenarios and design guidelines, we saw how these twin features of Java empower software designers to implement client-server applications in a modular, adaptive, and extensible way. In the light of these features, we contrasted client-server design using Java against using other languages like C and C++.
The next chapter expands the material presented in this chapter and presents specific code samples illustrating the design of protocol and content handlers in Java.