1 / 39

Chapter 9

Chapter 9. Network Programming. Overview. Java has rich class libraries to support network programming at various levels. There are standard classes that support server and client sockets, datagram sockets, and multicast sockets.

apria
Download Presentation

Chapter 9

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 9 Network Programming

  2. Overview • Java has rich class libraries to support network programming at various levels. • There are standard classes that support server and client sockets, datagram sockets, and multicast sockets. • There are standard classes that support remote method invocation (RMI).

  3. Overview • Support for network programming is in packages such as java.net and java.rmi • There are also related standard packages for security, cryptography, and server-side scripting. • Additional third-party packages support technologies such as CORBA.

  4. Overview • Java networking reflects TCP/IP as the de facto standard for networking infrastructure, but the Java interfaces and classes abstract from low-level TCP/IP implementation details. • Classes such as InetAddress disclose the underlying IP infrastructure.

  5. Overview • Although network applications ultimately must be tested in a distributed environment with physically machines, initial testing can be done a standalone machine using the localhost IP address, which is 127.0.0.1 in dotted-decimal notation.

  6. Sockets • Java supports sockets of various types. • The Socketclass supports TCP client sockets, that is, a socket used by a client to send requests to a server. • The ServerSocket class supports TCP server sockets, that is, sockets used by a server to await client requests.

  7. Sockets • In a typical client/server application based on sockets, • A client opens a client Socket to the server by specifying the server’s Internet address and the port number on which the server listens. • The server’s ServerSocket listens for clients. When a client connects, the accept() method returns a reference to the client socket.

  8. Sockets • The Socket has associated input and output streams through which the client and the server can exchange data, including serialized objects. • Once a transaction completes, the Socket is closed, which breaks the connection.

  9. Sockets • Single-threaded servers are called iterative servers. Multithreaded servers are called concurrent servers. • In a typical concurrent server, the thread T that listens for clients constructs and starts separate threads to handle each client so that T can focus exclusively on listening for clients.

  10. Sockets • The java.net package includes a SocketImp class for applications that need to deal with firewalls, proxy servers, and the like. • The Socket and ServerSocket classes have a default socket implementation that meets most needs.

  11. Datagram sockets • The DatagramSocket and DatagramPacket classes support IP-based networking. • The MulticastSocket class supports group-based socket applications. • Multicast sockets use datagrams.

  12. Datagram sockets • In a typical datagram application, • The sender constructs a DatagramPacket to store the cargo bytes to be sent to a receiver. The packet is addressed to a server and sent through a DatagramSocket. • The receiver constructs a DatagramPacket to receive, through a DatagramSocket, the sent packet of bytes.

  13. Serialization over sockets • Serialization over sockets is attractive because of its simplicity and power. • An object can serialized to an ObjectOutputStream constructed from the socket’s output stream, and then deserialized from an ObjectInputStream associated with a socket’s input stream.

  14. Java Secure Sockets Extension • The JSSE package supports secure Internet communications based on the Secure Sockets Layer and Transport Layer Security protocols in the TCP/IP suite. • For legal reasons, the JSSE must be provided as a separate package available for free at http://java.sun.com/products.

  15. Applets • An applet is a typically small program embedded in another application, generally a Web browser that provides a JVM. • An applet’s host program provides an applet context in which the applet executes. • An applet is generally launched from an HTML document with an APPLET tag that specifies the URL for the applet bytecodes

  16. Applets • At the technical level, • An applet is an object whose class descends ultimately from Applet or JApplet. • An applet is an embeddable Panel, which is a simple Container window. • An applet’s class must be public. • An applet typically overrides the inherited init, start, stop, and paint methods.

  17. Applets • When a Web browser downloads an applet, it typically • Invokes the init method to enable once-only initialization (e.g., setting colors, fonts, and the like) • Invokes the start method. If the applet is multithreaded, other threads can be constructed and started in this method.

  18. Applets • Provides the applet real-estate in which to display itself, that is, the applet’s Panel and embedded components. • If the page that launched the applet is exited, the browser typically invokes the stop method, which then can perform appropriate cleanup operations. If the launching page is entered again, the browser again invokes start.

  19. Applets • Applets in the same context can communicate straightforwardly with one another by, for example, invoking one another’s accessible methods. • Applets can be packaged in compressed JAR (Java Archive Files) for efficient downloading.

  20. Applet security • Applets typically execute under a strict security manager that prevents an applet from • Accessing the local disk to read, write, delete, or execute files. • Loading nonstandard libraries. • Opening connections to arbitrary hosts.

  21. Applet security • The tight applet security is sometimes described as sandbox security to suggest that an applet must “play” within a confined area from which it must not venture. • An applet is allowed to open a socket to the server from which is downloaded, thus enabling socket-based communications.

  22. Applets and host programs • Any Java application can download an applet’s bytecodes, load the applet, and invoke the usual applet methods such as init and start. • In summary, any Java application can act as an applet’s host program. • In this respect, an applet shows itself to be the bean or component that it truly is.

  23. RMI • Remote method invocation allows a Java program executing on one machine to invoke methods that execute on another machine. • At the implementation level, an RMI client gets a reference to a remote object whose methods, exposed in an RMI interface, then can be invoked by the client.

  24. RMI • RMI uses serialization over sockets to handle (1) argument passing from a client invocation to a server execution and (2) a return value from a server to the invoking client. • RMI technology thus leverages underlying socket technology.

  25. RMI • A typical RMI client • Sets its security manager to an RMISecurityManager. • Declares a reference of an interface type (e.g., Iface1) that the server implements. • Invokes the lookup method with the registered name of the server. • Invokes the methods declared in IFace1.

  26. RMI • A code segment from a sample client: System.setSecurityManager( new RMISecurityManager() ); try { Ihello hi = (Ihello) Naming.lookup( “rmi://kalinnt.cti.edu/hello” ); hi.sayHi(); hi.sayBye(); } catch( Exception e ) {/*...*/}

  27. RMI • A typical RMI server • Creates a public interface that extends java.rmi.Remote. Each declared method throws a RemoteException. • A public class implements the interface by appropriately defining the methods therein. The server generally extends the UnicastRemoteObject to handle argument and return value marshalling.

  28. RMI • The server invokes the Naming method bind or rebind to register a server object under a symbolic name such as “HelloServer.” • The rmic utility is run on the compiled server code to generate a skeleton and a stub, which handle low-level RMI interactions. The skeleton is the server’s proxy and the stub is downloaded automatically to the client to act as the client’s proxy.

  29. RMI • A code segment from a sample server: public interface Ihello extends Remote { public String sayHi() throws Remote Exception; public String sayBye() throws RemoteException; }

  30. RMI • A code segment from a sample server: public class HelloServer extends UnicastRemoteObject implements IHello { public HelloServer throws RemoteException {/*...*/} public String sayHi() throws RemoteException {/*...*/} } // continued on next slide

  31. RMI public static void main( String[ ] a ){ try { Naming.rebind( “hello”, new HelloServer() ); } catch( RemoteException e ) {/*...*/} catch( MalformedURLException e ) {/*...*/} } } // end of class

  32. RMI • Once the server has been rmic compiled and started, the rmiregistry utility is started on the server machine. • The registry must be active so that clients can invoke lookup to locate a specific RMI server object. • The server application is then started to await clients.

  33. RMI activation • A standard RMI server runs continuously waiting for clients. An alternative is RMI activation, which starts a server only when a client connects to invoke a method remotely.

  34. RMI and Jini • RMI activation provides the infrastructure for Jini technology, which allows small digital devices (e.g., cellular phones) and software modules to be mutually accessible through a network. • Jini technology extends the registry and naming services available in RMI.

  35. RMI summary • RMI technology leverages socket technology. • Jini and Enterprise Java Bean technologies leverage RMI technology. • RMI is highly flexible. For instance, an applet can be an RMI client, and a servlet can be an RMI server.

  36. CORBA technology • RMI requires, in effect, that the client and the server be written in the same language, Java. • RMI requires that the client know the server’s URL. • CORBA (Common Object Request Broker Architecture), by contrast, supports language and location transparency.

  37. CORBA technology • CORBA clients and servers can be written in different languages. • CORBA clients can access servers through symbolic names given to the CORBA naming service. • CORBA clients need not know the server’s URL.

  38. CORBA technology • CORBA serves as an ORB, or object request broker. • A CORBA client requests access to an object that some CORBA server provides. • At the syntax level, CORBA is quite similar to RMI: a client typically uses a reference of an interface type to invoke methods remotely.

  39. CORBA technology • The nonstandard org.omg package and its subpackages support CORBA under Java. • CORBA is an alternative to RMI in contexts in which Java is not the exclusive language. • If Java is used on both the client and the server side, RMI has efficiency and “ease of use” advantages over CORBA.

More Related