Advanced Java Programming
Advanced Java Programming
Unit IV
JNDI is based on the naming and directory concepts and allows applications to access multiple
naming and directory services via a common interface.
Naming service - provides a mechanism to name objects and to retrieve objects by name.
If you want to associate an object with a particular name, you have to bind it. Once the
object is bound, it can be accessed through the lookup operations and through the
operations for working with names (rename, rebind, unbind.).
Some objects cannot be stored directly so they are put in the system as references.
A reference is an object, which contains one or some addresses of objects that are not
directly bound to the naming system.
Directory service - a naming service that allows each bound object to be associated with
attributes and provides a way of retrieving an object by looking up some of its attributes
rather than its name. The attributes are object characteristics. Both the attributes and the
object itself form a directory object. A directory is a linked set of directory objects.
The Java Naming and Directory Interface (JNDI) is an application programming interface (API) for
accessing different kinds of naming and directory services.
JNDI is not specific to a particular naming or directory service, it can be used to access many different
kinds of systems including file systems; distributed objects systems like CORBA, Java RMI, and EJB;
and directory services like LDAP, Novell NetWare, and NIS+.
JNDI is similar to JDBC in that they are both Object-Oriented Java APIs that provide a common
abstraction for accessing services from different vendors. While JDBC can be used to access a variety of
relational databases, JNDI can be used to access a variety of of naming and directory services.
Using one API to access many different brands of a service is possible because both JDBC and JNDI
subscribe to the same architectural tenet: Define a common abstraction that most vendors can implement.
The common abstraction is the API.
It provides an objectified view of a service while hiding the details specific to any brand of service. The
implementation is provided by the vendor, it plugs into the API and implements code specific to
accessing that vendor's product.
JNDI provides two APIs and one SPI. JNDI has a naming API that allows Java applications to access
naming systems like CORBA's Naming services and a directory API that extends the naming service to
provide access to directory services like LDAP.
JNDI also has a SPI (Service-Provider Interface) which is a programming model that vendors use to write
JNDI plug-ins or implementations for their specific product. Each vendor's plug-in is called a service-
provider.
A service-provider implements the JNDI APIs so that a Java application can access that vendor's product.
For the most part, JNDI hides the implementation details of the a service-provider so that Java developer
that uses JNDI can use the same objects and method regardless of the brand of naming or directory
service accessed.
This is the real power behind APIs like JDBC and JNDI: They provide one programming model for
accessing many different products; there is no need to learn a different programming model every time a
different product is used.
The JNDI Properties of the Universal Test Client allows you to specify the Initial Factory and Provider
URL to be used during the JNDI lookup. You can also specify additional JNDI properties.
Initial Factory, a unique class provided by the application server used to communicate
with the client.
For example, the initial factory for WebSphere® Application Server is
com.ibm.websphere.naming.WsnInitialContextFactory.
Provider URL, specifies the host name (and optionally, the port number) for the name
server. The provider URL must have the following form (where hostname is the remote
name server's host name and port is the port number on which the remote name server is
listening): iiop:// hostname:port/ To test enterprise beans running in a different
installation of WebSphere Application Server, modify the Provider URL field with the
IP address of the remote installation.
User, specifies the user ID used to connect to the JNDI.
Password, specifies the password to the user ID.
Q) Explain J2EE?
The Java EE stands for Java Enterprise Edition, which was earlier known as J2EE and is currently
known as Jakarta EE. It is a set of specifications wrapping around Java SE (Standard Edition). The Java
EE provides a platform for developers with enterprise features such as distributed computing and web
services. Java EE applications are usually run on reference run times such
as microservers or application servers. Examples of some contexts where Java EE is used are e-
commerce, accounting, banking information systems.
Specifications of Java EE
Java EE has several specifications which are useful in making web pages, reading and writing from
database in a transactional way, managing distributed queues. The Java EE contains several APIs which
have the functionalities of base Java SE APIs such as Enterprise JavaBeans, connectors, Servlets, Java
Server Pages and several web service technologies.
1. Web Specifications of Java EE
o Servlet- This specification defines how you can manage HTTP requests either in a synchronous
or asynchronous way. It is low level, and other specifications depend on it
o WebSocket- WebSocket is a computer communication protocol, and this API provides a set of
APIs to facilitate WebSocket connections.
o Java Server Faces- It is a service which helps in building GUI out of components.
o Unified Expression Language- It is a simple language which was designed to facilitate web
application developers.
o Java API for RESTful Web Services- It helps in providing services having Representational State
Transfer schema.
o Java API for JSON Processing- It is a set of specifications to manage the information provided in
JSON format.
o Java API for JSON Binding- It is a set of specifications provide for binding or parsing a JSON
file into Java classes.
o Java Architecture for XML Binding- It allows binding of xml into Java objects.
o Java API for XML Web Services- SOAP is an xml based protocol to access web services over
http. This API allows you to create SOAP web services.
JavaBean
According to Java white paper, it is a reusable software component. A bean encapsulates many
objects into one object so that we can access this object from multiple places. Moreover, it
provides easy maintenance.
One of the most important advantages of a JavaBean is, the events properties and the methods of
a bean can be exposed directly to another application.
A JavaBean can be registered to receive events from other objects. However, we can also
generate events that can be sent to other objects.
3. Ease of configuration
We can easily use auxiliary software to configure the JavaBean. However, we can also save the
configuration setting of a JavaBean to persistent storage.
4. Portable
As JavaBeans are built in Java, we can easily port them to any other platform that contains JRE.
5. Lightweight
JavaBeans are light weighted, I.e., we don't need to fulfill any special requirement to use it. Also,
it is very easy to create them. However, it doesn't need a complex system to register components
with JRE.
The other advantages of JavaBeans include reusability, deployment, and customization that can
be archived using JavaBeans.
However, there are a few disadvantages of JavaBeans, which are its mutability, which makes it
not working with Immutable Objects. Also, creating a setter and getter for each property in a
class may lead to a boilerplate code.
JavaBean Properties
A JavaBean property is a named feature that can be accessed by the user of the object. The
feature can be of any Java data type, containing the classes that you define.
1. getPropertyName ()
For example, if the property name is firstName, the method name would be getFirstName() to
read that property. This method is called the accessor.
2. setPropertyName ()
For example, if the property name is firstName, the method name would be setFirstName() to
write that property. This method is called the mutator.
//Employee.java
package mypack;
public class Employee implements java.io.Serializable{
private int id;
private String name;
public Employee(){}
public void setId(int id){this.id=id;}
public int getId(){return id;}
public void setName(String name){this.name=name;}
public String getName(){return name;}
}
package mypack;
public class Test{
public static void main(String args[]){
Employee e=new Employee();//object is created
e.setName("Arjun");//setting value to the object
System.out.println(e.getName());
}}
The JavaBeans API and its implementation are contained in the java.beans package. A few of the
classes are used by beans while they run in an application. For example the event classes are
used by beans that fire property change events (see PropertyChangeEvent).
However, most of the classes in this package are meant to be used by a bean editor that is, a
development environment for customizing and putting together beans to create an application.
In particular, these classes help the bean editor create a user interface that the user can use to
customize the bean. For example, a bean may contain a property of a special type that a bean
editor may not know how to handle. By using the PropertyEditor interface, a bean developer can
provide an editor for this special type.
Enterprise Java Beans (EJB) is one of the several Java APIs for standard manufacture of
enterprise software. EJB is a server-side software element that summarizes business logic of an
application. Enterprise Java Beans web repository yields a runtime domain for web related
software elements including computer reliability, Java Servlet Lifecycle (JSL) management,
transaction procedure and other web services. The EJB enumeration is a subset of the Java EE
enumeration.
The EJB enumeration was originally developed by IBM in 1997 and later adopted by Sun
Microsystems in 1999 and enhanced under the Java Community Process.
The EJB enumeration aims to provide a standard way to implement the server-side business
software typically found in enterprise applications.
To run EJB application we need an application server (EJB Container) such as Jboss,
Glassfish, Weblogic, Websphere etc. It performs:
Stateless: These beans do not declare any instance (class-level) variables, so that the methods contained
within can act only on any local parameters. There is no way to maintain state across method calls.
Stateful: These beans can hold client state across method invocations. This is possible with the use of
instance variables declared in the class definition. The client will then set the values for these variables
and use these values in other method calls.
There may be more work involved for the server to share stateful session beans than is required to share
stateless beans. Storing the state of an EJB is a very resource-intensive process, so an application that uses
stateful beans may not be easily scalable. Stateless session beans provide excellent scalability, because
the EJB container does not need to keep track of their state across method calls. You'll see how to develop
both stateless and stateful session beans later in this article.
All EJBs, session beans included, operate within the context of an EJB server, as shown in Figure 2. An
EJB server contains constructs known as EJB containers, which are responsible for providing an
operating environment for managing and providing services to the EJBs that are running within it.
In a typical scenario, the user interface (UI) of an application calls the methods of the session beans as it
requires the functionality that they provide. Session beans can call other session beans and entity beans.
Figure 2 illustrates typical interactions between the user interface, session beans, entity beans, and the
database.
Entity beans
Before object orientation became popular, programs were usually written in procedural
languages and often employed relational databases to hold the data. Because of the strengths and
maturity of relational database technology, it is now often advantageous to develop object-
oriented applications that use relational databases. The problem with this approach is that there is
an inherent difference between object-oriented and relational database technologies, making it
less than natural for them to coexist in one application. The use of entity beans is one way to get
the best of both of these worlds, for the following reasons:
Entity beans are objects, and they can be designed using object-oriented principles and used in
applications as objects.
The data in these entity bean objects are persisted in some data store, usually relational
databases. All of the benefits of relational technologies—including maturity of products, speed,
reliability, ability to recover, and ease of querying—can be leveraged.
In a typical EJB scenario, when a session bean needs to access data, it calls the methods of an
entity bean. Entity beans represent the persistent data in an EJB application. For example, an
application for an educational institution might have an entity bean named Student that has one
instance for every student that is enrolled in an institution. Entity beans, often backed by a
relational database, read and write to tables in the database. Because of this, they provide an
object-oriented abstraction to some information store.
it is a good practice to call only session beans directly from the client, and to let the session
beans call the entity beans. Here are some reasons for this:
This practice doesn't circumvent the business logic contained in the session beans. Calling entity
beans directly tends to push the business logic into the UI logic, which is usually a bad thing.
The UI doesn't need to be as dependent on changes to the entity beans. The UI is shielded from
these changes by the session beans.
In order for a client to interact with a bean on the EJB server, there must be a remote reference to
the bean, which takes resources. There tends to be far more (orders of magnitude) entity bean
instances in an application than session bean instances. Restricting client access to session beans
conserves server and network resources considerably.
Struts is used to create a web applications based on servlet and JSP. Struts depend on the
MVC (Model View Controller) framework. Struts application is a genuine web application.
Struts are thoroughly useful in building J2EE (Java 2 Platform, Enterprise Edition) applications
because struts takes advantage of J2EE design patterns. Struts follows these J2EE design
patterns including MVC.
In struts, the composite view manages the layout of its sub-views and can implement a
template, making persistent look and feel easier to achieve and customize across the entire
application. A composite view is made up by using other reusable sub views such that a small
change happens in a sub-view is automatically updated in every composite view.
Struts consists of a set of own custom tag libraries. Struts are based on MVC framework which
is pattern oriented and includes JSP custom tag libraries. Struts also supports utility classes.
Features of Struts: Struts has the following features:
Struts encourages good design practices and modeling because the framework is designed
with “time-proven” design patterns.
Struts is almost simple, so easy to learn and use.
It supports many convenient features such as input validation and internationalization.
It takes much of the complexity out as instead of building your own MVC framework, you
can use struts.
Struts is very well integrated with J2EE.
Struts has large user community.
It is flexible and extensible, it is easy for the existing web applications to adapt the struts
framework.
JavaServer Faces
It is a server side component based user interface framework. It is used to develop web
applications. It provides a well-defined programming model and consists of rich API and tag
libraries. The latest version JSF 2 uses Facelets as its default templating system. It is written in
Java.
The JSF API provides components (inputText, commandButton etc) and helps to manage their
states. It also provides server-side validation, data conversion, defining page navigation, provides
extensibility, supports for internationalization, accessibility etc.
The JSF Tag libraries are used to add components on the web pages and connect components
with objects on the server. It also contains tag handlers that implements the component tag.
With the help of these features and tools, you can easily and effortlessly create server-side user
interface.
1) It provides clean and clear separation between behavior and presentation of web application.
You can write business logic and user interface separately.
2) JavaServer Faces API?s are layered directly on top of the Servlet API. Which enables several
various application use cases, such as using different presentation technologies, creating your
own custom components directly from the component classes.
3) Including of Facelets technology in JavaServer Faces 2.0, provides massive advantages to it.
Facelets is now the preferred presentation technology for building JavaServer Faces based web
applications.
Q) Explain life cycle of JFS?
JSF application life cycle consists of six phases which are as follows −
Restore view phase
Apply request values phase; process events
Process validations phase; process events
Update model values phase; process events
Invoke application phase; process events
Render response phase
The six phases show the order in which JSF processes a form. The list shows the phases in their
likely order of execution with event processing at each phase.
JSF begins the restore view phase as soon as a link or a button is clicked and JSF receives a
request.
During this phase, JSF builds the view, wires event handlers and validators to UI components
and saves the view in the FacesContext instance. The FacesContext instance will now contain all
the information required to process a request.
After the component tree is created/restored, each component in the component tree uses the
decode method to extract its new value from the request parameters. Component stores this
value. If the conversion fails, an error message is generated and queued on FacesContext. This
message will be displayed during the render response phase, along with any validation errors.
If any decode methods event listeners called renderResponse on the current FacesContext
instance, the JSF moves to the render response phase.
During this phase, JSF processes all validators registered on the component tree. It examines the
component attribute rules for the validation and compares these rules to the local value stored for
the component.
If the local value is invalid, JSF adds an error message to the FacesContext instance, and the life
cycle advances to the render response phase and displays the same page again with the error
message.
During this phase, JSF handles any application-level events, such as submitting a form/linking to
another page.
During this phase, JSF asks container/application server to render the page if the application is
using JSP pages. For initial request, the components represented on the page will be added to the
component tree as JSP container executes the page. If this is not an initial request, the component
tree is already built so components need not be added again. In either case, the components will
render themselves as the JSP container/Application server traverses the tags in the page.
After the content of the view is rendered, the response state is saved so that subsequent requests
can access it and it is available to the restore view phase.