| When designing an architecture that would allow them to build a self-extensible browser, the engineers at Sun divided the problem into two parts : handling protocols and handling content. Handling a protocol involves the interaction between a client and a server: generating requests in the correct format, interpreting the headers that come back with the data, acknowledging that the data has been received, etc. Handling the content involves converting the raw data into a format Java understandsfor example, an InputStream or an AudioClip . These two problems, handling protocols and handling content, are distinct. The software that displays a GIF image doesn't care whether the image was retrieved via FTP, HTTP, gopher, or some new protocol. Likewise, the protocol handler, which manages the connection and interacts with the server, doesn't care if it's receiving an HTML file or an MPEG movie file; at most, it will extract a content type from the headers to pass along to the content handler. Java divides the task of handling protocols into a number of pieces. As a result, there is no single class called ProtocolHandler . Instead, four different classes in the java.net package work together to implement the protocol handler mechanism. Those classes are URL , URLStreamHandler , URLConnection , and URLStreamHandlerFactory . URL is the only concrete class in this group ; URLStreamHandler and URLConnection are abstract classes and URLStreamHandlerFactory is an interface. Therefore, if you are going to implement a new protocol handler, you have to write concrete subclasses for the URLStreamHandler and the URLConnection . To use these classes, you may also have to write a class that implements the URLStreamHandlerFactory interface. |
