[ Pobierz całość w formacie PDF ]
.intValue( ); } else { port = echoUDPServer.echoPort; } try { srv = new echoUDPServer( port ); srv.start( ); statusMessage = “Server running on port “ + port + “.\n”; statusMessage += “Watch the Java console for information.”; } catch( Exception e ) { statusMessage = “Error creating server: “ + e; } TextArea statusArea = new TextArea( 80, 4 ); setLayout( new BorderLayout( ) ); statusArea.setText( statusMessage ); statusArea.setEditable( false ); add( “Center”, statusArea ); }}Example Applet TagThe following tag will start an echo server running on port 7007.Remember that the compiled class files need to be located somewhere in the CLASSPATH for wherever you are using to view the applet.Otherwise, you will get a SecurityException when the echoUDPServer tries to allocate a DatagramSocket.<applet code=”echoUDPServerApplet.class” width=”500" height=”200"><param name=”port” value=”7007"></applet>SummaryYou now should know enough to strike out on your own and develop networking applets and applications.For simple Web-based applets, the urlFetcher example should show you all you need to know.The other examples can be altered and used as the core of new applications.For example, the TCPServer could be rewritten to service Finger requests for hosts that don't already have a finger daemon (such as Windows 95 boxes).To see more examples of how to put the networking classes to use, check out Chapter 31, “Extending Java with Content and Protocol Handlers.” The fingerClient is used to enable Java to understand URLs of the form finger://hostname/user, and the urlFetcher applet is extended.Chapter 30Overview of content and protocol handlersThe 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.Historical and Evolutionary NoteThe 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.Java Protocol HandlersThis 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.Definition of a Protocol HandlerIn 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.Dynamic Protocol Handlers in JavaThe 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:lA client or a server program need not possess the protocol handler code in advance—the code can be loaded on the fly.llIf a client program needs a new (and hitherto unknown) protocol handler, it can query the server (which initiated the transaction) and get the handler code from across the network.llDesign changes in the handler can be propagated on the fly without affecting other parts of the system and going through a full implementation-release cycle.lThe following features of Java make this possible:lversion-checked loading of classesllability to fetch classes from across the networklGiven 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 [ Pobierz całość w formacie PDF ]