Ftp Web Hosting - PHP, MySQL, Java, Jsp, Servlet, Tomcat, Ssh Blog

public UserView authenticate( String email, String password ) throws InvalidLoginException, ExpiredPasswordException, AccountLockedException, DatastoreException, RemoteException; public List getFeaturedItems( ) throws DatastoreException, RemoteException; public ItemDetailView getItemDetailView( String itemId ) throws DatastoreException, RemoteException; } The first thing to notice about the IStorefront interface is that its methods don’t exactly match those declared by IStorefrontService. First of all, our business interface doesn’t include the logout( )and destroy( )methods found in the service interface. The reason for this is that those methods represent web-tier functionality, not true business logic that needs to move to the application tier. Also, every method in IStorefront is declared to throw RemoteException, which is not part of the declarations in IStorefrontService. All business methods exposed to a remote client of an EJB must be declared to throw RemoteException, which is used to report communication failures specific to remote method execution. This is the one aspect of a remote interface that can’t be hidden by the business interface. Without this restriction, this interface could be made to look very much like our service interface. Once we cover how our example session bean will be implemented, we’ll discuss how these mismatches between the interfaces can be handled. It’s also important to notice that our business interface is referencing the view classes already created to support the service interface. The same Data Transfer Object (DTO) pattern introduced in Chapter 7 applies to an EJB-based model. Instead of exposing the actual business object implementation classes or many fine-grained methods to access their properties, you can use simple JavaBean classes to communicate the state of the model to the client. We declared our BaseViewsuperclass to be Serializable so that the view classes could be referenced in a remote interface. DTO classes tend to consist of simple data types, so this constraint should be a minor one. With our business interface defined, Example 13-2 shows the trivial remote interface declaration we’ll need to eventually deploy our session bean. Example 13-2. The remote interface for the Storefront session bean package com.oreilly.struts.storefront.service; import javax.ejb.EJBObject; public interface Storefront extends EJBObject, IStorefront { /** * The remote interface for the Storefront session bean. All methods are * declared in the IStorefront business interface. */ }
We highly recommend you visit web and email hosting services if you need stable and cheap web hosting platform for your web applications.

implement the remote interface. This object intercepts calls made by clients of the bean, then delegates them to the implementation class after performing any operations (such as security or transaction management) that might be required. Instead of the Java compiler verifying that the bean class implements each of the business methods declared by the remote interface, that responsibility falls to the deployment tools provided by the container. Even a bean class that compiles without any errors will fail at deployment if there’s a mismatch between it and its remote interface. If you declared a session bean to implement its remote interface, you’d be guaranteed that the compiler would catch any problems with its business-method declarations. The problem is that you’d also have to provide dummy implementations of the non-business methods declared by javax.ejb.EJBObject. These methods would never be called (they’re called only on the intermediate object created by the container), but they would have to be there to satisfy the compiler. Instead of taking this approach, most EJB developers create a second interface, known as the business interface, that declares the business methods that need to be exposed. Declaring the remote interface to extend this interface and the bean class to implement it exposes the required methods, so the compiler can verify that the bean implements them. This pattern provides a convenient starting point for defining our client access mechanism. The use of a business interface also prevents programmers from accidentally passing or returning a this reference to an instance of a bean class that has been declared to implement its remote interface. This topic is beyond the scope of this book, but the short explanation is that the EJB container can manage bean instances properly only when they’re referred to using only their remote (or local) interfaces. A bean reference can’t be returned in place of its remote interface if the bean class implements only its business interface. Returning to the IStorefrontService interface that eventually must be satisfied by our implementation, recall that it contains methods related to both user authentication and the product catalog. Even when using a session fa ade, you would likely separate these responsibilities into separate session beans. This would reduce the complexity of the session beans involved and simplify their maintenance. However, given that EJB design isn’t our focus here, our first simplification will be to assume that our fa ade will consist of a single Storefront session bean. You probably wouldn’t do this in a real application, but once you know how to interface with a single session bean, applying the same technique to multiple session beans is straightforward. A suitable business interface for the Storefront session bean is shown in Example 13-1. Example 13-1. The business interface for the Storefront session bean package com.oreilly.struts.storefront.service; import java.rmi.RemoteException; import java.util.List; import com.oreilly.struts.storefront.catalog.view.ItemDetailView; import com.oreilly.struts.storefront.customer.view.UserView; import com.oreilly.struts.storefront.framework.exceptions.*; /** * The business interface for the Storefront session bean */ public interface IStorefront {
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.

13.1.3 The Business Interface When using a session fa ade, you must first define the details of the interface between the web and application tiers. You might have some questions about which side should be the primary driver of this contract between the two tiers. Early in the development of the Storefront example, the IStoreFrontService interface was introduced to define the application-tier functionality required to support the presentation needs of the application. In particular, the presentation layer relies on the supporting service to authenticate users and to provide product descriptions needed to build the online catalog. Taking a user-centered view of the application, it’s easy to see how the service-layer requirements can be driven by the web tier. After all, if a certain view is to be built, the model functionality to support it has to exist. However, one of the main reasons to implement an enterprise’s business logic within EJBs is to allow those business rules and the supporting data to be used to across multiple applications. This includes providing support for clients other than those associated with web applications. This isn’t a problem, because the division of responsibility between session and entity beans helps to protect the reusability of business logic. Because session beans are treated as extensions of the clients they serve, there’s nothing wrong with defining a session fa ade that’s specific to a particular client application. As long as your entity and message-driven beans remain independent of the client, it’s reasonable to implement a session-bean interface in response to the requirements set forth by a specific client. If multiple client views of the model are required, multiple fa ades can be implemented to support them. The fa ade presented by a session bean can support either local or remote clients. Local clients of a session or entity bean can only be other EJBs deployed within the same container. These clients are tightly coupled to the beans they access, but they offer performance advantages when calls need to be made between EJBs. This is because these method calls use pass-by-reference semantics instead of being treated as remote calls between distributed components. Session beans are often local clients of entity beans, but it’s less common for them to have local clients of their own to support. Our web-tier components obviously aren’t EJBs running within the application tier, so we care only about remote clients for our purposes here. What we need to do, then, is define the remote interface for our session fa ade. Every session bean that supports remote clients must have a corresponding remote interface that extends the javax.ejb.EJBObject interface. This interface determines the business methods that are exposed by the session bean. It might seem strange, but you’ll almost never see a method explicitly declared in a remote interface. This is because of an EJB design pattern known as the business interface. Besides its remote interface, a session bean supporting remote clients must have a home interface that extends javax.ejb.EJBHome, an implementation class, and one or more XML deployment descriptors. Unlike the remote interface, which declares the bean’s business methods, the home interface defines factory-like methods for creating session-bean references. By definition, the bean’s methods are implemented by the implementation class. The deployment descriptors identify and configure a bean for use within a particular EJB container. We’ll define each piece for our example as we go along. When you think of a class and an interface with which it’s associated, you would normally expect that the class would explicitly implement that interface. This isn’t true with remote (or local) interfaces in EJB. Instead, the container creates an intermediate object (often referred to as an EJBObject) to
In case you need affordable webhost to host your website, our recommendation is ecommerce web host services.

the user session, and possibly the database, instead of making use of stateful session beans. For this reason, we’ll focus on stateless beans for our examples here. The EJB 2.0 specification added message-driven beans as the third bean type so that EJB could be integrated with the Java Message Service (JMS). Message-driven beans differ from the other two types in that they respond asynchronously to requests instead of being called directly by a client application. The container invokes a message-driven bean whenever a JMS message that meets the selection criteria of the bean is received. For example, in a more complex version of the Storefront application, a message-driven bean could be used to respond to a notification that an item is being backordered. The bean could be responsible for emailing any customers that had orders already in place for the item. Message-driven beans have no direct interaction with client applications, so they are even less dependent on the client than entity beans are. 13.1.2 The Session Fa ade The first step in designing an interface to the application tier is to identify the entry points exposed to a client application. Message-driven beans aren’t called directly, so they don’t come into play here. However, a typical EJB application can include a number of session and entity beans. As already pointed out, standard practice is to insulate entity beans from the details of the client so that they can be reused in other applications. If your Struts actions were to interact with entity beans directly, the web tier would quickly become coupled to the object model implemented by the application tier. This tight coupling, combined with the distributed nature of EJB, would lead to a number of issues: Changes in the EJB object model would require corresponding changes in the web tier. Action classes often would be required to execute multiple remote calls to the application server to satisfy the business logic needs of a request. The business logic and transaction-management code needed to orchestrate multiple calls would have to exist in the web tier. To avoid these issues, the interface exposed to the clients of the application tier is almost always limited to session beans. This approach is commonly referred to as either “session wraps entity” or a ” session fa ade.” There are quite a few advantages to this design. When a client application makes a single call to a session-bean method to perform a required operation, the session bean can easily execute the request as a single transaction, and the implementation details can be hidden. This session- bean method might need to access a number of entity beans, or even other session beans, to satisfy the request. No matter what the flow of control is on the application server, the complexity is hidden from the client. Because session beans become the only clients of the entity beans when using a session fa ade, there’s little chance of the entities becoming tied to any particular type of external client. Even though the discussion here assumes that the business objects are implemented as entity beans, this doesn’t have to be the case in an EJB application. The same concerns and advantages that support using a session fa ade apply when other implementations are used. Just as some Java developers don’t like EJB, not all EJB developers like entity beans. Because the session fa ade hides the object model from the client, entity beans can be replaced with another approach, such as Java data objects (JDOs) or regular data access objects (DAOs), without impacting the interface exposed to the client.
We recommend high quality webhost to host and run your jsp application: christian web host services.

13.1 Implementing the Storefront Service Using EJB Even though this chapter is specific to EJB, the intent is still to keep the focus on Struts. With that in mind, the discussion of EJB implementation details will be kept to a minimum. EJB is a complex topic, but the nature of several design patterns geared toward the interaction between EJBs and their clients makes this an easier task than you might first think. After all, an overriding goal of this chapter is to demonstrate how to design an application so that your Struts classes aren’t impacted by the choice to use an EJB implementation of the model. You already have a head start on some of the central issues here, having seen how the model component of a web application can be hidden behind a service interface. In particular, you’ve seen through the Storefront example how easy it is to swap a debug model with a full implementation that accesses a database when this design approach is followed. Throughout this chapter, the Storefront example will be used to illustrate how an EJB application tier can be used with a Struts application. If it weren’t for the remote nature of accessing an EJB from a client application, this implementation choice wouldn’t make any difference to you. However, the distributed aspects of EJB must be taken into account when your web-tier classes access this type of model. What you’ll see in the remainder of this chapter are some recommendations on how best to implement the code needed to interface with the application tier. Key to this discussion is an approach for isolating the code that handles what’s unique about EJB so that your action classes aren’t affected. 13.1.1 A Quick EJB Overview The EJB specification defines three types of beans: entity, session, and message-driven. Each type of bean has a different purpose within an EJB application. Entity beans provide transactional access to persistent data and are most often used to represent rows stored in one or more related tables in a database. For example, you might implement CustomerBean, ItemBean, and OrderBean entity classes, among others, to support the Storefront application. These entity beans would incorporate the functionality provided by the corresponding business object classes in the example application. When entity beans are used, they take on the primary role of supplying the application model. They are expected to provide both the required data persistence operations and the business logic that governs the data they represent. Because the model should be reusable across applications in an enterprise, entity beans need to be independent of the types of clients that ultimately access the application tier. Session beans are often described as extensions of the client applications they serve. They can implement business logic themselves, but more often their role is to coordinate the work of other classes (entity beans, in particular). They are more closely tied to their clients, so the precaution of keeping entity beans reusable doesn’t apply to session beans to the same extent. The application tier is primarily considered to be the application model, but session beans are also referred to as “controllers” because of the coordination they do. This is especially true when session-bean methods are used to implement transactions that touch multiple business objects. Session beans can be implemented as either stateless or stateful. A stateless session bean maintains no state specific to its client, so a single instance can efficiently be shared among many clients by the EJB container. A stateful bean instance, on the other hand, is assigned to a specific client so that state can be maintained across multiple calls. Holding state in the application tier can simplify the client application logic, but it makes it more difficult to scale to a large number of clients. Typical web applications maintain their client state in
We highly recommend you visit web and email hosting services if you need stable and cheap web hosting platform for your web applications.

As you’ve seen so far, you can use Struts to build both the controller and the view components of an MVC-based application. Struts isn’t a framework for business logic or data access, so it doesn’t play a role in the model component. This means that business logic (other than presentation validation) would be out of place in an action or form class. It also means that choosing to use Struts in an application shouldn’t place any constraints on the design of the model. The separation of responsibilities in a layered architecture means that your Struts classes shouldn’t care about how your model is implemented. Likewise, the model shouldn’t care (or even know) that the controller and view are built using Struts. Up to this point, the example applications presented in this book have used the web tier to provide everything needed from the middle tier, including the business logic and database access. With this approach, the application model has consisted simply of regular Java classes deployed in the web container. These classes have had complete responsibility for servicing requests from the action classes that depend on the application model. This architecture is common among web applications, and it works well as long as the requirements in areas such as security, scalability, and transaction complexity stay within the limits of what a web container can do. Trying to do everything within the web tier can prove to be a challenge when these requirements, which aren’t necessarily as high a priority in the design of a web container as they are in other container types, become too stringent. The alternative to building the model into the web tier is to use a true application tier, such as a J2EE application server. With this approach, the web tier provides the controller and view, and the application tier supplies the business data and its associated rules. Such a design is appropriate when the scalability, security, and transactional needs of an enterprise application require a more robust container. This situation is what we want to consider in this chapter. While it’s true that the development of your Struts classes can be independent of the model implementation, this does require some effort on your part. This chapter covers some of the issues you need to consider when developing an interface between your Struts actions and an application tier. In particular, the focus here is on interfacing to a model built using Enterprise JavaBeans (EJB). To EJB or Not to EJB? As the J2EE architecture grew in significance for enterprise application development, it was often assumed that an application that didn’t include EJB wasn’t a J2EE application at all. The rush was on to build enterprise-strength systems backed by EJB containers and all they had to offer. For carefully designed applications that required the type of infrastructure inherent with EJB, the technology provided a standards-based approach that led to many successful deployments. However, the focus on the EJB portion of J2EE also led to its use in applications that could have been better served by more lightweight approaches. This, along with some developers’ disappointment with the pace of EJB’s evolution, has led to a backlash against using EJB at all. Developers fall on both sides of this issue, with some in the Struts community being quite vocal in their criticism of EJB. The more moderate opinion is that EJB offers value where its strengths are truly needed, but can be costly both in performance and complexity otherwise. This chapter won’t attempt to argue the pros and cons of EJB. That topic falls outside the scope of this book. Instead, we’ll simply presume that you’ve been asked to build a Struts- based web tier that needs to interface with an EJB application tier. With that as a starting point, the main concerns will be to identify the key issues and come up with an effective approach for addressing them.
You want to have a cheap webhost for your apache application, then check apache web hosting services.

as UTF-8. Check with the vendor’s documentation, as each one will be configured differently. You can also set up a servlet filter to do this, but this requires a container that supports the 2.3 Servlet API. Next, the contentType property within the controller element in the Struts configuration file needs to be set correctly. Set it to text/html;charset=UTF-8for HTML Unicode support. You can also specify this in the JSP pages by putting the following line at the top of each page: <%@ page contentType="text/html; charset=utf-8" %> and this line in the HTML head section: Another option is to set the content type and encoding scheme in the response object, like this: response.setContentType(”text/html; charset=UTF-8″); However, you might have to do this in several different places, making maintenance and customization more difficult. You may also have to tell the browser to always send URLs as UTF-8. There’s usually a checkbox or option to do this in IE 5.5, it’s in the advanced options section. There are two final steps to ensure that your application can fully support Unicode. The first is to make sure your database is configured for Unicode. This is usually the default, but you should verify that this is the case. Second, if you’re using the JRE rather than the SDK, use the I18N version and not the U.S. version. 12.4 Exception Handling and Internationalization Exception handling was covered in detail in Chapter 10, and as you saw, there are I18N issues that need to be considered when building an exception-handling framework for your application. Unless you plan to localize the exception messages that are thrown, you need to isolate the exception messages and be sure that they are never shown to the end user. The one thing that is more frustrating for an end user than getting an exception message or stack trace printed out on the screen is getting one that is not in that user’s native language. As Chapter 10 pointed out, exceptions should be caught and localized messages should be displayed to the user. This can be accomplished by using the Struts message resource bundle and the ActionError class. You should never display a Java exception to the end user. Even when there’s a system failure that can’t be recovered from, you should still have a system error page that is localized for the user. Chapter 13. Struts and Enterprise JavaBeans
Check Tomcat Web Hosting services for best quality webspace to host your web application.

ActionError newError = new ActionError(”error.security.invalidlogin”); errors.add( ActionErrors.GLOBAL_ERROR, newError ); saveErrors( request, errors ); return mapping.findForward( IConstants.FAILURE_KEY ); }catch( ExpiredPasswordException ex ){ ActionErrors errors = new ActionErrors( ); ActionError newError = new ActionError(”error.security.passwordexpired”); errors.add( ActionErrors.GLOBAL_ERROR, newError ); saveErrors( request, errors ); return mapping.findForward( IConstants.FAILURE_KEY ); }catch (AccountLockedException ex){ ActionErrors errors = new ActionErrors( ); ActionError newError = new ActionError(”error.security.accountlocked” ); errors.add( ActionErrors.GLOBAL_ERROR, newError ); saveErrors( request, errors ); return mapping.findForward( IConstants.FAILURE_KEY ); } This fragment is another reason why the declarative exception-handling feature of Struts is so attractive. Look at the amount of work that we did here. With declarative exception handling, all of this would be defined within the Struts configuration file. 12.3.2.1 The Bean tag library’s MessageTag class The Struts framework contains several custom tags that can be used in conjunction with the MessageResources for an application. One of the most important, however, is the Message tag that is part of the Bean tag library. This custom tag retrieves a message string from one of the bundles for an application. It supports optional parametric replacement if the JSP page requires it. All you need to do is provide the key from the bundle and specify which application bundle to use, and the tag will write out the information to the JSP page. For example, the following JSP fragment uses the MessageTag to write out the title of the HTML page: This is one tag that you will find yourself using quite often within your Struts applications. 12.3.3 Setting the Character Set Supporting character sets other than the typical U.S. default ISO-8859-1 is a little tricky. There are several steps that you must perform before your environment will be prepared to support them. First, you need to configure the application server and/or servlet container to support the character-encoding scheme that you want to use. For example, for Unicode you would tell the container to interpret input
In case you need affordable webhost to host your website, our recommendation is ecommerce web host services.

Each MessageResourcesinstance is stored in the ServletContext when the application is initialized and can be accessed from just about any component within the servlet container. However, you’ll more typically use a combination of the custom tags and the ActionMessageor ActionError classes to access the resources, rather than calling methods on the MessageResources class directly. In fact, if you use a combination of the declarative exception handling discussed in Chapter 10 and the Validator framework from Chapter 11, it’s possible that you won’t have to create ActionMessageor ActionError instances at all; the framework will do it for you automatically. If you need to create an ActionMessageor ActionErrormanually, however, you can. From the validate( ) method of an ActionForm, it would look something like this: public ActionErrors validate(ActionMapping mapping, HttpServletRequest request){ ActionErrors errors = new ActionErrors( ); if(getEmail() == null || getEmail().length( ) < 1) { errors.add(ActionErrors.GLOBAL_ERROR, new ActionError("security.error.email.required")); } if(getPassword() == null || getPassword().length( ) < 1) { errors.add(ActionErrors.GLOBAL_ERROR, new ActionError("security.error.password.required")); } return errors; } The String argument passed into the constructor of the ActionError class must be a key in the resource bundle. The ActionMessageand ActionError classes have several constructors, most of which allow you to pass in substitution arguments, for when your messages are compound messages, as explained earlier in this chapter. You can also create ActionMessages and ActionErrors from an Action class. The following is a small fragment from the Storefront LoginActionclass: // Log in through the security service IStorefrontService serviceImpl = getStorefrontService( ); String errorMsg = null; UserView userView = null; try{ // Attempt to authenticate the user userView = serviceImpl.authenticate(email, password); }catch( InvalidLoginException ex ){ ActionErrors errors = new ActionErrors( );
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.

Notice that the keys used in Example 12-3 are separated by a period (.). We could have used other characters in the keys, or we could have used a single- word key like labelPhone=Phone. Using namespacing in your keys is a great way to organize the localized text to make maintenance easier and to prevent name collisions. This is similar to how Java classes use package names. You have to be careful, however, when using characters other than the period as a separator. The colon (:), for example, can be used instead of the equals sign (=) to separate the key and the value, and it will cause problems if you use it within your keys. If you don’t want to use the period character in your keys, you can safely use the underscore or the hyphen character. Spaces are not a good choice, as they will also cause problems. 12.3.1.2 Resource bundle naming guidelines The naming of the resource bundle is critical to it working properly. All resource bundles have a base name that you select. In Example 12-3, the name StorefrontMessageResources was used as a base name. If you needed to provide an additional localized resource bundle for the French language and the country Canada, you would create a properties file called StorefrontResouces_fr_CA.properties with the appropriate localized resources. When the Struts framework searches for a message from one of the bundles, it looks for a bundle that is the closest match, based on the base name and the locale. If no locale is provided, it will use the default locale. Only when it fails to find a resource bundle with a specific language and country code as part of the name will it default to the base resource bundle. The base resource bundle is the one without any language or country code in its name. You should always provide a base resource bundle. If a user with a locale that you don’t support visits your site, the application will select the base bundle for that user. 12.3.1.3 The resource bundle and the classpath The resource bundle needs to be placed in a location where it can be found and loaded. This means that the same class loader that loads the web application must also be able to locate and load the resource bundle. For web applications, the appropriate location is the WEB-INF/classes directory. If you provide a package name for the resource bundle, it must reside in the correct package as well. For example, if you name your resource bundle com.oreilly.struts.StorefrontResources.properties, you must place it into the WEB-INF/classes/com/oreilly/struts directory. 12.3.2 Accessing the Resource Bundle The resource bundles for a Struts application are loaded at startup, and each bundle is represented in memory by an instance of the org.apache.struts.util.MessageResourcesclass (actually by its concrete subclass, PropertyMessageResources).
We recommend high quality webhost to host and run your jsp application: christian web host services.