01 An Introduction To J2ee

An Introduction To j2EE There is a great demand for experienced J2EE professionals now in the market and students and programmers from other languages want to know whether J2EE is Java atall or something else. This tutorial is a conceptual presentation of what & why of J2EE. (It is better for aspiring Java professionals to be forewarned that the Industry expects sound knowledge of EJB, JAX and Struts ..as well as hands on experience in Application servers like WebLogic /WebSphere as a MINIMUM! .It is also important to remember that jdk1.4 is the current version with a lot of new features and jdk1.5 is expected shortly. Moreover, Security in computing is assuming great importance and the candidate should have sound knowledge about java security.) J2EE is not the Java , that comprises of topics like Applets, Console- mode programs, Standalone GUI, Multithreading, Graphics,Exception-handling, String processing, IO Streams, Java Beans in BDK, Swing etc.( topics covered in great detail by books on Core Java , such as 'Java2 -complete reference' by Schildt.,with not a word anywhere on that staple of Computing world of any type (ie) DataBase access!) The title of the book was appropriate some 7 years back! That is why we are puzzled and dismayed that the Java that we studied so 'completely' is so basic and so incomplete!..To be fair, even with the arrival of jdk1.1,some authors like Bill McCarty ('Java ..Distributed Objects') and Jaworsky ('Java2 Unleashed') had a better perspective about the Enterprise potential & orientation of Java and wrote accordingly. However, they are being mentioned only now in curricular circles. after what they wrote so well has sadly become , partly outpaced..This is not to say that Core Java is useless. As the name suggests, it is the core and absolutely essential . But, Java has always been a language for the Web and Enterprise. Without that essential paradigm shift from desktop/LAN to the sprawling WEB & huge enterprise data, it is very difficult to appreciate the modern trends and why there is so much clamour for J2EE (despite the supposed challenge from DotNet). The only topics that could bridge the Core and Enterprise Java are Sockets & Beans. (Among web-professionals, there is a fancy for JavaScript, which is mostly used in Client-side webpages ..It's only use should be 'client-side' validation and no gymnastics. JavaScript is in no way connected with Java . It is unfortunate that this 'script' originally known as 'Live Script' from Netscape , got mixed up with Java . When any one talks about Java Script in the same breath as Java, he is missing Enterprise Java, the true essence of Java language. For aspiring J2EE professionals, ' the less javascript, the better' should be the motto.). We will begin with what Javabean is and also see how beans can be used in Socket programming. Then we will bring out the difference between invoking the method on a bean in a remote server by passing arguments & the Distributed Object paradigm. We will also explain why Distributed Object Technology is not just Client-server or Web-

server technology and why it is superior. Finally, we will see why Distributed Object Technologies like EJB ,CORBA & DCOM were found to be wanting in true interoperability and how the problem is being sought to be tackled by the latest approach (ie) XML WEBSERVICE. This, however, is pretty long journey and this 'short' tutorial cannot cover all the details. The readers are equested to refer to the books mentioned towards the end to get more details. J2EE ( Java 2 -Enterprise Edition) is a basket of 12 inter-related technologies , which can be grouped as follows for convenience.: Group-1 (Web-Server & support Technologies ) ===================================== 1) JDBC ( Java Database Connectivity) 2) Servlets 3) JSP

(Java Server Pages)

4) Java Mail Group-2 ( Distributed-Objects Technologies) ===================================== 5) RMI

(Remote Method Invocation)

6) Corba-IDL ( Corba-using Java with OMG-IDL) 7) RMI-IIOP 8) EJB

(Corba in Java without OMG-IDL) (Enterprise Java Beans)

Group-3 ( Supporting & Advanced Enterprise technologies) ============================================= 9) JNDI

( Java Naming & Directory Interfaces)

10) JMS

( Java Messaging Service)

11) JAVA-XML ( such as JAXP, JAXM, JAXR, JAX-RPC, JAXB, and XML-WEB SERVICE) 12) Connectors ( for ERP and Legacy systems).

J2EE is essentially about Distributed Objects Technology, which is defined as invoking a method on an object residing in a remote machine as if it were local to the invoking program. The Distributed Object may be based on RMI or IDL or RMI-IIOP or EJB. The invoking program can be a standalone mode java program. But , if this were so, it presents two problems. The first problem is that it requires JDK to have been installed in each end-user's machine.This is not a correct assumption because, the only thing that we can be sure of is that the end-user has a browser. Secondly, even with JDK installed in the end-user machine, the java program has to be distributed to each client personally.. This is hardly a practical proposition, if we want our program to be useful to lakhs of end-users out there. Applets, are a possible solution. An applet is a java class file embedded in HTML document, downloaded from the web server and executed in the end-user's browser.( The browser should be java-enabled). With built-in sandbox security, Applets made program distribution very easy and elegant. However, Applets also had two problems. First, standard browsers like InternetExplorer(Microsoft) and NetscapeNavigator (NetscapeCorporation) did not implement JDK fully. This required a java-plug in from Sun.This was clumsy. Secondly, java applets, except in very simple cases, downloaded the classes from the server and though this is a remarkably powerful feature, it also meant that the process was a heavy one and entailed delay in downloading. For these reasons, Applets also ceased to be the recommended method. That is why Sun developed the Servlets technology. Servlets are java class files , execeuted in server and the resulting html sent to the end-user's browser. Now, at one stroke , it solved many problems. 1) We no longer had to instal JDK in end-user's machine. 2) We need not have a java-enabled browser at the user's end. 3) As the result was sent as html only to the browser, it is lightweight & very fast. But, this creates a different problem! A WebServer is just for delivering documents as requested by the user. It need not have any scripting features. Various Webservers have built in facilities for executing CGI and CGI like programs. For instance, Personal WebServer has built in feature for executing ASP which uses VBScript. Apache server provides PERL & PHP. Similarly , JavaWebServer provides Servlet engine and JSP engine. Realising that Apache is the leading WebServer in Internet world, Sun collaborated with Apache Foundation and created the Tomcat engine. We must remember that not any web server can execute a servlet.. So, the correct method of invoking the

function on a remote object in remote server is through a servlet. The modern practice is to have a thin client.(ie) the end user has just a browser like InternetExplorer or Netscape Navigator. He downloads an HTML form and invokes a servlet or JSP through the form. If Distributed Objects are not involved, the servlet/jsp does the processing in web server itself and sends the result to the browser. For Distributed Computing , however, the servlet program in the web-server is the client-side for the Distributed Object computing.It invokes the method of the remote object in the Remote Server. ( it may be RMI/IDL/RMI-IIOP/EJB).The result is sent to the end-user's browser. . All this may be very dense fog right now but will clearup as we progress. With these introductory remarks, let us now take up the technologies one by one. Group1 ======== Servlets & JSP are Web-server technologies.( Distributed Objects Technologies are the more advanced stage...covered in second group) In most of the cases the requirement is that a database is to be accessed either for queries or for modifications . So we use a jdbc program in the webserver and access the database & send the result to the user's browser. Apart from this , it is also very useful to be able to send email through the server. These two opeartions (ie) database operation & mailing are essential applications in webserver. That is why JDBC & JavaMail have found a prominent place in the first group of J2EE technologies. JSP , is a technology which tries to separate the code from the presentation.( However, new developments like JSTL (Java Standard Template Library) & Struts have appeared which insist on much higher degree of separation between code & presentation.JSP-2 is awaited and it aims at total elimination of java code anywhere in the JSP page!..something that ASP.NET has already achieved!). A simple html form('dbdemo.htm') which invokes dbdemo.jsp follows: dbdemo.htm
method=post

type the selectquery here

action=dbdemo.jsp>


name='text1'>


dbdemo.jsp <%@page import="java.sql.*" %> <% Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); String

url = "jdbc:odbc:telephone";

// an access database registered

in odbc Connection

con = DriverManager.getConnection(url);

Statement

stm = con.createStatement();

// container for sql

String

sql = request.getParameter('text1'); // sql

ResultSet

rs = stm.executeQuery ( sql);

while(rs.next()) { out.println(rs.getString(1)+"
");

// name

out.println(rs.getString(2)+"
");

// telephone number

out.println("========"); } %>

------------------------------------------------------------------------------------------------------------------------As for sending mail from webserver, using JavaMail API, the following code shows how the required data such as 'from', 'to', 'subject' and 'message' are collected by the servlet and then processed for sending the mail. ----------------------------------------------------------------------------------------------------------------mailservlet.htm

sender




Reciever




Subject




Message

<br /> <br />
type=submit>



mailservlet.java

import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.mail.*; import javax.mail.internet.*; // important import javax.mail.event.*;

// important

import java.net.*; import java.util.*; public class servletmail extends HttpServlet { public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException { PrintWriter out=response.getWriter(); response.setContentType("text/html"); try { Properties props=new Properties(); props.put("mail.smtp.host","localhost"); // 'localhost' for testing Session session1 = Session.getDefaultInstance(props,null); String s1 = request.getParameter("text1"); //sender (from) String s2 = request.getParameter("text2");

String s3 = request.getParameter("text3"); String s4 = request.getParameter("area1"); Message message =new MimeMessage(session1); message.setFrom(new InternetAddress(s1)); message.setRecipients (Message.RecipientType.TO,InternetAddress.parse(s2,false)); message.setSubject(s3); message.setText(s4); Transport.send(message); out.println("mail has been sent"); } catch(Exception ex) { System.out.println("ERROR....."+ex); } } }

Using javamail requires that we provide classpath to mail.jar & activation.jar. These should have been already installed in our machine. Otherwise, we will not be able to compile the servlet. For testing the servlet, we should have installed some mail server in our machine. For compiling the servlet, we have to set classpath to c:\jsdk2.0\src (java servlet development kit).

(We are using Tomcat server. The TOMCAT server is a webserver especially created for executing servlets and JSP . It is a joint effort by SunMicroSystems & Apache

Foundation. Tomcat can be run on Apache server or independently. Tomcat will work in Windows platform also. The current version is Tomcat 4. Tomcat 5 is expected shortly).

We can move dbdemo.htm and dbdemo.jsp to : c:\tomcat\webapps\root directory. In another dos window, c:\tomcat\bin>SET TOMCAT_HOME=C:\TOMCAT >SET JAVA_HOME=C:\JDK1.3 >startup ( this will start the tomcat server in port 8080) Start InternetExplorer and type the url as 'http://localhost:8080/dbdemo.htm. We will get the form. Type the sql and submit the form. We will get the resultset sent by the server. We need not compile the jsp file. It is automatically compiled at the server. For running a servlet, copy the servlet's class file to: c:\tomcat\webapps\root\webinf\classes directory. For javamail , we have to copy mail.jar & activation.jar to classes folder. copy the invoking html file to: c:\tomcat\webapps\root

directory.

In the browser type the URL as 'http://localhost:8080/mailservlet.htm'. Enter the required data and submit the form to the server. The mail will be sent as specified by us. That is as brief a tour as possible of the first group of technologies in the J2EE basket. This is an essential foundation because , even when we use RMI/EJB , the correct practice is to invoke the RMI through a servlet. In the JSP example seen above, the code was exposed to the web-administarator. The better method is to encapsulate the code as a bean and invoke it. This way, only the class file will be seen by the server-administaror. The JSP page also will be easier to read and maintain.In the following example , we will adopt that method. To bring out the differences between the different appraoaches, we will consider a simple case where the user types his name in the textbox(text1) in the html form and submits it to the webserver. The JSP then invokes the greeter bean in the webserver . The greeter bean encapsulates the 'Business Logic' ,and so it appends a greeting message to the name thus submitted and sends it back to the user.

What is a Javabean? A Javabean is just a java class with the following requirements. i) It has a public no-args constructor ii) It has 'set' and 'get' methods for its properties. iii) It may have any general functions. iv) If required it must be Serializable. However, It is not necessary always that a bean should have properties. If there are no properties, we need not provide 'set' & 'get' methods either. ( Even the no-args constructor is provided by the compiler by default!) If the bean uses library classes alone, it is automatically serializable. In that case, it becomes just a class for encapsulating some functionality (ie) business logic.

Such a bean , may or may not have a visual representation. As the field has moved away from the desktop, to webserver, there is no point in providing a visual represenation for a component which works in server side as the user cannot interact with it directly. (Such a bean used by jsp in webserver, is exactly similar to ASP component). ( So no worry about jar file ,BDK, BeanBox etc traditionally associated with JavaBean) Let us now create such a bean. The Tomcat server searches for any classes in c:\tomcat\webapps\root\web-inf\classes folder. We create a subfolder under classes folder and name it 'ourbeans'. Therefore, we specify the package information in the first line of our jspbean as : package

ourbeans;

************************* package ourbeans; public class greeterbean

{ public greeterbean() { } public String greetme(String s) { return "How are you?...."+s; } } ***************************************************************** To compile the above file : > javac greeterbean.java We get greeterbean.class We move this class file to: c:\tomcat\webapps\root\web-inf\classes\ourbeans ***************************************************************** We will now create greeter.htm & greeter.jsp and place them in: c:\tomcat\webapps\root greeter.htm
method=post


name='text1'>



action=greeter.jsp>

greeter.jsp <jsp:useBean id="greeter1" class="ourbeans.greeterbean"

/>

<% String s = request.getParameter("text1"); String a = greeter1.greetme(s); out.println(a); %> In the above example, the business logic was invoked through an instance of 'greeter' bean class. So, it is object-oriented approach. Where was the method invoked? It was invoked in the Webserver.Where was the object available? The object was available in webserver itself.(ie) 'locally'. This point is worth noting carefully. For this reason, the jspbean method cannot be classified as 'Distributed Object ' Technology. Because, in Distributed Object Technology, the object on which the method is invoked locally, should be available in a remote server and not locally .( Why is this distinction so important? Is it important atall? If we are able to answer these questions to ourselves convincingly, we have truly grasped the essence of Enterprise computing but not otherwise. That is why this point is being laboured. Let us now consider a case where the object is not available in the webserver but in another remote machine. This is a typical case of MULTI-TIER Client-Server computing. The client here is a servlet program.Let us call it 'socketservlet.java'. This program accepts the data from the form as before but passes the data to the remote server. The bean in the remote server uses this data as parameter for its business logic, creates the result and then sends the result to the servlet. The servlet then forwards the result to the client's browser. We will use the standard Socket method.

It is evident that we are now introducing one more layer.( we have 3 layers now). 1) The user's browser 2) The servlet in web-server 3) The Remote Server housing the bean encapsulating the business logic. In this case, no processing is done at the web-server. The servlet simply accepts the data from the user, forwards it to the remote server where the data is processed by the bean at the remote server and the program sends the result to the servlet , which in turn sends it to the user's browser. import java.io.*; import java.net.*; public class socketgreetserver { public static void main(String args[]) { try { ServerSocket server= new ServerSocket(1234); System.out.println("server ready..listeneing for client in port 1234!"); while(true) { Socket sock = server.accept(); System.out.println("client connected"); DataInputStream ins=new DataInputStream(sock.getInputStream()); String s = ins.readLine(); System.out.println("data received");

greeter greeter1 = new greeter();

// create instance of local bean

String s1 = greeter1.greetme(s); PrintStream ps= new PrintStream(sock.getOutputStream()); ps.println(s1); } }catch(Exception e1)

{System.out.println(""+e1);}

}//main } //======================== Edit the above file in a dos window. >set path=c:\windows\command;c:\jdk1.3\bin >javac socketgreetserver.java >java socketgreetserver Now the remoteserver is running and is waiting for connection request from the client. (ensure that the bean class is available in the same folder). ---------------------------We now see the corresponding servlet. // socketgreetservlet.java import java.io.*; import java.net.*; import javax.servlet.*; import javax.servlet.http.*;

public class socketgreetservlet extends HttpServlet { public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out=response.getWriter(); //======================================== try { String s1=request.getParameter("text1");// get data from browser Socket client= new Socket("localhost",1234); // for testing System.out.println("server connected!"); PrintStream ps= new PrintStream(client.getOutputStream()); ps.println(s1); // send data to remote server DataInputStream ins=new DataInputStream(client.getInputStream()); String s = ins.readLine();

// get the data sent by the remote server

System.out.println("result obtained from remote server"); out.println(""); out.println(""); out.println(s);

// send it to browser

out.println(""); out.println(""); }catch(Exception e1)

{System.out.println(""+e1);}

}//main } //======================== (Compilation & deployment in Tomcat , as before) Can we call this 'Distributed Object 'Technology? Though , this indeed is a case of Distributed Computing, it does not qualify for being classified as 'Distributed Objects' technology, because the method on the bean was invoked in the Remote Server and the bean also resided in the Remote Server. -------In the example considered , we assume that at both ends we are having JVM and the remote object also is a java object. What if the remote object is not a java object? what if the remote object is wriiten in C++ and the author of that code does not care to provide a java wrapper? Such cases are covered by CORBA which Sun emulated in graded steps through RMI, IDL, RMI-IIOP & finally EJB. -----Another important feature required by most web-applications is Session-Tracking. HTTP is a stateless protocol. (ie) In a multiform application, the data sent through the first form will not be remembered and cannot be used in a subsequent form. , unless we make some arrangement. The usual illustration of this problem is the 'Shopping Cart'. The following methods have been proposed. a) Hidden FormFields b) URL-rewriting

c) Cookies d) Session object e) Application Object But , due to various reasons, it is the 'Session ' object method , that is found to be the best solution. Basically, Session-tracking means that any data pertaining to a browser session is retained for about 20 minutes by default, unless the user closes the session earlier. The data is retained in the webserver's memory and not in the server's hard disk.( This point is important because, EJB entity bean is stored in Enterprise-server's hard-disk., as we shall see shortly). JSP makes it very easy to do session-tracking if we use a bean. We simply declare the scope of the jspbean as 'Session' and we get sessiontracking. The following example shows a typical ' shoppingcart' bean. We will call it cart.java (' Shopping Cart' is a generic term used for describing session-tracking apps.) package ourbeans;

// THIS IS A JAVA BEAN.

import java.util.*; public class cart { Vector vector1; public cart() { vector1= new Vector(); } public void add(String s) { vector1.addElement(s); } public Vector showitems() {

return vector1; } }

carter.htm
method=post action=carter.jsp >

WHICH PLACES DO YOU WANT TO VISIT?
<select name=combo1> Bombay Bangalore Madras Delhi Calcutta Nagpur

The following JSP file is invoked by carter.htm ( pay particular attention to 'scope' of the bean!)

carter.jsp <jsp:useBean id="cart1" scope="session" class="ourbeans.cart" /> <% String s=request.getParameter("combo1"); cart1.add(s); Vector vector1 =cart1.showitems(); int n=vector1.size(); for(int j=0; j"); } %> Copy carter.htm & carter.jsp to c:\tomcat\webapps\root directory. In Internet Explorer , we type the url as 'http://localhost:8080/carter.htm. We get the form which asks you what places you would like to visit. You can select some city and submit. You can go back and select another city and submit again. We find that city names thus selected are added to the list and displayed, thereby achieving session-tracking. While studying EJB, the most important topic in J2EE, there will be reference to 'stateful session bean'. (ie) a session bean which has session-tracking feature. ( A stateless session bean does not retain its state).The greeter bean that we saw earlier is an example of 'stateless' bean. ( but not in EJB context).

Having thus familairized ourselves with the essential web-server techniqies, we are now ready to move on to the enterprise tier, (ie) the remote object server. This RemoteObjectServer may be either RMI server or IDL server or RMI-IIOP server . Finally, it can be an EJB server. The core of J2EE is EJB . At present , EJB is sought to be exposed as an XML-WebService. The second group is the essence of J2EE. Though, four technologies are mentioned there (ie) RMI, IDL, RMI-IIOP and EJB, the first 3 technologies are a build up towards EJB ,the culmination. RMI was introduced in JDK1.1

(1997)

IDL was introduced in JDK1.2

(1998)

RMI-IIOP was introduced in JDK1.3

(1999)

EJB followed closely. Modern Enterprise Computing , in the final reckoning, is a manifestation of Distributed Objects Technology. Typically, the Enterprise Computing world is characterized by great many Operating systems and equally varied Programming languages. The operating systems may be IBM Mainframe, IBM Midframe like OS 400, Mini Computer systems (HP) , UNIX systems ( AIX of IBM, HP-UX of HewlettPackard, Solaris of SUN etc) , Linux & finally Desktop Windows / Mac & Mobile PALM. Such a situation may well occur even within a single organization, if it is fairly large and mature.( In other words, even an Intranet may have a multiplicity of platforms and languages). The earliest Enterprise language of the Mainframe era was COBOL. In the UNIX systems , C & later C++ reigned supreme. By 1990, Visual Basic entered the scene and gradually matured into VB.net, and it now challenges C++! In 1995, Java was released and today it is almost the default language for Enterprise world. Even in MicroSoft DotNet platform, J# is a an approved choice and so Java ( pure or tainted) can claim to be the universal language for Enterprise computing today.( J# is another incarnation of Visual J++6. but restricted to webapplications using ASP.net.) ( However, for works like device drivers, Java is not directly suitable, as it does not have pointers. Hence C/C++ are preferred for such work. But, the C/C++ routines can be wrapped in Java using JNI (Java Native Interface) and then released for the Web World. Hence, there is a great need to develop a standard, where the objects written in different languages & residing within different machines running different opearting systems can coopearte to produce the end result. Such a system will be an instance of Distributed computing.And the objects are Distributed Objects.Before the advent of Object -Oriented Programming, RPC (Remote Procedure Call) was used between different machines. This was later modified into ORPC ( Object-Oriented Remote Procedure call). Microsoft DCOM was based on such a concept. DCOM was based on COM and COM is language -agnostic.(ie) we can create COM in any language of our choice in Microsoft

platform.( At present DCOM , has been superceded by DotNet framework) . The drawback of DCOM was that it was very much platform-dependent. (ie) It worked only where both the server and client were Windows machines. Even DotNet platform is , as yet,Windows-specific.(However, DotNet WebService is able to communicate with other platforms like Unix/Linux etc by using XML .This is for the first time that it has become possible , with such ease. XML is textual and non-proprietory. XML parsers are available for all platforms. Hence the superiority of ASP.net webservice over DCOM.) And Microsoft has unceremoniuosly jettisoned DCOM. Java is the only compiled language , so far ,which runs in a great variety of platforms. Unlike C & C++ programs , we do not have to compile the code and tweak it for each platform.This feature , besides automatic garbage collection, is the greatest merit of Java and why J2EE is the preferred choice of big companies ,which typically use OS like Mainframe, Midframe, MiniComputer, UNIX & Linux rather than Windows. Around 1990, the OMG (Object Management Group) was formed by just EIGHT founder members.( SUN MICROSYSTEMS, HEWLETT-PACKARD, Unisys Corporation, Philips Telecom, Data General, 3Com Corporation , American Aitlines and Canon . OMG developed the CORBA standard.( Common Object Request Broker Architecture).The membership grew into nearly 800 , which includes all the big names in the Enterprise computing world .( except Microsoft). Corba is just a specification. The required Interace is defined in a C-like language known as OMG-IDL. The IDL is a contract. It is like a function declaration in C++. The name of the method, the type of parameters required and the type of return value are specified by the IDL file. Typically, an IDL compiler 'compiles' this IDL file into the language chosen ( it may be C++ or Java ). The idl compiler ,in reality translates the IDL interface into a real language like C++ or Java. Much more important, it automatically generates what are known as 'Stub' & 'Skeleton' files .Companies like IONA ORBIXWEB, VISIGENIC, MICO, JAC-ORB specilaised in creating such IDL-COMPILERS. That was the period between 1991 and 1996. Java had not yet arrived and C++ was the language of choice for Enterprise work, besides COBOL, ADA ( for real time systems) & SMALLTALK. The earliest Corba language bindings were for these languages.The characteristic feature of Distributed Object Technologies is that the client invokes the method of an object which resides in a remote server in its own workspace, as if the object resided locally. Why is this so important? Why not just pass parameters to the remote object and invoke the function in remote server itself? Please read on. That is where the relevance of 'Distributed Objects ' technology becomes evident. If the author of the remote object ( wriiten in C++) wants his object to be accessible to other clients, he can start with the IDL file at his end and publish the idl to others. Using the IDL file, others can create the Stub &skeleton .and they can write their own clients to use the remote object.

Thus, the remote object's location is not disturbed.Its implementation details are not revealed. It can be written in any language , suitable for the specific application realm.( As they say, Java is no 'Silver Bullt' (ie) a solution suitable for all situations. Legacy objects can still be used. It may be running on any platform. In the Corba approach, the stub and skeleton source files are automatically created by the IDL compiler. The component designer, then creates an implementation for the interface. During compilation, the stub and skeleton files are referenced.The client file requires information about the stub. After these steps, the class files are installed in both ends, as appropriate. Now the client is able to invoke the remote object's methods from its own workspace.Actually, the remote object after being created is registered in Corba Naming Service.The client simply enquires the Naming service for the remote object , by 'name'.This is known as 'Location Transparency'. Why is 'Location Transparency' important? For Security?

No.

A server is supposed to work 24X7 ( a fancy way of saying 'continuously'). If for some reason , there is some problem in the server, the remote server's administrator can transfer the classes to another machine without disturbing the service.In Enterprise world, Location transparency is essential. Imagine a continuously touring businessman who informs his current contact number to the enquiry desk and if we want to contact him, we have to get his current whereabouts from the enquiry desk.( read 'Naming service'). The other important characteristic of Interface approach is what is usually referred to as ' Immutability of Service Contract'. , in COM circles. All that it means is that the corba provider can improve the implementation if desired without disturbing the contract with the client. This is an important merit of 'Interface-based'approach over 'Classbased ' approach. SUN MICROSYSTEMS being one of the founder members of the OMG (Object Management Group)which created the CORBA specification , aimed at providing simple API for creating CORBA-compliant RemoteObjectServers , using just the Java language. (ie) the aim is to develop RemoteObjectServers, which can be invoked and used by client programs written in other languages and working in different platforms. As Java language is already platform independent, the only problem was that of the language of the client. With an eventual aim of creating a simple version of Corba-compliant server , using nothing but Java, Sun began the journey with RMI. Remote Method Invocation is a corba-like solution in its approach. It begins with interface . It then creates an implementation class. Using this, it creates the Skeleton class file (Skeleton is the proxy for the RemoteObject in the server side). and also 'Stub ' class file.(Stub is the proxy for the Remote Object in client side). The remote object is registered in the Remote Registry.& waits for the client's call. All this was very much similar to Corba.( However, there is no location transparency in RMI).

RMI requires Java at both ends. Many programmers have asked in web forums why we cannot simply use the socket method instead of RMI. It is true that the merit of Interface approach is not all that evident if we have Java at both ends. But, even within that constraint, experienced programmers advise that if our program involves a lot of complex objects created by us and passed as parameters to the server, it is advisable to use the RMI method as it will take care of the Serialization details. Apart from this, we gain a better insight if we consider RMI as just a first step towards RMI-IIOP, which enables us to write Corba-compliant servers without the hassle of learning OMG-IDL. When we are experienced in writing RMI programs, we can easily switch over to RMI-IIOP. The merit of RMI-IIOP is that we write just a java file and the RMI compiler which comes with JDK1.3 can create the IDL from this file! This is known as 'Quick Corba'. ( Previously, Visigenic company had provided a software known as Caffiene , along the same lines.) Many earlier books like ' Java Distributed Objects' & 'Developing Servlets' by James Goodwill refer to that. That role is being done by RMI-IIOP now. The advantage of RMI-IIOP is that the programmer does not need to know anything about OMG-IDL. He simply writes a program with very slight changes from RMI style. He can get the IDL file automatically generated by the IDL compiler. This IDL file can be distributed for CORBA clients.They can use their own IDL compiler suitable for their platform and language and still use our java server. (RMI--IIOP was developed jointly by SUN & IBM). We will now see how the same interface can be used to create an RMI program and then an RMI-IIOP program. Let us now consider the RMI version of the 'greeter' program. RMI PROGRAM...HOW TO CREATE & RUN? ================================= From a DOS window, create a folder as c:\greeter cd to c:\greeter --->set path=c:\windows\command;c:\jdk1.3\bin >set classpath=c:\greeter -----

Edit greeterinter.java ( This is the Interface file). import java.rmi.*; public interface greeterinter extends Remote { String

greetme(String s)

throws

RemoteException;

} --------------------------------------------------------------------compile this file. >javac greeterinter.java We get greeterinter.class file after compilation. ----------------------------------------------------------Next, edit the implementation file as follows: //greeterimpl.java import greeterinter.*; import java.rmi.*; import java.rmi.server.*;

// essential. do not omit.

public class greeterimpl extends UnicastRemoteObject implements greeterinter { public static void main(String args[]) { //

System.setSecurityManager(new RMISecurityManager() ); try

{ greeterimpl app = new greeterimpl(); Naming.rebind("//" + "localhost" + "/greeterinter",

app);

System.out.println("greeter is registered"); } catch(Exception ex) { System.out.println("point1

"+ex);

} } //============================================== public greeterimpl() throws RemoteException { } //================================================ public String greetme(String s) throws RemoteException { return("How are you?......"+s); } } //over. ------------------------------------------------------------------Now, compile greeterimpl.java

>javac greeterimpl.java We get greeterimpl.class -----------------------------------The next step is to create the class files for the Stub & Skeleton using the rmic.exe provided in jdk. >rmic greeterimpl You will find that this command automatically creates the class files for Stub & Skeleton. -------------------------------------------------------We can now create the servlet file as follows, which will be the client for the RMI server. -------------------------greeterclientservlet.java import greeterinter.*; import greeterimpl.*; import greeterimpl_Stub.*; import greeterimpl_Skel.*; import java.net.*; import java.rmi.*; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import java.util.*; public class greeterclientservlet extends HttpServlet

{ greeterinter

server;

public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); String s = request.getParameter("text1"); try { server =(greeterinter) Naming.lookup("//" + "localhost" + "/greeterinter"); // Protocol is left unspecied.Normally it is JavaRemoteMethod Protocal // If there are firewall restrictions , it automatically // switches over to http . } catch (Exception e1)

{out.println(""+e1);}

String s1 = server.greetme(s); System.out.println(s1); out.println(""); out.println(""); out.println(s1); out.println("");

out.println(""); } } ----------------------------------------------------------------------To compile the servlet, change the classpath as follows: >set classpath=%classpath%;c:\jsdk2.0\src -Now we will be able to compile the servlet. -----------------------------------------------------------Create the html file to invoke the above servlet. greeterclientservlet.htm

================================ Now copy greeterclientservlet.htm to c:\tomcat\webapps\root Copy all the class files in c:\greeter to c:\tomcat\webapps\root\web-inf\classes ---------------

Now, we are ready to execute our RMI-servlet program. ==== c:\greeter>start rmiregistry This command creates a blank window. Minimize it. In the same DOS window, >java greetserverimpl -This starts the remote server . The remote object is created and registered in the RMI registry in the remote server. We get a message informing us about it. The implementation program creates an instance of the class and registers the instance in the RMI REGISTRY in the remote server, by the identity of 'greeterinter'. // Naming.rebind("//" + "localhost" + "/greeterinter",

app);

Remember to start the 'Tomcat' server as before. Now , we start the InternetExplorer and type the URL as 'http://localhost:8080/greeterclientservlet.htm' -----------We get a form. Fill up your name in text1 and submit. --The data is sent to the servlet. The servlet program looks up at the Registry to locate the object by name 'greeterinter'. After getting an instance.by 'Naming.lookup' , it invokes the 'greetme' function on the object and passes the string from the form as paramter to the method called. The method call with parameter is passed to the stub.The stub sends it to the Skeleton.The skeleton sends it to the remoteobject in remote server. The remote object executes the function

there and sends the result to skeleton. The skeleton sends it to stub. The stub sends it to the servlet. The servlet sends the result to the browser. *********************************************************************** *********** ( For reasons of space , we are constarined to limit ourselves to this much. If you need a more elaborate treatment, the books by Jaworsky and the one by Bill McCarty are ideal). *********************************************************************** ******* Let us now see how, an RMI-IIOP program is developed. This part is very unique and important. You may not find this in any textbook, because , RMI-IIOP was introduced only in JDK1.3 and most of the Java books in circulation deal only with JDK1.2.Sun's tutorial is not much helpful. So, read carefully. ----------------------------------------------------------------------------Here ara a few lines from Sun's documentation on RMI--IIOP. 'RMI lacks interoperability with other languages, and because it uses a non-standard communication protocol, cannot communicate with CORBA objects. IIOP is CORBA'S communication protocol.It defines the way in which the bits are sent over a wire between CORBA clients and servers. Previously Java programmers had to choose between RMI and JavaIDL.for Distributed programming solution. Now, by adhering to a few restrictions, RMI objects can use the IIOP protocol.( Internet InterOperable Protocol) and communicate with CORBA objects. Thus, RMI-IIOP combines RMI-style ease of use with CORBA cross-language interoperability. To resume, We will need 4 files (ie) a) greeter.java

( the Interface file)

b) greeterimpl.java ( the implementation file) c) greeterclientservlet.java ( the servlet which invokes the remote server) d) greeterclientservlet.htm

( the html file to invoke the servlet)

These files have been given below.( Carefully compare these files with their RMI counterpart to appreciate the similarity and minute dfferences) greeter.java import java.rmi.*; public interface greeter extends Remote { String greetme(String s) throws RemoteException; }

greeterimpl.java import javax.rmi.PortableRemoteObject; import javax.naming.*; import java.rmi.*; import java.rmi.server.*; import greeter.*; public class greeterimpl extends PortableRemoteObject implements greeter { String s; public static void main(String args[]) {

try { Context initialNamingContext = new InitialContext(); //

System.setSecurityManager(new RMISecurityManager()); greeterimpl obj = new greeterimpl("sam"); initialNamingContext.rebind("sam",obj); System.out.println("remote server ready!"); System.out.println("sam is registered & waiting for call"); } catch(Exception e1) { System.out.println("error"+e1); } } public greeterimpl(String a) throws RemoteException { s = " SUN'S RMI-IIOP(RMI-CORBA) PROGRAM WELCOMES ........."; } public String greetme(String a) throws RemoteException { return s+ a; }

}

greeterclientservlet.java import javax.servlet.*; import java.io.*; import javax.servlet.http.*; import greeter.*; import greeterimpl.*; import _greeterimpl_Tie.*; import java.rmi.*; import java.rmi.server.*; import javax.rmi.PortableRemoteObject; import javax.naming.*; import java.util.*; public class greeterclientservlet extends HttpServlet { public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException,IOException { response.setContentType("text/html"); PrintWriter out=response.getWriter(); try {

String s1=request.getParameter("text1"); Hashtable hash1 = new Hashtable(); hash1.put("java.naming.factory.initial","com.sun.jndi.cosnaming.CNCtxFactory"); hash1.put("java.naming.provider.url","iiop://localhost:900"); Context context1 = new InitialContext(hash1); greeter obj= (greeter)PortableRemoteObject.narrow(context1.lookup("sam"),greeter.class); String s = obj.greetme(s1); out.println(""); out.println(""); out.println(s); out.println(""); out.println(""); } catch(Exception e1) {

out.println("error"+e1); }

} } greeterclientservlet.htm

ENTER NAME

How to compile and run the RMI-IIOP program? 1) We require jndi package for running this program. We create a folder in c:\jdk1.3\bin\rmicorba. 2) We brought jndi folder into c:\jdk1.3\bin\rmicorba. 3) cd to c:\jdk1.3\bin\rmicorba. 4) set path=c:\windows;c:\windows\command;c:\jdk1.3\bin; 5) set classpath=c:\jdk1.3\bin\rmicorba 6) create greeter.java in this folder. 7) compile greeter.java 8) create and compile greeterimpl.java 9) MOST IMPORTANT STEP. >rmic -iiop greeterimpl (creates corba style stub and tie class files.) 10) start tnameserv // ( this is transient name server) >tnameserv 11) Go to another window ,set path & classpath as before. start the server and register the remote object. (this line must be typed most carefully without break!) (continuously). >java -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory

-Djava.naming.provider.url=iiop://localhost helloimpl ( -Djava means we are supplying runtime properties) 12) If every thing is done correctly , you will find the following message in the console. 'remote server ready!' 'sam is registered and waiting for call' 13) Now compile greeterclientservlet.java We have to set classpath=%classpath%;c:\jsdk2.0\src 14) After compiling copy all the classfiles in c:\jdk1.3\bin\rmicorba folder to c:\tomcat\webapps\root\web-inf\classes folder 15) copy greeterclientservlet.htm to c:\tomcat\webapps\root directory. 16) Start the tomcat server as already seen. 17) type the URL as 'http://localhost:8080/greeterclientservlet.htm" in the browser. 18) We get the form. Type your name ( say 'Thomas') and submit. 19) We will get the greeting : " SUN'S RMI-IIOP(RMI-CORBA) PROGRAM WELCOMES ...Thomas" 20) Thus we have invoked the remote object's method in Corba style. 21) So far so good. But how about the automatic generation of IDL for non-java end? This is the best part of RMI--IIOP, See step 9 listed above. We used the -iiop flag while invoking rmic compiler. If we use -idl flag instead, we get the idl file automatically generated. We can then distribute this idl file to other corba customers.

You would have noticed that , we have changed the order in which distributed order technologies in the j2ee basket were mentioned. Instaed of taking up JAVA-IDL after RMI, we took up RMI-IIOP. This way, we can easily compare RMI & RMI-IIOP. Just to complete the picture, we will now see the JAVA-IDL version of the same program and then on to the meat of J2EE (IE) EJB. There are 4 files as follows: 1) greeter.idl 2) greeterserver.java 3) greeterservlet.java 4) greeterservlet.htm We begin with greeter.idl , which is the interface file written in OMG-IDL. Let us edit this file in say, c:\idl folder. Set path for the dos window c:\idl>set path=c:\windows\command;c:\jdk1.3\bin Also set classpath: c:\idl>set classpath=c:\idl Create greeter.idl as given below. greeter.idl interface greeter { string greetme(in string s); };

We now use the idl compiler in jdk1.3 as follows: c:\idl>idlj -fall greeter.idl

This command creates a number of java source files as follows: 1) greeter.java 2) _greeterImplBase.java 3) _greeterStub.java 4) greeterHelper.java 5) greeterHolder.java 6) greeterOperations.java These files are created in the same folder as greeter.idl because we have not specified 'module' in the idl file. This is a simple method. Now, create greeterserver.java in the same folder as follows: greeterserver.java import org.omg.CORBA.*; import org.omg.CosNaming.*; import java.io.*; public class greeterserver { public static void main(String[] args) { try { ORB orb = ORB.init(args,null); greeterservant ref = new greeterservant(); orb.connect(ref); org.omg.CORBA.Object

objRef =orb.resolve_initial_references("NameService");

NamingContext

ncRef = NamingContextHelper.narrow(objRef);

NameComponent

nc = new NameComponent("greeter","");

NameComponent

path[] = {nc};

ncRef.rebind(path,ref); System.out.println("server ready...waiting for client"); java.lang.Object sync = new java.lang.Object(); synchronized(sync) { sync.wait(); } } catch(Exception e1) { System.out.println(" "+e1); } }//main }//class //------------class greeterservant extends _greeterImplBase { public String greetme(String s) { return "How are you....?"+s;

} } Compile all the java files as follows: c:\idl>javac *.java This compiles all the java files in the folder. We now create the servlet file which is the client for the corba program. greeterservlet.java import org.omg.CORBA.*; import org.omg.CosNaming.*; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import java.util.*; public class greeterservlet

extends HttpServlet

{ greeter server; public void init(ServletConfig config) throws ServletException { super.init(config); try { ORB orb = ORB.init((String[])null,null); org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("greeter",""); NameComponent path[] = {nc}; server = greeterHelper.narrow(ncRef.resolve(path)); System.out.println("servlet init ok!"); } catch(Exception e1){System.out.println(""+e1);} }

//init

public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException { response.setContentType("text/html"); PrintWriter out=response.getWriter(); String a =request.getParameter("text1"); // name System.out.println(a); String s1=server.greetme(a); out.println(s1); } }

//--servlet over-----

To compile the servlet file, we should set classpath as follows: c:\idl>set classpath=%classpath%;c:\jsdk2.0\src; c:\idl>javac greeterservlet.java This command compiles the servlet.

The following html file invokes the servlet.

Now, we copy greeterservlet.htm to c:\tomcat\webapps\root Then we copy all the class files in c:\idl folder to: c:\tomcat\webapps\root\web-inf\classes folder. We are now ready to test our corba program. Start Tomcat as before. Start the browser and type the URL as: "http://localhost:8080/greeterservlet.htm" We get a form with a textbox. Fill up your name,say Thomas and submit. We will get : "How are you...?Thomas". We have completed the first leg of our long journey.

In the second part, we will take up EJB , XML etc. In the previous instalment , we familiarized ourselves with Servlet, JSP, JavaMail, JDBC, RMI, RMI-IIOP and IDL. as, these were preliminaries to grapple with EJB. Now , it is time to takeup EJB.