Java EE Programming - PowerPoint PPT Presentation

About This Presentation
Title:

Java EE Programming

Description:

UDP & TCP Java s RMI Topics Networking and Internetworking Inter-process communication Distributed objects and remote invocation UDP & TCP Java s RMI Networking ... – PowerPoint PPT presentation

Number of Views:116
Avg rating:3.0/5.0
Slides: 112
Provided by: BarbaraH157
Category:

less

Transcript and Presenter's Notes

Title: Java EE Programming


1
Java EE Programming
  • UDP TCP
  • Javas RMI

2
Topics
  • Networking and Internetworking
  • Inter-process communication
  • Distributed objects and remote invocation
  • UDP TCP
  • Javas RMI

3
Networking Issues for Distributed Systems
  • Previous networks had to meet simple application
    requirements
  • File transfer, remote login, e-mail and
    newsgroups
  • With the growth of the Internet, more stringent
    requirements are necessary
  • New modes of use
  • Additional and more stringent requirements

4
Current Networking Requirements Terms
  • Performance
  • Speed with which individual messages can be
    transferred between two interconnected computers
  • Latency is the delay that occurs after a send
    operation is executed before data starts to
    arrive at the destination computer (network
    latency)
  • Data transfer rate is the speed at which data
    can be transferred between two computers in the
    network once the transmission has begun
  • Bits per second
  • Message transmission time
  • latency length/data transfer rate

5
Current Networking Requirements Terms
  • Scalability
  • The potential future size of the Internet is
    commensurate with the population of the planet
  • Indicates size and load of the Internet
  • Networks must scale

6
Current Networking Requirements Terms
  • Reliability
  • The degree in which an application can recover
    from communication failures
  • Security
  • Techniques for achieving security in distributed
    systems
  • Firewalls creates a protection boundary between
    an organizations intranet and the rest of the
    Internet
  • Distributed systems need a secure network
    environment with end-to-end authentication,
    privacy, and security
  • Example - encryption

7
Current Networking Requirements Terms
  • Mobility
  • Wireless networks provide connectivity to devices
    such as laptops, cell phones, PDAs
  • Addressing and routing schemes of Internet were
    developed before the advent of wireless devices
    so are not well-adapted to their intermittent
    connection to many different subnets
  • Quality of service
  • Applications that transmit multimedia data
    require guaranteed bandwidth and latencies

8
Current Networking Requirements Terms
  • Multicasting
  • One-to-many communication
  • Needed in distributed systems

9
Types of Networks in Distributed Systems
  • PAN Personal area network
  • Various digital devices carried by a user are
    connected to a low-cost, low-energy network
  • LAN Local area network
  • Carry messages at high speed between computers
    connected by a single communication medium
  • Twisted copper wire, coaxial cable, fiber optics
  • WAN Wide area network
  • Carry messages a lower speeds between nodes that
    are often in different organizations and may be
    separated by large distances
  • Uses routers to route the messages
  • MAN Metropolitan area network
  • High speed network installed in towns/cities for
    transmission of data and video
  • DSL and Cable modem connections

10
Types of Networks in Distributed Systems
  • WLAN Wireless local area network
  • Used in place of wired LANs for wireless mobile
    devices
  • IEEE 802.11 (WiFi) standard protocol
  • WMAN Wireless metropolitan area network
  • Supercedes 802.11
  • IEEE 802.16 WiMAX protocol

11
Types of Networks in Distributed Systems
  • Internetworks communication subsystem in which
    several networks are linked together to provide
    common data communication facilities
  • Overlay the technologies and protocols of the
    individual component networks and methods used
    for their interconnection
  • Needed for the development of extensible, open
    distributed systems
  • Example Internet

12
Network performance
13
Network Protocols
  • Protocol refers to a well-known set of rules
    and formats to be used for communication between
    processes in order to perform a given task
  • Two parts
  • a specification of the sequence of messages that
    must be exchanged
  • a specification of the format of the data in the
    messages

14
Conceptual Layering of Protocol Software
15
Protocol Layers
  • Network software is arranged in a hierarchy of
    layers
  • Each layer presents an interface to the layers
    above it and below it
  • Sending side each layer (except top) accepts
    items of data in a specified format from the
    layer above it and applies transformations to
    encapsulate the data in the format specified for
    that layer
  • Receiving side converse transformations are
    applied to data items received from the layer
    below before being passed to layer above

16
Encapsulation as it is applied in Layered
Protocols
The tags in the headers are the protocol type for
the layer above, needed for the receiving
protocol stack to correctly unpack the packets
17
Protocol Suites
  • Complete set of protocol layers is referred to as
    a protocol suite or protocol stack
  • Reference Model for Open Systems Interconnection
    (OSI)
  • Protocol layering brings substantial benefits in
    simplifying and generalizing the software
    interfaces for access to the communication
    services of networks
  • Also carries significant performance costs
  • Why do you think this is so?

18
Protocol layers in the ISO Open Systems
Interconnection (OSI) model
19
OSI Protocol Summary
20
Internet Protocols
  • TCP/IP Transmission Control Protocol/Internet
    Protocol
  • Grown now to over 60 million hosts
  • Example application services protocols based in
    TCP/IP
  • Web (HTTP)
  • email (SMTP, POP)
  • netnews (NNTP)
  • file transfer (FTP)
  • Telnet (telnet)

21
TCP/IP Layers
22
TCP/IP Layers
  • Two transport protocols
  • TCP reliable connection-oriented protocol
  • UDP datagram protocol that does not guarantee
    reliable transmission
  • Internet Protocol (IP) is the underlying
    network protocol
  • IP datagrams provide the basic transmission
    mechanism for the Internet and other TCP/IP
    networks
  • Internet protocols are usually layered over other
    network technologies
  • i.e, Ethernet

23
Encapsulation in a message transmitted via TCP
over an Ethernet
24
The programmer's conceptual view of a TCP/IP
Internet
25
IP Addressing
  • Scheme chosen for naming and addressing hosts and
    routing IP packets to their destination
  • Assigns an IP address to each host in the
    Internet a 32-bit numeric identifier
    containing
  • network identifier uniquely identifies one of
    the subnetworks in the Internet
  • host identifier uniquely identifies the hosts
    connection to that network

26
Internet Address Space
Class A is reserved for very large networks
(i.e.,US NSFNet) Class B is used for
organizations that operate networks likely to
contain more than 255
computers Class C is allocated to all other
network operators Class D is reserved for
Internet multittask communication Class E
contains a range of unallocated addresses
reserved for future use
27
TCP and UDP
  • Provide the communication capabilities of the
    Internet in a form that is useful for application
    programs
  • TCP and UDP are transport protocols and must
    provide process-to-process communication
  • Accomplished by using ports
  • Port numbers are used for addressing messages to
    processes within a particular computer and are
    only valid for that computer
  • Once an IP packet has been delivered to its
    destination host, the TCP- or UDP-layer software
    dispatches it to a process via a specific port at
    that host

28
UDP Features
  • UDP datagram is encapsulated inside an IP packet
  • Short header with source and destination port
    numbers, length field and a checksum
  • UDP does NOT guarantee delivery
  • Adds no additional reliability mechanisms except
    for checksum (which is optional)
  • Use is restricted to applications and services
    that do not require reliable delivery of single
    or multiple messages

29
TCP Features
  • TCP provides a much more sophisticated transport
    service
  • Provides reliable delivery of a long sequences of
    bytes
  • Guarantees the delivery to the receiving process
    of all the data presented to the TCP software by
    the sending process in the same order
  • Provides retransmission if necessary
  • Done when the it does not receive an
    acknowledgement from the receiving process within
    a specified timeout

30
Middleware
  • Looking at IPC from the Programmers point of
    view
  • Remote Method Invocation (RMI)
  • Remote Procedure Call (RPC)

31
Interprocess Communication(IPC)
  • Distributed Systems
  • rely on exchanging data and achieving
    synchronization amongst autonomous distributed
    processes
  • Inter process communication (IPC)
  • shared variables
  • message passing
  • message passing in concurrent programming
    languages
  • language extensions
  • API calls
  • Principles of IPC
  • (Concurrent programs collections of two or more
    sequential programs executing concurrently
  • Concurrent processes collection of two or more
    sequential programs in operation, executing
    concurrently

32
IPC Characteristics
  • Message passing between pairs of processes can be
    supported by two message communication
    operations
  • send
  • receive
  • In order for one process to communicate with
    another, one process sends a message (sequence of
    bytes) to a destination and another process at
    the destination receives the message

33
Types of Communication
  • Synchronous
  • Sending and receiving process synchronize at
    every message
  • Both send and receive are blocking operations
  • Whenever a send is issued, the sending process
    (or thread) is blocked until the corresponding
    receive is issued
  • Whenever a receive is issued, the process (or
    thread) blocks until a message arrives

34
Types of Communication
  • Asynchronous
  • Send is non-blocking sending process is allowed
    to proceed as soon as the message has been copied
    to a local buffer
  • Receive operation can have blocking and
    non-blocking variants
  • Non-blocking receiving process proceeds with
    its program after issuing a receive operation
    which provides a buffer to be filled in the
    background
  • Must separately receive notification that is
    buffer has been filled by polling or interrupt
  • Todays systems do not generally provide the
    non-blocking form of receive because it adds
    complexity to the application

35
Sockets
  • Both UDP and TCP use socket abstraction
  • Provides an endpoint for communication between
    processes
  • Originated from BSD UNIX but in all Unix flavors
    (i.e., Linux)
  • IPC consists of transmitting a message between a
    socket in one process and a socket in another
    process

36
Sockets and Ports
37
Sockets and Ports
  • For a process to receive messages, its socket
    must be bound to a local port and one of the
    Internet addresses of the computer on which it
    runs
  • Messages sent to a particular Internet address
    and port number can be received only by a process
    whose socket is associated with that Internet
    address and port number
  • Processes may use the same socket for sending and
    receiving messages

38
Moving from Interprocess to Distributed
Communication
  • A distributed system breaks up a previously
    monolithic application into different components
    and then proceeds to place them on different
    systems (i.e. tiers).
  • We are decoupling the consumer and the supplier
    we are spreading the activities of an application
    onto team players (systems)

39
Moving from Interprocess to Distributed
Communication
  • Analogy
  • Let us imagine for a moment a small business run
    by a single entrepreneur. This one person,
    Suzette Sellers, does everything, much like a
    monolithic application. She sells to customers,
    orders new product, manages the books, pays the
    bills, and does anything else. Internally, she
    has compartmentalized her job function (much like
    we program in a modular fashion) selling,
    ordering, and administration. There is no
    overhead associated with external communication
    she does everything.
  • When her store becomes successful, she finds that
    she simply cannot do it all and requires
    assistance. Suzette hires Henry Helpers, a
    capable and likeable chap. This is now similar
    to our two-tier architecture. Because Suzette
    and Henry work in the same physical location,
    this is a logical two-tier system. Communication
    is quick and easy.
  • Think about two programs on a computer they can
    communicate via files, shared memory, pipes, or
    other constructs.
  • If you are familiar with processing on a UNIX- or
    Linix-based system, multiple commands are often
    strung together with pipes.

40
Moving from Interprocess to Distributed
Communication
  • Suzettes store does so well that she moves her
    office into another building to increase the
    amount of retail floor space in her original
    store. Now Suzette and Henry are in different
    physical locations but still need to complete the
    same tasks of selling, ordering, and
    administration. We have moved into a physical
    two tier distributed system and things just
    become more complicated. Suzette and Henry still
    need to communicate but the previous methods will
    no longer work.
  • The obvious solution is the telephone, but this
    changes the dynamic of the entire conversation
  • In our computer analogy, we now have a client and
    a server tier where the previous solutions of
    files, shared memory, or pipes are no longer
    solutions as they only work within a single
    system.

41
Moving from Interprocess to Distributed
Communication
  • Suzette and Henry must now specifically locate
    each other (i.e. phone numbers) before
    communicating.
  • Conversations will be slower (network latency).
  • Data will need to be shared in different ways
    (difficult to draw a picture on the phonethe
    crayon keeps breaking on the handset).
  • And finally, the phone lines can go down or have
    interference (network errors or corruption).

42
Moving from Interprocess to Distributed
Communication
  • Yes, we have gained some benefits by spreading
    out Suzette and Henry (more retail floor space)
    but we have introduced complexity and latency
    into the business.
  • Similarly, when a distributed application is
    placed on different systems (whether physically
    or logically separated), we also introduce
    complexity and latency into the application.
  • However, the ability to take advantage of
    multiple computers is such a powerful incentive
    that we have devised many ways to accommodate our
    new problems
  • The stage is now set to discover how to implement
    this distributed communication.

43
Middleware Layer
  • By choosing Java, we are explicitly ignoring the
    platform because Java (in theory) runs exactly
    the same on any platform that has a
    Java-compatible runtime environment.
  • We are not yet concerned with what capabilities
    an application will exhibit other than we will
    create a server component that holds the
    desired properties and a client component that
    requests these capabilities.
  • Assume that our distributed Java-based
    application will communicate via the TCP/IP
    protocol

44
UDP Communication
  • Basis of TCP/IP protocol stack is the Internet
    Protocol (IP) data packet
  • IP is a connectionless and stateless protocol
    (fire and forget)
  • Once a IP packet is sent, the sender simply does
    not care about it anymore
  • IP packet can become lost, destroyed, misplaced,
    or corrupted on its way to its destination
  • If multiple IP packets are sent they can arrive
    out of order
  • IP is quick to use but not reliable
  • Think of IP as simple postal envelopes they can
    be easily damaged, lost, and delivered out of
    order.
  • However, IP envelopes are cheap and convenient.
    (The analogy to a postal service is very
    appropriate as the cost is low per message and
    the service is usually reliable but there is no
    capability to trace a wayward envelope.)

45
UDP Communication
  • The User Datagram Protocol (UDP) is implemented
    on top of IP layer.
  • UDP is still a fairly lightweight protocol which
    means that most of its effort is spent on
    delivering data.
  • UDP adds two important features larger
    payloads and data integrity.
  • If a message is larger than the size of a single
    IP envelope, UDP will split the message into
    multiple IP envelopes, taking care to remember
    how it split up the original message.
  • UDP guarantees that the data in a single UDP
    packet in the will arrive exactly as it was sent.
  • What happens if one of the IP packets that made
    up the UDP packet is lost? Then UDP discards the
    rest of the IP packets and thus the entire UDP
    packet rather than deliver a damaged UDP packet.
  • This is analogous to sending a four page letter
    in separate envelopes if envelope 3 does not
    arrive, then UDP will throw array the remaining
    envelopes that did arrive as it has no way to
    reconstruct the original four page letter.

46
UDP Communication
  • UDP is also a stateless and connectionless
    protocol
  • Stateless means that once a message is sent, the
    sender does not care about it anymore.
  • If the message arrives, then that is fine. If it
    does not arrive, we do not feel any grief
  • Connectionless means that there is no continued
    conversation.
  • The message is complete in and of itself.
  • Think about sending postcards. If we send one
    postcard from Europe and another from South
    America, neither of the postcards depend upon
    each other. They are separate communications

47
UDP Design Considerations
  • For client-server applications that transfer
    relatively small amounts of data, UDP is
    acceptable
  • For the simplest application, a client will send
    a single message to the server and expect a
    response
  • If the client does not receive a response within
    a pre-determined amount of time, the client may
    send the request again.
  • This is similar to asking a person to repeat an
    answer. Of course, after asking for the answer
    so many times, it is likely that we (the client)
    will just give up.
  • If a DNS server does not respond after a couple
    of seconds, a client will simply accept that no
    answer is forthcoming and either ask another DNS
    server or return an error.

48
UDP Example
  • UDP communications can be implemented in Java
    quite easily
  • However, it should be pointed out that UDP is
    simply a service to ferry data from point A to
    point B.
  • UDP does not understand data types or other Java
    constructs, such as objects.
  • To accommodate this understanding, we will use
    the capability of the String class to convert
    itself into an array of bytes and back.
  • We are implicitly relying on the String class to
    correctly convert an array of bytes using the
    correct code set.
  • Both the server and client will perform many of
    the same operations but the server has the
    additional task of existing in a state where it
    can receive requests at any time and must respond
    to them. A client, on the other hand, will only
    be executed on demand and exit as soon as it
    receives a response.

49
UDP Server
  • The UDP server may look complicated but there is
    actually very little to it.
  • The server first creates a socket, which is a
    logical construct that we may attach to an actual
    port.
  • We have hard-coded the port upon which our server
    will listen, 7777.
  • You may choose any port between 1024 and 65535
    (assuming that it is not already in use).
  • The server attaches to the port and then performs
    an endless loop of listening for any incoming
    message and sending the same message (known as a
    datagram) back to its sender.
  • The effect is similar to a mirror
  • See UDPServerSimple.java

50
UDP Client
  • The UDP client seems to be much longer in length
    but that is because we have added in the ability
    to specify the message to send, the server name,
    and the port on which the UDP server is listening
    on the command line, rather than hard-coding it.
  • This approach should allow you to run the program
    as-is, even though you will run it on your system
    (which has a different network name and IP
    address than everybody elses system).
  • The client, similar to the server, first creates
    a socket that can be bound to a network port.
  • However, we will not bind it to a particular port
    because we do not carejust as when you send a
    letter, the mailbox you use is irrelevant to the
    receiver.

51
UDP Client
  • The client program then resolves the name of the
    server (first argument) to an IP address, which
    is what the UDP protocol requires.
  • The second argument is the port that the UDP
    server is listening on, and the third argument is
    the actual message (remember to enclose it in
    double quotes if it contains a space).
  • A datagram message is then created and sent to
    the server.
  • Immediately after sending the message, the client
    then acts like the server, waiting for a reply.
  • Although the client did not request a specific
    port, the port that was automatically assigned is
    included in the outgoing message so that the
    server can successfully respond back to us.
  • See UDPClientSimple.java

52
UDP Example In Action
  • We first start the UDP server which opens the
    port and waits for the first incoming message.
  • It will wait until the program is terminated
  • Although not shown, the UDP server is running on
    a system with the name Alpha (as in the first
    Greek letter).

53
UDP Example In Action
  • The server gets up and running quickly and then
    immediately starts waiting for eternity
  • Then run the UDP client which sends a message and
    then itself waits for a reply.

54
UDP Example In Action
  • Notice that the client runs and then exits.
  • This is typical of most client-server
    communications where the client makes a request,
    receives a reply from the server and is done.

55
UDP Example In Action
  • Meanwhile, the server has recorded the incoming
    message, responded to it, and begun waiting for
    another incoming request.

56
TCP Communication
  • TCP network communication is similar to UDP but
    it fixes the flaws inherent in UDP by providing
    message delivery guarantee and concurrency.
  • TCP goes a step beyond UDP and is a stateful and
    connection-oriented protocol.
  • Stateful means that the TCP remembers what it has
    sent and ensures that it arrives in the same
    order
  • Connection-oriented means that each packet sent
    is actually part of a larger conversation, or
    stream.

57
TCP Communication
  • A TCP-based server differs from a UDP-based
    server in that a single thread does not perform
    all of the communication.
  • The usual solution to handle TCP communications
    is to create a new thread that is dedicated to
    incoming requests from a particular client.
  • A server can distinguish multiple requests from
    the multiple clients on the same client system
    because each client will be forced to use a
    different port

58
TCP Example
  • The programs for the TCP client and server are
    similar in nature although the details vary a
    bit.
  • Because TCP is stateful, we actually open up two
    streams one inbound and one outbound
  • These act like conveyor belts for data to flow
    between the client and the server.
  • From a programming standpoint, we no longer have
    to use datagrams but can simply read and write a
    simple data type or a string object.

59
TCP Server
  • For the server, the largest change is that
    additional of threads in order to maintain each
    connection as a separate conversation.
  • However, once inside of a thread, the commands
    are simply reading and writing data.
  • See TCPServer.java

60
TCP Client
  • The TCP client is very similar to the UDP client
    except that instead of sending datagrams, we hook
    up to the streams-based plumbing.
  • However, the rest of the logic is pretty much the
    same.
  • See TCPClient.java

61
TCP Example in Action
  • Set CLASSPATH first!
  • Start with the server first

62
TCP Example in Action
  • Next we invoke the TCP client to send a simple
    message.
  • We can see that the client was able to acquire a
    port to communicate out and received a reply that
    was different than what was originally sent,
    proving that something happened.

63
TCP Example in Action
  • The server first received a connection from the
    remote port of 4304 (the client).
  • It then created new clientConnection object (the
    two lines with the word setup in the brackets)
    and then went back to listening for more
    connection requests.
  • Meanwhile, the new thread was run and it picked
    up the message sent by the client and then sent
    it back with the prefix Received.

64
Remote Method Invocation (RMI)
  • Provides for communication between distributed
    objects by means of remote method invocation
  • RMI objects that can receive remote method
    invocations are called remote objects and they
    implement a remote interface
  • Is an extension of local method invocation that
    allows an object living in one process to invoke
    methods of an object living in another process

65
Middleware Layer for RMI
66
Interfaces in Distributed Systems
  • An interface specifies the procedures and
    variables that can be accessed from other modules
  • Modules are implemented so as to hide all the
    information about them except that which is
    available through its interface.
  • As long as the interface does NOT change,
    implementations may change without affecting the
    users of the module
  • In a distributed program, the modules can run in
    separate processes.
  • Cannot access the variables in a module in
    another process not direct variable access

67
Interfaces in Distributed Systems
  • Other differences
  • Parameter-passing mechanisms (i.e., call by
    value, call by reference) used in local procedure
    calls do not work in a distributed system
  • Uses input and output parameters that are passed
    between processes
  • Pointers in one process are not valid in another
    process on a remote computer
  • No pointer passing allowed

68
Remote and Local Method Invocations
69
Java RMI
  • Java RMI provides an adapter that effectively
    hides the network from us, instead allowing us to
    simply lookup functionality that we want
    (regardless of where it actually exists) and use
    it as if it was locally available.
  • The level of complexity definitely increases once
    we decide to distribute the objects in a Java
    system.
  • Assuming that we started with two Java programs,
    with one calling the other, we now introduce the
    following elements
  • an interface that explicitly states what
    functionality is remotely available
  • a server that provides access to the remote
    object
  • the RMI registry that links up requests from a
    client to a remote object

70
Overview of RMI Interfaces and Classes
71
Java RMI Example Foundation
  • We will start with two Java classes that are not
    RMI-enabled and then adapt them to operate with
    RMI so we can see exactly what changes are
    needed.
  • Let us imagine that we have devised an automated
    registration process class which, upon knowing
    which class for which we want to register, will
    tell us if we are registered or if the class is
    full.

72
AskTheRegistrar.java
public class AskTheRegistrar private String theClass public AskTheRegistrar ( String in_whichClass ) theClass in_whichClass public String getRegistrationStatus() if ( theClass.toUpperCase().indexOf( "CS483" ) gt 0 ) return "You are registered" else return "There are no positions available to be registered"
If the class includes the word CS483 (case
sensitive) then the class must have some spots
open. Otherwise, the class is full.
73
Java Application to Invoke the Functionality
LocalStudent.java
class LocalStudent public static void main( String args ) System.out.println() System.out.println( "LocalStudent running..." ) System.out.println( "--------------------------" ) System.out.println() String studentClass if ( args.length lt 1 ) studentClass "CS483" else studentClass args0 AskTheRegistrar currentRegistrationStatus new AskTheRegistrar(studentClass) System.out.println( "The registration status for " studentClass " is") System.out.println(" gt currentRegistrationStatus.getRegistrationStatus()) System.out.println() System.out.println( "--------------------------" ) System.out.println( "LocalStudent finished." )
In order to work, both classes just need to be
in a directory within the current CLASSPATH
environment variable
74
Result when run...
  • By passing the argument CS483, the
    AskTheRegistrar service concludes that the
    student is registered

75
Java RMI Example (with a server)
  • We now seek to move the AskTheRegistrar service
    to a remote server so that it can be accessed
    from multiple locations within the university.
  • The first step is to decide what functionality
    should be made available.
  • Currently, the AskTheRegistrar class has two
    member functions the constructor and
    getRegistrationStatus.
  • The constructor will not be available remotely
    and so we need to create an alternative method to
    set the location.
  • These two functions, setClass and
    getRegistrationStatus, will be available to
    remote invocation and we can now create an
    interface detailing this decision.
  • Need to enhance the object AskTheRegistrar so
    that it can be remotely used

76
RMI Server Example Sequence Diagram
77
AskTheRegistrarInterface.java
import java.rmi. public interface AskTheRegistrarInterface extends Remote public void setClass( String in_whichClass ) throws RemoteException public String getRegistrationStatus( ) throws RemoteException
Remember an interface is a contract that a class
can choose to implement so there is no actual
code in the interface itself
78
New Version of AskTheRegistrar
  • See AskTheRegistrarRemote.java
  • Imported java.rmi and java.rmi.server packages to
    enable remote invocation capability
  • Class inherits from the UnicaseRemoteObject
    parent class
  • This object means that a single instance (as
    opposed to one instance per request) of the
    AskRemoteRegistrarRemote object will be enabled
    to be called remotely
  • Provides methods outlined in the interface
  • Added an additional constructor that takes no
    arguments and sets the private theClass variable

79
RMI Registry
  • A client wishing to use a remote object will need
    to know exactly where it is located
  • RMI registry
  • Coordinated phone book that records every
    objects name and address
  • Publishes objects info in a well-known location
  • rmiregistry.exe
  • In the same directory as other java executables
  • Can be run by itself as a background process
  • We will run in its own command window

80
RMI Registry
  • RMI Registry starts off with an empty directory
  • Has no way of actually invoking any objects
  • Its only job is to provide locations to any
    program that asks (like directory assistance)

81
RMI Server Example
  • We now need a Java program similar to our UDP
    server that accepts requests for a remote object
  • This server program must also communicate to the
    RMI registry that it exists so clients can find it

82
AskTheRegistrarServer.java
import java.rmi. import java.rmi.server. class AskTheRegistrarServer public static void main ( String args ) try Naming.rebind("//localhost/AskTheRegistrar", new AskTheRegistrarRemote()) System.out.println("AskTheRegistrar Server is ready.") System.out.println() catch (Exception e) System.out.println("AskTheRegistrar Server unexpectedly quit. "Exception message " e.getMessage()) //end try //end main //end class
83
RMI Server Example
  • This seems like a very small amount of code
    compared to our previous UDP server.
  • The magic happens on a single line

. . . Naming.rebind( "//localhost/AskTheRegistrar", new AskTheRegistrarRemote() ) . . .
84
RMI Server Example
  • The rebind command is what actually informs the
    RMI registry that a remote object is now
    available for remote invocation.
  • The first argument is the remote objects name in
    the directory as well as which RMI registry will
    be informed.
  • In our example, we are contacting the registry on
    the local server (i.e. localhost).
  • If the registry was on a port other than its
    default 1098, this could be specified by placing
    a colon and the new port number directly after
    the server name.
  • The identifier after the server is the name that
    the object will be listed as in the registry.
  • This directory name does not have to be the same
    as the actual remote object.

85
RMI Server Example
  • The second argument creates the actual remote
    object that will accept requests from clients.
  • Because we are unsure of what location a client
    will specify, we invoke the no-argument version
    of the constructor which will set the internal
    location to an empty string (and thus require the
    client to specify an actual location later).
  • Most important point to heed is that in our
    non-RMI setup (previous example), each instance
    of the client application (LocationStudent)
    created its own instance of the AskTheRegistrar
    service class.
  • In the RMI version, we have a single instance of
    the AskTheRegistrar class that will be used by
    any and all clients.

86
RMI Server Example
  • Before we can run the server, we need to generate
    a stub class for the remote object that will be
    used by the server.
  • We use the rmic utility to do this.
  • Server does not exit RMI registry still has an
    open reference to it continuously available to
    any incoming requests
  • Now that we have a server, we run it from the
    command line like so

87
Client Example
  • Create a client that accesses the AskTheRegistrar
    remote object
  • Two critical lines

. . . AskTheRegistrarInterface theRegistrar (AskTheRegistrarInterface) Naming.lookup ( "//" remoteServer "/AskTheRegistrar" ) . . . System.out.println( " gt " theRegistrar.getRegistrationStatus()) . . .
88
Client Example
  • The first uses the same class, Naming, that the
    server did to contact the RMI registry.
  • In this case, we are asking the registry for the
    location of a remote object that should be known
    as AskTheRegistrar.
  • Note that what is returned is a reference to the
    interface we initially created.
  • This interface hides the fact that there is no
    code locally but simply provides some stubs that
    will make a call to the remote object to perform
    the actual work.
  • The second line uses the resulting object
    reference as if it were localwhich was our
    original intent

. . . AskTheRegistrarInterface theRegistrar (AskTheRegistrarInterface) Naming.lookup ( "//" remoteServer "/AskTheRegistrar" ) . . . System.out.println( " gt " theRegistrar.getRegistrationStatus()) . . .
89
Client Example
  • We can now see the result of running the client

90
Server Output
  • This is the activity on the server
  • Server displays the callers (client) IP address

91
Java RMI Example (with a daemon)
  • The previous example requires us to run a
    separate Java application in a server capacity to
    register and make a remote object available.
  • If we wish to make multiple objects available as
    remote objects, we will either need to run a
    separate server for each or create super-server
    that registers one of each object.
  • To solve this problem use the RMI daemon
    (background process), or rmid.
  • This one process will replace all of the other
    server processes and allow any remote object to
    be dynamically invoked
  • No adjustments to the interface or the client
    code are required.

92
Java RMI with the Daemon Sequence Diagram
93
Java RMI Example (with a daemon)
  • The remote object that we created in
    AskTheRegistrarRemote last time needs to be
    modified to inherit from a different, but related
    objectthe Activatable object (which implies that
    the remote object may be activated on demand).
  • For clarity, we will rename the class
    AskTheRegistrarRemote to AskTheRegistrarActivation
    .

94
import java.rmi. import java.rmi.server. import java.rmi.activation. public class AskTheRegistrarActivation extends Activatable implements AskTheRegistrarInterface private String theClass // This constructor (which was not required when // we used the server-based form of RMI) will // be automatically called by the RMI daemon. // public AskTheRegistrarActivation( ActivationID id, MarshalledObject data ) throws RemoteException // Register the object with the activation system // then export it on an anonymous port // super(id, 0) // Here is our additional code. theClass "(No class set)" . . .
AskTheRegistrarActivation.java
95
Java RMI Example (with a daemon)
  • Instead of inheriting from UnicastRemoteObject,
    the remote object now inherits from Activatable.
  • Both of the constructors that previously existed
    have been removed and replaced with one that has
    two arguments Activation ID MarshalledObject
  • Any initialization code we need is placed after
    the parent constructor is called. Other than
    those changes, the code for the remote object is
    the same.
  • What has changed the most is that instead of a
    server process, we only need to register the
    object as available for remote invocation and
    then create a stub for use with the new daemon
    process.

96
Java RMI Example (with a daemon)Server
Application
  • See AskTheRegistrarRMIDSetup.java
  • The server application has undergone some
    dramatic change.
  • The first statement inside the main class
    provides the first hint of the alterations.
  • We are now operating with enhanced security
    restrictions that we will need to alter in order
    for our remote object to accept any connections
    (a remote object that communicates with nobody is
    not very useful).

97
Java RMI Example (with a daemon)Server
Application
  • To accomplish these alterations, we need a
    security manager to be available like so

. . . System.setSecurityManager( new RMISecurityManager()) . . .
98
Java RMI Example (with a daemon)Server
Application
  • Next, we need to associate a security policy file
    with the remote object when it is activated.
  • The policy file simply states that the remote
    object is allowed to accept connections via the
    network from any address as long as the
    originating port is unprivileged (i.e. above
    1023).
  • It should be noted that although the policy file
    kind of looks like Java code, it is a
    configuration file and not compiled it remains a
    text file called AskTheRegistrarActivation.policy

grant // This allows the remote AskTheRegistrar object to accept // incoming connections from anywhere, as long as it is on // an unprivileged port (which is normally the case). // permission java.net.SocketPermission "1024-", "accept"
99
Java RMI Example (with a daemon)
  • The RMI registry is still operating as it was
    previously therefore it must be run first of all
    the server-based processes.
  • The RMI daemon must be run next.
  • However, it will default to being very
    restrictive with any of the remote objects that
    will be registered with it as available to be
    activated.
  • So, we must define a security policy for the RMI
    daemon itself that allows future remote objects
    to be allowed to register their own security
    policy.
  • This could potentially open the door for
    arbitrary permissions which is why this step is
    explicitly required.

100
Java RMI Example (with a daemon)
  • Our security policy will look like the following
    RMID.policy
  • This policy has only one purpose future remote
    objects that will be registered may use the
    security policy located in a file
    Z\CS483\AskTheRegistrarActivation.policy. Any
    other request for elevated permissions will be
    expressly denied.

grant // This allows the remote AskTheRegistrar object to // request the security policy in the file // Z\CS483\AskTheRegistrar.policy. // If this is not allowed, then the remote AskTheRegistrar // object will either not be allowed to registered, or // will be registered with no ability to make network // connections. // permission com.sun.rmi.rmid.ExecOptionPermission "-Djava.security.policyZ/CS483/AskTheRegistrarActivation.policy"
101
Run the daemon
  • By default, the RMI daemon uses a security policy
    of none (which is like selling a padlock with
    no key) so we must change this when running the
    daemon process.
  • Start the daemon

Cgt JAVAHOME\rmid J-Djava.security.policyRMID.policy
102
Java RMI Example (with a daemon)
  • Next, we must register the AskTheRegistrar remote
    object with the daemon and registry.
  • The registration program itself needs permission
    to contact both the daemon and the registry.
  • Here is its policy file

grant // This allows the AskTheRegistrar setup to connect to // the RMI registry. // permission java.net.SocketPermission "Alpha1098", "connect" // This allows the AskTheRegistrar setup to connect to // the RMI daemon (background process). // permission java.net.SocketPermission "Alpha1099", "connect"
103
Java RMI Example (with a daemon)
  • Assuming that the remote AskTheRegistrar object
    will reside on the server known as Alpha, the
    policy file allows the setup program to contact
    the registry on the default port 1098 and the
    daemon on the default port of 1099
  • If the registration succeeds like we sincerely
    hope it will, we should get two status messages

Cgt java -Djava.security.policyAskTheRegistrarRMIDSetup.policy AskTheRegistrarRMIDSetup
104
Java RMI Example (with a daemon)
  • It is worthwhile to note here that the remote
    object, AskTheRegistrarActivation, has not yet
    been instantiated and will remain so until the
    first request.
  • This is one of the main benefits of the daemon
    implementation in that it conserves resources
    until they are required.

105
Java RMI Example (with a daemon)
  • We need to make two more adjustments.
  • First, we need to provide the client with a
    stub copy of the remote object (in addition to
    the compiled interface definition).
  • After compiling the remote object (which is
    AskTheRegistrarActivation in our example), we
    employ the remote invocation compiler to whittle
    it down to just a stub.

Cgt JAVAHOME\rmic AskTheRegistrarActivation
106
Java RMI Example (with a daemon)
  • This will produce a file named AskTheRegistrarActi
    vation_stub.class that needs to be distributed
    with the client application (in addition to the
    AskTheRegistrarInterface.class and
    LocalStudentClient.class files).
  • Secondly, while the client is unchanged, it now
    requires a security policy file in order to
    access the RMI daemon and registry

grant // This allows the local client permission to use the network // and make outbound connections to the "Alpha" server on any // unprivileged port. // permission java.net.SocketPermission "Alpha1024-", "connect,resolve"
107
Java RMI Example (with a daemon)
  • The policy file for the client says that
    connections may be made to any non-privileged
    port on the server that contains the remote
    object.
  • When executing the client application, we now
    need to include a reference to the security
    policy file.

Cgt java -Djava.security.policyLocalStudentClient.policy LocalStudentClient Alpha "CS483"
108
Executed Client Applicationwith Reference to
Policy File
109
LocalStudent Client
  • Our invocation of a remote object is now
    functional again!
  • That was certainly a lot of work just to learn
    that we are registered for CS483.
  • If we look back at the RMI daemon, we note that
    the status messages are displayed, with some
    extra logging information about execution groups
    (which we did not cover).

110
RMI Daemon
  • Again, the benefit to this setup is that we can
    run with just the daemon and dynamically register
    objects with the daemon and the object will be
    immediately available for use by clients.

111
Java RMI Resources
  • http//java.sun.com/docs/books/tutorial/rmi/index.
    html
  • http//java.sun.com/j2se/1.5.0/docs/guide/rmi/inde
    x.html
  • http//java.sun.com/j2se/1.5.0/docs/guide/rmi/spec
    /rmiTOC.html
  • http//java.sun.com/j2se/1.5.0/docs/tooldocs/windo
    ws/rmic.html
Write a Comment
User Comments (0)
About PowerShow.com