SUMMARY 199 6.4.5.2 Handling EIS Access Authorization An application component provider relies on both the container and the EIS for authorizing access to EIS data and functions. The application component provider specifies security requirements for application components declaratively in a deployment descriptor. A set of security roles and method permissions can be used to authorize access to methods on a component. For example, an application compo- nent provider declaratively specifies the PurchaseManager role as the only security role that is granted permission to call the purchase method on a PurchaseOrder enterprise bean. The purchase method in turn drives its execution through an ERP logistics application by issuing a purchase requisition. In effect, this application has authorized only end-users with the PurchaseManager role to do a purchase requisi- tion. This is the recommended authorization model. An application component provider can also programmatically control access to enterprise information system data and functions based on the principal or role associated with the client who initiated the operation. For example, the EJB speci- fication allows component code to invoke getCallerPrincipal and isCallerInRole to get the caller’s security context. An application component provider can use these two methods to perform security checks that cannot be expressed declaratively in the deployment descriptor. An application can also rely on an enterprise information system to do access control based on the security context under which a connection to the enterprise information system has been established. For example, if all users of an applica- tion connect to the database as dbUser, then a database administrator can set explicit permissions for dbUser in the database security domain. The database administrator can deny dbUser permission to execute certain stored procedures or to access certain tables. 6.5 Summary This chapter has described designs and guidelines for integrating enterprise infor- mation systems into enterprise applications. These guidelines enable an application component provider to develop an enterprise application based on its overall func- tional and system requirements for EIS integration. The chapter focuses on access- ing EIS resources from a component, using tools to simplify and reduce application development effort involved in accessing EISes, obtaining and managing connec- tions to EISes, and supporting the security requirements of an application. DEA2e.book Page 199 Friday, March 8, 2002 12:31 AM CHAPTER 6 INTEGRATING WITH THE ENTERPRISE INFORMATION SYSTEM TIER 200 The current version of the J2EE platform includes the Connector architecture version 1.0, which provides full support for integrating all types of enterprise information systems, including database and legacy systems, with the J2EE plat- form. The JDBC API is also available for accessing relational databases. Asyn- chronous messaging is available through the JMS API. 6.6 References and Resources We recommend the following publications for more information on enterprise appli- cation integration. For more details on the J2EE Connector architecture: • The J2EE Connector Architecture. R. Sharma, B. Stearns, T. Ng. Copyright 2001, Sun Microsystems, Inc. • The J2EE Connector Specification, versions 1.0 and 2.0. Sun Microsystems, Inc. < http://java.sun.com/products/j2ee> For complete information on JDBC, see: • JDBC API Tutorial and Reference, Second Edition. S. White, M. Fisher, R. Cattell, G. Hamilton, M. Hapner. Copyright 2001, Sun Microsystems, Inc. • JDBC 2.0 API, (JDBC specification). Copyright 1998, 1999, Sun Microsys- tems, Inc. Available at < http://java.sun.com/products/jdbc> • JDBC 3.0 API, (JDBCspecification).Copyright 2000, Sun Microsystems, Inc. Available at < http://java.sun.com/products/jdbc> • JDBC 2.0 Standard Extension API (JDBC extension specification). Copyright 1998, 1999, Sun Microsystems, Inc. Available at < http://java.sun.com/products/jdbc> For more information on JMS, see: • Java Message Service, Version 1.0.2 (JMS Specification). Copyright 1998, Sun Microsystems, Inc. Available at < http://java.sun.com/products/jms> • Java Message Service API and Tutorial. M. Hapner, R. Sharma, K. Haase. Copyright 2002, Sun Microsystems, Inc. DEA2e.book Page 200 Friday, March 8, 2002 12:31 AM 201 CHAPTER 7 Packaging and Deployment by Inderjeet Singh and Vijay Ramachandran THE Java 2 Platform, Enterprise Edition, enables developers to assemble applica- tions from components. The process of assembling components into modules, and modules into enterprise applications, is called packaging. Well-designed, reusable components can be customized to their operational environment. The process of installing and customizing an application in an operational environment is called deployment. To be customizable, components need to be configurable. However, application developers should not have to repeatedly reinvent a configuration mech- anism. They need a standard mechanism that provides flexibility for configuration and supports using tools to help the process. The J2EE platform provides facilities to make the packaging and deployment process simple. It uses Java Archive (JAR) files as the standard package for modules and applications, and XML-based description and customization of com- ponents and applications. This chapter begins with an overview of the packaging and deployment process for the J2EE platform. It describes how to perform each stage in the process and provides guidelines for each stage. It concludes by dis- cussing requirements for tools that support the deployment process. 7.1 Packaging Components A J2EE component (such as a servlet or an enterprise bean) is an independent func- tional software unit that conforms to interfaces defined by a component specifica- tion, and has only explicit dependencies on its environment. A component may be a single class, but more often is a collection of classes, interfaces, and resources. The DEA2e.book Page 201 Friday, March 8, 2002 12:31 AM CHAPTER 7 PACKAGING AND DEPLOYMENT 202 J2EE platform offers five types of components: enterprise beans, servlets and JSP pages, applets, application clients, and connectors. The J2EE platform specification provides a way to bundle one or more com- ponents into a module, which is the smallest unit of independent deployment for any component type. A module may be deployed directly into a J2EE container, or one or more modules may be combined to form a J2EE application. For exam- ple, several enterprise bean components may be packaged into an EJB module that provides all or part of an application model, and that EJB module may be further combined with other modules to create a J2EE application. Modules and applications for the J2EE platform are packaged and deployed as deployment units, which are compressed archive files similar to JAR files, but with a specified internal structure and file extension. There are four types of J2EE platform modules: • EJB modules contain enterprise beans and related classes. • Web modules contain web-tier components and resources. • Application client modules contain application client classes. • Resource adapter modules contain Java connectors, resource adapters, and support libraries and resources. The deployment unit for each type of module has a structure defined by the corresponding component technology specification. For example, a Web module deployment unit is called a “Web archive,” which has (among other things) a WEB- INF directory containing support files for the module. One or more J2EE platform modules can be composed into a J2EE application, which has its own type of deployment unit. In addition to components and resources, each deployment unit contains a deployment descriptor, which is an XML file that specifies the explicit dependen- cies between each component and its environment. Deployment descriptors specify two kinds of information: • Structural information—Meta-data that describes the components contained in the deployment unit, their relationships to each other, and their external de- pendencies. Structural information corresponds to hard-coded features that are not configurable at deployment time. Such information includes the names of enterprise bean home and remote interfaces and implementation classes, entity bean primary key classes, the persistence mechanisms used, and so on. Envi- DEA2e.book Page 202 Friday, March 8, 2002 12:31 AM ROLES AND TASKS 203 ronment entry declarations and resource requirements are also part of structur- al information. A component container uses structural information to manage component instances at runtime. Changing structural information in a deployment descriptor can cause a com- ponent to operate incorrectly or not at all, because it must be consistent with inherent hard-coded features. For example, an entity bean is an entity bean be- cause itimplements the EntityBean interface,and adeployment descriptorthat says otherwise is simply wrong. • Assembly information—This optional information describes how the con- tents of a deployment unit are composed with other deployment units to pro- duce a new component. Assembly information includes enterprise bean relationship names, descriptive entries, security roles, method permissions, and the values of environment entries. Assembly information in a deployment descriptor can be changed without breaking the corresponding component, although doing so may alter the be- havior of the assembled application. See Code Example 7.1 and the text following it for an example of structural and assembly information. Each J2EE developer role has specific packaging and deployment responsibil- ities. 7.2 Roles and Tasks Three development roles play a part in the J2EE packaging and deployment process: application component providers, application assemblers, and deployers. The pack- aging and deployment tasks that each role performs are summarized in Figure 7.1. DEA2e.book Page 203 Friday, March 8, 2002 12:31 AM CHAPTER 7 PACKAGING AND DEPLOYMENT 204 Figure 7.1 J2EE Packaging and Deployment Tasks Developers in each of these roles create deployment units and perform spe- cific tasks with the deployment descriptors of the deployment units they create. 7.2.1 Application Component Provider Tasks Application component providers develop enterprise beans, HTML and JSP pages, servlets, applets, application clients, and associated helper classes. They also create the deployment descriptor for each component. Code Example 7.1 contains an excerpt from the sample application’s enterprise bean deployment descriptor: <session> <description>This is the Catalog ejb</description> <display-name>The Catalog</display-name> <ejb-name>TheCatalog</ejb-name> <local-home> com.sun.j2ee.blueprints.catalog.ejb.CatalogLocalHome </local-home> <local>com.sun.j2ee.blueprints.catalog.ejb.CatalogLocal</local> <ejb-class> com.sun.j2ee.blueprints.catalog.ejb.CatalogEJB </ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> DEA2e.book Page 204 Friday, March 8, 2002 12:31 AM ROLES AND TASKS 205 <env-entry> <env-entry-name> ejb/catalog/CatalogDAOClass </env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value> com.sun.j2ee.blueprints.catalog.dao.CatalogDAOImpl </env-entry-value> </env-entry> <resource-ref> <res-ref-name>jdbc/CatalogDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> </session> Code Example 7.1 Descriptor Elements for an Entity Bean Code Example 7.1 shows the deployment descriptor declaration of the sample application’s catalog session bean. For this example, assembly information is shown in italics and structural information is in regular code font. Notice that structural information defines the public interface of the bean and the resources the bean uses. Structural information corresponds to hard-coded features of the bean, such as the classes it uses and the environment entries and resources it accesses. Assembly information, such as the bean’s name, its description, and the values of environment entries, can be changed without causing inconsistencies with the code. Notice also that additional whitespace and newlines are significant within deployment descriptor text elements, and so should usually be avoided, except when it is truly desired. For example, text content to be used as a label may include whitespace, but resource reference names must not. An application component provider typically creates the structural informa- tion in a deployment descriptor and may assign default values for some assembly informations. Application assemblers and deployers change or define the assem- bly information to configure the component for its role in an application, but usually leave structural information unchanged. DEA2e.book Page 205 Friday, March 8, 2002 12:31 AM CHAPTER 7 PACKAGING AND DEPLOYMENT 206 7.2.2 Application Assembler Tasks Application assemblers combine existing components into applications and provide application assembly information for the application as a whole. Code Example 7.2 is an excerpt from the sample application’s Web deployment descriptor: <web-app> <servlet> <servlet-name>MainServlet</servlet-name> <display-name>HTML Client Front Controller</display-name> <description>no description</description> <servlet-class> com.sun.j2ee.blueprints.waf.controller.web.MainServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>webTierEntryPoint</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> </web-app> Code Example 7.2 Web Application Assembly Information In the sample application, the application assembler uses the deployment descriptor to configure servlet class MainServlet to serve all URLs ending in suffix .do. The application assembler also defines the error pages that the application uses, its security constraints and roles, and so on. The only structural information shown in Code Example 7.2 is the servlet class. Everything else is assembly information created by the application assembler. 7.2.3 Deployer Tasks Deployers deploy J2EE components and applications into an operational environ- ment. They use tools created by the J2EE product provider to install J2EE modules and applications and configure them to their runtime environment. The J2EE plat- form and its related specifications for releases prior to the J2EE 1.4 release define DEA2e.book Page 206 Friday, March 8, 2002 12:31 AM PACKAGING J2EE APPLICATIONS 207 some requirements for deployment tools, but do not define the interface between the deployment tools and containers; therefore, deployment tools for these releases are vendor-specific. Thus, prior to the J2EE 1.4 release, the deployment process is not standardized and portable across products. However, the J2EE 1.4 release will stan- dardize the deployment process so that work a deployer performs will be portable across products. Although the details differ from product to product, deployment typically involves two high-level tasks: 1. Installation—The deployer moves the media to the server, generates the addi- tional container-specific classes and interfaces that enable the container to manage the components at runtime, and installs the components and additional classes and interfaces into the J2EE server. 2. Configuration—The deployer resolves all the external dependencies declared by the application component provider and follows the application assembly instructions defined by the application assembler. For example, the deployer configures the data sources that the application uses to persist data and maps the security roles defined by the application assembler to the operational envi- ronment’s user groups and accounts. In some cases, a qualified deployer may customize the application components’ business logic at deployment time, us- ing tools provided with a J2EE product. For example, a deployer may write ap- plication code that wraps an enterprise bean’s business methods or may add a company’s logo to a login JSP page. 7.3 Packaging J2EE Applications A J2EE application is packaged as a portable deployment unit called an enterprise archive (EAR) file. An EAR file is standard JAR file with a .ear extension. An EAR file contains: • One or more J2EE modules • A J2EE application deployment descriptor Creation of a J2EE application is a two-step process. First, application component providers create EJB, Web, and application client modules. Second, the application assembler packages these modules together to create a J2EE appli- DEA2e.book Page 207 Friday, March 8, 2002 12:31 AM CHAPTER 7 PACKAGING AND DEPLOYMENT 208 cation module that is ready for deployment. This section discusses issues involved in both of these steps. All J2EE modules are independently deployable units. This enables compo- nent providers to create independent units of functionality without having to implement full-scale applications. Figure 7.2 illustrates the various types of J2EE modules (EJB, Web, applica- tion client, and application) and how they can be deployed. Although the figure shows only an independently deployed EJB module (at the bottom of the figure), all four types of J2EE modules can be deployed independently. To assemble an application, an application assembler resolves dependencies between components by creating links in the corresponding modules’ deployment descriptors. Each component may have dependencies on other components within the same archive, on components in different archives, or both. All such depen- dencies must be resolved before deployment. For example, in the sample application, the Web components in the WAR file need to refer to ShoppingClientController, Catalog, Account, Order, and ShoppingCart enter- prise beans in the EJB JAR file. The application assembler ensures that the description of the enterprise beans in the WAR file matches their descriptions in the EJB JAR file. The J2EE specifications place a number of requirements on components and deployment units, most of which are essential for proper component operation. Yet component containers are not required to enforce many of these rules at run- time. Application assemblers should run verifier tools (such as the one included with the J2EE SDK) on assembled EAR files to verify that their contents are inter- nally consistent. A verifier performs a number of static checks to ensure that the deployment descriptor and the archive file contents are referentially valid and conform to the EJB, servlet, and J2EE specifications. Common errors that a veri- fier can identify include mandatory naming convention violations, missing excep- tion declarations, missing deployment descriptor entries, unresolved external component and resource references, name collisions, structural information that conflicts with code, and inaccessible support classes and interfaces. In addition, a vendor-supplied verifier can check the consistency of product-specific deployment information. An intelligent verifier can guide a deployer through the process of resolving these inconsistencies, provide contextual help, and even present sug- gested solutions. While verification does not guarantee correct runtime behavior, it can catch a wide class of errors before deployment. DEA2e.book Page 208 Friday, March 8, 2002 12:31 AM [...]... relative to the root of the Web server namespace A context path is always either empty (meaning that the root of the Web application is the root of the Web server namespace) or it both begins with a slash and does not end with one • The servlet path is the part of the URI that matched the servlet mapping for the request It appears directly after the context path and never begins with a slash • The path... Application Directory Structure The root directory of the Web application is the context root, which is mapped to the context path at deployment time The context root contains the application’s JSP pages, content, graphics, applet classes, and other files that the application serves to clients These files are shown on the right in Figure 7.3 Also under the context root is the WEB-INF directory, which contains... element defines the bean’s ejb-name (TheCart) Among other things, the session element declares the bean’s home interface class Figure 7.4 shows a direct mapping from a home interface name to the actual home interface; in J2EE implementations, the map from an ejb-name to the actual component is vendor-specific For example, the J2EE reference implementation maps the ejb-name to the JNDI name of the bean’s... defines the global ejbname that serves as the reference target DEA2e.book Page 231 Friday, March 8, 2002 12:31 AM DEPLOYMENT DESCRIPTORS An enterprise bean that is a target of ejb-link can be in the same EJB module or in another EJB module within the same J2EE application The target enterprise bean must be type-compatible with the declared enterprise bean reference This means that the target enterprise. .. gives the reference a logical name (that is, the name by which the component looks up the connection factory) using a res-ref-name element This allows the component module consumer (that is, application assembler or deployer) to discover all the connection factory references used by the component The component provider also indicates the type of the connection factory, not the type of connection the. .. A bean that makes frequent calls to another bean in a separate address space can cause performance problems 7.3.2.1.3 Grouping for Circular References When two enterprise beans refer to each other, the result is a circular dependency Neither bean can function without the other, and so neither is reusable without the other In some cases redesign may eliminate these dependencies When circular references... Example 7 .6 Tag Handler for Context Path-Independent Hyperlinks Method doStartTag in Code Example 7 .6 builds a URL from the context path from the pageContext and the value of the alink tag’s href attribute It outputs an HTML a tag with href set to the constructed URL Method doEndTag simply closes the a tag Code Example 7.7 shows the result of serving the JSP page This hyperlink is portable: ... References to Enterprise Beans J2EE components look up enterprise bean home interface references by name using JNDI The deployment descriptors of both the referencing and referenced beans link the two beans together A component (an enterprise bean or Web-tier component) looks up an enterprise bean with JNDI using a logical name, which is the referencing component’s local name for the reference The application... Connection The deployer must bind the connection factory references to the actual resource factories configured in the target environment The details of how to accomplish this binding are specific to the implementation For example, in the J2EE reference implementation, a deployer uses the JNDI LinkRef mechanism to create a symbolic link to the actual JNDI name of the connection factory, which is defined by the. .. compatible with the type declared in the res-type element The res-auth subelement of the resource-ref element specifies whether resource sign on is managed by an application component or by its container See Section 6. 4.5.1 on page 1 96 for more information on resource sign on The Mailer enterprise bean calls MailHelper to open a mail session Code Example 7.14 contains the code from the MailHelper class . information defines the public interface of the bean and the resources the bean uses. Structural information corresponds to hard-coded features of the bean, such as the classes it uses and the environment. Installation The deployer moves the media to the server, generates the addi- tional container-specific classes and interfaces that enable the container to manage the components at runtime, and installs the. result is a circular dependency. Neither bean can function without the other, and so neither is reusable without the other. In some cases redesign may eliminate these dependencies. When circular