Jini: A Java SOA that rocks

Jini in action

Jini in action details

• · Remote object is exported on the server side
  (Produces a proxy to the remote object)
• · Client side obtains the proxy somehow (RMI Registry, Jini Lookup Service, UDDI, etc.)
  (Code may be downloaded in the process)
• · Execution of the call is initiated on the client side
• · Communication between client and server occurs
• · Execution of the call occurs on the server side

Lookup discovery and join

Service discovery

Client and service interaction

• Code downloaded into the client side ... but client only knows about service's public interface
• Execution is initiated on the client side
• Execution occurs on the service side

Support Services

• Jini objects are moved in ``marshalled'' form
• Class files may need to follow these for proper activation
• The class files may need to be available from HTTP servers
• Security permissions will need to be set using JDK 1.2 security model

Non-distributed Application

Distributed Version

Client Structure

Internally a client will look like

Server Structure

SIMPLE SYSTEM

Jini Converter Service

• This shows a Jini version of the Converter service
• It is as minimal as possible!
• Some poor practises are used, like throwing exceptions out to the main process

Jini Service Specification

Jini Service Implementation

Jini Server

Jini Client

Jini Environment

• There must be a Jini lookup service running to act as the "billboard"
• The Jini distribution contains one, called reggie
• An HTTP server should be running, to deliver class files
• The converter server runs with one set of class files
  • Converter
  • ConverterImpl
  • Server
• The converter client runs with another set of class files
  • Converter
  • Client
• These files should be on the HTTP server so that clients can find the class definitions
  • Converter
  • ConverterImpl

SECURITY

JDK 1.2 Security

• Jini security uses the security model of JDK 1.2, with no changes or extensions
• Security is based on granting permissions (access rights), in security files
• Debug the application with a slack policy

  
        grant {
            permission java.security.AllPermission "", "";
        };
        

• Leave it like this of production only at your peril

Service requirements

grant {
    permission net.jini.discovery.DiscoveryPermission "*";
    // multicast request address
    permission java.net.SocketPermission "224.0.1.85", "connect,accept";
    // multicast announcement address
    permission java.net.SocketPermission "224.0.1.84", "connect,accept";

    // RMI connections
    permission java.net.SocketPermission "*.dstc.edu.au:1024-", "connect,accept";
    permission java.net.SocketPermission "130.102.176.249:1024-", "connect,accept";
    permission java.net.SocketPermission "127.0.0.1:1024-", "connect,accept";

    // reading parameters
    // like net.jini.discovery.debug!
    permission java.util.PropertyPermission "net.jini.discovery.*", "read";
};

Client requirements

Client policy

grant {
    permission net.jini.discovery.DiscoveryPermission "*";

    // multicast request address
    permission java.net.SocketPermission "224.0.1.85", "connect,accept";
    // multicast announcement address
    permission java.net.SocketPermission "224.0.1.84", "connect,accept";

    // RMI connections
    permission java.net.SocketPermission "127.0.0.1:1024-", "connect,accept";
    permission java.net.SocketPermission "*.dstc.edu.au:1024-", "connect,accept";
    permission java.net.SocketPermission "130.102.176.249:1024-", "connect,accept";

    // DANGER
    // HTTP connections - this is where external code may come in - careful!!!
    permission java.net.SocketPermission "127.0.0.1:80", "connect,accept";
    permission java.net.SocketPermission "*.dstc.edu.au:80", "connect,accept";

    // reading parameters
    // like net.jini.discovery.debug!
    permission java.util.PropertyPermission "net.jini.discovery.*", "read";

};

Variations

• If the implementation implements Serializable and the implementation itself is advertised, then a copy of the service is run on the client
• Same as above, but the copy communicates to a third party service by e.g. SOAP

URLs