1. RMI Packages Overview java.rmi java.rmi.server java.rmi.registry
General RMI classes and exceptions.
java.rmi.server
RMI server-specific classes and interfaces.
java.rmi.registry
To access, launch, and locate RMI registries.
java.rmi.activation
To start remote services on demand.
java.rmi.dgc
To support distributed object garbage collection.
Netprog Java RMI

2. java.rmi Package Remote interface RemoteException class
To identify a service as remotely accessible.
RemoteException class
java.io.IOException subclass, superclass of most RMI exceptions.
Netprog Java RMI

3. java.rmi Package Naming class
Static methods to assign or retrieve object references of the RMI object registry (rmiregistry).
bind(String url, Remote obj)
Inserts a registry entry and binds it to given obj.
rebind(String url, Remote obj)
Does not throw AlreadyBoundException.
Remote lookup(String url)
Returns a reference for the remote object
Also unbind(url), list(url)
Netprog Java RMI

4. java.rmi Exceptions ServerError class ServerException class
An error in the RMI server was thrown (e.g. out of memory)
ServerException class
When a method call to an RMI server throws a RemoteException, a ServerException is thrown.
UnexpectedException class
Used by clients to represent an exception thrown by the remote method but not declared in the RMI interface.
Netprog Java RMI

5. java.rmi Exceptions AccessException class AlreadyBoundException class
Thrown by naming to indicate that a registry operation cannot be performed.
AlreadyBoundException class
A remote object is already bound to a registry entry.
ConnectException class
Inability to connect to a remote service, such as a registry.
NotBoundException class
Attempts to lookup or unbind a non-existent registry entry.
Netprog Java RMI

6. java.rmi Exceptions UnknownHostException class
A client making a remote method request can’t resolve the hostname.
StubNotFoundException class
Stub not in local file system or externally (if using dynamic class loading).
ConnectIOException class
Inability to connect to a remote service to execute a remote method call.
Netprog Java RMI

7. REMOTE METHOD INVOCATION – 6 STEPS
Create the remote interface
Provide the implementation of the remote interface
Compile the implementation class and create the stub and skeleton objects using the rmic tool
Start the registry service by rmiregistry tool
Create and start the remote application
Create and start the client application

8. create the remote interface
For creating the remote interface, extend the Remote interface and declare the RemoteException with all the methods of the remote interface. Here, we are creating a remote interface that extends the Remote interface. There is only one method named add() and it declares RemoteException.
import java.rmi.*;  
public interface Adder extends Remote{  
public int add(int x,int y)throws RemoteException;  
}  

9. Provide the implementation of the remote interface
For providing the implementation of the Remote interface, we need to Either extend the UnicastRemoteObject class,or use the exportObject() method of the UnicastRemoteObject class
In case, you extend the UnicastRemoteObject class, you must define a constructor that declares RemoteException.
import java.rmi.*;  
import java.rmi.server.*;  
public class AdderRemote extends UnicastRemoteObject implements Adder{  
AdderRemote()throws RemoteException{  

10. 3) Create the stub and skeleton objects using the rmic tool.
rmic AdderRemote  
4) Start the registry service by the rmiregistry tool
Start rmiregistry

11. ACTIVATION MODELS
Object activation is a mechanism for providing persistent references to objects and managing the execution of object implementations
When an activatable remote object is accessed (via a method invocation) if that remote object is not currently executing, the system initiates the object's execution inside an appropriate JVM
Active object is a remote object that is instantiated and exported in a JVM on some system.
A passive object is one that is not yet instantiated (or exported)in a JVM, but which can be brought into an active state.
Transforming a passive object into anactive objectis a process known as activation.

12. Activation Protocol
In order to make a remote object that can be accessed via an activation identifier over time, a developer needs to:register an activation descriptor for the remote object, and include a special constructor in the object's class that the RMI system calls when it activates the activatable object
The ActivationDesc Class
The ActivationID Class
The Activatable Class
Activatable Class Methods
Constructing an Activatable Remote Object
Registering an Activation Descriptor Without Creating the Object

15. RMI CUSTOM SOCKETS
Custom socket factories can be used to control how remote method invocations are communicated at the network level. For example, they can be used to set socket options, control address binding, control connection establishment (such as to require authentication), and to control data encoding (such as to add encryption or compression).
When a remote object is exported, such as with the constructors or exportObject methods of java.rmi.server.UnicastRemoteObject  or java.rmi.activation.Activatable, then it is possible to specify a custom client socket factory (ajava.rmi.server.RMIClientSocketFactory instance) and a custom server socket factory (a java.rmi.server.RMIServerSocketFactory instance) to be used when communicating remote invocations for that remote object.

16. A client socket factory controls the creation of sockets used to initiate remote invocations and thus can be used to control how connections are established and the type of socket to use. A server socket factory controls the creation of server sockets used to receive remote invocations and thus can be used to control how incoming connections are listened for and accepted as well as the type of sockets to use for incoming connections.

17. Implementing a Custom Socket Factory
Below are three steps for implementing a pair of custom socket factory classes:
Implement a custom ServerSocket and Socket.
Implement a custom RMIClientSocketFactory.
Implement a custom RMIServerSocketFactory.

18. Object Serialization
To serialize an object means to convert its state to a byte stream so that the byte stream can be reverted back into a copy of the object. A Java object is serializableif its class or any of its superclasses implements either the java.io.Serializableinterface or its subinterface, java.io.Externalizable.

20. java.io.Serializable interface
Serializable is a marker interface (has no data member and method). It is used to "mark" java classes so that objects of these classes may get certain capability. It must be implemented by the class whose object you want to persist.
The String class and all the wrapper classes implements java.io.Serializable interface by default.

21. ObjectOutputStream class
The ObjectOutputStream class is used to write primitive data types and Java objects to an OutputStream. Only objects that support the java.io.Serializable interface can be written to streams.
Important Methods
Method
Description
1) public final void writeObject(Object obj) throws IOException {}
writes the specified object to the ObjectOutputStream.
2) public void flush() throws IOException {}
flushes the current output stream.
3) public void close() throws IOException {}
closes the current output stream.

22. import java.io.Serializable;  
public class Student implements Serializable{  
 int id;  
 String name;  
 public Student(int id, String name) {  
  this.id = id;  
  this.name = name;  
 }  
}  

23. import java.io.*; class Persist{ public static void main(String args[])throws Exception{ Student s1 =new Student(211,"ravi"); FileOutputStream fout=new FileOutputStream("f.txt"); ObjectOutputStream out=new ObjectOutputStream(fout); out.writeObject(s1); out.flush(); System.out.println("success"); } }

24. COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA)
Common Object Request Broker Architecture (CORBA) is the communication infrastructure for creating distributed remote objects between client and remote server machine.
CORBA is a standard that enables an object written in one programming language, running on one platform to interact with objects across the network that are written in other programming languages and running on other platforms.
For example, a client object written in Java programming and running under Windows can communicate with an object on a remote machine written in C++ programming running under Linux platforms
The CORBA is a standard framework allowing software (C++,Java,Python, PHP programmings) objects to communicate with one another, no matter where they are located or who has designed them

25. The Object Request Broker (ORB) is the "middleware" (its like intermediary) which performs the communication. Objects (services) may reside on the same computer, or different computers connected by a network.
An Portable Object Adapter (POA) assists an Object Request Broker (ORB) in delivering client requests to server object implementations (servants).

26. CORBA ARCHITECTURE With IDL Technology

28. CORBA COMPONENTS: Object Implementation
defines operations that implement a CORBA IDL interface. It can be written in various languages including C, C++, Java, etc.
Client
the program entity that invokes an operation on an object implementation
Object Request Broker (ORB)
 provides a mechanism for transparently communicating client requests to target object implementations 
makes client requests appear to be local procedure calls
ORB Interface
provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface

29. CORBA COMPONENTS CORBA IDL Stubs & Skeletons
the static interface between client and server
generated by an IDL compiler
Dynamic Invocation Interface (DII)
allows a client to directly access the underlying request mechanisms provided by an ORB.
Dynamic Skeleton Interface (DSI)
allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing
Interface Repository
a run-time database that contains machine-readable versions of the IDL-defined interfaces
Implementation Repository
a run-time repository of information about the classes a server supports, the objects that are instantiated, and their IDs

30. CORBA Naming Services
Naming Service is the principal mechanism used in distributed systems.
File system used file name as reference to access a file.
CORBA clients can use object names which reference objects in remote machine.
The Naming Service allows clients to find objects by looking up the corresponding names.
A server that holds a CORBA object binds a name to the object by contacting the Naming Service.
The Naming Service maintains a database of names and the objects associated with them.

32. The Persistent Naming Service provides persistence for naming contexts
The Persistent Naming Service provides persistence for naming contexts. This means that this information is persistent across service shutdowns and startups, and is recoverable in the event of a service failure. If ORBD is restarted, the Persistent Naming Service will restore the naming context graph, so that the binding of all clients'and servers' names remains intact (persistent).
Transient Naming Service shipped with older versions of the JDK, is also included in this release of J2SE. A transient naming service retains naming contexts as long as it is running. If there is a service interruption, the naming context graph is lost.

33. CORBA Programming Models
The CORBA programming model describes the artifacts that you develop and implement to enable client applications to interact with server applications in a CORBA environment
The CORBA programming model, as a distributed-object programming model.
Objects
Communications protocol
Object references
Naming service

34. CORBA PROGRAMMING MODEL

35. JAR FILE CREATION
The Java™ Archive (JAR) file format enables you to bundle multiple files into a single archive file.
The JAR file format provides many benefits:
Security: You can digitally sign the contents of a JAR file.
 Decreased download time: If your applet is bundled in a JAR file, the applet's class files and associated resources can be downloaded to a browser in a single HTTP transaction without the need for opening a new connection for each file.
 Compression: The JAR format allows you to compress your files for efficient storage.  
Packaging for extensions: The extensions framework provides a means by which you can add functionality to the Java core platform
 Package Sealing: Packages stored in JAR files can be optionally sealed so that the package can enforce version consistency.
 Package Versioning: A JAR file can hold data about the files it contains, such as
vendor and version information.
Portability: The mechanism for handling JAR files is a standard part of the Java platform's core API.

36. Common JAR file operations