1. Middleware Technology (J2EE/EJB) RMI-IIOP/JNDI

2. 2 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

3. 3 Distributed Object

4. 4 Client Object Reference Stub Servant Skeleton Server network Client and server are collocated in different address space.

5. 5 Client and Server Object Reference Proxy 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.

6. 6 Distributed Objects and Middleware Explicit Middleware (transaction, security, etc.)  Difficult to write  Difficult to maintain  Difficult to support

7. 7 Explicit Middleware (gained through API)

8. 8 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

9. 9 Implicit Middleware (gained through declaration)

10. 10 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 java.rmi package RMI-IIOP java.rmi, javax.rmi package

11. 11 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, platform- independent Remote Method Invocation  Marshalling and Unmarshalling  Parameter passing conventions (pass-by-value or pass-by- reference)  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)

12. 12

13. 13 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

14. 14 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

15. 15

16. 16 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

17. 17 Rules for serialization The rules are effective to member variables held in serialized objects

18. 18 Object Serialization When you pass a object as a parameter, if the object contains non- transient sub-objects, the object serialization process will be repeated recursively for every object until the entire reference graph of objects is serialized.

19. 19 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.

20. 20 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.txtRMI-IIOP/readme.txt

21. 21 Remote Object pass-by-reference RMI demo

22. 22 RMI-IIOP demo

23. 23 RMI-IIOP and Object Serialization

24. 24 Remote Object and Pass by Reference

25. 25 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.

26. 26 Naming Service A naming service is analogous to a telephone operator. P 506 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

27. 27 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

28. 28 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.

29. 29 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.

30. 30 JNDI Architecture LDAP: Lightweight Directory Access Protocol NIS: Network Information System NDS: Novell ’ s Network Directory System *

31. 31 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.

32. 32 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.

33. 33 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 namespaceDNS namespaceFile System namespace

34. 34 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.txtInitCtx/readme.txt

35. 35 Example of a Composite Name