Download Document

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
RMI Packages Overview
• java.rmi
– 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 2002 Java RMI
1
java.rmi Package
• Remote interface
– To identify a service as remotely accessible.
• RemoteException class
– java.io.IOException subclass, superclass of most
RMI exceptions.
Netprog 2002 Java RMI
2
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 2002 Java RMI
3
java.rmi Exceptions
• ServerError 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 2002 Java RMI
4
java.rmi Exceptions
• AccessException 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 2002 Java RMI
5
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 2002 Java RMI
6
REMOTE METHOD INVOCATION – 6 STEPS
1. Create the remote interface
2. Provide the implementation of the remote
interface
3. Compile the implementation class and create
the stub and skeleton objects using the rmic
tool
4. Start the registry service by rmiregistry tool
5. Create and start the remote application
6. Create and start the client application
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;
}
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 imple
ments Adder{
AdderRemote()throws RemoteException{
3) Create the stub and skeleton objects using
the rmic tool.
• rmic AdderRemote
4) Start the registry service by the rmiregistry
tool
Start rmiregistry
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.
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
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.Act
ivatable, 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.
• 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.
• 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.
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.
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.
ObjectOutputStream class
• The ObjectOutputStream class is used to write
primitive data types and Java objects to an
Important Methods
Method
Description
OutputStream. Only objects that support the
1)
public
final
void writes the specified object to the
java.io.Serializable
interface
can be written to
writeObject(Object
obj) throws
ObjectOutputStream.
IOException {}
streams.
2) public void flush() throws flushes the current output stream.
IOException {}
3) public void
IOException {}
close()
throws closes the current output stream.
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;
}
}
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"); } }
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
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).
CORBA ARCHITECTURE With IDL Technology
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
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 IDLdefined interfaces
• Implementation Repository
• a run-time repository of information about the classes a server supports,
the objects that are instantiated, and their IDs
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.
• 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.
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
CORBA PROGRAMMING MODEL
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.
Common JAR file operations