jump to navigation

J2EE 3-tier or n-tier architecture August 18, 2007

Posted by Allu in J2EE.
12 comments

The J2EE platform is a multi-tiered system. A tier is a logical or functional partitioning of a system. When the developers are not disciplined, the display logic, business logic and database logic are muddled up and/or duplicated in a 2- tier client server system.

The advantages of the multi-tier architecture are:

·         Forced separation of user interface logic and business logic.

·         Business logic sits on small number of centralized machines (may be just one).

·         Easy to maintain, to manage, to scale, loosely coupled etc.

Each tier is assigned a unique responsibility in a 3-tier system. Each tier is logically separated and loosely coupled from each other, and may be distributed.

Client tier represents Web browser, a Java or other application, Applet, WAP phone etc. The client tier makes requests to the Web server who will be serving the request by either returning static content if it is present in the Web server or forwards the request to either Servlet or JSP in the application server for either static or dynamic content.

Presentation tier encapsulates the presentation logic required to serve clients. A Servlet or JSP in the presentation tier intercepts client requests, manages logons, sessions, accesses the business services, and finally constructs a response, which gets delivered to client.

Business tier provides the business services. This tier contains the business logic and the business data. All the business logic is centralized into this tier as opposed to 2-tier systems where the business logic is scattered between the front end and the backend. The benefit of having a centralized business tier is that same business logic can support different types of clients like browser, WAP, other stand-alone applications etc.

Integration tier is responsible for communicating with external resources such as databases, legacy systems, ERP systems, messaging systems like MQSeries etc. The components in this tier use JDBC, JMS, J2EE Connector Architecture (JCA) and some proprietary middleware to access the resource tier.

Resource tier is the external resource such as a database, ERP system, Mainframe system etc responsible for storing the data. This tier is also known as Data Tier or EIS (Enterprise Information System) Tier.

j2eetiers.gif

The advantages of a 3-tiered or n-tiered application: 3-tier or multi-tier architectures force separation among presentation logic, business logic and database logic. Let us look at some of the key benefits:

·         Manageability: Each tier can be monitored, tuned and upgraded independently and different people can have clearly defined responsibilities.

·         Scalability: More hardware can be added and allows clustering (i.e. horizontal scaling).

·         Maintainability: Changes and upgrades can be performed without affecting other components.

·         Availability: Clustering and load balancing can provide availability.

·         Extensibility: Additional features can be easily added.

Advertisements

What is the Max amount of information that can be saved in a Session Object? February 7, 2007

Posted by Allu in J2EE.
3 comments

As such there is no limit on the amount of information that can be saved in a Session Object. Only the RAM available on the server machine is the limitation. The only limit is the Session ID length(Identifier), which should not exceed more than 4K. If the data to be store is very huge, then it’s preferred to save it to a temporary file onto hard disk, rather than saving it in session. Internally if the amount of data being saved in Session exceeds the predefined limit, most of the servers write it to a temporary cache on Hard disk.

Difference between session and cookie? February 7, 2007

Posted by Allu in J2EE.
12 comments

1) session should work regardless of the settings on the client browser. even if users decide to forbid the cookie (through browser settings) session still works. there is no way to disable sessions from the client browser.
2) session and cookies differ in type and amount of information they are capable of storing.
Javax.servlet.http.Cookie class has a setValue() method that accepts Strings. javax.servlet.http.HttpSession has a setAttribute() method which takes a String to denote the name and java.lang.Object which means that HttpSession is capable of storing any java object. Cookie can only store String objects.

Difference between variable declared inside a declaration part and variable declared in scriplet part of JSP? November 11, 2006

Posted by Allu in J2EE, JSP.
1 comment so far

Variable declared inside declaration part is treated as a global variable. that means after convertion of a jsp file into servlet that variable will be in outside of service method or it will be declared as instance variable. And the scope is available to complete jsp and to complete in the converted servlet class. where as if u declare a variable inside a scriplet that variable will be declared inside a service method and the scope is with in the service method.

Difference between a Web server and an application server November 2, 2006

Posted by Allu in J2EE.
3 comments

In general, an application server prepares data for a Web server — for example, gathering data from databases, applying relevant business rules, processing security checks, and/or storing the state of a user’s session. The term application server may be misleading since the functionality isn’t limited to applications. Its role is more as retriever and manager of data and processes used by anything running on a Web server. In the coming age of Web services, application servers will probably have an even more important role in managing service oriented components. One of the reasons for using an application server is to improve performance by off-loading tasks from a Web server. When heavy traffic has more users, more transactions, more data, and more security checks then more likely a Web server becomes a bottleneck.

EAR, WAR, JAR files October 31, 2006

Posted by Allu in J2EE.
5 comments

An EAR file is a standard JAR file with an “.ear” extension, named from Enterprise ARchive file. A J2EE application with all of its modules is delivered in EAR file. JAR files can’t have other JAR files. But EAR and WAR (Web ARchive) files can have JAR files.
 An EAR file contains all the JARs and WARs belonging to an application. JAR files contain the classes and WAR files contain the Web components (JSPs, static content (HTML, CSS, GIF etc), Servlets etc.). The J2EE application client’s class files are also stored in a JAR file. EARs, JARs, and WARs all contain an XML-based  deployment descriptor.

Differences between normal Beans and EJBs? October 12, 2006

Posted by Allu in J2EE, JAVA.
add a comment

JavaBeans may be visible or nonvisibleat runtime. For example, the visual GUI component may be a button, list box, graphic, or a chart

An EJB is a nonvisual, remote object

Java Beans are intended to be local to a single process and are primarily intended to run on the client side. Although one can deevelop server-side JavaBeans, it is far easier to develop them usin the EJB specification instead.

EJBs are remotely executable components or business objects that can be deployed only on the server

JavaBeans is a component technology to create generic java component that can be composed together into applets and applications

Even though EJB is a component technology, it neither builds upon nor extends the original javaBeans specification.

Java Bean have an external interface called the properties interface, which allows a builder tool to interpret the functionality of the bean

EJBs have a deployment descriptor that describes its functionality to an exteternal builder tool or IDE

 

Difference between getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface and javax.servlet.ServletContext interface September 11, 2006

Posted by Allu in J2EE.
2 comments

The getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface accepts parameter the path to the resource to be included or forwarded to, which can be relative to the request of the calling servlet. If the path begins with a “/” it is interpreted as relative to the current context root.

The getRequestDispatcher(String path) method of javax.servlet.ServletContext interface cannot accepts relative paths. All path must start with a “/” and are interpreted as relative to current context root.

Advantage of using Entity bean for database operations, over directly using JDBC API September 9, 2006

Posted by Allu in EJB, J2EE.
2 comments

Entity Beans actually represents the data in a database. It is not that Entity Beans replaces JDBC API. There are two types of Entity Beans Container Managed and Bean Mananged. In Container Managed Entity Bean – Whenever the instance of the bean is created the container automatically retrieves the data from the DB/Persistance storage and assigns to the object variables in bean for user to manipulate or use them. For this the developer needs to map the fields in the database to the variables in deployment descriptor files (which varies for each vendor).

In the Bean Managed Entity Bean – The developer has to specifically make connection, retrive values, assign them to the objects in the ejbLoad() which will be called by the container when it instatiates a bean object. Similarly in the ejbStore() the container saves the object values back the the persistance storage. ejbLoad and ejbStore are callback methods and can be only invoked by the container. Apart from this, when you use Entity beans you dont need to worry about database transaction handling, database connection pooling etc. which are taken care by the ejb container. But in case of JDBC you have to explicitly do the above features. what suresh told is exactly perfect. ofcourse, this comes under the database transations, but i want to add this. the great thing about the entity beans of container managed, whenever the connection is failed during the transaction processing, the database consistancy is mantained automatically. the container writes the data stored at persistant storage of the entity beans to the database again to provide the database consistancy. where as in jdbc api, we, developers has to do manually.

types of Clustering in J2EE September 4, 2006

Posted by Allu in J2EE.
add a comment

J2EE clusters usually come in two flavors: shared nothing and shared disk.

In a shared-nothing cluster, each application server has its own file systems with its own copy of applications running in the cluster. Application updates and enhancements require updates in every node in the cluster. With this setup, large clusters become maintenance nightmares when code pushes and updates are released.

In contrast, a shared-disk cluster employs a single storage device that all application servers use to obtain the applications running in the cluster. Updates and enhancements occur in a single file system and all machines in the cluster can access the changes.