Q) Diff Struts1.0 & 1.1?
A) 1.RequestProcessor class, 2.Method perform() replaced by execute() in Struts base Action Class
3. Changes to web.xml and struts-config.xml, 4. Declarative exception handling, 5.Dynamic ActionForms, 6.Plug-ins, 7.Multiple Application Modules, 8.Nested Tags, 9.The Struts Validator
Change to the ORO package, 10.Change to Commons logging, 11. Removal of Admin actions, 12.Deprecation of the GenericDataSource
Q) Struts Validator Framework?
A) Struts Framework provides the functionality to validate the form data. It can be use to validate the data on the users browser as well as on the server side. Struts Framework emits the java scripts and it can be used validate the form data on the client browser
Q) ActionServlet:-
The class org.apache.struts.action.ActionServlet is the called the ActionServlet. In the Jakarta Struts Framework this class plays the role of controller. All the requests to the server goes through the controller. Controller is responsible for handling all the requests.
Q) Action Class:-
The Action Class is part of the Model and is a wrapper around the business logic. The purpose of Action Class is to translate the HttpServletRequest to the business logic. To use the Action, we need to Subclass and overwrite the execute() method. In the Action Class all the database/business processing are done. It is advisable to perform all the database related stuffs in the Action Class. The ActionServlet (commad) passes the parameterized class to Action Form using the execute() method. The return type of the execute method is ActionForward which is used by the Struts Framework to forward the request to the file as per the value of the returned ActionForward object.
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
public class TestAction extends Action
{
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception{
return mapping.findForward("testAction");
}
}
Q) Action Form:-
An ActionForm is a JavaBean that extends org.apache.struts.action.ActionForm. ActionForm maintains the session state for web application and the ActionForm object is automatically populated on the server side with data entered from a form on the client side
Q) Message Resource Definition file:-
M.D.R file are simple .properties file these files contains the messages that can be used in struts project. The M.D.R can be added in struts-config.xml file through
Q) Reset:-
This is called by the struts framework with each request, purpose of this method is to reset all of the forms data members and allow the object to be pooled for rescue.
public class TestAction extends ActionForm{
public void reset(ActionMapping mapping, HttpServletRequest request request)
}
Q) execute:-
is called by the controller when a request is received from a client. The controller creates an instance of the Action class if one do not already exist. The frame work will create only a single instance of each Action class.
public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)
Q) Validate:-
This method is called by the controller after the values from the request has been inserted into the ActionForm. The ActionForm should perform any input validation that can be done and return any detected errors to the controller.
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request)
Q) Struts-config.xml
input="/employeeForm.jsp">
Q) web.xml :-
Is a configuration file describing the deployment elements.
Design Patterns Questions
Service Locator
To access different resources/services, J2EE compatible server binds these resources/services to the JNDI server so that the clients can lookup those resources/services through JNDI lookup process from anywhere in the network. The resources/services can be
1. EJBHome objects
2. DataSource objects
3. JMS ConnectionFactory
4. JMS Topic/Queue etc.
EJB Client needs to initially get EJBHome object from JNDI to manage life cycle of EJBObjects. JMS clients need to get ConnectionFactory and Topic/Queue from JNDI for processing messages. JDBC clients need to get DataSource object in order to get database connection. All these services need to bind to the JNDI services and the clients need to lookup JNDI to get those services. Clients have to go through JNDI lookup process every time to work with these services. JNDI lookup process is expensive because clients need to get network connection to the JNDI server if the JNDI server is located on a different machine and need to go through lookup process every time, this is redundant and expensive.
The solution for the redundant and expensive JNDI lookup process problem is to cache those service objects when the client performs JNDI lookup first time and reuse that service object from the cache second time onwards for other clients. This technique maintains a cache of service objects and looks up the JNDI only first time for a service object. This technique reduces redundant and expensive JNDI lookup process thus increasing performance significantly. Service Locator Pattern implements this technique by having a class to cache service objects, methods for JNDI lookup and methods for getting service objects from the cache.
The figure below shows the ServiceLocator class intercepting the client request and accessing JNDI once and only once for a service object.
Here the clients call ServiceLocator class to get a service object rather than calling JNDI directly. ServiceLocator acts as interceptor between client and JNDI. For source code and different flavors of implementation of this Pattern, see the following links.
Session Facade
EJB clients (swing, servlets, jsps etc) can access entity beans directly. If EJB clients access entity beans directly over the network, it takes more network calls and imposes network overhead.
Here the servlet calls multiple entity beans directly to accomplish a business process, thereby increasing the number of network calls.
The solution for avoiding number of network calls due to directly accessing multiple entity beans is to wrap entity beans with session bean (Facade). The EJB client accesses session bean (Facade) instead of entity beans through coarse grained method call to accomplish a business process.
Message Facade
Session bean and entity bean methods execute synchronously that means the method caller has to wait till a value is returned. In some situations like sending hundred's of mails or firing a batch process or updating processes, the client does not have to bother about return value. If you use synchronous session and entity beans in such situations, they take a long time to process methods and clients have to wait till the method returns a value.
The client has to wait till all the eight synchronous steps complete. This synchronous execution takes a long time and has an impact on performance when the method process is huge.
To avoid blocking of a client, use asynchronous message driven beans, so that client does not have to wait for a return value. If a client uses asynchronous messaging then the client need not wait for a return value but can continue its flow of execution after sending the message.
Value Object
When a client calls a remote method there will be process of marshalling, network calls and unmarshalling involved for the remote method invocation. If you choose fine grained approach when calling methods remotely, there will be a significant network overhead involved. For example if you call fine grained method like this,
remoteObject.getName();
remoteObject.getCity();
remoteObject.getState();
remoteObject.getZipCode();
Here, there are four network calls from client to the remote object because every method call is remote method call.
The solution for avoiding many network calls due to fine grained method calls is to use coarse grained approach. For example :
// create an Value Object and fill that object locally
PersonInfo person = new PersonInfo();
person.setName("Ravi");
person.setCity("Austin");
person.setState("TX");
person.zipCode("78749");
// send Value Object through network
remoteObject.getPersonInfo(person);
Here, there is only one network call instead of three network calls and PersonInfo object is a Value Object. The following figure illustrates the coarse grained approach that is passing a Value Object through network.
Value Object is an object that is passed over the network rather than passing each attributes separately thus increasing performance by reducing network calls.
ValueObjectFactory
For a single request, a client might need to access multiple server side components such as different session beans and entity beans. In such situations the client accesses multiple components over the network, this increases the network traffic and has an impact on the performance.
To reduce the network traffic due to accessing multiple components by a client for a single request, let ValueObjectFactory hold different ValueObjects as place holders and respond with a single ValueObject for a client request. Here ValueObjectFactory holds creation and delegation logic of ValueObjects for different client requests.
Value List Handler
J2EE applications generally have the search facility and have to search huge data and retrieve results. If an application returns huge queried data to the client, the client takes long time to retrieve that large data and If that application uses entity bean to search data, it has an impact on.
1. Use Data Access Objects (DAO) rather than Entity beans
2. Return small quantity of data multiple times iteratively rather than returning large amount of data at once to the client.
Data Access Object encapsulates JDBC access logic. ValueListHandler caches list of Value objects that are retrieved through DAO. When client wants to search data, It calls ValueListHandler that is in turn responsible for caching data and returning data to the client iteratively.
Singleton
There will be only one instance for the entire JVM. You can achieve this by having the private constructor in the class.
Singleton is probably the most widely used design pattern. Its intent is to ensure that a class has only one instance, and to provide a global point of access to it. There are many situations in which a singleton object is necessary: a GUI application must have a single mouse, an active modem needs one and only one telephone line, an operating system can only have one window manager, and a PC is connected to a single keyboard
Public class Singleton{
Private static final Singleton s = new Singleton();
Private Singleton(){}
Public static Singleton getInstance(){ return s;}
}
Business Delegate
The Business Delegate hides the underlying implementation details of the business service, such as lookup & access details of the EJB architecture. The business delegates acts as a client-side business abstraction and hides the implementation of the business services.
The delegate may cache results and references to remote business services. Caching can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network.
A Business Delegate uses a component called the Lookup Service. The Lookup Service is responsible for hiding the underlying implementation details of the business service lookup code. The Lookup Service may be written as part of the Delegate, but we recommend that it be implemented as a separate component, as outlined in the Service Locator pattern
Figure shows the class diagram representing the Business Delegate pattern. The client requests the BusinessDelegate to provide access to the underlying business service. The BusinessDelegate uses a LookupService to locate the required BusinessService component.
0 comments:
Post a Comment