Chapter - 1 JAVA RMI

Transcription

1 Remote Method Invocation : Chapter - 1 JAVA RMI RMI is the technology used to create distributed Java applications. The methods of remote Java objects (objects that have methods on different virtual machines are called as remote objects) can be invoked from other Java applications running on different hosts. Any Java program can make a call on a remote object once it obtains a reference to the remote object. This can be done either by looking up the remote object in the bootstrap-naming service provided by RMI or by receiving the reference as an argument or a return value. RMI applications are often comprised of two separate programs: a server and a client. A typical server application creates some remote objects, makes reference to them accessible, and waits for clients to invoke methods on these remote objects. A typical client application gets a remote reference to one or more remote objects and then involves methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. This type of application is called distributed object application. Distributed Application A distributed application is an application whose processing is distributed across multiple networked computers. Distributed applications are able to concurrently serve multiple users and depending upon their design make use of processing resources. Distributed applications are typically implemented as client/server system that are organized according to user interfaces, information processing and information storage layers. The information processing layer is implemented by an application client an application server or an application support server. User Interface layer Information Processing layer Information storage layer Distributed object application need to: 1) Locate remote objects: The organization of Distributed systems. Applications can use one of two mechanisms to obtain references to remote objects. An application can register its remote object with RMl s simple naming facility, the rmiregistry, or the application can pass and return remote object references. 2) Communicate with Remote obiects: Communication between remote objects is handled by RMI. For programmers it is like a standard Java method Invocation, 3) Load class byte codes for objects that are passed around: 1

2 RMI provides the necessary mechanisms for loading an object code, as well as for transmitting its data RMI distributed application that uses the registry to obtain a reference to a reference object. The server calls the registry to associate or (bind) a name with the remote object. The client looks up the remote object by its name in the server s registry and then invokes a method on it. RMI treats a remote object differently from a non-remote object when the object is passed from one virtual machine to another RMI passes a remote stub and skeleton for a remote object rather then making copy of its implement class. The stub acts as a local representative for the remote object and basically is to the caller, to the remote reference. The caller invokes a method on the local stub, which is responsible is carrying out the method call in the remote object. A stub for remote object implements the same set of remote interfaces that the remote object implements. This also means that only those methods defined in the remote interface are available to be called in the receiving virtual machine. Remote interfaces, Objects and Classes: RMI application is made up of interfaces and classes. These interfaces define methods and the classes implement these methods. But some of the implementations are assumed to reside in different virtual machines. Objects that have methods on different virtual machines are called as remote objects. A object becomes remote by implementing the remote interface. The methods of this interface throws RemoteException. 2

3 How to create Distributed Applications using RMI: First the programmer should decide on the components which should be remotely accessible. To achieve this he should define the remote interface, which in turn specifies the methods, which can be invoked remotely by a client. The methods in this interface must declare java.rmi.remoteexception in its throws clause. Any local objects that will be used as parameters should be determined. It is important to determine the return values of these methods too. Clients that use remote objects can be implemented at any time after the remote interfaces are defined, including after the remote objects have been deployed. After this, all the implementation source files should be complied with the javac compiler and rmic compiler should be used to create stubs for Remote Objects. This stub class is used as a proxy in clients so that clients can communicate with a particular object. Then all the classes associated with the remote interfaces, stub and other classes that need to be downloaded to clients-accessible via a Web Server. Creating Distributed applications using RMI To develop a distributed application the following steps have to be done: 1. Design and implement the components of your distributed application. 2. Compile sources and generate stubs. 3. Make classes network accessible 4. Start the application Design and implement the application component Look into the application and decide which are the local objects and which one should be remotely accessible. The steps are Defining the remote interface: A remote interface specifies the method that can be invoked remotely by a client. Ciients program to remote interfaces not to the implementation classes of those interfaces. 3

4 Implementing the remote objects: Remote objects must implement one or more interfaces. The remote object class may include implementations of other interfaces (either local or remote) and other methods which are available only locally. Implementing the clients: Clients that use remote objects can be implemented at any time after the remote interfaces are defined including after the remote objects have been deployed. Compile sources and generate Stubs This is a two step process. First step you use Java to compile the source files, which contain the implementations of the remote interface or implementations the server classes and the client classes. In the second step the rmic compiler is used to create stubs for the remote objects. Make classes network accessible: In this step all the class files associated with the remote interfaces, stubs, and other classes are downloaded to clients-accessible via a Web server. Start the Application This means starting the RMI remote object registry the server and the client. RMI Communication Architecture: RMI Communication consists of three layers. The stub/skeleton layer. The remote reference layer. The transport layer. A client has stubs to invoke methods in the remote object. A stub has implementation of the service of the remote interfaces and forwards the requests to the server object using the Remote reference layer. These stubs can be generated using the rmic compiler. The remote reference layer carries the semantics of the invocation. The transport layer is responsible for connection setup, connection management and keeping track of and dispatching to remote objects residing in the transport s address space. The communication architecture will exactly look like this: Client Server Stubs Skeletons Remote Reference 4 Layer Transport Layer

5 The client side stub is responsible for: Initiating a call to the remote object. Marshalling arguments to the marshal stream. Informing the remote reference layer that the call should be invoked. Unmarshalling return value or exception from the marshal stream. Informing the Remote reference layer that the call is complete. The server side skeleton is responsible for Unmarshalling arguments from the marshal stream. Making the up-call to the actual remote object implementation. Marshalling the return value of the call or an exception onto the marshal stream. Stubs and skeletons are dynamically loaded when there is a requirement. Stubs and Skeletons are generated using the rmic compiler. Implementing a remote interface The implementation class of a remote interface should be at least 1. Declare the remote interface being implemented 2. Define the constructor for the remote object 3. Provide an implementation for each remote method in the remote interfaces. The server needs to create and to install the remote objects. This setup procedure can be encapsulated in a main method in the remote object implementation class. The Java RMI package. The Java RMI package declares the remote interface the MarshalledObject, Naming and RMI security manager classes, and a number of exceptions that are used with remote method invocation. All remote objects must implement the Remote interface. This interface has no methods. They are used for identification processes. The Marshalled Object is used maintain a serialized byte stream of an object. A small example of RMI Writing Interface: 5

6 import java.rmi.*; public interface Intf extends Remote public double add(double d1,double d2) throws RemoteException; public double mult(double d1,double d2) throws RemoteException; public String getmodidata(string s) throws RemoteException; Let us discuss this part. A Intf interface is developed. The interface is extended from the Remote package which has its declaration in the java.rmi.remote. Three methods are declared. Note that all the methods throws RemoteException. Writing Implementation for interface: import java.rmi.*; import java.rmi.server.*; public class Impl extends UnicastRemoteObject implements Intf String msg; public Impl(String msg) throws RemoteException this.msg = msg; public double add(double dl,double d2) throws RemoteException double d3; d3 = dl +d2; return d3; public double mult(double dl,double d2) throws RemoteException return d1*d2; public String getmodidata(string s) throws RemoteException return msg + +s.touppercase(); After successfully compiling the program, type the following in the command prompt. Prompt:\...> rmic Impl 6

7 Two files Impl_stub.class and Impl_skel.class part of the code the implementation class Impl is created which extends UnicastRemoteObject and implements the Intf interface. The java.rmi.server.unicastremoteobject class defines a single remote object whose references are valid only when the server process is alive. Client Program : import java.rmi.*; import java.net.malformedurlexception; public class Client public static void main(string a[]) if(a.length!= 4) System.out.println( Usage : <seradd> <n1 > <n2> <message> ); System.exit(1); String addr = a[0] double n1 = Double.parseDouble(a[1]); double n2 = Double.parseDouble(a[2] ); String msg = a[3]; String url = rmi.// +addr+ /ServerObj try Intf intf; intf = (Intf)Naming.lookup(url); double res = intf.add(nl,n2); System.out.println( Addition is +res); res = intf.mult(n1,n2); System.out.println( Multiplication is + res); System.out.println( Modified data is + intf.getmodidata(msg) ); catch(remoteexception e) System.out.println( error is +e); catch(malformedurlexception m) 7

8 catch(notboundexception e) In this module when the program runs it looks for an object name ServerObj with the help of the statement intf =(lntf)naming.lookup(url); The add(n1,n2) method is called using statement double res = intf.add(n1,n2); which is stored into the double variable res and later on value of that is sent to the console. The mult(nl,n2) method is called using statement double res = intf.mult(nl,n2); which is stored into the double variable res and later on value of that is sent to the console. The getmodidata(msg) method is directly called along with the statement to send that on console. Server Program: import java.rmi.*; import java.net.malfromedurlexception; public class Server public static void main(string a[]) if(a.length!= 1) System.out.println( Usage : < Message for The Client Please > ); System.exit(1); String msg = a[o]; try Impl imp = new Impl(msg); String url= rmi://localhost:1o99/serverobj System.out.println( Binding Object ); Naming.rebind(url,imp); System.out.println( Object binded ); 8

9 catch(remoteexception e) System.out.println( Remote error is +e ); catch(malformedurlexception m) System.out.println( URI format wrong ) The Server program is creating object of Impl class and binding that object to the rmiregistry with the name ServerObj using method rebind of Naming class. So you have created the client, server, interface and implementation program too. Now you have to run the rmiregistry at the command prompt. RMI registry is a simple server-side bootstrap naming facility that allows remote clients to get.a reference to a remote object. Before starting the rmiregistry, make sure that the shell or window in which it will be run has no CLASSPATH environment variable that does not include the path to any classes, including the stubs for the remote object implementation classes. This command produces no output and is typically run in the back ground. After doing this open new command prompt, run the server program along with one argument as message for client. e.g. prompt:\...>java Server hello You will get this message at Server program. Binding Object Object Binded Open one more command prompt and run client program along with four arguments. e.g. prompt:\...>java Client localhost hi You will get this output at client program. Addition is 35.0 Multiplication is Modified data is hello Hi A GUI based Example: First developing the RMI interface; 9

10 import java.rmi.*; import java.rmi.server.*; interface RMIServer extends Remote public void senddata(string data) throws RemoteException; public String receivedata() throws RemoteException; You must save this file as RMIServer.java and compile the same. Now the second part of developing the implementation class. import java.rmi.*; import java.rmi.server.*; public class RMIDatabase extends UnicastRemoteObject implements RMIServer super(); try private CustomerData Customert=null; public RMIDatabase (String name) throws RemoteException catch(exception error) Naming. rebind(name,this); System.out.println( Unable to bind ); Customert= new CustomerData( xyz ); // xyz is the driver name for your database public String receivedata() //code to be added return null; public void senddata(string data) 10

11 System.out.println( Server sending the data ); Customer.sendData( Details,data); /*Details is the table name with atleast one field varchar(30) in which data is to be stored*/ Save the code as RMIDatabase.java and compile the program. CustomerData program should be present in the current directory in which you are working. After successfully compiling the program, type the following in the command prompt. Prompt:\...>rmic RMIDatabase. Two files part of the code and the implementation class RMIDatabase is created which extends UnicastRemoteObject and implements the RMIServer interface. An object for CustomerData is created. The statement Naming.rebind(name,this); establishes binding between the name and the remote object. The name will be used from the client program to identify the remoteobject. When the statement Customert= new CustomerData( Customer ) constructs the Customerdata object with the DSN name as the string input. Here the DSN name is customer. Developing the Server: import java.rmi.*; public class Server public static void main(string args[l) try System.setSecurityManager(new RMISecurityManager()); RMIDatabase connect=new RMIDatabase ( Connect ); System.out.println( Server started ); catch(exception error) System.out.println( Error in Server ); Save this program as Server.java and compile the same. Here the RMI Server is developed. In the main() method of the server class the security manager is initialized to RMISecurityManager using System.setSecurityManager(new SecurityManager()); 11

12 The security manager guarantees the classes loaded do not perform any illegal operations. If no security manager is specified, no class leading for RMI classes, local or otherwise is allowed. An object is created for RMIDatabase class and message is displayed on the standard output with RMIDatabase connect=new RMIDatabase( Connect ); The constructor RMIDatabase() export the remote object, that when created is ready to listen for any incoming calls. Now create the user interface. This is the part where we develop the client program. import java.awt.*; import java.awt.event.*; import java.sql.*; import java.rmi.*; import java.rmi.registry.*; class Customer extends Frame implements ActionListener Label IblFname, IblMname, Ibllname, IblAddress, IblCity, IblPin, IblPhone; TextField txffname, txfmname, txflname, txfcity, txfpin, txfphone; TextArea txfaddress; Button btnsubmit,btnquit; public Customer() lblfname = new Label( First Name ) IblMname = new Label( Middle Name ); IblLname = new Label( Last Name ); IblAddress=new Label( Address ); IblCity = new Label( City ); IblPin=new Label( Pincode ); IblPhone=new Label( Phone ); txffname= new TextField(10); txtmname = new TextField(10) txflname = new TextField(10); txfcity = new TextField(10); txfpin = new TextField(10); txfphone = new TextField(10); txfaddress=new TextArea(4,10); btnsubmit=new Button( Submit ); btnquit=new Button( Quit ); 12

13 setlayout(new FlowLayout()); add(lblfname); add(txffname) ; add(lblmname); add(txfmname) ; add (IblLname); add(txflname) ; add (IblAddress): add(txfaddress); add(lblpin); add(txfpin) ; add (IblPhone); add(txfphone); add (btnsubmit); add (btnquit); setsize(600,480); setvisible (true); btnsubmit. addactionlistener(this) ; btnquit.addactionlistener(this); addwindowlistener(new WindowAdapter() public void windowclosing(windowevent we)(system.exit(0); ); public void actionperformed (Act ionevent evt) if(evt.getsource( ) = = btnsubmit) try RMIServer server=(rmiserver) Naming.lookup( rmi://localhost/connect ); String name = txffname.gettext(); server.senddata(name) ; catch(exception error) System.out.println( Unable to contact server ); 13

14 if(evt. getsource() = = btnquit) System.exit(O); public static void main(string arg[!) Customer Custom = new Customer(); Now create CustomerData file import java.sql.*; public class CustomerData private Connection conn = null; private Statement qry = null; //private ResultSet rs = null; public CustomerData(String dsn) dsn = jdbc:odbc: +dsn; try Class.forName( sun.jdbc.odbc.jdbcodbcdriver ); conn = DriverManager. getconnection(dsn, sa, ) qry = conn.createstatement(); catch(exception e) e. printstacktrace(); System.out.println( connection failed ); public void senddata(string table,string data) try String sql= insert into + table + values( + data + ) qry.executeupdate(sql); 14

15 System.out.println( Data succesfully sent ); catch(exception ae) System. out.println( sql querry failed + ae); ) In this module when the button Submit is clicked the program looks for an object name Connect! with the help of the statement RMIServer server=(rmiserver) Naming. lookup( rmi://localhost/connect ); The getdata() method recivers the data and stores it into the string variable and forwards the same to the server with the next two statements. String name=getdata(); Server.sendData(Name); So you have created the client, server, interface and implementation program too. Now you have to run the rmiregistry at the command prompt. Open one more command prompt and run the server program. If should be noticed that the server program should be started always before the client. If the server is not on then client will always throw a runtime error. Open another command prompt and run the client program. Here the user interface screen will appear and then you can submit the data through RMI. It is not necessary that the server and the client should exist in different machine it can exist in same machine also. Automatic Object Activation One of the new RMI features is remote object activation framework. This framework allows you to activate remote objects remotely, deactivate the objects when they are not used, and then reactivate them when needed. This capability is very important in developing large distributed systems consisting of many objects running in many computers. In large distributed systems it is not possible to run all objects at the same time. Remote object activation helps to build distributed systems that are more reliable and resources efficient. Reliability is increased because remote objects are not transient references to object instances, but persistent references to objects that can be reactivated across multiple instances. How Remote Activation Works A remote object is active when it is instantiated within a Java Virtual Machine and exported for access via RMI. A remote object is inactivate when it is not instantiated or exported. Activation is the process of transforming an inactive object into an active object. An active object is an object that is capable of being activated. 15

16 RMI uses a form of remote activation that is lazy activation. Lazy activation does not mean it is slow it means that it is not activated unless one of its methods are have been involved. Lazy activation is implemented using a technique called faulting remote reference. A remote reference to an object consists of two points A transient object reference. A persistent object activation ID. The transient remote object reference or live reference is a reference to an instance of a remote object. When a remote object is no longer active the live reference is no more valid. The persistent object activation ID is an object identifier that is valid whether the object is active or inactive. When a client object invokes a method of an activable remote object, the live reference is checked to see whether it is valid or not. If it is not valid that is a faulting remote reference and the remote objects activation ID is used to create a valid live reference. Activation of the remote object is done using activation protocol. The activator maintains a database of information that maps activable objects to information that is needed to activate them such as an objects class name and its code source (location). This information is referred to as activation descriptor. All executing JVM are associated with activation group. The activation group of JVM is used to activate objects on that JVM. The activation descriptor tells the activator what class to load where to load it from where to activate it and where to initialize it. The activator checks for an executing JVM if it is not there it creates one. The activator then requests the activator group to activate the object, which is passed back to the client object making the method invocation. Creating an Activable Object To create an activable object three points have to be done. Register an activation descriptor for a remote object. Provide special constructors to be used for initial creation and activation. Export the object for remote access. The activation descriptor must be registered with the activator it will have the information needed to activate the object. The activation group uses the special constructors to create and activate or reactivate the object. The first two steps are done by making your objects class extend java.rmi.activation.activable. When this is done, registration and export are taken care of when your object is created. 16

17 Exercise 1. class that allows application to implement a security policy. 2. UnicastRemoteObject throws Exception. 3. The ability of an object to store its state is known as. 4. method is used for binding the Object in the server. 5. Object externalization means. 6. Write the advantages of Remote Method Invocation? 7. Define the terms Marshaling Unmarshaling? 8. What are the goals of Remote Method Invocation? 9. Explain about Distributed Garbage Collection? 10. Describe about Stub and Skeleton Layer? 17

18 Chapter - 2 SERVLETS Servlets are modules that extend request and response-oriented servers, such as Java-enabled web servers. For example a servlet might be responsible for taking data in an HTML order-entry form and applying the business logic used to update a company s order database. Servlets are to servers what applets are to browsers. Unlike applets however, servlets have no graphical user interface. Clients Ordering Servlet receives and does the required process HTTP Server Database Servlets can be embedded in many different servers because the servlet API. which you use to write servlets, assumes nothing about the server s environment or protocol. Servlets have become most widely used within HTTP servers, many web servers support servlets. Uses of Servlets: Here are a few applications for servlets: Servlet Package Allowing collaboration between people: A servlet can handle multiple requests concurrently, and can synchronize requests. This allows servlets to support systems such as on-line conferencing. Forwarding requests: Servlets can forward requests to other servers and servlets. Thus servlets can be used to balance load among several servers that mirror the same content and to partition a single logical service over several servers, according to task type or organizational boundaries. The javax.servlet package provides interface and classes for writing servlets. The architecture of the package is described below. 18

19 The Servlet Interface The central abstraction in the Servlet API is the Servlet interface. All servlets implement this interface either directly or more commonly by extending a class that implements it such as HttpServlet. The Servlet interface declares, but does not implement methods that manage the servlet and its communications with clients. Servlets writers provide some or all of these methods when developing a servlet. Servlets Generic Servlet HTTPServlet MyServlet Client Interaction When a servlet accepts a call from a client, it receives two objects: A ServletRequest which encapsulates the communication from the client to the server. A ServletResponse, which encapsulates the communication from the servlet back to the client. The ServletRequest Interface The ServeltRequest interface allows the servlet access to: Information such as the names of the parameters passed in by the client: the protocol (scheme) being used by the client and the names of the remote host that made the request and the server that received it. The input stream, ServletInputStream.Servlets use the input stream to get data from clients that use application protocols such as the HTTP POST and PUT methods. Interface that extend ServletRequest interface allow the servlet to retrieve more protocol-specific data. For example the HttpServletRequest interface contains methods for accessing HTTP specific header information. 19

20 Methods : init()- This method is called only once when first request for servlet is made. Initializes the servlet and logs the initialization. Service(ServletRequest rq,servetresponse rp)- This method will be called every time when client sends request. All the codes for receiving the request and sending the response will be written in this method. destroy()- Called only once when server close down. Cleans up whatever resources are being held (e.g. memory. file handles. Threads) and make sure that any persistent state is synchronized with the servlet s current in-memory state. The ServletResponse Interface The ServletResponse interface gives the servlet methods for replying to the client. Allows the servlet to set the content length and MIME type of the reply. Provides an output stream. ServletOutputStream and a Writer through which the servlet can send reply to the client. Interface that extend the ServletResponse interface give the servlet more protocol-specific capabilities. For example, the HttpServletResponse interface contains methods that allow the servlet to manipulate HTTP specific header information Interacting with Clients An HTTP Servlet handles client requests through its service method. The service method supports standard HTTP client requests by dispatching each request to a method designed to handle HTTP requests. Handling GET and POST Requests The methods to which the service() method delegates HTTP requests include. doget, for handling GET, conditional GET, and HEAD requests dopost, for handling POST requests doput, for handling PUT requests dodelete, for handling DELETE requests By default, these methods return a BAD_REQUEST(400) error. Your servlet should override the method or methods designed to handle the HTTP interactions that it supports. This section shows you how to implement methods that handle the most common HTTP requests: GET and POST. The HttpServlet s service method also calls the dooptions method when the servlet receives an OPTIONS request and dotrace when the servlet receives TRACE request. The default implementation of dooptions automatically determines what HTTP options are supported and 20

21 returns that information. The default implementation of dotrace causes a response with a message containing all of the headers sent in the trace request. These methods are not typically overridden. Threading Issue HTTP Servlets are typically capable of serving multiple clients concurrently. If the methods in your servlet do work for clients by accessing a shared resource, then you must either: Synchronize access to that resource, or Create a servlet that handles only one client request at a time. Requests and Responses Methods in the HttpServlet class that handle client requests take two argument: An HttpServletRequest object. which encapsulates the data from the client An HttpServletResponse obiect. which encapsulates the response to the client HttpServletRequest Objects An HttpServletRequest object provides access to HTTP header data, such as any cookies found in the request and the HTTP method with which the request was made. The HttpServletRequest object also allows you to obtain the arguments that the client sent as part of the request. To access client data The getparameter method returns the value of named parameter. If your parameter could have more than one value use getparametervalues instead. The getparametervalues method returns an array of values for the named parameter. (The method getparameternames provides the names of the parameters.) For HTTP GET requests, the getquerystring method returns a String of raw data from the client You must parse this data, yourself to obtain the parameters and values. For HTTP POST, PUT, and DELETE requests, If you expect text data. The getreader method returns a BufferedReader for you to use to read the raw data. If you expect binary data. The getinputstream method returns a ServletInputStream for you to use to read the raw data. HttpServletResponse Objects An HttpServletResponse object provide two ways of returning data to the user. The getwriter method returns a Writer The getoutputstream method returns a SewletOutputStream 21

22 Use the getwriter method to return text data to the user, and the getoutputstream method for binary data. Closing the Writer or ServletOutputStream after you send the response allows the server to know when the response is complete. HTTP Header Data You must set HTTP header data before you access the Writer or OutputStream. The HttpServletResponse class provides methods to access the header data. For example. the setcontenttype method sets the content type, (This header is often the only one manually set.) Handling GET and POST Requests To handle HTTP requests in a servlet, extend the HttpServlet class and override the servlet methods that handle the HTTP requests that your servlet supports. This lesson illustrates the handling of GET and POST requests. The methods that handle these requests are doget and dopost. GET requests: Handling GET requests involves overriding the doget method. The following example shows the BookDetailServlet doing this. import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class BookDetailServlet extends HttpServlet public void doget (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException //set content-tyupe header before accessing the Writer response.setcontenttype( Text/html ); PrintWriter out = response.getwriter( ); //then write the response out.println( < html > + < head > < title > Book Description </title > < body > ); //Get the identifier of the book to display String bookid = request. GetParameter( bookid ); if (!bookid equals( )) //and the information about the book and print it out.println( <h3>the name of the book you have Requested is:</h3> + bookid); 22

23 else (.. out.println( < h2 > Give a book name in the BOOK field</h2> ); outprintln( </body></html> ); out.close(); Now write a html file to access this servlet < html> < head> < title > BookDetail</title> </ head> <body> <form action = /servlet: BookDetailServlet method = get > <table > <tr> <td> BOOK: </td><td> < Input type = text name = bookid > < /td > < /tr > < tr > < td > < input type = submit value = Submit > < ltd > < /tr > </ table> </form> < /body> < /html> Now on command prompt run the servlet by writing this command Prompt c:\servletrunner -d c:\...path of your current servlet class file Now access this servlet through the html file The servlet extends the HttpServlet class and overrides the doget method. Within the doget method, the getparameter method gets the servlet s expected argument. To respond to the client, the example doget method uses a Writer from the HttpServletResponse object to return text data to the client. Before accessing the writer, the example sets the content-type header. At the end of the doget method, after the response has been sent, the Writer is closed. POST Requests: 23

24 Handling POST requests involves overriding the dopost method. The following example shows the ReceiptServlet doing that. import javax.servlet.*; import javax.servlet.http.*; import java.io.*: public class ReceiptServlet extends HttpServlet public void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException //set content type header before accessing the Writer response.setcontenttype( text/html ); PrintWriter out = response.getwriter( ); //then write the reponse out.println( < html > + < head > < title > Receipt < /title > < /head > ); out.println( < h3 > Thank you for purchasing books from us </h3 >! + request. getparameter( bookid )+ </html>? ); out,close(): Now make small changes in html file i.e. name of servlet and method=post and run the program as you had run earlier, The Servlet Life Cycle Each servlet has the same life cycle: A server loads and initializes the servlet The servlet handles zero or more client requests The server removes the servlet (some servers do this step only when they shut down) Let us see how a server invokes an applet. 1. The servlet loads servlet when it is first requested by a client. The servlet may be loaded from a remote location or n-local host using the standard Java class loading facility. This step is equivalent to the following code: Class c= Class.forName( com.sourcestream.myservlet ). 24

25 2. The server creates one or more instances of the servlet class. Servlet= (Servlet)c. newinstance(); 3. The server constructs a ServletCofig object that provides initialization information to the servlet. 4. The server calls the servlet s init() method. 5. The server creates ServletRequest or HttpServletRequest object from the data included in the client s request. It also constructs ServletResonse or HttpServletResponse object that provides methods for customizing the server s response. 6. The server calls the servlet s service () method (or other, more specific method like doget() or dopost() for HTTP servlets.) 7. The service method processes the client request by evaluating ServletRequest or HttpServletRequest object and responds using ServletResponse or HttpServletResponse object. 8. When instructed to unload a Servlet, perhaps by the server administrator or programmatically by the server itself the server calls the servlet destroy() method. The servlet is then eligible for garbage collections. An example of a Servlet: import javax.selvlet.*; import javax.servlet.http.*; import java.io.printwriter; import iava.io.ioexception; public class SampleServlet extends HttpServlet static int numrequests=0: public void service(httpservletrequest request, HttpServletResponse response) throws ServletException,IOException response.setcontenttype( text/html ); PrintWriter Out = response.getwriter( ): Out.println( < HTML> ); Out.println( <H EAD><TITLE>Sample Servlet< /TITLE><H EAD> ): Out.println( < BODY > ): Out.println( < H3 > Hello World! </H3>< br > ); numrequests ++; Out.println( <p> This servlet has been requested: +numrequests+: times. ), Out.println( /p></body> ); 25

26 Out.println( </html> ); Out.close(): Saving Client State You might be aware of the fact that http is a stateless protocol. The Servlet API provides two ways to track client state: 1. Session Tracking Session tracking is a mechanism that servlets use to maintain state about a series of requests from the same user (i.e. requests origination from the same browser) across some period of time. Session example: import java.io.*; import java.util.*: import javax.servlet.*; import javax.servlet. http.*; public class DateSessServlet extends HttpServlet Public void doget(httpservletrequest req,httpservletresponse resp)throws IOException.ServletException HttpSession hs=req.getsession(true); resp.setcontenttype( text/html ); PrintWriter pw = resp.getwriter(): pw.print( <b> ); Date dt = (Date)hs.getValue( date ); if(dt! =null) pw.print( Last access: +dt+ <br> ); dt = new Date (): hs.putvalue( date.dt): pw.println ( Current Date: + dt); 26

27 Call the DateSessServlet by this html document: <html> < title > Cookie details < title > <body> < b > Click on submit button to create session:</b > <BR> <form name = form1 action = method= get > <input type=submit value = Submit > </form> </body> </html> 2. Cookies A cookie is stored on a client and can contain state information. Cookies are mechanism that servlet uses to store small amount of state information associated with the user. Servlets can use the information in a cookie as the user enters a site (as a low-security user sign-on, for example), as the user navigates around a site (as a repository of user preferences for example) or both. example for setting the Cookie: import javax servlet.*; import javax.servlet.http.*; import java.io.*; public class CookieSewlet extends HttpServlet public void dopost(httpservletrequest req,httpservletresponse resp) throws ServletException, loexception String dt= req.getparameter( data ); Cookie co = new Cookie( Mycookie,dt); resp.addcookie(co); resp.setcontenttype( text/html ); PrintWriter pw=resp.getwriter(); pw.println( <b>mycookie has been set to ) pw. println (dt); pw.close() 27

28 set the cookie using this simple html file: < html > < title > Cookie details < /title > <body> < b > Enter value for MyCookie: < BR> <form name = form1" action= method= post > < table > < tr> < td > < input name = data type = textbox width = 15 ></td > <td> < input type = submit value = Submit > < /td > < /tr > < /table > </body> </form> </html> example for getting the values of Cookie : import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class GetCookieServlet extends HttpServlet public void dopost( HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException Cookie co[] = req.getcookies() resp.setcontenttype ( text/html ) ; PrintWriter pw= resp.getwriter(); pw.println( <b> ); for(int i =0;i < co.length;i + +) String nm = co[i].getname(); String vl=co[i].getvalue(); pw.println( Name= +nm+ ; Value- +vl); pw.close(); 28

29 Get the values from cookies using this html document: < html> < title > Cookie details < /title > <body> <b>click this button to get the value form MyCookie: <b>< BR> <form name= form1 action= method= post > <input type=submit value= Submit > </body> </form> </html> Servlet Communication Using other Server Resources To have your servlet access another resource such as another servlet, as JSP page, or a CGI script, you can either: Have the servlet make an HTTP request Make a request of resource using a RequestDispatcher object, if the resource is available from the server that is running the servlet. To gain access to a RequestDispatcher object, use the ServletContext object s getrequestdispatcher method. This method takes the requested resource s URL as an argument. The format of this argument is a slash ( / ) followed by one or more slash-separated directory names and ending with the name of the resource. The following are examples of valid URLs: /servlet/myservlet /servlet/tests/myservlet.class /myinfo.html The URL must be for a resource currently available on the server that is running the servlet. If the resource is not available, or if the server has not implemented a RequestDispatcher object for that type of resource, this method will return null. The servlet should be prepared to deal with this condition. Sharing Resources Among Servlets Servlets running in the same server sometimes share resources. This is especially true of servlets that combine to form a single application. Servlets in the same server can share resources using the 29

30 ServletContext interface s methods for manipulating attributes: setattribute, getattribute, and removeattribute. Naming Conventions for Attributes All servlets in a context share the attribute stores with the ServletContext interface. To avoid collisions of attribute names, name attributes using the same conventions as package names. Setting an Attribute Servlets set attributes using the ServeltContext setattribute method; they typically do so during initialization. When you have multiple servlets sharing an attribute, you might have each one try to initialize the attribute. If so, each servlet should check for the attribute value, and only set the attribute if another servlet has not already done so. Calling Servlets From Servlets To have your servlet call another servlet, you can either: A servlet can make an HTTP request of another servlet. A servlet can call another servlet s public methods directly, if the two servlets run within the same server. To call another servlet s public methods directly, you must: Know the name of the servlet that you want to call. Gain access to that servlet s Servlet object Call the servlet s public method To gain access to the Servlet object, use the ServletContext object s getservlet method. Get the ServletContext object from the ServletConfig object stored in the Servlet object. An example should make this clear. When the BookDetail servlet calls the BookDataBase servlet, the BookDetail servlet obtains the BookDataBase servlet s Servlet object like this: public class BookDetailServlet extends HttpServlet public void doget (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException. BookDataBaseServlet database = (BookDataBaseServlet) getservletconfig().getservletcontext().getservlet( bookdb ); 30

31 Once you have the servlet object, you can call any of that servlet s public methods. For example, the BookDetail sewlet calls the BookDB sewlet s getbookdetails method: public class BookDetailServlet extends HttpServlet public void doget (HttpServeltRequest request, HttpSewletResponse response) throws ServletException, IOException. BookDataBaseSewlet database = (BookDataBaseServelet) getservletconfig().getservletcontext().getservlet( bookdb ) ; BookDetails bd = database.getbookdetails(bookld);. You must exercise caution when you call another servlet s methods. If the servlet that you want to call implements the SingleThreadModel interface, your call could violate the called servlet s single threaded nature. (The server has no way to intervene and make sure call happens when the servlet is not interacting with another client.) In this case, your servlet should make an HTTP request of the other servlet instead of call in the other servlet s methods directly. Advantages of Servlets: Capable of running inside the same process. Servlets are capable of running in the same process space as the server. Server side programming like CGI require programs to run as separate processes when servicing client requests. Due to the multithreaded nature of servlets, all clients requests can be serviced by separate threads within the server s process space. Complied Servlets are compiled Java byte-codes. This improves performance. The compiled code is more compact and secure. Crash Resistant Servlets come closer to the ideal of completely crash proof. This is primarily due to the fact that servlets are written in Java and executed by Java Virtual Machine. Cross-Platform Because servlets can be run on virtually every popular Web Server in existence today. More than a dozen major software vendors currently provide native support for servlets within their products. 31

32 Durable Servlets are durable objects. They remain in memory until specifically instructed to be destroyed. Servlets only need to be initiated a single time in order to service may requests. Dynamically Loadable across the Network. Similar to applets, sevlets can be dynamically downloaded either locally or from across the network. Dynamic loading ensures that unused servlets do not consume precious server resources. They are only loaded when needed. Extensible Since servlets are written in Java, there is a wealth of third-party support for writing and extending them. Multithreaded Servlets are written in Java. As Java is a multi threaded language, servlets support multithreaded functionality. Protocol Independent Though servlets are commonly used to HTTP server functionality, they are by no means limited to this protocol. Servlets are completely protocol independent. Protocol independency allows a servlet to be specially constructed to support FTP commands. SMTP or POP3 functionality Telnet sessions, NNTP newsgroups, or any other protocol. Secure Servlets are secure in many different ways. Servlets are written in Java. Then servlets use the security Manager for the customization and enforcement of special security policies. A Servlet has access to all information contained in each client request. Online Book Store: In this practical oriented session, you have to create an Online Book store. Create an online book store in which different servlets are used for different functions: The necessary functions: 1. Browse the list of books offered for sale. 2. To get more details on a specific book. 3. To buy a book and place it in the shopping cart. 4. See the book that have been purchased. 5. Remove one or more books from the shopping cart. 32

33 6. Buy the books in the shopping cart. 7. Receive a thank you for the purchase. 8. Manage the book store data base. Exercise 1. interface allows sessions to be managed. 2. HTTP is a protocol. 3. class provides methods to handle HTTP requests and response. 4. method will be called when the web server receives a GET request for the result. 5. Servlet is side program. 6. What is the life cycle of a servlet? 7. What is the difference between doget() and dopost() methods? 8. Define Cookie? Write a program to create Cookie by using Cookie class? 9. What is meant by Session Tracking? 10. Write a program to display a text on the browser? 33

34 Chapter - 3 CORBA CORBA is a product of a consortium called Object Management Group (OMG) that includes over 800 companies, representing the entire spectrum of the computer industry. Since its creation, the OMG has focused on standards for implementing distributed objects. CORBA is a result of this effort. It provides a Standard architecture for developing distributed object-oriented systems. This architecture specifies how a client object written on one language can invoke the methods of a remote server object developed in a different language. What makes CORBA so important? It defines middle ware that has the potential of subsuming every other form of existing client server middleware. The entire CORBA System is self-describing. In 3-tier architecture, component development plays a vital role. Component architecture enables the programmer to develop components, which can offer services to client irrespective of platforms and development tools. CORBA was designed to allow intelligent components to discover each other interoperate on an object. How ever CORBA goes beyond just interoperability. It also specifies an extensive set of busrelated services for creating and deleting objects, accessing them by name, storing them in persistent stores, externalizing their states defining adhoc relationships with them. CORBA enables components developed in C++, Java or any other language to offer services irrespective of language and platforms. CORBA Components are packed as binary components. Any remote client can avail the services from these components with method invocation. The CORBA Component publishes its services to the outside world with interfaces. The interface is the binding contract between clients and components. Client needs to know where the distributed object lies or what operating system it executes on. What the client needs to know is the interface its server object publishes. The interface acts as the binding contract between client and servers. These interfaces are purely declarative which don t have any definition. The interfaces will be written using the neutral declarative language IDL (Interface Definition Language). Once after the interface declaration the component can be implemented in any language (C,C+ +,Java). The client needs to know only the services published by the interface. There is no necessary for the client to know about the server implementation code. Otherwise the server code is completely transparent to the client. IDL can be used to specify a component s attributes, the parent classes it inherits from, the exceptions it raises, the typed events it emits and the methods the interface support-including the input, output argument and their corresponding data types. CORBA ORB: Objects can discover each other and invoke services through CORBA ORE. The Object Request Broker (ORE) lets the objects transparently make requests to and receive responses from-other objects located locally or remotely. The CORBA 1.1 specifications introduced in only specified IDL, language bindings and API s for interfacing to the ORE. Only portable programs that could run on top of dozens of CORBA-compliant ORB s in the market (especially on the client side). CORBA 2.0 specifies interoperability across vendor ORB s. Benefits of CORBA ORB: 34

35 Static and Dynamic invocations In CORBA ORE communications the method invocations can be informed during compile time or the client can discover the methods during run-time. This enables programmers to have both strong-type checking and late binding functionality. High-level language bindings The CORBA ORE enables the developer to invoke methods from the server objects irrespective of language implementation. That means there is no need for the client object to know about the high-level language that is used to implement the server object. This is because the services offered by the server object are published in IDL, which is independent of any high-level language. Self-describing system The ORE support Interface Repository, which offers run-time information describing the functions offered by the server. The repository provides run-time metadata information about all service offered by the CORBA components. The clients can use the Interface Repository dynamically to discover the methods available. The Interface Repository is populated after compiling the IDL definitions of CORBA components. Local/Remote transparency CORBA offers local and remote transparency. The CORBA ORE can be interconnected with other ORB s in the network and offer service or it can run in the stand-alone mode. The IIOP (Internet Inter ORE protocol) enables the communication between ORB s across the network irrespective of platforms. This makes any CORBA component to be identified in the Internet environment. Another major advantage of CORBA ORE is there is no need to worry about dependencies, OS internals etc, from the developer s point of view. The developer needs to know only what service he wants to invoke. Built in security and transactions The context information provided in the messages by the ORE enables to handle the security and transactions across machine and ORE boundaries. Polymorphic messaging In contrast to other forms of middle were, and ORE does no simply invoke a remote function - it invokes a function on a target object. This means that the same function call will have different effects, depending on the object that receives it. That means described () will display system configuration when applied to the system object and will display the printer s configuration when applied to the printer object. Co-existence with legacy systems 35

36 The declaration is separated from the definition of server objects. This makes CORBA reuse legacy applications. Using CORBA IDL, you can make your existing code look an object on the ORE, even if it s implemented in stored procedures. The structure of CORBA ORB: Client Object implementation Dynamic Invocation Client IDL Adapter Interface ORB interface Static Skeletons DSI Object Interface Repository Impiementation Repository ORB(IIOP) The basic structure of CORBA is given above. Now let us discus the client side CORBA: The Client IDL Stubs : They are pieces of pre-compiled code, which provide static interfaces. These precompiled stubs define how clients invoke corresponding services to servers. The stubs are termed as local proxy for the remote object. The services are defined using IDL, and both client and server stubs are generated by the IDL compiler. A client must have a IDL stub for each interface it uses on the server. The stub encodes and decodes methods and its parameters into the standard format that be connect to the server. This is termed as marshalling. The Dynamic Invocation Interface : This enables to discover the methods to be invoked at runtime. CORBA defines standard API's for looking up the MetaData that defines the server interface, generating the parameters, issuing the remote call and getting back the results. Interface Repository : Interface Repositories APIs allow you to modify the details of the components registered such as its interfaces, the methods they support, and the parameters they require. The interface Repository is the runtime-distributed database that contains binary versions of the IDL defined interfaces. The API's allow components to dynamically access, store and update MetaData information. This enables the entire ORE as a selfdescribing system. ORE Interface : It consists of a few API's to local services that may be of interest to an application. For example CORBA provides API's to convert an object reference to a string and vice versa. These calls can be very useful if you need to store and communicate object 36

37 references. Now you got a clear idea about the client side CORBA. Let us now discuss about the server side CORBA. Server IDL Stubs : These are also called as skeletons. They provide static interfaces to each service exported by the server. These stubs, like the ones on the client, are created using IDL computer. Dynamic Skeleton Interface(DSI) : This feature was introduced in CORBA 2.0. This provides a run time binding mechanism for servers that need to handle incoming method calls for components that do not have IDL-based compiled skeletons (or stubs). The dynamic skeleton does this by identifying the arguments in the incoming message to understand the target object for which the request is made. Dynamic Skeletons are very useful for implementing generic bridges between ORB's. Object Adapter : It accepts the requests for service on behalf of the server objects from the remote clients. This offers the run-time environment for instantiating server objects, passing, requests to them and assigning them object Id's. The Object Adapter registers the classes it supports and their run-time instances with the Implementation Repository. CORBA Specification emphasizes the each ORE must support a standard adapter called the Basic Object Adapter (BOA). Servers may support more than one object adapter. Implementation Repository : This provides a run-time repository of information about the classes server supports, the objects that tare instantiated and their id's. It also server as a common place to store additional information associated with the implementation of ORB's. ORB Interface : It consists of a few API's to local services that are identical to those provided on the client side. What Java brings to CORBA? Java provides a portable object infrastructure that works on every major operating system. CORBA deals with network transparency, while Java deals with the implementation transparency. Java allows CORBA to move intelligent behavior around. Both client and server are allowed to gain intelligence dynamically. Java complements the CORBA Life cycle and Externalization services. Java is making CORBA universal on the Web. Java simplifies code distribution in large CORBA systems: Java code can be managed centrally from the server. So managing large-client/server internet installations will be easy. Java complements CORBA's agenting infrastructure. The agenting framework for distributed object will let roaming objects move from node to node based on the rules you define. Java is becoming universal, consequently, the agents can safely assume that a Java Virtual Machine will be present on every node they visit. Java is a great language for writing CORBA objects. Java is almost the ideal language for writing both the client and server objects. Java built-in multithreading, garbage collection and error management makes it easier to write robust network objects. 37

38 Java complements CORBA's component services. We can say that Java solves many thorny problems that have stood in the way of creating a truly portable distributed object market. Java lets you run portable applications that will one day able to run on any machine in the galaxy. 38

39 Exercise 1. An object reference is a to CORBA. 2. Server skeleton and client stubs are generated by the. 3. Marshaling is process of. 4. OMG stands for. 5. Implementing Interface means. 6. What is IDL and Why is it useful? 7. What is a client stub? 8. What does IIOP stands for and What is its significance? 9. What is the relation between CORBA, OMG and OMA? 10. Write the drawback to the use of client stubs in a CORBA client application? 39

40 Chapter 4 JAVA BEANS A component is a reusable software module, which can publish its service to its containers. Java Beans specifies the component architecture for Java. A Bean is a reusable software component written in Java. A bean may be a visible component or an invisible component. A Bean's features are exposed because feature names adhere to specific design patterns. A builder tool maintains Beans in a palette or a tool box. The user can select a Bean from the tool box, drop the Bean into a form, modify its appearance and behavior, define its interaction with other Beans and compose it and other Beans into an applet, an application or a new Bean. All these can be done without writing a single line of code. Bean Info Methods Properties Java Bean Component Customize Events JAR A Bean can expose its events, its methods and properties to the world. This enables the component reusability. Any other bean or tool now discovers the services of this component. The state of a bean can be serialized and can be stored in a.jar file. Multiple beans can be packaged together into a single jar file. The bean info class can be used to discover the services of the Bean, which makes bean introspective. The design pattern of java beans enables it to identify its services. Features of a Bean Bean components can vary in the functionality they provide, however, the following features are typical in all Beans. Introspection - Controls the publishing and discovering of bean operations and properties. Customization - Enables a developer to customize the appearance and of Bean at design time. Event - Enables Beans to communicate and connect to each other using the bean event model. Persistence - Enabling storing and restoring the state of a bean in a standard way. 40

41 Beans vary in functionality and purpose. Some examples of bean includes GUI (Graphical User Interface) widgets, Non visual beans such as spelling checker An Animation Applet A spreadsheet application. Classes and beans Beans themselves are classes (or a group of classes) that follow the naming conventions set forth in the Java Beans API specification for properties, methods, events and so on. This enables the introspection process to analyze a bean and discover its properties and behaviors; otherwise Builder tools will not be able to "learn" what is necessary about Beans to be able to hook beans together to create more complex behavior or functionality. Design Goals of the Java Beans Model To fully appreciate the Java Beans component Model it is good to understand its goals. Compact The Java Beans architecture was designed to leverage much of the functionality provided with the Java platform so that the Java Beans architecture would remain a very compact model. The Java Beans component model also uses the Serialization API for bean persistence, and the cut copy-paste mechanisms of the AWT. Easy to create and Use. The Java Beans APIs are relatively uncomplicated and simple components are very easy to create. Fully Portable Java Beans components have a distinct advantage over other component models: they are not bound to a particular platform, container, or component model. Because the Java Beans model is written in the Java programming language and the Java Beans API is part of the standard Java platform, Java beans components are fully portable. Flexible build time component editors The Java Beans architecture enables developers to create build-time property sheets, inspectors, and editors for their components. Many property editors are provided with the BDK, but developers may want to provide an editor better suited for the functionality of the components properties. Leverage Distributed Computing Mechanisms The Java platform provides several distributed computing mechanism, such as RMI and Java IDL (CORBA IDL). Java Beans component Developers can take advantage of these robust mechanisms when creating components for use in distributed applications. Benefits of Java Beans: A Bean enables the foundation of Java "Write once Run any where' 41

42 The JAR delivery, mechanism enables a convenient way for packaging the beans that can be easily delivered. The introspection ability of the bean enables the services to be discovered. This makes multiple Beans components to interact with each other. A user can us the builder tool to explicitly control the properties, methods and services offered by the beans. The property editors and customizers makes the java Beans a sophisticated component development/deployment architecture. Serialization makes the state of Beans to be stored in a persistent manner that can be retrieved at any point of time. The internationalization support makes the beans to be deployed anywhere. A bean can co-operate with other distribute software modules using RMI, sockets etc. The Java Beans provides the ability of offering services and integration with other component architectures such as CORBA and ActiveX technologies. A Bean can offer a facility of supporting legacy applications. Components Architectures Building large applications can be slow and expensive. By creating components, developers have portable, reusable code with which to work. Components can be developed quickly to meet market opportunities and needs. The functionality provided in each component can be combined with future components in new ways are seen at development time. Service of Component Models All component models should provide the following major services Component interface publishing and discovery Event handling Persistence Layout control Application Builder Support. Component Interface Publishing and Discovery The Interface publishing and discovery feature of a component model enables other components to learn of the existence and interfaces of a new component. This enables component to interact with each other. In the Java Beans model introspection and reflection provide this feature. Event Handling Event passing is the mechanism by which components communicate with each other. Components broadcast events and the underlying framework delivers the events to the components that want to be notified. The notified component usually takes some action based on the event that takes place. Component models provide a mechanism for persistence that enables the state of components to be stored in a nonvolatile place for later retrieval. Layout Control Layout control in component models is two folds Control of the visual appearance of a component 42

43 Mechanisms and services for determining layout of components within a container. Application Builder Support All component models provide interfaces for application builder support. With these interfaces, tools determine the properties and behaviors of arbitrary components. Builder tools usually provide mechanisms that help the developers to quickly assemble components into an application. Life Cycle of a Bean The life cycles of a Bean are three main phases that can be referred to as Development Design Time Run Time Development In the development phase a developer writes the code of a bean, adhering to the standards and conventions of the Java beans specification. The bean captures or encapsulates some small piece of functionality. The bean can be sold to or used by other developers. Design Time During the design time phase, a bean (probably written by someone else) is imported into a builder tool to be enhanced, customized, reused, and persisted (saved). The bean can be together with other beans to create a new level of functionality. Run Time During run time, a bean is put into an applet or application and used by other users. (The bean may actually be a combination of beans hooked together.) BeanBox The BeanBox is a simple tool used to test the JavaBeans and to learn how to visually manipulate their properties and events. It is not a builder tool. The main features of BeanBox: The ToolBox contains the Beans available for use by the BeanBox. To work on a Bean you choose it from the ToolBox and drop it on the BeanBox WINDOW. The BeanBox window is the area where the programmers usually wire Beans together defining how Beans appear and interact with other Beans. The Properties sheet displays the properties for the Bean currently selected within the BeanBox window. Beans step by step: The minimum requirements for a class to be Bean are Bean is public instantiate class. There should not be any abstract class definitions or interfaces. Bean class must have a null constructor. 43

44 Bean class must be serializable. The "design pattern" of Java Bean enables the introspector class or BeanInfo to describe the properties and methods. Package membership will Isolate the Beans from other beans. Helps to group related beans together. Acts as a common place to put associated classes and custom BeanInfo class. Class signature refers the name of the class, its base and associated interfaces. The class signature is important for its type and for the information that can be derived by the introspector class. A default constructor is a constructor with no arguments. This is required by the Bean supported IDE to create the Bean. It should set all the properties to the default value. Apart from the default constructor a bean can have specialized constructors too, which is very useful when hand-coding the beans. A Bean must implement the property change Listener interface to make the class bound to the changing data in another class. Add and Remove property listener methods are design signatures required to add remove property classes that implement property changelistener interfaces. This can be achieved by using the simple property changelistener support classes. Windows of the Bean Box Tool Box Window The tool Box Window, also referred to as the Bean palette, displays the beans currently available to the Bean Box. Bean Box Window 44

45 The Bean Box, also called the composition window is where a bean from the bean palette is placed. Sizing, moving, Changing properties using the Bean Box menus and so forth are carried out relative to the bean currently selected in this window. Properties Window The properties window displays the properties of the bean currently selected in the Bean Box window (the bean name is specified after the dash [-] in the frame tile.) In the figure the properties window is displaying the properties of the Bean Box itself, which is the currently selected Bean. 45