Transcript RMI-IIOP and Object Serialization

Middleware Technology (J2EE/EJB)
RMI-IIOP/JNDI
Distributed Objects
• EJB components are based on distributed objects. A distributed object can be
called from an in-process client, an out-of-process client, or a client located
elsewhere on the network.
• Three different technologies
 OMG’s CORBA (Common Object Request Broker Architecture)
 Microsoft’s DCOM
 Sun’s Java RMI-IIOP
2
Distributed Object
3
Client
Server
network
Stub
Skeleton
Servant
Object
Reference
Client and server are collocated in different address space.
4
Client and Server
Proxy
Object
Reference
Servant
Client and server are collocated in the same address space.
Location Transparency
No changes to the source code are necessary in either client or
server.
5
Distributed Objects and Middleware
• Explicit Middleware
(transaction, security, etc.)
Difficult to write
Difficult to maintain
Difficult to support
6
Explicit Middleware (gained through API)
7
Distributed Objects and Middleware
• Implicit Middleware (Recommended)
JTS
Instead of writing any code to middleware APIs, you declare what you need in a
simple text file. The request interceptor provide the middleware logic for you
transparently
8
Implicit Middleware (gained through declaration)
9
RMI-IIOP and JNDI
• EJB technology depends on Java RMI-IIOP and Java Naming and
Directory Interface (JNDI)
• Your J2EE server implementation should ship with RMI-IIOP and JNDI
implementations. It is generally a bad idea to mix and match
implementations, like combining Sun’s RMI-IIOP packages with BEA’s
JNDI implementations.
• RMI-IIOP (RMI over Internet Inter-ORB Protocol) allows you to write
distributed objects in Java, enabling objects to communicate in memory,
across JVM, and across physical devices.
RMI
RMI-IIOP
java.rmi package
java.rmi, javax.rmi package
10
Remote Method Invocations
• Compared to RPC (Remote Procedure Call), RMI-IIOP yields the
benefits of an object-oriented programming, such as inheritance,
encapsulation and polymorphism.
PRC: Inter-Process Communication
RMI-IIOP: Distributed Object Communication, platformindependent
• Remote Method Invocation
 Marshalling and Unmarshalling
 Parameter passing conventions (pass-by-value or pass-byreference)
 Network or machine instability
A crash of a single JVM should not cause the distributed system to
grind to a halt. (RemoteException)
(See also: Figure A.1 page 494)
11
12
The Remote Interface
• In RMI-IIOP, all networking code you write is applied to interfaces, not
implementations. You can operate solely on the interface to that object’s class.
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface IPKGenerator extends Remote {
public long generate() throws RemoteException;
}
interface f1 {}
class c1 implements f1 {}
f1 ff = new c1(); //upcasting, safety
13
The Remote Object Implementation
• To make your object a remote object available to be invoked on by
remote hosts, you remote class must perform one of the following
steps:
 Extend the class javax.rmi.PortableRemoteObject (In the sample, we use RMI,
so the super class is changed to java.rmi.UnicastRemoteObject)
 Don’t extend javax.rmi.PortableRemoteObject. To export your object, call
javax.rmi.PortableRemoteObject.exportObject(). (*)
• Running the sample IPKGenerator
RMI_PKGenerator/readme.txt
14
15
Object Serialization and Parameter Passing
• Pass-by-value
When invoking a method using RMI-IIOP, all parameters are copied
from client to server.
If you are trying to pass an object over the network and that object
contains reference to other objects, how are those references resolved
on the target machine? *
• Object Serialization
RMI-IIOP uses object serialization to send parameters over the
network. Serialization is the conversion of a Java object into a bit-blob
representation of that object.
writeObject: Serialization
readObject: Deserialization (bit-blob back into a object)
You can provide your own custom serialization by implementing the
methods above, such as some sort of compression
16
Rules for serialization
• The rules are effective to member variables held in serialized
objects
17
Object Serialization
• When you pass a object as a parameter, if the object contains nontransient sub-objects, the object serialization process will be
repeated recursively for every object until the entire reference graph
of objects is serialized.
18
Why Transient
• The object is very large, which may not be suitable for serialization. Object
serialization is a heavyweight operation for large graphs of objects. *
• The object represents a resource that cannot be reconstructed on the target
machine. (database connection)
• The object represents sensitive information that you do not want to pass in a
serialized stream.
19
Object Serialization and RMI-IIOP
• RMI-IIOP relies on object serialization for passing parameters via
remote method invocations.
• pass-by-reference
RMI-IIOP simulates a pass-by-reference convention, which means
the arguments are not copied over. If you want to pass a parameter
by reference, the parameter must itself be a remote object.
Running sample RMI and RMI-IIOP
RMI/readme.txt
RMI-IIOP/readme.txt
20
Remote Object
pass-by-reference
RMI demo
21
RMI-IIOP demo
22
RMI-IIOP and Object
Serialization
23
Remote Object and Pass
by Reference
24
Java Naming and Directory Interface
• JNDI is the standard way of looking things up over the network. JNDI is used
in EJB, RMI-IIOP, JDBC, and more.
• You can use JNDI to locate a printer on your intranet. You can also use it to
locate a Java object or to connect with a database.
• JNDI is a J2EE API that provides a standard interface for locating users,
machines, networks, objects, and services.
25
Naming Service
• A naming service is analogous to a telephone operator. P506
• A naming service performs the following tasks:
 It associates names with objects. (bind)
 It provides a facility to find an object based on a name. (lookup)
– Examples of naming services
DNS (Domain Name System): translating a machine name to
an IP address
File System: translating a filename into an actual file of data
26
Directory Service
• A directory object differs from a generic object because you can store attributes
with directory objects. (API:javax.naming)
• You can use a directory object to represent a user and store information about that
user, such as login name, password, email address, phone number, and postal
address, etc.
• A directory service is a naming service that has been enhanced and extended to
provide directory object operations for manipulating attributes.
• Examples: Netscape Directory Server, Microsoft Active Directory
27
A Hierarchical Directory Structure
• The directory’s contents-the set of connected directory objects-usually forms a
hierarchical tree-like structure.
• Benefits of JNDI (4 items)
• In J2EE, you can use JNDI for many purposes.
28
JNDI Architecture
• JNDI is made up of two halves: the client API and the Service Provider Interface
(SPI).
• The client API allows your Java code to perform directory operations. This API is
uniform for all types of directories. (similar to JDBC’API)
• The JNDI SPI is an interface to which naming and directory service vendors can
plug in. The SPI allows naming and directory service vendors to fit their
particular proprietary protocols into the system.
29
JNDI Architecture
LDAP: Lightweight Directory Access Protocol
NIS: Network Information System
NDS: Novell’s Network Directory System *
30
JNDI Concepts
•
Atomic Name
simple, basic, indivisible component of a name
For example, in the string /etc/fstab, etc and fstab are atomic names.
•
Compound Name
zero or more atomic names put together
In the previous example, the entire string /etc/fstab is a component name.
•
Binding
an association of a name with an object
/etc/fstab consists of multiple bindings, one to etc, one to fstab
•
Context containing zero or more bindings. Each binding has a distinct atomic
name. For an instance, /usr/bin, /usr/local (in UNIX), /usr folder is a context
which contains two distinct atomic names, bin and local. Each of these atomic
names is bound to a subfolder, we can call them subcontext in JNDI terms.
31
Naming System, Namespace, and Composite Name
• Naming System
A naming system is a connected set of contexts. Each naming
system has a different syntax for accessing contexts.
For example, in an LDAP tree, a compound name is identified
by a string such as:
cn=Ed Roman, ou=People, o=Middleware-Company.com,
c=us
whereas a file system compound name might look like
c:\java\lib\tools.jar.
32
Naming System, Namespace, and Composite Name
• Namespace
A namespace is all the names contained within naming system.
• Composite Name
A composite name is a name that spans multiple naming system.
http://java.sun.com/products/J2SDK
Schema-id namespace
DNS namespace
File System namespace
33
Initial Context Factory
• The starting point of exploring a namespace is called an initial context. An initial
context is a starting point for performing all naming and directory operations.
• To acquire an initial context, you use an initial context factory. An initial context
factory basically is your JNDI driver, such as LDAP initial context factory, file
system initial context factory, and others. These initial context factories know the
specific semantics of a particular directory structure.
Demo: InitCtx/readme.txt
34
Example of a Composite Name
35