Enterprise Architecture Planning Guide

POWERTIER™ FOR THE J2EE PLATFORM ENTERPRISE ARCHITECTURE PLANNING GUIDE FROM DESIGN TO DEPLOYMENT VERSION 7.0 NOVEMBER 2001

Enterprise Architecture Planning Guide Version 7.0 Copyright  1993–2001 Persistence Software Inc. All rights in the software and the documentation reserved. This documentation is an instruction manual and not an agreement or contract. The software and documentation is provided under a license agreement containing restrictions on use and disclosure. No part of this documentation may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by information storage or retrieval system without permission in writing from Persistence Software. Reverse engineering of the software is prohibited. The software and documentation are “commercial item(s),” as that term is defined in 48 C.F.R. 2.101, consisting of “commercial computer software” and “commercial computer software documentation,” as those terms are used in 48 C.F.R. 12.212. If the software and/or documentation is/are used by a U.S. Government Agency of the Department of Defense, then such software and documentation shall be governed by 48 C.F.R. 227.7202-1 through 227.7202-4. If the software and/or documentation is/are used by a U.S. Governmental Agency not within the Department of Defense, then such software and documentation shall be considered, delivered and used as “restricted computer software,” as defined and governed by 48 C.F.R. 52.227-19. Persistence Software, Inc. products and technology are protected by U.S. Patent Nos. 5,499,371, 5,615,362, 5,706,506, and 6,078,926. PERSISTENCE, POWERTIER and PROACTIVE AGENTS are trademarks of Persistence Software, Inc. JAVA, JAVABEANS, and other JAVA-based terms used in the software and documentation are trademarks of Sun Microsystems, Inc. Other trademarks used in the software and documentation are the property of their respective owners. Information in this documentation is subject to change without notice. Persistence Software does not warrant that this document is error free. Companies, names, and data used in the software and documentation examples are fictitious unless otherwise noted.

Table of Contents About This Guide Chapter 1. Introduction The Challenges of Enterprise Development ...................................................................................... 1 PowerTier’s End-to-End Development and Deployment Solution................................................ 2 Client Tier ........................................................................................................................................ 3 Middle Tier ...................................................................................................................................... 4 Information System Tier ................................................................................................................ 4 PowerTier’s Product Suite .................................................................................................................... 5 Development Tools......................................................................................................................... 5 Runtime Processes .......................................................................................................................... 9 Chapter 2. J2EE Development J2EE and Enterprise Applications ..................................................................................................... 13 The J2EE APIs ....................................................................................................................................... 16 Enterprise JavaBeans (javax.ejb) ................................................................................................. 16 JDBC (javax.sql)............................................................................................................................. 17 JavaMail (javax.mail) and Java Activation Framework (javax.activation)........................... 17 Java Messaging Service (javax.jms)............................................................................................ 17 Java Transaction API (javax.transaction) .................................................................................. 18 JNDI (javax.naming)..................................................................................................................... 18 JavaIDL........................................................................................................................................... 18 RMI over IIOP (javax.rmi and javax.rmi.CORBA)................................................................... 18 Servlets and JavaServer Pages (javax.servlet & javax.servlet.jsp) ......................................... 19 Development Phases ........................................................................................................................... 19 Plan ................................................................................................................................................. 21 Code ................................................................................................................................................ 23 Build................................................................................................................................................ 24 Test .................................................................................................................................................. 25 Deploy in Your Production Environment................................................................................. 26 Manage ........................................................................................................................................... 27 Chapter 3. J2EE Components J2EE Clients........................................................................................................................................... 29 Web Clients.................................................................................................................................... 30 Standalone Clients ........................................................................................................................ 31 Table of Contents iii

Web Components .................................................................................................................................32 Java Servlets ...................................................................................................................................32 JavaServer Pages ...........................................................................................................................33 Enterprise JavaBeans............................................................................................................................34 Container- and Bean-Managed Entity Beans ............................................................................35 Session Beans .................................................................................................................................37 Enterprise JavaBean Structure.....................................................................................................38 Overview of Deployment Descriptors ..............................................................................................39 The Relationship of Deployment Descriptors to Modules......................................................39 Deployment Descriptor Contents ...............................................................................................41 Working with Deployment Descriptors ....................................................................................43 Chapter 4. Understanding JNDI The JNDI Architecture .........................................................................................................................45 How JNDI Services Work....................................................................................................................47 How Naming Services Resolve Names.............................................................................................48 The Difference Between Naming and Directory Services ..............................................................48 Chapter 5. Understanding Transactions Transaction Basics ................................................................................................................................51 What are Transactional Resource Managers? ...........................................................................52 When Are Transactions Required?.............................................................................................52 Transaction Design Choices................................................................................................................53 Transaction Demarcation and Method Granularity ................................................................54 Implicit and Explicit Transactions ..............................................................................................54 Transaction Types ................................................................................................................................55 Container-Managed Transactions...............................................................................................55 Bean-Managed Transactions .......................................................................................................56 Choosing Transaction Modes .............................................................................................................56 Transaction Mode Settings...........................................................................................................57 Performance Advantage of Deferring Writes ...........................................................................57 Chapter 6. The PowerTier Server J2EE Server Overview..........................................................................................................................61 How the Server Operates .............................................................................................................62 Server-Specific Commands and Tools .......................................................................................62 Types of PowerTier Servers ................................................................................................................63 The Standard PowerTier J2EE Server.........................................................................................63 The Embedded PowerTier Server...............................................................................................64 iv Enterprise Architecture Planning Guide

Chapter 7. The PowerTier Server and Your Database How the Server Uses Database Connections ................................................................................... 65 Configuring Database Connections .................................................................................................. 67 Improving Performance...................................................................................................................... 67 Chapter 8. Planning for Security Assessing the Need for PowerTier Security..................................................................................... 69 Client-Program Security Requirements............................................................................................ 70 Java-Application Clients .............................................................................................................. 70 Java-Applet Clients....................................................................................................................... 71 Java-Servlet Clients....................................................................................................................... 71 Naming-Service Security Requirements........................................................................................... 71 Certificate Authority Security Requirements .................................................................................. 72 Server-Program Security Requirements ........................................................................................... 73 Authentication............................................................................................................................... 73 Administrative API Access ......................................................................................................... 74 Custom Security-Manager Implementations............................................................................ 74 Enterprise Bean Security Requirements ........................................................................................... 74 Chapter 9. PowerTier Enterprise Features Load Balancing ..................................................................................................................................... 77 How Load Balancing Works .............................................................................................................. 78 How the PowerTier Server Publishes Itself with the Naming Service ................................. 81 How the Load-Balancing Service Resolves Names ................................................................. 82 Load-Balancing Optimization..................................................................................................... 83 Understanding Failover Issues .......................................................................................................... 83 The Benefits of Transparent Failover......................................................................................... 84 Failover-Enabled Object Types ................................................................................................... 85 Planning for Failover ........................................................................................................................... 85 Cache Synchronization........................................................................................................................ 87 The Messaging System................................................................................................................. 88 Synchronization Messages .......................................................................................................... 89 Cache Synchronization in Action ............................................................................................... 89 Chapter 10. Recommended Architecture Performance and Scalability Issues ................................................................................................... 93 Runtime Processes ............................................................................................................................... 95 A Deployed PowerTier Application .......................................................................................... 96 Hardware and Network Issues................................................................................................... 97 Table of Contents v

Component Design ..............................................................................................................................97 Entity Beans....................................................................................................................................98 Session Beans .................................................................................................................................99 Servlets and JSPs .........................................................................................................................101 Standalone Clients.......................................................................................................................101 Server Configuration Options ..........................................................................................................102 Index vi Enterprise Architecture Planning Guide

4 About This Guide The Enterprise Architecture Planning Guide introduces PowerTier for the Java 2 Platform, Enterprise Edition (J2EE). This section provides an overview to this guide in the following topics: n Intended Audience n Notational Conventions n Related Documents n The Online Documentation n Contacting Support Intended Audience The Enterprise Architecture Planning Guide introduces the PowerTier™ product to developers and system architects. This guide assumes that you understand: n the Java™ programming language n your relational database products n relational modeling concepts About This Guide vii

Notational Conventions This document uses the following conventions to distinguish special terms, and to present object model relationships: Typographic Notations This document uses the following typographic conventions to distinguish special kinds of text: Convention Description ps-gen Examples of code, command-line instructions, and user input appear in a fixed-width font. Security Guide Document titles, emphasized words, and first references to specialized terms appear in italics. EditÅCopy Window titles, field names, menu selections, and other elements of a graphical user interface (GUI) appear in a bold font. getClassName() Class names, method names, path and file names, and command (script) names appear in the same bold font when they are mentioned in body text. ClassHome; Variable or user-defined elements appear in an italicized version ps-gen perFile of their base font. CTRL-C Key combinations (or sequences) that you must input from the keyboard appear in UPPERCASE LETTERS. Object Model Notation This document uses the following notational conventions within object models: Relationship Notation zero-to-one to zero-to-one zero-to-one to one-to-one zero-to-one to one-to-many viii Enterprise Architecture Planning Guide

Relationship Notation zero-to-one to zero-to-many one-to-one to zero-to-many composite type (aggregation) relationship indicator Object Model Inheritance This document uses the following format to indicate inheritance within object models: Operating System Conventions The instructions in this document work for both the UNIX and the Windows environments. However, for simplicity, some procedures use only Windows conventions. If you are working in a UNIX environment, please substitute the corresponding UNIX conventions: the “/” (forward slash) separator for path names, and the “:” (colon) separator for environment variables. About This Guide ix

Related Documents This guide presents conceptual information to help you make high level architectural decisions. For information about developing and deploying a PowerTier J2EE application, refer to the following documentation: n Client Development Guide Describes how to create J2EE clients. n Command Center Guide: Configuring and Managing PowerTier Explains how to configure, control, and monitor the PowerTier J2EE server and the PowerTier Servlet Engine using the Command Center. n Deployment Guide Describes the process of deploying J2EE application components to development, test, and production environments. n Installation and Configuration Guide: Windows NT and UNIX Operating Systems Provides instructions for installing and configuring PowerTier for J2EE. n PowerTier Server and EJB Development Guide Provides programming information on EJBs and the PowerTier server APIs. n QuickStart Tutorial Uses a sample application to introduce new users to the PowerTier development process, tools, and environment. n Reference Guide: APIs, Commands, and File Formats Contains reference information about the PowerTier classes, files, and commands. n Security Guide Introduces general security concepts, and describes how to use the PowerTier security features, interfaces, and tools. n Tools Guide: The Rose Add-Ins, Object Builder, and Commands Describes the object modeling tools and the command for building applications. n Web Application Development Guide: The PowerTier Servlet Engine and PowerPage Provides an architectural and functional explanation of the PowerTier Servlet Engine. Explains how to develop and deploy Web applications. x Enterprise Architecture Planning Guide

The Online Documentation This version of PowerTier for J2EE includes a complete online documentation library, in both PDF and HTML format. The PDF versions enable you to print additional copies of the documentation. On UNIX systems, the documentation library comes in a tar file separate from the software. You should create a doc directory in the desired location, perhaps under PERSISTENCE_HOME, and extract the documents there. To use the documentation library, open the file doc/index.htm with your browser. On Windows systems, the PowerTier installation process places the documentation in the doc subdirectory of your PowerTier installation. To use the HTML Help (files ending in .chm), you must have Internet Explorer 4.0 or higher (though it need not be your default browser), and you must install the HTML Help update that comes with your PowerTier installation media. On Windows systems, you can open the ps-doc.chm file and use the Search tab to search across all of the books in the documentation set. To search for a phrase (or a pattern of adjacent words), enclose the phrase in quotes. Contacting Support For additional information on Persistence products, contact your distributor or sales representative. To receive customer support, you must have a current customer- support contract, which details the level of support that your company purchased. If you have a support contract, you can contact Persistence customer support as follows: e-mail: support@persistence.com telephone: 1+ 650.372.3655 fax: 1+ 650.341.8432 Internet http://support.persistence.com About This Guide xi

xii Enterprise Architecture Planning Guide

1 Introduction 1 This chapter introduces the PowerTier product in the following sections: n The Challenges of Enterprise Development n PowerTier’s End-to-End Development and Deployment Solution n PowerTier’s Product Suite The Challenges of Enterprise Development Whether your organization develops applications to serve employees, external customers, or partners, you likely face challenges common to the development of enterprise applications. In today’s competitive market, business success depends on many factors. It is no longer sufficient to be the first to market. Your application must also provide high performance and reliability, and must be easily manageable. PowerTier for the Java 2 Platform, Enterprise Edition (J2EE) offers you a solution for applications that must meet the following requirements: n provide highly performant Internet or intranet access to back-end data n scale to serve hundreds to thousands of end-users n provide continuous availability n provide remote administration 1

1 Introduction PowerTier implements the J2EE standard to satisfy your application and business requirements, and simplifies development. The use of J2EE provides the following benefits: n the Java language’s “write once, run everywhere” advantage n a standard that enables interoperability between components from different vendors n an architecture that was designed for enterprise applications that support browser or standalone clients To these advantages that come from use of J2EE, Persistence’s experience in the application server market allows us to add value with the following features: n patented caching technology to speed performance n component code generation (Enterprise JavaBeans and JavaServer Pages) n server clustering to provide load balancing and failover n transaction service extensions to provide better performance PowerTier’s End-to-End Development and Deployment Solution As a licensed J2EE vendor, Persistence distinguishes itself by providing rapid application development and a mature, tested runtime environment. Persistence products have a proven track record in ensuring the successful development and deployment of complex distributed applications. Dozens of Persistence customers have large applications in deployment and are benefiting from PowerTier technology today. Browse our Web site at www.persistence.com to read about their projects. Although many organizations recognize the benefits of standardizing on the J2EE platform, component and enterprise development present challenges to even sophisticated developers. PowerTier provides an end-to-end solution that addresses development and integration across all tiers of your application. Figure 1 illustrates the logical components as they are typically distributed across the three main tiers of a J2EE application: the client tier, the middle tier, and the back-end (information system or database) tier. J2EE containers—Web, EJB, and client—provide the runtime services for components. The runtime architecture of the application determines the physical distribution of the components. 2 Enterprise Architecture Planning Guide

PowerTier’s End-to-End Development and Deployment Solution Figure 1. J2EE Components and Application Tiers The following sections describe how PowerTier for J2EE supports development and deployment across the three main tiers of your application: n Client Tier n Middle Tier n Information System Tier Client Tier PowerTier applications support browser clients, standalone clients, or a combination of both. Requirements for client components can include support for particular browsers, security measures, or conversion of data to XML format. The PowerTier model allows client developers to concentrate on their application-specific requirements. It does so by providing the following features: n For browser clients: rapid prototyping of a Web site with a tool that generates Web components, including HTML pages and JavaServer Pages (JSPs) for accessing and updating persistent data. 3

1 Introduction n For standalone clients: a JAR file that encapsulates the methods that EJB components expose to clients and a runtime container. n Generated methods that serialize and deserialize entity bean data to and from an XML format. n Interfaces for load balancing and failover of EJB components. Middle Tier In the middle tier, PowerTier simplifies development and deployment by providing: n Mature, stable implementations of a servlet container (which also supports JSPs), an EJB container, and a J2EE server. n A distribution of the Apache Web server for development and testing. n Tools that generate components: Enterprise JavaBeans (EJBs) and JavaServer Pages (JSPs) that map to existing, or to-be created, database tables. JSP generation provides “starter” HTML files that give you a working prototype without your having to write a line of code. n Tools that automate the build, packaging, and deployment processes. n The ability to run the servlet container either independently or collocated with the EJB container. n The Command Center, a Web-based management tool that simplifies the deployment and runtime management of clusters of J2EE servers. n Support for load balancing and failover at different points in your application. Information System Tier On the information system tier, your organization might have legacy applications or databases. The PowerTier J2EE server specializes in persisting entity bean data in one or more relational databases. The server maintains pools of database connections and handles transactions. PowerTier works with the following relational databases (see your Release Notes for a matrix of supported versions): n DB2 n Informix n Microsoft SQL Server n Oracle n Sybase 4 Enterprise Architecture Planning Guide

PowerTier’s Product Suite Note: PowerTier supports all multibyte character sets, but does not support Unicode. PowerTier’s Product Suite Persistence Software offers two standards-based products for the development and deployment of enterprise multi-tier applications: PowerTier for J2EE (the Java 2 Platform, Enterprise Edition) and the CORBA-compliant PowerTier for C++. Both versions contain development tools that accelerate implementation and deployment, and application processes that provide enterprise services and high performance. Persistence’s Dynamai product, sold separately, boosts performance for Web applications. Dynamai is a proxy server that caches your dynamic, as well as static, content. Caching content in this way relieves the load on your Web server and page- generation software, while speeding up customer access to your information. With Dynamai, you can insulate your site against spikes in usage and against denial-of- service attacks. Development licenses give you access to PowerTier development tools and allow you to run the following for testing and debugging: the PowerTier Servlet Engine, the PowerTier J2EE server, the Command Center management tool, and a Web server. Deployment licenses cover the Servlet Engine, the J2EE server, and the Command Center in your production system. Contact a Persistence sales representative for more information on pricing and licensing. Development Tools PowerTier for J2EE simplifies application development, and automates the tasks of compilation and deployment, by providing the following: n Modeling Tools, which enable the rapid development of EJB components that map to your database and prototype Web components that invoke the EJB components. n Data Dictionary Readers (DDRs), which allow you to generate source code from your existing database schema. n A set of commands that automate common development and deployment tasks. 5

1 Introduction Modeling For model-based development, PowerTier provides two tools: the Object Builder and the PowerTier Add-Ins for Rose: n The Object Builder is a graphical user interface through which you enter information about your object model and database schema, and then generate source code for EJB and Web components. n The PowerTier Add-Ins for Rose also allow you to generate component source code from Rose models. To use the Rose Add-Ins, you must purchase Rose modeling software from Rational Software Corp. or one of its resellers. Figure 2 provides an example of the PowerTier Object Builder graphical user interface, and Figure 3 provides an example of the PowerTier Add-Ins for Rose graphical user interface. Figure 2. The PowerTier Object Builder 6 Enterprise Architecture Planning Guide

PowerTier’s Product Suite Figure 3. The PowerTier Add-Ins for Rose Both tools offer you these productivity advantages: n Patented object-relational mapping technology that reduces development time, and ensures code reliability and efficiency. The modeling tools generate complete source code for container-managed persistent entity beans that map to your database. This eliminates the need for specialized knowledge of SQL or JDBC-/ODBC-specific code. n The generated entity beans contain methods that serialize and deserialize the data to and from an XML format. n Automatic generation of a “starter” Web site: presentation and source files that allow Web clients to access and update relational data through container-managed entity beans. The features that differentiate the two modeling tools make each one well-suited for different types of applications. The Object Builder works best for applications with small sets of data objects, while the Rose Add-Ins support more complex applications. Table 1 summarizes the main feature differences between the two products. 7

1 Introduction Table 1. Feature Comparison of the Object Builder and Rose Add-Ins Feature Object Builder Rose Add-Ins Provides application-level granularity: the ability No Yes to view and work with multiple classes and relationships simultaneously. Provides object-level granularity: allows you to Yes Yes view the attributes and relationships of one class at a time. Generates code for CMP entity beans. Yes Yes Generates code for session beans. No Yes Allows you to invoke the compiler from the user No Yes interface. Models non-PowerTier-specific classes No Yes Data Dictionary Readers (DDRs) DDRs extract the schema from an existing database to a text file. You can edit the resulting file with the Object Builder or the Rose Add-Ins, to add PowerTier-specific object-oriented features and then generate entity beans that map to your database. PowerTier provides Data Dictionary Readers for Sybase and Oracle databases. Development and Deployment The PowerTier product includes the following command-line tools for development and deployment: n ps-makeejb for compiling and packaging EJB and standalone client components n ps-makeweb for constructing and packaging Web applications n ps-deploy for extracting the contents of J2EE archive files n ps-webadm and ps-webgui for installing and removing Web applications to and from servlet containers 8 Enterprise Architecture Planning Guide

PowerTier’s Product Suite Runtime Processes PowerTier provides a complete suite of runtime processes for the middle tier of your application. The PowerTier J2EE server hosts an EJB container, and optionally, a servlet and JSP container. The distribution includes a JNDI-compliant naming service, and the Apache Web server for development and testing. The PowerTier Command Center allows you to manage individual J2EE servers, or clusters of servers, from a Web-based interface. The following sections further describe the: n J2EE Server n Servlet Engine n Web Server n Command Center n Remote Communication and Naming Services J2EE Server The PowerTier J2EE server provides a set of critical application services for J2EE components by hosting EJB and, optionally, servlet and JSP containers. The multithreaded J2EE server transparently manages multiple client requests to increase concurrency. It handles pools of database connections to increase scalability. By default, the PowerTier server uses a high-performance memory manager. You can disable the default memory manager if you wish to use your own. The EJB container is tightly integrated with the J2EE server. It supports life-cycle services and transactions for enterprise beans. PowerTier’s patented caching technology enables it to support high volumes of requests to EJB components from hundreds or thousands of clients, with sub-second response times. Uniquely, the PowerTier J2EE server stores frequently read data in its local cache, making the data readily available to multiple clients. This minimizes communication with the back-end database, provides better performance, and maximizes the potential of limited database resources. Both the PowerTier Servlet Engine and the PowerTier J2EE server provide enterprise services such as load balancing and failover. This robust and flexible architecture allows you to choose where you want to implement these critical services to best support your application. For example, some applications may benefit the most from load balancing between the Web server and the Servlet Engine, while others may need to load balance between the Servlet Engine and the J2EE server. 9

1 Introduction If your application requires load balancing or failover of EJB objects, the PowerTier cache synchronization service supports failover of stateful objects within a server cluster. The cache synchronization service includes: n Out-of-the-box support for three messaging systems: JBroker, SpiritWave, and TIBCO’s TIB/Rendezvous (available in C++ or Java versions). JBroker and SpiritWave ship with PowerTier. You must purchase TIB/Rendezvous separately. n Support for custom integrations with other messaging systems. By extending the framework and implementing custom methods, you can support any messaging system. Servlet Engine The PowerTier Servlet Engine has two parts, a distributable servlet container and a Web server plug-in. The Web server plug-in directs HTTP requests for servlets and JavaServer pages to the servlet container. The distributable servlet container includes a built-in JSP engine, and it allows JSPs and servlets to access EJBs, a database, or other resources, as needed. The servlet container runs either as a standalone process or collocated in the same process as your PowerTier J2EE server. In either configuration, the servlet container communicates with the Web server through the Web server plug-in. Figure 4. PowerTier Server with Collocated Servlet Container Web Server PowerTier for J2EE supplies an Apache Web server for development and testing purposes. The PowerTier installation configures the Servlet Engine plug-in for the Apache Web server. The Web server provides the part of the Web container that allows 10 Enterprise Architecture Planning Guide

PowerTier’s Product Suite Web-based clients of J2EE applications to invoke Web components which access and update relational data using servlets or JSPs. You can also configure the PowerTier Servlet Engine to run with Netscape/iPlanet or IIS Web servers. Command Center The Command Center gives you the ability to configure and control individual PowerTier J2EE servers (and, optionally, clusters of servers to provide load balancing and failover). You access the Command Center with a Web browser and use it to control local and remote PowerTier servers. With the Command Center, you can start, stop, or pause—as well as add or remove—servers or clusters across the network. Remote Communication and Naming Services Remote communication in a J2EE application involves 1) remote method invocations between distributed components and 2) the actual communication connections between processes. The runtime processes involved vary according to the needs of your application. Remote Invocation For the remote invocations, PowerTier for J2EE includes JBroker, a CORBA (Common Object Request Broker Architecture) ORB (object request broker). When you build your components using PowerTier tools, they invoke JBroker’s RMI compiler to generate the underlying RMI-IIOP code. EJB components and client components use these communication services transparently as provided by their respective EJB and client containers. Note: JBroker’s jorbd is not necessary to use RMI-IIOP. The jorbd process implements naming, server activation, and authentication services. You are not required to run jorbd in your application. Communication Connections Communication connections between distributed processes can be: n IIOP (synchronous) between standalone clients and the J2EE server, between servlets and EJBs, or between EJBs in one server and another server. 11

1 Introduction n HTTP (synchronous) between Web clients and the Web server and from the Web server plug-in to the servlet and JSP engine n Java Messaging Service (JMS) (asynchronous) between JMS clients, which can be any component or process in your application. The J2EE-compliant way of locating remote object references to establish RMI-IIOP connections is through a JNDI naming service. By default, the PowerTier J2EE server uses JBroker’s COSNaming (Common Object Services Naming) service. COSNaming is the Object Management Group’s standard for CORBA naming services and is also JNDI-compliant. PowerTier also supports other JNDI-compliant naming and directory services, such as LDAP (lightweight directory access protocol), which may provide more enterprise-level functionality. PowerTier bundles the Standard version of SpiritSoft’s JMS-compliant SpiritWave JMQ product. If you require enterprise-level scalability and fault-tolerance, you can upgrade from JMQ Standard to JMQ Professional message transport. To do so, you must first obtain a JMQ Professional license key directly from SpiritSoft. Related Information See the following sources for related information: Subject Location Object Builder and Rose Add-Ins Tools Guide PowerTier EJB Server PowerTier Server and EJB Development Guide PowerTier Servlet Engine Web Application Development Guide PowerTier Command Center Command Center Guide Developing standalone J2EE clients Client Development Guide Dynamai Ask your sales representative or visit www.persistence.com The J2EE API Sun’s J2EE documentation COSNaming JBroker’s documentation JBroker’s documentation in the doc directory of your PowerTier installation and “Understanding JNDI” on page 45 12 Enterprise Architecture Planning Guide

2 J2EE Development 2 This chapter provides an overview of J2EE application development and PowerTier- specific development in the following sections: n J2EE and Enterprise Applications n The J2EE APIs n Development Phases J2EE and Enterprise Applications Sun Microsystems, Inc.’s J2EE platform reduces the complexity of developing multi- tiered applications for Internet or intranet applications. Whether your organization requires business-to-business, business-to-customer, or business-to-employee interaction, J2EE specifies components and services that support your complete infrastructure, from the user interface to the back end. The J2EE application architecture divides the runtime portion of enterprise applications into logical “tiers,” containing presentation, business logic, and data. On each of these tiers, “components”—such as EJBs, JSPs, servlets, applets, and standalone clients—encapsulate your critical data, provide application-specific logic, and present a user interface. Vendor-supplied “containers” provide the J2EE- mandated services to support the components. J2EE currently specifies the following containers: n Enterprise JavaBean (EJB) container n Web container (for JSPs, servlets, and HTML pages) 13

2 J2EE Development n Applet container n Client container Clients can include browsers for a Web-based application, GUI standalone clients, or J2EE clients on any type of networked device, such as a PDA. Web servers, servlet engines, and transactional J2EE servers host JSPs, servlets, HTML pages, and EJB components. An information system might include relational databases or legacy applications. Vendors implement the APIs defined by the J2EE platform to provide the following services for your application: n Naming and Directory (JNDI) n Messaging (JMS) n Transactions (JTA) n Remote communication (RMI over JRMP or IIOP) n Mail (JavaMail) n Direct database connectivity (JDBC) Since the distributed pieces of a J2EE application can be deployed on different hardware platforms and physical machines, this architecture requires support for remote communication between processes. Remote communication includes the following aspects: n A naming service—a way of locating another object independent of its physical location. Clients and remote servers locate each other using a JNDI-compliant naming service. n A communication protocol that dictates the format of data that is passed over the network. Similar to CORBA applications, J2EE applications employ standard network communication protocols, such as HTTP, HTTPS, JRMP, or IIOP. n A programming API that allows applications to invoke remote components. The Remote Method Invocation (RMI) API spares developers the need to explicitly code the underlying communication layer. RMI supports two communication protocols: JRMP and IIOP. These communication protocols are both synchronous: the thread sending the request typically blocks until it receives a reply. n A messaging system that transports data between distributed applications. JMS supports asynchronous messaging: the sender of a message does not wait until the recipient responds before performing further work. PowerTier ships SpiritSoft’s Standard SpiritWave JMQ messaging system. To provide access to J2EE services from outside of a firewall, you would typically use browser clients that send HTTP and HTTPs requests. Browser clients would normally access Web components, which in turn, might access EJB components. 14 Enterprise Architecture Planning Guide

J2EE and Enterprise Applications Clients inside of a firewall would likely be standalone Java or CORBA clients. The following figure illustrates the pieces involved in remote communication between a standalone Java or CORBA client making invocations on EJB components in a PowerTier J2EE server. The interactions occur in this general order: 1. The server starts up and publishes its available EJB objects in the naming service. 2. The client initializes a context object that allows it to access the remote naming service—the underlying code uses IIOP as the communication protocol. 3. The client looks up an EJB object of interest and the naming service returns an object reference to the client. 4. The client can then make a direct invocation of that object. Figure 5. Remote Communication In summary, the J2EE platform offers many benefits for enterprise development: n The Java language presents a simple, yet powerful, programming model. n Java’s “write once, run everywhere” philosophy simplifies deployment on heterogeneous platforms. n The J2EE specifications set standards for vendors, which both ensure that they provide critical services and give you a basis for comparison. 15

2 J2EE Development n Vendors implement complex services that require specialized domain knowledge, while you concentrate on your area of expertise, the business requirements of your application. n The J2EE architecture provides a model for enterprise applications that gives you a tested model upon which to build. The J2EE APIs Sun Microsystem’s Java 2 Enterprise Edition (J2EE) defines standard extensions to the Java Development Kit (JDK) that simplify the development of sophisticated, enterprise-scale EJB applications. Persistence Software, Inc. is a licensed vendor of J2EE solutions. The J2EE both: n describes a standard for vendors who implement the services, and n defines a consistent set of APIs that vendors expose to application developers. A PowerTier application can take advantage of the following J2EE services. The associated Java packages are listed in parentheses. n Enterprise JavaBeans (javax.ejb) n JDBC (javax.sql) n JavaMail (javax.mail) and Java Activation Framework (javax.activation) n Java Messaging Service (javax.jms) n Java Transaction API (javax.transaction) n JNDI (javax.naming) n RMI over IIOP (javax.rmi and javax.rmi.CORBA) n Servlets and JavaServer Pages (javax.servlet & javax.servlet.jsp) Enterprise JavaBeans (javax.ejb) The EJB specification defines the behavior of enterprise beans, and the services that an J2EE server and container must provide for those beans. PowerTier tools generate entity beans and simplify development and deployment tasks. The PowerTier server and container provide system-level services for enterprise beans. 16 Enterprise Architecture Planning Guide

The J2EE APIs Although the EJB technology is relatively young, PowerTier products leverage Persistence Software, Inc.’s extensive experience in the C++ application server market. PowerTier delivers a proven solution that incorporates Persistence’s patented database mapping and caching technologies. JDBC (javax.sql) JDBC is J2EE’s standard Java API for database communication. The JDBC API contains methods for establishing database connections, sending SQL statements, and processing the results. JDBC provides connectivity to virtually any relational database. In a PowerTier application, several types of components can use JDBC: n session beans n bean-managed persistent (BMP) beans n CMP 1.1 beans n servlets and JSPs JavaMail (javax.mail) and Java Activation Framework (javax.activation) The JavaMail 1.2 API provides a set of abstract classes for implementing a mail system. The platform-independent and protocol-independent framework allows vendors to build Java technology-based mail and messaging applications. The Java Activation Framework (JAF) is required for using JavaMail. PowerTier supports obtaining resource manager connection factories for JavaMail sessions through the deployment descriptor. The PowerTier containers and PowerTier-specific deployment descriptors support use of a JavaMail system with your PowerTier application. Java Messaging Service (javax.jms) The Java Messaging Service (JMS) API provides a framework for asynchronous communication between components in your enterprise application. PowerTier ships a development version of SpiritSoft’s SpiritWave, which provides an implementation of JMS. This single-daemon version allows you to develop and test your Java messages. You can easily upgrade to the Professional version of SpiritWave, should your application require the enterprise features. 17

2 J2EE Development Java Transaction API (javax.transaction) PowerTier implements a transaction service that supports the Java Transaction API (JTA). The PowerTier container exposes the required javax.transaction.UserTransaction interface to enterprise beans and their clients. Your custom code can use the methods exposed by the javax.transaction package as well as PowerTier extensions that provide performance enhancements. JNDI (javax.naming) The Java Naming and Directory Interface (JNDI) specification defines a common naming and directory API. JavaSoft partially implements JNDI, and service providers implement the rest of the specification. In a J2EE application, any component can use JNDI calls to locate services and other components. Sun has provided specifications for vendors of LDAP, DNS, COS naming, and DSML naming services to expose JNDI. PowerTier comes bundled with JBroker’s COS naming-compliant service and provides a load-balancing service. Both of these services implement the JNDI service provider’s interface, javax.naming.spi. JavaIDL JavaIDL is an interface definition language that allows J2EE application components to invoke external CORBA objects using the IIOP protocol. These CORBA objects may be written in any language and typically run outside the J2EE environment. RMI over IIOP (javax.rmi and javax.rmi.CORBA) The Remote Method Invocation (RMI) standard allows Java objects running in one JVM to invoke methods on objects running in a remote JVM. RMI creates a stub for the remote object in the client’s address space. This local stub acts as a proxy for the object located on the server. RMI over IIOP integrates RMI with Java IDL (Interface Definition Language), allowing you to write Java code that can communicate with any CORBA (Common Object Request Broker Architecture) application. PowerTier development tools generate the remote communication layer for your enterprise beans. JBroker, the CORBA- compliant object request broker bundled with PowerTier, uses the IIOP network protocol to handle remote communication between clients and the PowerTier server. 18 Enterprise Architecture Planning Guide

Development Phases Servlets and JavaServer Pages (javax.servlet & javax.servlet.jsp) Servlets are Java programs that run on the middle tier of your application. They respond to HTTP and HTTPS requests from Web clients by performing server-side processing and dynamically generating the results that will be passed back to the client. The JavaServer Pages (JSP) API allows you to embed Java code in a static HTML page. The PowerTier for J2EE ships the Apache Web Server and PowerTier Servlet Engine, which runs both servlets and JSPs. The PowerTier Servlet Engine compiles the Java code into a servlet, but when it generates the resulting page, it does so according to the HTML formatting of the JSP. The PowerTier Object Builder generates a starter Web site. The generated code includes JSPs that allow HTML clients to access and update relational data. You are also free to write your own servlets or JSPs. Development Phases J2EE application development resembles the usual software development phases. Figure 6 illustrates these phases. Each phase can include processes tailored to your organization and specific J2EE development tasks. The following sections describe how PowerTier tools and executables fit into these development phases. 19

2 J2EE Development Figure 6. Software Development Phases 20 Enterprise Architecture Planning Guide

Development Phases Development “Roles” The J2EE specification identifies development roles to simplify the process of developing complex, distributed applications. These roles allow the specification to assign responsibility for all development tasks, and to show where development tasks can be divided among individuals or teams with different skills and backgrounds. Your development organization need not mirror J2EE development roles, but understanding their purpose helps you adapt the J2EE development process to fit your organization’s structure. As J2EE specifications develop and mature, Sun is refining the role names and their definitions. To avoid confusion, the PowerTier documentation set refers to J2EE development roles only in cases where these terms seem necessary to clarify the division of development tasks. The following sections describe J2EE tasks and PowerTier-specific contributions during each phase of development: n Plan n Code n Build n Test n Deploy in Your Production Environment n Manage Plan In most organizations, planning includes the process of gathering and prioritizing application requirements. Requirements documents often specify the characteristics of the resulting application, while functional specifications and design documents outline the visible interfaces and underlying implementation, respectively. This section covers the level of planning and design that feed into requirements, functional specifications, and design documents. The planning phase should include analysis of the best way to take advantage of PowerTier strengths in the context of your application. The final chapters in this guide outline a “recommended” architecture. Assuming a lack of application-specific or hardware constraints, the recommended architecture would allow your PowerTier application to perform and scale to its potential. 21

2 J2EE Development Planning for a J2EE application includes both logical and physical architectural choices. At an abstract level, you can divide your requirements into logical tiers: presentation, business logic, and underlying data. These logical tiers of your application might cross the boundaries of the physical tiers of your application. n Presentation considerations include the look and feel of the interface. Your users’ requirements dictate whether you will support browser clients, standalone clients, or a combination of both. n Business logic resides in components: Client-side components include applets and J2EE clients. Server-side components include Web and EJB components. You need to decide how to distribute the business logic among these components. If your application includes browser clients, you need to make choices on how to separate presentation from business logic—servlets versus JSPs, and client-demarcated transactions versus controlling transactions in the middle tier. In EJB components, session beans handle business logic while entity beans encapsulate underlying data. n Underlying data: Assuming that you use an existing relational database, will the application access existing tables? If so, are there any constraints on the way you access these? Will the application create the data, or will the application use a combination of existing and newly-created data? You will encapsulate this data in entity beans for access by your application. Once you understand the logical relationships, and determine your components, you can map these to the physical architecture—the runtime processes you will deploy, such as Web servers, Servlet and JSP engines, EJB application servers, DB servers—and the machines and network on which they will run. You need to consider how the new application needs to interact with your existing infrastructure: n How will the application interface with existing Web servers, naming services, security, and other runtime processes? n Will clients access J2EE services from inside or outside the firewall, or both? PowerTier for J2EE offers you the following choices for your physical architecture: n Will you run the PowerTier Servlet Engine and the J2EE server in the same process or separately? n Will you run clusters of servers to provide load balancing and failover? n What level of security will you provide? For complex architectures, CASE tools such as Rational Corporation’s Rose 2000 allow you to model both the logical and physical relationships in your application. In addition, PowerTier provides Add-Ins for Rose that allow you to generate code from a 22 Enterprise Architecture Planning Guide

Development Phases Rose model. The type of code you can generate from the PowerTier Add-Ins for Rose includes: CMP entity beans that map to your database, and JSPs and HTML files that allow you to call these CMP entity beans from a browser client. Code The J2EE paradigm shifts responsibility for providing application software infrastructure away from developers to J2EE vendors. Deployment descriptors support this paradigm by allowing you to change the runtime behavior of containers and components using configuration files and tools—no coding is required. The specification divides component development responsibilities between component creators, application assemblers, and deployers. The goal is to allow a third-party vendor, or development department within an organization, to code and build components without knowing details about the runtime system in which the components will be deployed. You concentrate on your application’s business requirements, and decide whether you want to implement or purchase components to meet these requirements. Table 2 lists J2EE components and describes the coding efforts required by your organization to use these components in a PowerTier for J2EE application. Table 2. J2EE Application Components Component Requirements Browser client You are free to add HTML pages, JSPs, and servlets to your application. Standalone client PowerTier tools generate a client JAR file that publishes the PowerTier-generated CMP entity bean interfaces that are available to clients. In addition, PowerTier provides a client package that allows clients to use the PowerTier load- balancing and failover services. JSPs PowerTier tools generate the HTML pages and JSPs necessary to invoke PowerTier- generated CMP entity beans. You can use these as starting points for a Web application. You are free to add other JSPs and servlets to your application. 23

2 J2EE Development Table 2. J2EE Application Components(Continued) Component Requirements Servlets You are free to add servlets to your application. Entity Beans PowerTier tools generate CMP entity beans that map to your database. The generated beans allow you to add custom methods. You can also hand-code BMP and CMP1.1 entity beans. Session Beans You need to hand-code session beans. Each phase of component development ends with component packaging, which bundles the implementation code and a component-level deployment descriptor into a module. Web components are packaged in a Web Archive (WAR) module, while a Java Archive (JAR) module packages EJB and client components. The J2EE 1.2 specification introduces an application-level EAR file that contains the JAR and WAR modules that make up a logical application. However, it states that modules should be deployable as stand-alone units. A minimal EAR includes an application-level deployment descriptor and one or more modules. The EAR allows for inclusion of runtime libraries and documentation. Each type of module has a specific XML-format deployment descriptor and vendors are allowed to specify their own additional requirements. The XML deployment descriptor contains configuration information and the Application Naming Environment (ANE). The ANE gives components access to other components and to J2EE platform resources such as transaction management, JDBC connections, and JMS. Build PowerTier provides a variety of tools for building and packaging components. The build process for J2EE Web and EJB components includes: n For EJB components only: RMI compilation to create container-adaptor code—the generated stubs and skeletons that handle remote communication. n Java compilation to turn .java source files into compiled .class files. n Creation of deployment descriptors that define runtime behavior. n Setting the values in deployment descriptors to the appropriate value for this phase of development. 24 Enterprise Architecture Planning Guide

Development Phases n Packaging of compiled EJB classes and deployment descriptors into a Java archive (JAR) file and packaging Web components and their deployment descriptors into a Web archive (WAR) file. n The servlet container compiles Web components, JSPs and servlets, the first time they are requested. After the initial compilation, they are only recompiled if the source files have changed (although you can change this behavior through configuration). Test A comprehensive test plan for a J2EE application should include unit, integration, and stress tests. Unit testing involves verifying that each component produces the expected behavior. Integration testing ensures that components work well together and that the application is configured correctly to run in a production system. Stress testing includes running the application under load and verifying that it can handle failures gracefully. You can perform unit testing by running all tiers of your application on a single machine. You will get the best results for integration and stress testing if you are able to closely simulate the production environment and the load of requests that you expect in production. Stress testing reveals weaknesses and allows you to tune configuration to provide the best performance in your environment. Integration and stress tests might require you to deploy the tiers of your application across multiple hosts in your network. Single Machine The PowerTier development installation includes all of the executables that you need to test a J2EE application on a single machine: a Web server, the PowerTier Servlet Engine, and the PowerTier J2EE server. In addition, you need a database client installed on your machine and access to a database. PowerTier development tools help you test on a single machine. The Profile Wizard helps you verify that your environment is configured properly to develop and test on your local machine. The ps-makeejb command produces a simple J2EE server configuration file. To test Web clients, you also need to package your Web components in a WAR file and configure the Servlet Engine plug-in for the Web server. The installation provides tools and sample configuration files for Servlet Engine configuration. 25

2 J2EE Development Multiple Machines To run a PowerTier J2EE application on multiple machines, you need to have a common naming service instance to which the servers register available objects and from which clients request lookups. Web clients must be able to connect to the Web server. During testing, you may want to set up a Web server for testing that listens on a port number that differs from that used by your production Web server. The Command Center provides a browser interface for managing PowerTier J2EE servers remotely. The Command Center simplifies the process of: n Configuring servers and clusters of servers n Starting and stopping servers and clusters of servers n Monitoring servers and clusters of servers To use the Command Center to configure and deploy servers, you must first install the appropriate PowerTier executables on the remote hosts and run ps-agent, the bootstrap command that handles communication between the Command Center and the server. Deploy in Your Production Environment Test results should identify optimal production configuration settings for your application. You should keep a record of this configuration and provide it to those who will be responsible for managing and monitoring your application. The person managing deployment for production should only need to modify values that identify resources—under most circumstances, they should not modify the behavior of the application. If your application includes security, the following security tasks apply during the deployment phase of your project: n Create and Distribute Certificates n Configure the Server for Security n Protect Enterprise Beans n Provide Client-Program Security 26 Enterprise Architecture Planning Guide

Development Phases Manage The tasks involved in managing your J2EE application can vary widely, depending on your implementation. PowerTier for J2EE provides the following processes and tools for application management: n The Command Center allows system administrators to manage and monitor PowerTier J2EE servers remotely. n The PowerTier Servlet Engine provides tools to install Web applications and to manage the servlet container—when the servlet container is run separately from the J2EE server. n If your application uses security, a system administrator can monitor the security audit log and respond to security problems. Related Information See the following sources for related information: Subject Location Object Builder and Rose Add-Ins Tools Guide Development and Deployment tools Tools Guide, Deployment Guide, and Reference Guide PowerTier EJB Server PowerTier Server and EJB Development Guide PowerTier Servlet Engine Web Application Development Guide PowerTier Command Center Command Center Guide The J2EE API Sun’s J2EE documentation COSNaming JBroker’s documentation JBroker’s documentation in the doc directory of your PowerTier installation. PowerTier Security Security Guide 27

2 J2EE Development 28 Enterprise Architecture Planning Guide

3 J2EE Components 3 In a J2EE application, components contain the application-specific logic. To provide easy access for components to other remote components and J2EE resources, the deployment descriptor provides a level of indirection—allowing you to code your components without being aware of the details of the production environment. Deployment descriptors also allow you to change some component behavior without modifying code. The following sections introduce J2EE components and deployment descriptors: n J2EE Clients n Web Components n Enterprise JavaBeans n Overview of Deployment Descriptors J2EE Clients Client components provide the interface through which the user interacts with a J2EE application. The designation of “J2EE client” reflects an expected interaction with the middle tier(s) of an enterprise application. This interaction usually includes requests to Web or EJB components. The containers and components on the middle tier respond to these requests and return the results to the client components which, in turn, present them to the user. A J2EE client can: n Connect to middle-tier components across the World Wide Web, or from inside an enterprise’s intranet. n Run on hardware ranging from powerful desktop machines to tiny wearable assistants. 29

3 J2EE Components n Provide a browser-based or standalone interface. Application and system requirements often limit the extent of processing that takes place within the client components themselves. The following sections describe the differences between: n Web Clients n Standalone Clients Web Clients Web clients use browser-based interfaces. Browsers use HTML and HTTP, and might involve the use of servlets, JSPs, or applets. HTML Browsers use HTML (hypertext markup language) for the display of communications between clients and servers. HTML: n uses embedded tags for formatting n requires no compilation (it is interpreted, not compiled) n is easy to learn and simple to use Despite HTML’s simplicity, some of the simpler browsers, such as PDAs (personal digital assistants), might not support more advanced HTML features. HTTP HTTP (hypertext transfer protocol) is used as a client-server protocol on the World Wide Web for the exchange of HTML documents. HTTP provides easy access, even outside of firewalls. However, HTTP alone might not provide the required level of security for the transmission of sensitive or critical enterprise information. Servlets or JSPs Web clients can request services from the middle tier by using servlets or JSPs (JavaServer Pages): 30 Enterprise Architecture Planning Guide

J2EE Clients n A servlet is a small server-side application that extends the functionality of a Web server. Servlets receive a request from a client, dynamically generate the response, and then send the response (in the form of an HTTP or XML document) to the client. n JSP technology provides an extensible way to generate dynamic content for a Web client. A JSP page is a text-based document that describes how to process a request and create a response. The first time the JSP engine receives a request for a JavaServer page, it parses the embedded code into a Java source file, and then compiles the source file into a servlet class. The servlet container then loads and runs the servlet class file like any other servlet, sending the output back to the client browser. Applets In addition, a Web client may use applets. Applets are Java-based GUI (graphical user interface) components that typically execute in a Web browser, although they can execute in a variety of other applications or devices. Browser-based applet clients usually communicate using HTTP. Applets may also communicate over a network using serialized objects or some other proprietary protocol. Applets download and install quickly. Standalone Clients In contrast to Web clients, J2EE standalone clients require the development of a UI (user interface), compilation of client code, and configuration of client-server communications. Standalone clients have access to a variety of services, including but not limited to: n RMI-IIOP n JNDI RMI-IIOP J2EE standalone clients interact directly with EJB components, using RMI-IIOP (remote method invocation over internet inter-ORB protocol) to communicate with the EJB server. n RMI is a Java communications package for performing distributed computing. n IIOP is the standard internet protocol for COBRA (Common Object Request Broker Architecture). 31

3 J2EE Components By joining the two, RMI-IIOP provides a language-independent bridge between Java clients, Java servers, and COBRA implementations. JNDI JNDI (Java Naming and Directory Interface) is a middle-tier service used for directory lookups. It is a system that allows Java-based clients to interact with a variety of naming and directory services. n JNDI provides a client and server API that allows Java code to perform naming and directory operations. n Vendors of other directory services, such as LDAP or COSNaming services, provide JNDI-compliant services that plug into JNDI’s service-provider interface, allowing them to operate with JNDI. Web Components In the J2EE architecture, Web components provide server-side processing for Web clients. The following sections describe the two types of Web components: n Java Servlets n JavaServer Pages Java Servlets Java servlets are small, server-side Java applications that extend Web server functionality in the same way that applets extend browser functionality. Servlets excel in providing content that requires intensive processing or manipulation of data. Similar to CGI scripts, servlets generate Web pages on-the-fly, using form input or other parameters. For example, a financial trading Web site might allow you to estimate the profit you would make by selling a particular stock. A form would contain fields where you enter the number of shares you want to sell and your income tax bracket. When you submit this information, the browser sends the request to the Web server. The Web server submits your variable information to the servlet container. The servlet container 32 Enterprise Architecture Planning Guide

Web Components invokes the servlet, which obtains the current price of the stock from a database or ticker feed, performs the calculations, and generates the answer. The container responds to the Web server, which in return, supplies the results to the browser. Servlets implement the Java API defined in the J2EE Servlet 2.2 specification. Adhering to this standard allows them to interoperate seamlessly in enterprise applications where they can invoke other Java APIs. As Java programs, they are portable across platforms and Web servers. This gives servlets an advantage over CGI scripts. Although you can write CGI scripts in many programming languages, they are not portable across platforms. Servlets also remain resident in memory. When a client first requests a servlet, the Web server passes that request to the servlet container, which initiates and loads the servlet. The loaded servlet then handles subsequent requests. Since they can be multithreaded, servlets can also handle concurrent requests simultaneously. If needed, you can deploy servlets to use a single-threaded model. These features allow servlets to provide more scalability and better performance than CGI scripts. JavaServer Pages JavaServer Pages (JSPs) extend the servlet API to provide a separation of presentation and business logic. Similar to servlets, JSPs allow you to implement business logic on the server. Use of JSPs further simplifies Web application development and maintenance because they allow you to change the appearance of the generated page without changing any code. At first glance, a JSP looks like a standard HTML document. HTML provides the basic framework, while reserved elements of the page contain embedded Java code. The .jsp file name extension tells the Web server to direct the page request to a JSP engine.The JSP engine compiles the Java code on-the-fly, to produce dynamic HTML content. The first time the JSP engine receives a request for a JavaServer page, it parses the embedded code into a Java source file, and compiles the source file into a servlet class. The servlet container then loads and runs the servlet class file like any other servlet, sending the output back to the client browser. Subsequent requests for the same JSP can use the same compiled servlet. If the JSP engine detects that the class file is older than the JSP you request (or if the class file no longer exists), it recompiles based on the new JSP. You can also configure JSPs to preload, so the servlet container parses and compiles the JSP at startup. JavaServer Pages are similar to Microsoft’s Active Server Pages (ASPs). Although Active Server Pages also separate presentation from business logic, ASPs are tied to Microsoft’s Active Platform and therefore lack the platform-independence of JSPs. 33

3 J2EE Components Enterprise JavaBeans Enterprise JavaBeans are J2EE components that run inside an EJB container. The PowerTier J2EE server hosts an EJB container. Together, EJB containers and J2EE servers provide all of the necessary underlying services to support the beans—including remote communication and database connections. Enterprise JavaBeans come in two types: entity and session beans. In a J2EE application, entity beans represent persistent data, and session beans represent business processes. Table 3 compares characteristics of entity and session beans. Table 3. Comparison of Entity and Session Beans Entity Beans Session Beans Represent persistent data, which survives Short-lived, stateful or stateless objects, client, server, or database exits. which do not survive client or server exits. Clients share instances. Each instance represents a specific client (one instance per client); client calls are serialized. Support transactions. Can initiate transactions, or can act as a client of a transactional entity bean. A primary key object uniquely identifies A session bean’s state can be stored and each instance. later retrieved. While the J2EE architecture relieves you of providing the low-level infrastructure required for a distributed application, PowerTier for J2EE goes further, by generating CMP (container-managed persistent) entity beans that map to your database, and by optionally generating JavaServer Pages that allow you to access CMP beans from HTML clients. When you take advantage of this feature, you are responsible only for writing any domain-specific logic. Both entity and session beans conform to the J2EE declarative programming model: n During development or deployment, you declare naming, bean transaction, and security characteristics. n At deployment time, PowerTier tools wrap the bean with the necessary runtime services. 34 Enterprise Architecture Planning Guide

Enterprise JavaBeans n At runtime, the server intercepts all calls to Enterprise JavaBeans and provides the transactional, threading, and synchronization security behavior required before the method invocation. The sections that follow describe the different types of Enterprise JavaBeans in more detail: n Container- and Bean-Managed Entity Beans n Session Beans n Enterprise JavaBean Structure Container- and Bean-Managed Entity Beans The EJB specification allows for two ways of implementing entity beans: n Container-Managed Persistence (CMP), where the data access logic resides in the container and in the container-adapter code of the entity bean. n Bean-Managed Persistence (BMP), where the data access logic resides in the bean’s code. PowerTier for J2EE supports two kinds of CMP entity beans, PowerTier CMP beans, and CMP 1.1 beans. PowerTier CMP beans are generated by PowerTier tools, based on an object model that you create using either the Object Builder or the PowerTier Add- Ins for Rose. The source files for CMP 1.1 beans, on the other hand, are not generated by PowerTier tools; you must code them. These beans are fully compatible with the EJB 1.1 specification, and can be deployed in any EJB-compliant container. PowerTier also supports BMP entity beans. Each type of bean has its own advantages and limitations, as described in the following paragraphs. PowerTier CMP Entity Beans PowerTier tools generate all the code for CMP entity beans that map to your database. This code generation relieves you from a tremendous amount of development and testing effort. Since the external resources required by the bean are specified in configuration files that can be modified during deployment, CMP entity beans are independent of the data source. For instance, you could create an “employee” entity bean and use it with any of the PowerTier-supported databases without changing the bean. If you need to change the database schema, you can regenerate your code without overwriting any of your custom business logic. 35

3 J2EE Components PowerTier CMP beans are also the most performant of the three types of entity beans. Database calls are handled through optimized native methods, rather than through JDBC, and concurrent access is supported through the activation and synchronization of multiple instances of a bean, rather than through the serialization of requests. The one limitation to keep in mind is that these beans will only run in the PowerTier J2EE server. CMP 1.1 Entity Beans CMP 1.1 beans resemble PowerTier CMP beans, in that the container manages the moving of data between the bean instance and the database. Like PowerTier CMP beans, these beans are also independent of the data source. Moreover, they are fully compliant with the EJB 1.1 specification, which means that they will run in any EJB 1.1- compliant container. If you are writing entity beans for resale, or using entity beans purchased from a third party, these are the beans you are most likely to use. If you know that your beans will be deployed in the PowerTier environment, however, PowerTier CMP beans are a better choice, since CMP 1.1 beans do not run as efficiently. Another disadvantage is that the source code for CMP 1.1 beans—comprising the home interface, remote interface, bean class, and primary key class—is not generated by PowerTier tools: although the PowerTier container will manage persistence for your beans, saving you the labor of writing JDBC calls, you must create the source files yourself. BMP Entity Beans BMP entity beans are neither the most performant beans, nor the easiest to write, but they have their place in the EJB architecture. Although all EJB 1.1-complaint containers must support container-managed persistence, the specification does not define the mechanism by which the container provides this service. If you are writing an entity bean that will be deployed in a container whose persistence mechanism is inadequate for your needs, you will want to consider BMP entity beans. Likewise, if your data source is an existing application, rather than a database, BMP beans might be required, since you will probably need to use vendor-specific protocols for exchanging data, rather than SQL code. With BMP beans, in addition to creating the source files, you or a third-party bean provider must code each bean’s database access calls. The advantage of coding data access in the bean is that it ensures portability between J2EE servers and containers. You should be able to deploy a BMP entity bean in any container. But the disadvantage, besides the time required to develop the beans, is that if you need to change the database schema or the type of database, you will likely need to modify the BMP code. 36 Enterprise Architecture Planning Guide

Enterprise JavaBeans The following table summarizes the differences between CMP and BMP entity beans. Table 4. Comparison of CMP and BMP Entity Beans PowerTier CMP and CMP 1.1 BMP PowerTier CMP: PowerTier tools BMP: You, or a third-party vendor, generate all source code, including a write the home and remote interface, variety of SQL calls. the bean class, and the primary key class. You write JDBC calls to provide CMP 1.1: You, or a third-party vendor, the database access. write the home and remote interface, the bean class, and the primary key class. PowerTier tools generate JDBC calls for you. PowerTier CMP: PowerTier tools BMP: Same. generate deployment descriptors and container-adapter code. CMP 1.1: Same. PowerTier CMP: The PowerTier BMP: PowerTier container serializes all container allows concurrent requests to a particular instance, as the transactional and non-transactional EJB specification directs. requests, while maintaining data integrity. CMP 1.1: PowerTier container serializes all requests to a particular instance, as the EJB specification directs. PowerTier CMP: The PowerTier BMP: Code invoking BMP beans container handles transactions. Code cannot mix implicit and explicit that invokes CMP beans can mix transactions in the same transactional implicit and explicit transactions in the scope. same transactional scope. CMP 1.1: Same. Session Beans Sometimes a more difficult choice than that between types of entity beans is the choice between entity beans and session beans. Session beans should be used, not to represent persistent data, but to represent the business processes of your application: workflow, 37

3 J2EE Components business logic, and application data that is specific to a given client. Often, a successful design will use session beans in combination with entity beans. For example, you can use session beans to hide fine-grained entity bean methods in coarse-grained business logic methods, or to perform server-side processing of data from several entity beans before returning a single value to the client. When you use session beans, you must decide which of the two types to use, stateless or stateful: n Stateless session beans do not maintain their state across multiple client requests. Any session bean can serve any client request. PowerTier maintains a pool of stateless session beans for your client programs to use. This means that a relatively few stateless session bean objects can serve a large number of clients. In addition, performance is enhanced by stateless session bean pooling, since the overhead of instantiating session bean objects is greatly reduced. n Stateful session beans do maintain their state across multiple client requests. A given client gets a reference to a stateful session bean and makes all its requests to that specific instance for the duration of the client’s session. The main advantage of these beans over stateless session beans is that the bean’s client does not need to provide client-specific data to the bean with each method invocation. Stateful session beans are especially useful when the business process they represent tends to require multiple method invocations on behalf of each client. You declare whether the session bean is stateless or stateful in the session bean’s entry in the deployment descriptor. For more information on session beans, see the chapters on session beans in the PowerTier Server and EJB Development Guide. Enterprise JavaBean Structure Several Java interfaces and classes make up each enterprise bean. Each bean has a home interface, a remote interface, and a bean class. The EJB specification defines the following functionality for home and remote interfaces, and the bean class: n The home interface and its implementation (similar to a class factory in COM or CORBA): n Returns a reference to the bean’s remote interface (clients cannot get a reference to the bean class itself). n Provides bean life-cycle services: creation and deletion, and, in the case of entity beans, the finding of instances that already exist. 38 Enterprise Architecture Planning Guide

Overview of Deployment Descriptors n The remote interface and its implementation: n Allows distributed clients to invoke remote bean methods as though these methods were local. n Contains the same methods as the bean class, and delegates to the bean class for actual behavior. n Allows the container to interpose its services before method calls are delegated to the bean class. n The bean class: n Contains the implementation of the methods declared in the remote interface. n Methods are invoked by the container, when a client invokes matching methods on the remote interface. Overview of Deployment Descriptors Deployment descriptors are XML (extensible markup language) files that support the declarative model of programming. By making or modifying the appropriate deployment descriptor entries, you can change the way your application behaves—without changing the source code or recompiling. In this manner, you can speed up testing of different alternatives and defer specification of resource names until deployment time. This section presents the following information about deployment descriptors: n The Relationship of Deployment Descriptors to Modules n Deployment Descriptor Contents n Working with Deployment Descriptors The Relationship of Deployment Descriptors to Modules In a J2EE application, you package component code and one or more component-level deployment descriptor(s) into a module. Web components are packaged in a Web Archive (WAR) module, while EJB and client components both use a Java Archive (JAR) modules. Each module contains components and other resources. For example, WAR files can contain servlets, JSPs (JavaServer Pages), HTML pages, audio, and graphic files. 39

3 J2EE Components The J2EE 1.2 specification introduces an application-level EAR file that contains the JAR and WAR modules that make up a logical application. A minimal EAR includes an application-level deployment descriptor and one or more modules. The EAR allows for inclusion of runtime libraries and documentation. J2EE deployment descriptors are XML files based on Sun Microsystems’ DTDs (Document Type Definitions) Standard deployment descriptors contain configuration information and the Application Naming Environment (ANE). The ANE gives components access to other components and to J2EE platform resources such as transaction management, JDBC connections, and JMS. The J2EE-standard deployment descriptors include the following files: n the application.xml file for EAR (Enterprise Archive) files n the ejb-jar.xml file for EJB JAR files n the application-client.xml file for client-side JAR files n the web.xml file for WAR files PowerTier-specific deployment descriptors contain elements that enable the associated JAR or WAR files to take full advantage of the services and features provided by PowerTier, such as transparent failover and failback, caching, and cache synchronization. They also include elements that refer to, or are related to, elements found in the corresponding standard deployment descriptors. The PowerTier-specific deployment descriptors are: n the pt-jar.xml file that, together with standard ejb-jar.xml file, supports EJB JAR files. n the pt-application-client.xml file that, together with standard application-client.xml file, supports client-side JAR files. n the ptwar.xml file that, together with standard web.xml file, supports WAR files. Figure 7 illustrates the modules and their related deployment descriptors in a PowerTier application. 40 Enterprise Architecture Planning Guide

Overview of Deployment Descriptors Figure 7. Enterprise Archive, Modules, and Deployment Descriptors Deployment Descriptor Contents Deployment descriptors support a declarative model of programming. This means that variables, references, and resources for components can be changed at deployment time, by editing the appropriate deployment descriptor rather than changing the source code and recompiling. For components in deployment descriptors, you can specify the following types of information: n Environment entries These entries provide the J2EE-standard way of specifying variable values for a component. These values then become easily modified at production time. You might use them for values you previously would have specified as a Java property. n EJB references These references are the J2EE-standard way of providing lookup strings for your components to get references to EJB interfaces. The EJB reference provides a way for you to map the name that you use in code to the name that is actually published in JNDI. 41

3 J2EE Components n Resource references These references provide a way of mapping resources a component requires (such as a JDBC connection) to the actual implementation available in the production environment. This category includes entries for configuring J2EE services such as JMS and JavaMail, including the java.net.URL resource. URL resources allow an application to use a hard-coded alias for a reference to a URL; the alias is then mapped to the actual URL in the deployment descriptor. n Security entries If your application requires security at the component level, you must also configure security in the deployment descriptor. The attributes provided include, among other elements, security policy names and security roles. n Bean attributes Several kinds of deployment descriptor entries provide information about EJBs, depending on the type of bean involved, as illustrated by the examples in the following table: Elements for Configuring EJBs Element Applies to Possible Values persistence-type entity beans container (container- managed) or bean (bean- managed) session-type session beans stateless or stateful transaction-type (specifies entity or session beans, but container (container- transaction demarcation only session beans can use managed) or bean (bean- type for a bean) bean-managed transactions managed) and be EJB 1.1-compliant trans-attribute (specifies container-managed NotSupported, Supports, transaction attribute for a transactional method Required, RequiresNew, method) invocations Mandatory, Never, and BeanManaged 42 Enterprise Architecture Planning Guide

Overview of Deployment Descriptors Working with Deployment Descriptors Persistence provides a variety of tools for creating, extracting, merging, or updating standard and PowerTier-specific deployment descriptors. You can edit or modify a deployment descriptor using any text editor. You can use the following PowerTier tools to extract, create, update, or validate deployment descriptors: n ps-deploy Command n ps-makeejb Command n ps-makeweb Command n Editing Deployment Descriptors n Validating Deployment Descriptors Note: For an overall description of the deployment process, see the Deployment Guide. Related Information See the following sources for related information: Subject Location Object Builder and Rose Add-Ins Tools Guide Developing EJBs PowerTier Server and EJB Development Guide Developing Servlets & JSPs Web Application Development Guide Developing client applications Client Development Guide Writing Transactions PowerTier Server and EJB Development Guide 43

3 J2EE Components 44 Enterprise Architecture Planning Guide

4 Understanding JNDI 4 The Java Naming and Directory Interface (JNDI) is the API for registering and locating J2EE resources in a distributed system. The following sections introduce JNDI concepts: n The JNDI Architecture n How JNDI Services Work n How Naming Services Resolve Names n The Difference Between Naming and Directory Services The JNDI Architecture The J2EE platform provides JNDI as the naming and directory service for enterprise Java applications. Similar to CORBA’s implementation repository, JNDI enables distributed clients to easily find and invoke remote EJB objects. Figure 8 illustrates the JNDI architecture as it relates to PowerTier applications. 45

4 Understanding JNDI Figure 8. JNDI Architecture As Figure 8 illustrates, JNDI has three layers and exposes two interfaces: an API for Java clients and servers to use, and a Service Providers Interface (SPI) for vendors who provide JNDI services. The standardization of these two interfaces makes the service provider almost transparent to the Java application code. Clients can use the JNDI API to bind and lookup over a wide range of naming services. The Naming Manager layer maps each JNDI call to a service provider. JNDI’s goal is to allow plug and play of naming and directory services. However, service providers do not need to support the complete JNDI API, so you might find it helpful to compare products before standardizing on a particular vendor. 46 Enterprise Architecture Planning Guide

How JNDI Services Work How JNDI Services Work Each JNDI service vendor is free to implement in their own way the set of naming and directory services they choose to support. So, it might be helpful for you to understand the general structure of these services and know which parts might differ from vendor to vendor. All of the names in a naming system comprise the system’s namespace. Naming systems use their own naming conventions, rules that object names must follow. A naming convention defines atomic names, which cannot be divided, and compound names, conglomerates of atomic names that organize similar names in the same namespace. Figure 9 illustrates the components of a JNDI naming system. Java applications interact with naming systems through a Context object. A Context object organizes similar objects in the same namespace. A naming system can have multiple contexts, as indicated by the overlapping box. A Context can also have one or more additional contexts bound to it; a bound Context is called a subcontext. In Figure 9, Context B is a subcontext of Context A. When objects register with the naming service, the service creates a binding, a pairing of the object’s atomic name with its address that is associated with the Context on which the object is bound. To create a compound name, an object binds to a subcontext, which is a related context of the same type. Flat naming systems do not support subcontexts, while hierarchical naming systems do. Think of a context as a directory and subcontext as a subdirectory. Figure 9. Naming-System Components Before performing any JNDI operations, an application must create a bootstrapping object called an initial context. This initial context is bound to the naming service you specify. To look up an object, an application invokes methods on the initial Context 47

4 Understanding JNDI object. The naming service responds to look up requests by resolving the requested name. To resolve the name, the service determines the atomic names and searches for them in each successive Context specified by the lookup call. JNDI provides an initial context that accepts URLs as name parameters. By passing a URL to the initial Context, you can locate an object on any available naming system. For example, you could locate an object in the COS Naming service by passing in a fully-qualified URL, such as iiop://hostname:port/objectName, or an object in LDAP by passing in ldap://objectName. Note: Contexts other than the initial context generally do not allow you to pass in URLs. This means that if you have an LDAP context object (not the initial context), URLs to other naming services will not resolve, even if they are fully-qualified. How Naming Services Resolve Names Naming services differ in their naming conventions and resolution. The naming convention defines the syntax of atomic and compound names. The service then resolves names based on the naming convention. For example, DNS uses dot separators and arranges compound names from right to left, as in: sales.Persistence.com. A DNS application resolves sales.Persistence.com by searching in order through the entities represented by the atomic names: com, Persistence, and sales. LDAP uses comma delimiters for name-value pairs and also arranges compounds from right to left. For example, “ou=sales, o=Persistence, c=US” is a valid LDAP compound name that would resolve exactly as the DNS name illustrated previously. In contrast, UNIX file systems arrange compound names from left to right. The /usr/bin path resolves by searching usr to find bin. The COS Naming service uses the same naming structure as UNIX file systems. The Difference Between Naming and Directory Services As mentioned previously, JNDI naming services map objects to names. This mapping provides a way to obtain references and invoke methods on remote objects without knowing each object’s physical address in the network. The jndi.jar and providerutil.jar files (part of the j2ee.jar in your PowerTier installation) include Sun’s 48 Enterprise Architecture Planning Guide

The Difference Between Naming and Directory Services JNDI implementations. You access JNDI naming services through the javax.naming package. Naming methods include methods to obtain an initial context, to bind objects to names, and to look up objects. Directory services provide extended functionality by supporting attributes which define additional information about the objects. Clients using directory services can search for an object by its name or by its attributes. LDAP, NDS, and NIS implement directory systems. You access their directory-specific services through the javax.naming.directory package. The directory package extends the naming package to provide naming operations as well as searches by attribute. To use a directory service, you create an InitialDirContext rather than the InitialContext that you would create for a naming service. Note: The COS Naming service shipping in this release of PowerTier is not a directory service. It does not support attributes in object lookups. Directory systems such as LDAP offer more powerful searching options than simple naming systems like the RMI registry. For example, you might need to find a network printer capable of printing a certain version of PostScript. A printer name would not necessarily provide this information. However, if the printer registers attributes describing the printer languages it supports, you could find the printer you want by searching for the desired attribute. Related Information See the following sources for related information: Subject Location Registration with naming service, bean PowerTier Server and EJB Development Guide environments Client lookups Client Development Guide Controlling clusters of servers Command Center Guide The J2EE API Sun’s J2EE documentation COS Naming JBroker’s documentation in the doc directory of your PowerTier installation. 49

4 Understanding JNDI 50 Enterprise Architecture Planning Guide

5 Understanding Transactions 5 The PowerTier EJB container ensures transactional integrity for you. The following sections introduce transaction concepts: n Transaction Basics n Transaction Design Choices n Transaction Types n Choosing Transaction Modes Transaction Basics Transactions allow an application to perform a logical set of modifications as one unit of work. The transactional resource manager ensures that either: n the modifications all occur successfully and the transaction commits, or, n if an error occurs, all modifications roll back so that none of the previous changes affect the database A transaction consists of a begin() call, one or more calls that modify data, and a commit() call. The scope of a transaction consists of the calls made between a begin() and commit() pair. A context object identifies the transaction initiator and is associated with the transaction until it commits. Transaction demarcation, or management, refers to the association of a transactional context with the method and the calls necessary to complete the transaction. In a distributed application, clients, components, or containers can demarcate transactions. 51

5 Understanding Transactions What are Transactional Resource Managers? Transaction management in a J2EE application involves complex interactions between remote clients and beans and between server-side components, such as servlets, session beans, and entity beans. A transactional resource manager handles the connections to the database and creates or tracks the transaction context to ensure that a transaction either completes or rolls back and that the caller receives any appropriate exceptions. In a PowerTier application, either the PowerTier J2EE server or a JDBC driver acts as the transactional resource manager. When Are Transactions Required? In the J2EE architecture, entity beans represent persistent data. Read operations on an entity instance do not require a transaction, unless you want to lock the database row to ensure data freshness. Write operations must be performed within the scope of a transaction. For example, the following operations must be performed in the scope of a transaction: n creating a new instance n setting an instance’s attributes n forming or breaking relationships between instances n locking an instance n deleting an instance n reading an instance from the database with a lock Client components, Web components, or other EJBs can invoke methods that change persistent data. However, because the EJB container supports both implicit and explicit transactions, it is not always necessary for the caller of a transactional operation to contain the transactional logic. Implicit transactions do not contain transaction logic; the container manages the transaction. Explicit transactions must include the code to obtain a transactional context and make the appropriate transactional calls. Explicit transactions offer you more control. For example, you can group multiple changes within the scope of one transaction. You can code explicit transactions in custom methods of entity beans, in session beans, or in client code. 52 Enterprise Architecture Planning Guide

Transaction Design Choices Transaction Design Choices The J2EE APIs provide a variety of ways to access persistent data. Client and Web components can do so through EJBs or through direct JDBC connections. Client components can demarcate explicit transactions by controlling the scope of the transaction, or they can rely on server-side components to control the transactions. Server-side EJB transaction demarcation includes container- and bean-managed transactions. Transaction Demarcation versus Persistence Unfortunately, the EJB specification uses the modifiers “container-managed” and “bean- managed” to describe both transaction control and persistence—two related, but separate, concepts. Transaction demarcation identifies where the transactional control resides. Clients, beans, and the container can demarcate transactions. In contrast, bean-managed and container-managed persistence identify the underlying mechanism that manages the database connections and updates the database. The container handles connections for container-managed persistence, while bean- managed persistence relies on an external resource manager, such as a JDBC connection. In a PowerTier application, you can code bean-managed persistent (BMP) entity beans by using JDBC connections. PowerTier generates the database access code for container-managed persistent (CMP) entity beans. The EJB specification requires entity beans to use container-managed transactions, while session beans can use either container- or bean-managed transactions. As a PowerTier enhancement, both BMP and CMP entity beans can use either container- or bean-managed transactions. The variety of ways to implement transactions in a J2EE application makes it difficult to reach design decisions without understanding the implications of each choice. To shorten this learning curve, Persistence recommends an application architecture that takes advantage of the recommended J2EE architecture and PowerTier features. This architecture simplifies design and development and provides scalability and reliability for your application. Architectural choices with respect to transactions include: n transaction demarcation n the granularity of transactions n the use of implicit and explicit transactions 53

5 Understanding Transactions Transaction Demarcation and Method Granularity Transactions can be demarcated by clients, by servlets, by enterprise beans, or by the EJB container. In many distributed applications, clients run on heterogeneous platforms, including PCs or handheld devices. Server programs usually run on more powerful platforms. You can thus take advantage of hardware resources by concentrating computation-intensive transaction demarcation in server-side components. Transaction demarcation for remote clients increases the network communication required. For these two reasons, an application will generally perform best if you restrict transaction demarcation to server-side components. The J2EE and EJB specifications define the purpose of entity beans to be that of mapping objects to relational data. One primary purpose of the EJB container is to support transactions. PowerTier adds to these benefits by generating CMP entity bean code. Your application takes full advantage of these features when it relies on CMP entity beans to access and update data. However, PowerTier-generated CMP entity beans expose fine-grained methods: methods that get and set individual attributes. It is expensive to expose this level of granularity to remote clients. Session beans and servlets can service client requests and invoke entity beans as necessary. This architecture concentrates processing on the server tier and offers a simpler programming model. You can also implement custom methods in the CMP entity beans to wrap multiple changes into one transaction. This provides a good solution when a transaction requires concurrent access to multiple beans. BMP and session beans provide only serialized access to their state. In addition, session beans can handle requests from only a single client at a time. Implicit and Explicit Transactions Transactions can be implicit to code on one tier of your application and explicit to another. The implicit and explicit designation depends on whether the calling code obtains a transactional context and controls the transaction. When choosing where to demarcate transactions, you need to analyze the interaction between methods. For example, if a transaction in a session bean spans several entity beans, you probably want all of those changes to be made in the scope of the same transaction. You can accomplish this with container-managed transactions by setting the transaction attribute of the methods correctly. 54 Enterprise Architecture Planning Guide

Transaction Types Transaction Types The EJB container intercepts all invocations of enterprise beans. It handles those calls based on the bean’s transaction type, which you declare in the deployment descriptor. These types correspond to the following transactions: n Container-managed transactions, where the transaction attribute in the deployment descriptor determines transactional behavior for each bean method. n Bean-managed transactions, which require the bean code to use JDBC calls to access the database. Allowing the EJB container to manage a bean’s transactions offers the simplest, and often the most robust, design. According to the EJB specification, entity beans must use container-managed transactions. Session beans can use either container or bean- managed transactions, but cannot contain mix the transaction control type in one bean. PowerTier Still Supports 1.0 Bean-Managed Transactional Behavior As an enhancement, this version of PowerTier continues to support bean-managed transactions as described in the EJB 1.0 specification. If you need control over particular methods within a bean, you can set the transaction-attribute to BeanManaged for a bean with a transaction-type of Container. This functionality mimics the EJB 1.0 TX_BEAN_MANAGED transaction attribute. The PowerTier container then allows you to mix container-managed and bean-managed transactions in the same bean. The 1.0 and 1.1 bean-managed behavior both allow a transaction to span bean methods with a specific UserTransaction instance. Container-Managed Transactions Container-managed transactions provide the simplest programming model. By setting a bean method’s transaction attribute in the deployment descriptor, you control how the container will handle a call to that method. This declarative style of transaction management allows you to change a method’s behavior without changing or recompiling bean code. A transaction attribute can be associated with an entire bean or with individual methods on the bean. If a method has a different transaction attribute than the bean, the method’s attribute takes precedence. If a method does not have a transaction attribute and you call the method, the container uses the bean’s transaction attribute. 55

5 Understanding Transactions Bean-Managed Transactions If you want to use bean-managed transactions in your application, you can choose whether to use the UserTransaction interface or the direct JDBC connection. Persistence recommends using the UserTransaction interface in bean-managed transactions when you have multiple clients accessing the same database table concurrently. In this case, the use of UserTransaction provides for more organized coordination of transactional resource commits. To have your transaction update the PowerTier server’s shared cache you must use the UserTransaction interface. When updating through JDBC, you can use the transactional methods on a javax.sql.Connection interface. To acquire an instance of Connection, use the javax.sql.DataSource lookup mechanism through the bean’s environment. Only functionality defined in the javax.UserTransaction interface can transactionally manage JDBC resources. The extended functionality provided by the com.persistence.container.UserTransaction interface is specifically for managing PowerTier server transactional resources. Choosing Transaction Modes The PowerTier transaction service extends the JTS model by offering transaction modes that let you control write timing and read locking. The write timing modes determine the point at which the PowerTier server writes updates to the database. The read locking modes determine whether the PowerTier server obtains a lock on the database for object reads during a transaction. Writing and locking data consume database connection resources and increase network traffic. You can markedly improve your application’s performance by using the PowerTier transaction modes to best advantage. The following sections describe how to set transaction modes and discuss the impact of different settings. 56 Enterprise Architecture Planning Guide

Choosing Transaction Modes Transaction Mode Settings When you begin a transaction, the server uses the current default transaction modes set for the server. The following modes are available: k_writeImmediate Write changes as they occur. The initial default setting. k_writeOnCommit Defer the write until the commit() call. The server accumulates changes during a transaction and stores them in a buffer until you call commit() or write(). When commit() or write() is called, the server acquires the necessary connections and writes the changes to the database. k_writeNever Never write changes to the database. This mode supports cache synchronization and never acquires database connections. k_lockUponRead Lock table rows when data is read in a transaction. k_noLockUponRead Do not lock table rows when data is read in a transaction. The initial default setting. Performance Advantage of Deferring Writes The k_writeOnCommit mode postpones the point at which the server reserves database connections. If you do not defer writes, the server acquires database connections as soon as a change is made inside a transaction and holds the connections until the transaction commits. During this time, connections are unavailable to other transactions. Since the number of available connections is usually limited, you can gain a performance advantage by reducing the length of time the server holds connections. Figure 10 illustrates connection acquisition using the k_writeOnCommit mode. 57

5 Understanding Transactions Figure 10. Connection Acquisition When Writes are Deferred to Commit The performance advantage of deferred writes can be increased by using the batch writes setting.By using deferred writes together with batch writes you can reduce the number of network calls in the interactions listed in Table 5. Table 5. Method Call Sequences that Write Timing Affects Method Call Sequence Results in... a create followed by a remove on the same object no database call a remove followed by a create on the same object 1 (one) database call three updates to the same object 1 (one) database call 58 Enterprise Architecture Planning Guide

Choosing Transaction Modes Related Information See the following sources for related information: Subject Location Writing server-side transactions PowerTier Server and EJB Development Guide Writing client-side transactions Client Development Guide Setting server transaction modes PowerTier Server and EJB Development Guide & Command Center Guide Setting transaction attributes Reference Guide information on deployment descriptors 59

5 Understanding Transactions 60 Enterprise Architecture Planning Guide

6 The PowerTier Server 6 The PowerTier server provides a robust, scalable runtime environment for your EJB, and optionally, Servlet container. The following sections introduce the PowerTier server: n J2EE Server Overview n Types of PowerTier Servers J2EE Server Overview The PowerTier server provides both standard EJB and PowerTier-enhanced services for your enterprise beans and clients. You can configure these services in application code, or at runtime. Runtime configuration allows you to change application behavior without changing code and recompiling. For applications that require custom behavior beyond that offered by configuration, the PowerTier server provides a customizable architecture. This architecture allows you to code Java classes that receive callbacks during the server’s life cycle and perform custom functions. Enterprise applications must often service thousands of clients concurrently. To meet these needs, the PowerTier J2EE server offers failover and load-balancing services. To use these services, you run clusters of PowerTier servers—multiple instances that load a common set of enterprise beans—that are strategically distributed across your network. 61

6 The PowerTier Server How the Server Operates The PowerTier server has three main life-cycle states: stopped, paused, and running. In the process of changing from one state to another, the server goes through transitional states, such as run pending and pause pending. In its running state, the server can receive and process client requests. The paused state allows configuration of services that must be initialized before the server enters the running state. On transition from one server state to another, the server makes calls to listeners, allowing them to perform state-dependent operations. Listeners are classes that register with the server to receive state-transition notification. The server has a default listener that applies server configuration in the correct order (load beans, configure cache service, create database connections, and configure classes) when the server starts. You can register additional server listeners to perform custom state-dependent tasks. Server-Specific Commands and Tools PowerTier for J2EE provides tools and commands for configuring and managing the PowerTier J2EE server. To help you choose the appropriate tool, the following sections describe the characteristics of the tools you use for: n Configuring the PowerTier J2EE Server n Starting the PowerTier J2EE Server Configuring the PowerTier J2EE Server At startup, the server obtains its runtime configuration from an XML file with a .ptc extension. The ps-makeejb command generates a minimal configuration file that you can use during development and unit testing. You can make minor changes in this file with any text editor. However, Persistence does not recommend that you try to add significant configuration elements to this file. Hand-coding XML syntax can be painstaking and error-prone. The Command Center provides a Web-based interface for creating and editing the more complex server configuration files that you will probably need for integrated testing and deployment. 62 Enterprise Architecture Planning Guide

Types of PowerTier Servers Starting the PowerTier J2EE Server During development and unit testing, you will probably find it simplest to use the ps-run-server command to start the PowerTier J2EE server. The ps-run-server command requires you to specify the location of a valid server configuration file. You must also provide a PowerTier JAR file—either in the default pantry, or in a location that you specify on the command line. During integrated testing and deployment, the Command Center simplifies the management of individual PowerTier J2EE servers and clusters of servers. The Command Center allows you to configure, start, and stop servers on remote hosts. To configure and deploy servers, you must first install a production version of PowerTier on the remote hosts, and run ps-agent, the bootstrap command that handles communication between the Command Center and server. Types of PowerTier Servers You can run the PowerTier server as a standalone process or embed the PowerTierServer class in your own main() method. The set of PowerTier features you can take advantage of varies depending on which type of server you use. The following sections describe the server types and explain which features are available from each: n The Standard PowerTier J2EE Server n The Embedded PowerTier Server The Standard PowerTier J2EE Server When run as shipped by Persistence, the PowerTier J2EE server calls the PowerTierServer.main() method. This server needs only a deployable JAR file to be a complete application. You can also extend the standard server by adding your own listener classes. When you use the standard server for your application, the following are true: n You can use the Command Center to manage and monitor your application. n You can use the ps-run-server command to run the server from the command line, for example when testing the application. n On Windows NT systems, the server can run as an NT service. 63

6 The PowerTier Server n The server registers the default server manager listener during startup. You extend the PowerTier server by registering an additional custom listener or by substituting your own for the default listener. n The server instantiates the default command handler class, and you can substitute a custom command handler if desired. The Embedded PowerTier Server If your application needs a custom main() method, it can still have some of the Command Center benefits by initializing and running a PowerTierServer instance within the application. When you embed the PowerTierServer class in your own main(), the following are true: n You can configure and monitor the server in the Command Center if desired. The Command Center pause and restart buttons work, but the Command Center cannot start your server. It cannot launch the JVM, because it lacks your particular class name and the necessary main() method arguments (neither the Command Center nor ps-run-server can start this kind of server). n The default server manager listener is registered during startup. You can register an additional custom listener or substitute one for the default listener if desired. n The default command handler class is instantiated, and you can substitute a custom command handler if desired. Related Information See the following sources for related information: Subject Location PowerTier EJB Server PowerTier Server and EJB Development Guide PowerTier Servlet Engine Web Application Development Guide Configuring the EJB server and Command Center Guide controlling multiple servers 64 Enterprise Architecture Planning Guide

7 The PowerTier Server and Your Database 7 The PowerTier server manages pools of database connections for your application. EJBs that obtain JDBC connections do not make use of the PowerTier database services. The following sections describe how the PowerTier server interacts with your database: n How the Server Uses Database Connections n Configuring Database Connections n Improving Performance How the Server Uses Database Connections The PowerTier server obtains and manages database connection pools for your application. Each pool maps entity beans to a database and provides the connection parameters. By using multiple connection pools, a PowerTier application can connect to multiple databases or apply different parameters, such as the username and password, to different classes. You can configure connection pools in one of the following ways: n by using the Profile Wizard to create a default connection pool n by using the Command Center, and entering Connection Pools information n by entering parameters in the ConnectionPools element of the server configuration file n by writing code that creates and sets connection specifications 65

7 The PowerTier Server and Your Database Connection specification parameters include a minimum and a maximum number of connections. When the server starts, it attempts to obtain the minimum number of connections for each set connection specification and maintains a pool of connections to handle transactional invocations. At runtime, the PowerTier server associates transactions with database connections. The server associates one connection from each set connection specification with each transaction. When a transaction completes, the server returns that transaction’s connections to the pool. The server acquires new connections, as needed, until it reaches the maximum number in the connection specification. If the maximum number of connections are all in use, incoming requests block until a connection is free. The PowerTier server maintains database connections in the pool, until they have been idle in the pool for the number of seconds you specify as the idleTimeout (in the DBConnParam class or in server configuration). Once a connection has been idle in the connection pool for that duration, the server terminates the connection, thus freeing it for other applications. The default idle timeout for database connections is 300 seconds (five minutes). The PowerTier server’s connection management saves you from having to explicitly code connection control. It also allows many clients to share a few database connections. Notes: 1. If you are using cache synchronization, cooperating servers must connect to the same database. You cannot use multiple connections or replicated databases. 2. Configuring database connections programmatically requires you to get a reference to the DBConnMgr and the DBClassMgr from the Finder. If your application uses the security features, there may be restrictions on access to these three APIs. Your security administrator or server programmer can tell you about any security policies set on the administrative APIs in your application. For more information on controlling access to the PowerTier administrative APIs, refer to the Security Guide. 66 Enterprise Architecture Planning Guide

Configuring Database Connections Configuring Database Connections You can create and set connection specifications programmatically or through server configuration, using the Command Center. These two methods are entirely independent of one another. The Command Center is unaware of connections you create programmatically. Your code cannot directly call methods (such as setDBConnSpec()) on connections you configure through the Command Center. Generally, you application will need connections configured one way or the other, depending upon the complexity of its required connections and the frequency with which they change. If you need to change connection specifications frequently (such as during development and testing), you might prefer creating and setting them through server configuration. These changes take effect once the server is paused and restarted, rather than requiring a recompile to use the new connection specifications. Refer to the Command Center Guide for details on creating and setting database connection specifications through server configuration. Improving Performance The number of database connections available to your application has an impact on performance. When the server associates a transaction with a connection, it associates it with one connection from each database connection specification that has been set. This prevents deadlock when multiple clients access multiple databases concurrently. If no database connections are available and the maximum number of connections specified by your application has not been reached, the PowerTier server opens another database connection. After the PowerTier server opens a database connection, it does not close it until your application resets or stops the PowerTier server. After the maximum number of connections has been reached, incoming requests block until a connection frees up. This behavior makes the connection specification with the lowest number of maximum database connections the gating factor. For instance, if spec1 defines ten maximum connections for database1 and spec2 defines five maximum connections for database2, five is the effective maximum number of connections. While five transactions are associated with connections, incoming requests will block because no spec2 connections are available. 67

7 The PowerTier Server and Your Database An additional consideration is write timing. The point at which a transaction becomes associated with the connection depends whether the write timing is immediate, on commit, or never. The default write timing is immediate. Your application can change the default write timing using the ServerMgr.setDefaultTransactionModes() or change it per transaction using the UserTransaction beginWithModes() method. The write timing affects connection acquisition as follows: k_writeImmediate Acquire database connection upon transaction’s begin (whether implicit or explicit). k_writeOnCommit Acquire database connection as late as possible (with first write, set savepoint, or commit call). k_writeNever Do not acquire connection. To determine the maximum number of connections to allow for a particular database, consider the database limits, the number of PowerTier servers accessing the database concurrently, the write timing, and the total number of applications accessing the database. For example, if a database only allows 20 connections and only two servers will be accessing the database concurrently, each might use a maximum of 10 connections. If the write timing is k_writeOnCommit, transactions will not tie connections up for as much time and you might not need as many connections. Note: While little or no performance cost is involved with setting the maximum number of connections too high, a significant performance cost is involved in specifying too few connections. Related Information See the following sources for related information: Subject Location Setting database connection pools PowerTier Server and EJB Development Guide programmatically & Reference Guide Configuring database connection Command Center Guide pools at runtime 68 Enterprise Architecture Planning Guide

8 Planning for Security 8 The level of security required by applications varies widely. The following sections introduce the features of PowerTier security: n Assessing the Need for PowerTier Security n Client-Program Security Requirements n Naming-Service Security Requirements n Certificate Authority Security Requirements n Server-Program Security Requirements n Enterprise Bean Security Requirements Assessing the Need for PowerTier Security The PowerTier APIs are designed to be low-overhead and high-performance. Every feature that you add means more coding, possible errors, and additional memory and CPU requirements when the program runs. Therefore, if your application does not need PowerTier security, it should not use PowerTier security. If your application can be properly secured in other ways, it may not need PowerTier security at all. Consider some of the following alternatives: n You can use firewalls to protect the application server machines and the naming- service host. n You can configure the host computers to protect against common Internet attacks. (You should do this whether you use PowerTier security or not.) n You can use router configurations or VPNs to limit access to your application. 69

8 Planning for Security Your application may require these kinds of efforts in any case, so relying on them (if they are sufficient) avoids work. If your application does not need the PowerTier security features, do not specify a SecurityPolicies element in the server configuration (.ptc) file. The server will not allocate resources for security management. Client-Program Security Requirements What kind of clients does your application use? PowerTier security features support: n Java-Application Clients n Java-Applet Clients n Java-Servlet Clients In general, if client programs are using read-only access, consider whether they actually require the privacy guaranteed by encryption. If only privacy is important, consider using weak encryption (DES) rather than strong encryption (3DES), to achieve better performance. Most client programs will require authentication, however, to verify that the user is allowed access at all. You must always use authentication if your application uses access control; PowerTier cannot determine if a user is acting in an authorized role if it does not know who the user is. At this point in your analysis, you should look at the client program actors and their related use cases (UML or another object-oriented notation can be useful for this). You can use the results of this analysis to determine the proper security roles for your application and to determine which roles should have access to which beans or methods. This kind of analysis is also useful in designing bean interfaces whose methods do not require different access controls depending on parameter values. For instance, a method isCurrent(boolean) might be callable by anyone if the parameter is true, but only by managers if the argument is false. You should change such an interface to two methods: currentIsTrue() (callable by anyone) and currentIsFalse() (callable only by managers). The authorized roles on these methods do not need to vary with the parameter values. Java-Application Clients A client program that is a Java application can use secure communications with the PowerTier server from its very first message. No additional message protection is required. 70 Enterprise Architecture Planning Guide

Naming-Service Security Requirements If your application uses any authentication, the client program needs to get the user name and password from its user. This client program also needs a local copy of the trusted CA certificate (usually distributed and installed with the client software) and the program needs to know the location of the certificate file. Java-Applet Clients A Java-applet client’s first communication to the Web server is made in the clear. This may be acceptable to you; all this first step does is download the applet code. However, if your application requires privacy on the applet download, you may need to configure the Web server to use its SSL (or similar features) to protect this initial message. Applet clients must get authentication information from the user at startup. They can download the trusted CA certificate and thus need not have one installed on the client host computer. This certificate file must, however, exist on the Web server’s host computer and the applet code needs to know its location. Java-Servlet Clients A servlet client’s communications to the Web server are always made in the clear. If these messages require privacy, you will need to configure SSL (or some similar protection) between the Web server and the client browsers. Servlet clients must get authentication information from their users. They require a copy of the trusted CA certificate on the computer that hosts the servlet (the Web server’s computer). Servlets need to know the location of the CA certificate file. Naming-Service Security Requirements Consider the role of the naming service in your application. Client programs of all types use the naming service to get an initial object reference to the PowerTier server. Relevant concerns are: n Must the naming service be outside your system’s firewall (or other network-level protection) or can it be kept inside? If your application uses only servlet clients (or if all client programs can tunnel through the firewall safely), you may be able to protect the naming service by keeping it inside the firewall. 71

8 Planning for Security n Does your application use a naming service that has its own security features? JNDI-compliant naming services (such as some LDAP services) often provide options for authentication of their users and encryption of their communications. If your naming service provides these options, consider their use to protect your naming service. n Does your application require security on the acquisition of object references? PowerTier uses client authentication and access control to protect against the invocation of any secure resource by an unauthorized principal. Calls on such an object reference result in an exception. Because of this protection, your application may not require a secure naming service. PowerTier’s COS Naming Service and Security In this release of PowerTier, the COS Naming service does not support the optional JNDI security features. This potentially leaves the COS Naming service open to the following security attacks: n Denial of service by unbinding references. If an attacker unbinds the references in the naming service, client programs will be unable to find references to any server object and thus will not function. n Impersonation of service by rebinding references. If an attacker rebinds the references in the naming service, he can have his program pretend to be the PowerTier server and intercept messages intended for it. If these risks (described above) are unacceptable for your application, you should use a JNDI implementation such as secure LDAP. Certificate Authority Security Requirements The certificate authority issues all digital certificates for a secure PowerTier application. Anyone who can access the software’s host computer and issue the ps-ca command can create (possibly bogus) certificates for authentication in your application. Because the certificate authority software has no need to run on your application network, protect it by installing it on a non-networked and physically-secure computer. The safest way to distribute your certificate files is to copy them to a diskette, carry the diskette to each server and client host computer, and copy the 72 Enterprise Architecture Planning Guide

Server-Program Security Requirements certificate files to the proper location on each computer. If you must distribute certificate files electronically (for example, by electronic mail to widely-distributed client computers), be careful to use proper protection on your distribution channel. Especially on client computers, the location where you store digital certificate files is a potentially vulnerable point in your security scheme. The file contains a password- encrypted private key, which should be kept from potential attackers. When determining where to store the certificate files, consider doing the following: n Choose a different location from the ps-ca command’s default. The PowerTier for J2EE documentation set is available from Persistence’s Web site. Any attacker interested in breaking your application will soon know the default certificate location if he wants to. n Set operating-system protections on the certificate file to keep bad guys from reading or copying the certificate. n Set operating-system protections on the certificate files’s location (the directory) to keep bad guys from finding the certificate. Server-Program Security Requirements Consider the following issues when planning the security of your PowerTier server: n Authentication n Administrative API Access n Custom Security-Manager Implementations Authentication PowerTier servers authenticate using digital certificates. Each server host computer requires its own certificate and a copy of the trusted CA certificate. For server authentication to work, you must configure the PowerTier server to reflect the location of these certificates. You set these values in the server configuration (.ptc) file, in the SecurityPolicies element’s ServerCertificate and CACertificate attributes. 73

8 Planning for Security Administrative API Access The PowerTier administrative APIs provide client-side access to some powerful features. You can set a security policy and access controls on each. In a secure PowerTier application, if you set no security policies, no client can access any of these APIs. Generally, all client programs will need access to the PowerTier Finder class in order to find enterprise beans’ home interfaces. Consider assigning the Finder a security policy and security role (for access) that allow all client program users to get a reference. The security policy can still be demanding in terms of authentication and encryption, if that is appropriate for your application. The other administrative APIs allow configuration of the PowerTier server. Generally, only special administrative client programs need access to these features. Simple users of your application should not, for example, be changing the way cache clearing works. Consider assigning a more restrictive security-role list to the remainder of the administrative APIs. Custom Security-Manager Implementations The security managers control the way your application defines and works with user accounts, security roles, and security-audit logging. Enterprise Bean Security Requirements For each enterprise bean in your application, consider what client programs need to access them and how sensitive their communications are. This will help you determine your beans’ access-control and security-policy requirements. You can set a security policy on each enterprise bean, by placing an entry in the PowerTier deployment descriptor (pt-jar.xml). These policies must be defined in the server configuration (.ptc) file. You can set a security role (for access control) on each bean or on each method in the bean. Generally, you will find that a good object model does not result in many different access-control requirements on a single bean. However, some beans may allow (for example) a wide range of users to have read access, while restricting write 74 Enterprise Architecture Planning Guide

Enterprise Bean Security Requirements access to a more limited set of users. You can assign this kind of access control by setting security roles for groups of methods in the bean. You control all enterprise bean access control in the PowerTier deployment descriptor. Related Information See the following sources for related information: Subject Location Implementing security Security Guide Configuring security in deployment Reference Guide descriptors 75

8 Planning for Security 76 Enterprise Architecture Planning Guide

9 PowerTier Enterprise Features 9 In enterprise deployment, you can run clusters of PowerTier servers to handle thousands of concurrent clients. To provide scalability and fault tolerance, PowerTier server clusters support load balancing and failover. The failover of stateful entity beans requires synchronization of cached entity bean state across the cluster. The following sections introduce these enterprise features: n Load Balancing n How Load Balancing Works n Understanding Failover Issues n Planning for Failover n Cache Synchronization Load Balancing Persistence has implemented PowerTier load balancing as a JNDI service provider that relies on underlying JNDI naming and directory services. A cluster of PowerTier servers can publish objects to any JNDI naming or directory service. Client requests that adhere to the PowerTier loadbalance naming scheme can be distributed among the available servers. 77

9 PowerTier Enterprise Features The PowerTier load-balancing service can balance any objects that you publish in your JNDI naming or directory service, even if those objects are not hosted by the PowerTier server. The load-balancing service provides two policies: random and minimum load. You can also use the interface that PowerTier provides to write your own custom load- balancing policy. How Load Balancing Works Imagine a simple scenario with two identical servers. The following interactions occur between the PowerTier application, the naming service, and the load-balancing service: n Both servers start and publish themselves with the naming service. n Clients obtain a context and perform a lookup using the loadbalance naming scheme. n The JNDI implementation manager delegates the lookup to the load-balancing service. n The load-balancing service uses the naming service to identify the servers in the specified cluster. n The load-balancing service applies the current load-balancing policy to the available servers, and chooses one. n The load-balancing service uses the naming service to locate the specified object, and returns it to the client. Figure 11 illustrates these interactions. 78 Enterprise Architecture Planning Guide

How Load Balancing Works Figure 11. Server Registration and Client Lookups in a Load-Balanced Application To use load balancing, you must configure the servers you want to include so that they publish with the naming service, and you must have your client programs perform lookups using the loadbalance naming scheme. The next section describes the loadbalance naming scheme. To use load balancing, client program lookups use the loadbalance naming scheme. Clients must perform these lookups either on a loadbalance initial context, or on any context using a loadbalance URL. This section describes the loadbalance URL. The loadbalance naming scheme consists of four components, separated by forward slashes: n keyword n cluster name n server name n object name The syntax for a loadbalance URL is: loadbalance://clusterName/serverName/objectName The loadbalance service uses “/” as the separator between the cluster, server, and object components. The naming service translates these as hierarchical or flat names, depending on your server configuration for the naming service. 79

9 PowerTier Enterprise Features Elements in the loadbalance URL loadbalance This keyword tells the JNDI implementation that the load-balancing service should interpret the URL. However, if you create an initial context that uses the load-balancing context factory, com.persistence.loadbalance.PSInitialContextFactory, you can omit the loadbalance keyword. In this case, JNDI uses the context as the starting point and delegates lookups to the loadbalance service. clusterName This additional name element is required for load-balancing lookups, and must match your servers’ ServerName configuration attribute. To use clusters of servers, you specify the server’s name in server configuration as ClusterName.ServerName. The clusterName is equivalent to the Java system property ps.jndi.clusterName. serverName This name element can either be * (asterisk) or can match the ServerName of the ServerName configuration attribute. The * (asterisk) character results in load balancing across the cluster of PowerTier servers. A ServerName value causes an exact lookup, which will fail if no server with that name is published in the naming service. The serverName is equivalent to the Java system property ps.jndi.serverName. objectName This name elements identifies the object published in naming. The object must have been published by the PowerTier server and must be one of: a Finder object, a service object (such as the ServerMgr), or an EJB Home object. Note: Because the applicable (EJB and J2EE) specifications do not describe load balancing, this service is PowerTier-specific. You cannot use the application naming environment (ANE) to perform load-balanced lookups. Reserved Characters in the loadbalance URL The following characters are reserved in loadbalance URLs: n / (forward slash) n = (equal sign) n (backward slash) n , (comma) 80 Enterprise Architecture Planning Guide

How Load Balancing Works The escape character is the (backward slash). How the PowerTier Server Publishes Itself with the Naming Service The JNDI ProviderURL configuration attribute specifies the context in which your server publishes its name with the naming service. Load balancing introduces an extra component in JNDI publication: the cluster name. Servers using load balancing must publish both a cluster and a server name. You must supply both names in the .ptc file (or using the Command Center) as a ClusterName.ServerName value pair to the ServerName attribute. Along with the cluster and server names, the server publishes the EJB Home objects you choose to publish, and PowerTier service objects (if you choose to publish them). Figure 12 shows a cluster of servers published at the root naming context for the service. In this example, the Bank cluster contains three servers, SAN, NY, and SJ. Figure 12. Server Registration in a Hierarchical Namespace Note: Your organization determines the namespace in which the server’s objects are published. The dotted line under Naming Service represents this user-defined context, which could contain multiple bindings. 81

9 PowerTier Enterprise Features Figure 13 shows how the same cluster of servers would be published in a flat namespace. In this example, the servers use the same ClusterName and ServerNames as in Figure 12. Figure 13. Server Registration in a Flat Namespace How the Load-Balancing Service Resolves Names Client lookups resolve according to the naming scheme of the underlying JNDI naming or directory-service provider. For example, a lookup on Financial/Bank/AccountHome could return an object published as AccountHome, Bank, Financial in LDAP or as Financial/Bank/AccountHome in COS Naming. If you want to make client lookups portable across naming services, you can use the loadbalance naming scheme with or without taking advantage of load balancing. For a server configured with the ClusterName of Bank, load-balancing lookups in LDAP or COS Naming would have the following results: n Bank/*/AccHome returns one of the SAN, SJ, or NY AccHome objects. n Bank/SAN/AccHome returns the AccHome from the SAN instance. n Bank returns empty. n Finder returns empty. 82 Enterprise Architecture Planning Guide

Understanding Failover Issues Load-Balancing Optimization The PowerTier load-balancing service was designed to provide the greatest flexibility while optimizing the performance of lookups. Rather than traversing through every server’s published objects, the load-balancing service chooses one of the servers (by applying the load-balancing policy) before it attempts to locate the required object. If the chosen server does not publish the needed object, the load-balancing service tries another server in the cluster. If all of the servers in a cluster publish the same objects, this optimization greatly increases performance. If any of the servers in a cluster do not publish the object a client requests using load balancing, the performance benefit can be offset by the additional attempts to locate the object. Therefore, Persistence recommends that all servers in a cluster publish the same set of objects. Understanding Failover Issues PowerTier applications incorporate server and client programs that are typically distributed across a local or remote network. A fault-tolerant PowerTier application needs to anticipate planned and unplanned events and provide for continuation of service. The interaction between the network, host machines, and software increases the potential for failures. These failures can include: n individual computer failures n communication failures between client and server n communication failures between server and database n unexpected errors that cause software failures n planned outages for maintenance or upgrades Of these types of failures, the transparent failover service handles the cases that prevent a server from responding to a client request. To take advantage of transparent failover, you deploy multiple servers in a cluster. As long as clients can communicate with any server in the cluster, they will not see interruption of service. Transparent failover provides a solution for increasing your application’s fault tolerance. It also allows you to maintain continuous availability while performing routine software or hardware upgrades, or software bug fixes. The failover service includes failback, which allows you to restart a server in the cluster and have requests redirected to it. 83

9 PowerTier Enterprise Features The Benefits of Transparent Failover To provide high performance, PowerTier applications cache shared data, and delegate computation-intensive business logic to the server. Clients can hold references to remote server objects, and can interact with them over an extended period of time. Since PowerTier servers maintain this state information, failover is not just a matter of connecting to a new server—the new server must also contain the correct state before the client can resume normal operations. PowerTier’s transparent failover service requires deployment of a cluster of PowerTier J2EE servers that are logically identical—they load the same entity and session beans. If they do not use the cache synchronization service, they should connect to the same database. If they use the cache synchronization service, they should synchronize the same set of entity beans. The cache synchronization service ensures that each server refreshes its cache when necessary to reflect updates. For more information, see the chapter on cache synchronization in the PowerTier Server and EJB Development Guide. The PowerTier failover service allows you to configure your server clusters in any of the following configurations: n peer clusters, where any server can handle any request n master-slave clusters, where one primary server handles requests while the additional secondary servers stand by n federated clusters, a variation of master-slave, where each server can be the primary master for a logical group of objects while being the secondary master for other logical object groups You can configure your application to use failover without additional programming. The servers generate failover-enabled object references for all failover-enabled objects. When a client obtains a reference to one of these objects, the reference contains the information necessary to connect to all of the servers in the cluster. Should a request fail, the client automatically retries the request using the next server listed in the object reference. The failover service’s failback behavior—where the traffic can be re-directed to the original server when it recovers—brings your system back to its intended state with minimum impact to application performance. In case of failure and failback, all of the processing necessary to connect with another server occurs transparently to the client. This avoids a storm of network traffic, and relieves the client developer of implementing failover logic. Thus, transparent failover provides reliability, scalability, and high performance for your PowerTier application. However, no failover scheme can withstand catastrophic outages—such as when all servers go down, or the network is not responding. So, it is always good distributed- programming practice to ensure that clients contain logic that catches and handles these types of system-level exceptions. 84 Enterprise Architecture Planning Guide

Planning for Failover Failover-Enabled Object Types The transparent failover service provides failover for the following objects: n All Home instances: CMP entity, BMP entity, stateless session, and session beans. n Container-managed persistent (CMP) and bean-managed persistent (BMP) entity object instances. n Stateless session bean instances. n PowerTier services (singleton instances of classes that end with Mgr, such as CacheMgr). n PowerTier Finder instances (a PowerTier enhancement for simplifying object lookups). Because of the stateful nature of the PowerTier server, objects whose state could not be known by another server cannot fail over. These objects include: n Objects involved in a client-managed explicit transaction – where the client calls the UserTransaction methods begin() and commit(). n The result set of a client-side lazy fetch operation. n Stateful session bean instances. n Enumerations resulting form findState methods. Planning for Failover The transparent failover service provides a level of fault tolerance for your application. Design of a robust application requires the following additional tasks: n Analyzing the Physical Architecture n Determining Client Requirements n Understanding Enterprise Service Interactions Analyzing the Physical Architecture The level of fault tolerance that transparent failover provides depends upon the characteristics of your network. Your first step in planning deployment of a cluster of PowerTier servers should be a careful analysis of the communication path. The communication path includes the connections: n between every server in the cluster 85

9 PowerTier Enterprise Features n from every server to the JNDI naming service n from every client to the JNDI naming service n from every client to every server Each link in these communication paths is a potential point of failure. The following figure illustrates the limitation of locating multiple servers on the same subnet. In this example, when the bridge fails, client applications have no way to reconnect to an available server. Figure 14. Identifying Single Points of Failure It may not always be possible to provide a direct communication path with no potential points of failure. For this reason and others, client applications need to contain their own system-level failover logic in addition to transparent failover. Determining Client Requirements Client programs should be able to handle failures that occur outside the scope of transparent failover. Some of these include: n Exceptions: user-defined, EJB, server, or container. n Failure of servers that are not enabled for transparent failover. 86 Enterprise Architecture Planning Guide

Cache Synchronization n Requests that may disable transparent failover, such as a client-demarcated transaction or lazy fetch. n Situations where all servers in the cluster fail. n Situations where network connectivity fails. Understanding Enterprise Service Interactions The transparent failover service is closely related to the PowerTier load-balancing and cache synchronization services. If you use cache synchronization or load balancing with failover, you should account for the interaction of the services in your planning. When clients use load balancing to look up objects in the naming service, the server to which they connect is determined by the load-balancing algorithm and the granularity of load balancing. You can optionally use load balancing with failover peer clusters. You would not want to use load balancing with master-slave or federated clusters because these types of clusters expect requests to be primarily directed at one server. The cache synchronization service simplifies the use of failover, by ensuring the freshness of objects in the servers’ caches. The servers in a cluster should have the same logical configuration: they should load the same beans and synchronize the same beans. If they update entity beans, their database connection pools should be identical. The cache synchronization service ensures that each server refreshes its cache when necessary to reflect updates. Cache Synchronization Cache synchronization supports load balancing and failover by keeping the in- memory entity beans of multiple servers consistent. A cluster of PowerTier servers can thereby satisfy client requests with current, correct data. PowerTier cache synchronization uses an underlying messaging system to provide communication within the cluster. After you set up and enable the cache synchronization service, the servers and the messaging system handle cache synchronization for you automatically. 87

9 PowerTier Enterprise Features The Messaging System This version of the cache synchronization service provides integrations with three different messaging systems: JBroker, SpiritSoft’s SpiritWAVE, and TIBCO’s TIB®/Rendezvous™. The supplied integrations take the form of a messenger class that handles communication between the PowerTier server and the messaging system. SpiritWAVE and JBroker both come bundled with the PowerTier product. You must purchase TIB/Rendezvous separately. The cache synchronization service also provides a framework by which you can support another messaging system. If you choose to implement support for a different messaging system, you write a custom SyncMessenger class. You can use any messaging system, which your custom class will map to the PowerTier C++ or Java framework. Characteristics of the JBroker Messenger The JBroker messenger uses point-to-point messaging. Point-to-point messaging may not meet the needs of a cluster that contains many servers, depending on the size and frequency of synchronization messages. In addition, JBroker does not guarantee message delivery. To provide a more robust service, the JBroker messenger allows you to re-send failed messages. Characteristics of the SpiritWAVE Messenger The SpiritWAVE messaging system, which provides JMS services for PowerTier applications, also serves as a JMS-based cache synchronization messaging service. The SpiritWAVE messenger uses publish-subscribe messaging for cache synchronization. Publish-subscribe messaging is an especially efficient mechanism for clusters that contain many servers, since it allows for a single message to be sent to a topic, where it can be accessed by multiple message consumers. The SpiritWAVE’s JMQ Standard message transport, which comes bundled with PowerTier, allows you to run a single SpiritWAVE daemon. For enterprise-level scalability and fault-tolerance, you can upgrade to JMQ Professional message transport by purchasing a Professional license key from SpiritSoft. The Professional license key enables you to run multiple SpiritWAVE daemons concurrently. 88 Enterprise Architecture Planning Guide

Cache Synchronization Characteristics of the TIB/Rendezvous Messenger The PowerTier TIB/Rendezvous implementation supports Rendezvous reliable broadcast communications. If you want to take advantage of Rendezvous advanced features, like certified message delivery, you must create a custom SyncMessenger class. Synchronization Messages You can choose which entity beans you want to synchronize. The entity beans to be synchronized must have an optimistic control attribute of one of the numeric types. The cache synchronization service uses the optimistic control attribute to determine whether an incoming synchronization message contains newer data than that already existing in the cache. Due to the complexity of interactions in a distributed system, it is impossible to guarantee the order in which the cache synchronization messages will arrive at the cooperating servers. Messages arriving in an unexpected order can cause application problems. The cache synchronization service applies an algorithm to the optimistic control value to determine whether the object in the incoming message is newer than the object existing in the cache. You can set the algorithm’s optimism level, a value that determines how the server handles messages that arrive out of order. The algorithm might cause the server to apply the new object state from the message, ignore it, or invalidate the object so the next access causes the server to refresh the object from the database. Synchronization messages include the full state of updated objects, excluding attributes of type text or BLOB. For attributes of type text or BLOB, the cache synchronization service sends an invalidation message. The invalidation message causes the receiving servers to refresh the object from the database when they receive the next client request for that object. Relationships between entity beans are synchronized if the related beans are synchronized and the relationships are already knitted in the receiving server’s cache. Cache Synchronization in Action To have a server cooperate in cache synchronization, you set server configuration attributes or write code that specifies: n which messaging system to use n any parameters required by the messaging system 89

9 PowerTier Enterprise Features n an optional optimism level If you are using the provided implementation for the TIB/Rendezvous messaging system, configuration parameters include a subject, under which synchronization messages are published. The use of subjects allows you to synchronize independent clusters of cooperating servers on the same network. For example, you might synchronize one cluster with an “accounting” subject and another with a “human resources” subject. If you are using the provided implementation for the SpiritWAVE messaging system, configuration parameters include the JMS Destination for cache synchronization and the SpiritWAVE transport-level driver to use for the ConnectionFactory. If you are using the provided implementation for JBroker, you can also synchronize messages across clusters. The JBroker configuration parameters include a ClusterNames attribute that causes participating servers to also send synchronization messages to any specified cluster. To deploy a system using cache synchronization, you start the messaging system (if necessary) and start your group of PowerTier servers and specify both a cluster name and a server name. Cache synchronization occurs in the following manner: 1. A cooperating server commits a transaction to the database. 2. The server passes the updates, creations, and deletions to the messaging system. 3. The server synchronizes its own cache. 4. The messaging system packages the changes and broadcasts them asynchronously to all cooperating servers. 5. Cooperating servers receive the message and apply an algorithm to determine if it contains the latest data. Based on the results of the algorithm, the server either ignores the message or updates its cache. Figure 15 illustrates the sequence of events after a server cooperating in cache synchronization updates an entity bean instance and commits the update to the database. 90 Enterprise Architecture Planning Guide

Cache Synchronization Figure 15. Cache Synchronization Related Information See the following sources for related information: Subject Location Cache synchronization PowerTier Server and EJB Development Guide Failover and load balancing Client Development Guide 91

9 PowerTier Enterprise Features 92 Enterprise Architecture Planning Guide

10 Recommended Architecture 10 PowerTier consistently outperforms competing J2EE products. This success results from over ten years of experience building mission-critical enterprise application servers. Your application can exploit PowerTier-specific performance, scalability, and availability advantages by using PowerTier features in the manner for which they were designed. The following sections discuss the optimal PowerTier architecture: n Performance and Scalability Issues n Runtime Processes n Component Design Performance and Scalability Issues PowerTier effectively addresses the most costly operations in a distributed system: remote communication, data access, and transactions. This section discusses the performance and scalability issues involved with these operations and outlines the principles upon which the recommended PowerTier architecture is based. In a J2EE application, requests from clients to the server tier and from the application server to the database usually require remote communication. Remote calls take longer to complete than local calls and network bandwidth limits the potential volume of concurrent requests. In addition to the communication overhead, remote data access requires database server processing and is subject to the limitations of the database. Data access becomes even more expensive when it includes modification of an object’s state. 93

10 Recommended Architecture J2EE allows for any component type (client, Web, or EJB) to directly access persistent data and manage their own transactions. However, the specification does recommend using entity beans to represent persistent data. Persistence experience has shown that performance and scalability are directly related to which components are responsible for persistent data access and how they manage transactions. Since other J2EE application servers do not support CMP entity beans that perform well, most J2EE documentation and even trade publications advocate accessing relational data with JDBC calls from session beans, BMP entity beans, or servlets to the database. This means that typical J2EE application servers must communicate with the database for every data access request. Figure 16 illustrates the redundant communication that occurs in a typical J2EE server. A similar pattern occurs if Web or client components are accessing the database through JDBC. Figure 16. The Architecture Supported by Competing J2EE Servers When you add concurrent users, this architecture does not scale well. When all database connections are in use, incoming requests queue up. When rows or tables are locked, requests block until the lock is released. You could try to solve this problem with database replication. However, database replication is expensive, complex, and does not solve the scalability problem. Application server replication (the clustering capability offered by most enterprise servers) alone does not solve the problem because it does not decrease the load on the database. The PowerTier server reduces the amount of network communication and processing required for data access by: n keeping the most commonly requested data objects in server memory and supporting optimistic data access (reading without locks) 94 Enterprise Architecture Planning Guide

Runtime Processes n providing transactional caching and transaction modes that increase efficiency Uniquely, PowerTier tools generate the code for CMP entity beans that use highly efficient SQL calls to access the database. Figure 17 shows how the PowerTier server caches the state of entity beans in server memory and amortizes the cost of a single database read across many requests. Therefore, caching both eliminates one leg of remote communication and relieves the load on expensive database connections. Benchmarks show that the PowerTier architecture provides unmatched performance and scalability. Figure 17. PowerTier Caching for Performance and Scalability Runtime Processes Assuming an extreme application that handles thousands of simultaneous requests, this section describes the ideal PowerTier architecture—starting with an overview of the deployed system and working down to specific configuration options. These recommendations assume an ideal environment with no constraints. If your application has special needs that require use of features that are not part of the recommended architecture, this information should help you analyze the trade-offs involved. 95

10 Recommended Architecture A Deployed PowerTier Application A robust PowerTier application consists of a cluster of PowerTier J2EE servers. Each server hosts EJB and servlet/JSP containers and all servers support the same servlet contexts and the same EJBs. At startup, each server preloads the cache with the entity beans that represent the core business state and precompiles JSPs. Figure 18 illustrates this architecture. Figure 18. PowerTier J2EE Physical Process Architecture Collocating the servlet and EJB containers, rather than hosting them on separate nodes, eliminates one network hop for Web requests that require data access. PowerTier cache synchronization ensures that the state of in-memory entity beans remains consistent between clustered server processes. A PowerTier cluster provides load balancing and failover for both standalone and Web clients. 96 Enterprise Architecture Planning Guide

Component Design You should determine the optimal number of servers in the cluster after simulating the expected load. Cluster performance and scalability will be the best if you have realistic data on which to base your decision. You want to provide enough capacity for spikes in usage and unexpected outages, but do not want more servers than necessary in the cluster due to the overhead required for cache synchronization. Hardware and Network Issues Since the reason for using server clusters is to provide load balancing and failover, each PowerTier server should be deployed on a separate host machine. You should also look at your network topology to reduce single points of failure and provide the fastest network connection possible. The hosts for PowerTier J2EE servers should be able to hold the server process with a full cache in main memory. You can estimate the amount of memory you need by adding the size of the database rows to the per-object overhead for caching, which is approximately 600 bytes, as follows: Estimated memory required = (DB row size + 600 bytes) * Maximum number of cached objects So, to provide a simplified example, if your application will cache 100,000 objects, each of which takes up 2000 bytes in the database, the calculation would be: Estimated memory required = (2 KB + 600 bytes) * 100,000 = 253 MB PowerTier has been designed to take advantage of multiple CPUs. Persistence has done testing up to 10 CPUs with excellent results. Component Design PowerTier best supports the component design promoted by the J2EE specification: the Web and standalone client components contain the presentation logic, session beans contain application-specific business logic, and session beans call entity beans to access and modify persistent data. Figure 19 shows communication between clients and components, with the cached entity beans being responsible for persistent data access. 97

10 Recommended Architecture Figure 19. PowerTier Component-Level Architecture Sun’s J2EE design patterns, available from their Website, contain helpful information on design for your presentation and business components. The following sections provide best practice suggestions for PowerTier application components: n Entity Beans n Session Beans n Servlets and JSPs n Standalone Clients Entity Beans Because they drastically reduce development time and fully exploit PowerTier’s caching, database connection, and transaction modes, you should use PowerTier- generated CMP entity beans for objects whose state will be stored in a relational database. The way you map entity beans to the database and the relationships that exist between the beans can drastically impact performance. The Tools Guide contains information on providing the best mapping strategy. 98 Enterprise Architecture Planning Guide

Component Design Session Beans Session beans perform business processing in response to client requests. Session bean clients might be Web components or standalone Java or CORBA programs. To access persistent data, stateless session beans should call PowerTier-generated CMP entity bean methods and read from objects in the shared cache whenever possible. In general, a request for an entity object causes the PowerTier server to bring it into the shared cache. (One exception is when you read an object within a transaction and do not update it.) The PowerTier-generated entity beans contain several methods for accessing cached objects only. Session beans should use these methods. During testing, you can turn on logging to verify that the beans are not inadvertently causing database access. See the PowerTier Server and EJB Development Guide information on PowerTier- generated CMP beans for a list of these methods. Since the session beans are running in the same process as the entity beans, there is no need to make remote calls to the naming service to locate an object. The PowerTier Finder object and collocation optimization feature allow session beans to avoid the overhead of the RMI communication layer. The simplest way to handle transactions is to leave it to the PowerTier-generated CMP entity beans themselves. However, to provide the best performance, you can group series of related operations into one transaction demarcated by the session bean. This avoids the overhead of the container starting a new transaction for each operation. The simplest and cleanest way to design session beans is to use container-managed transactions. To support the grouping of related transactions, designate any methods that might participate as Required in the deployment descriptor. Then you can use them on their own, or call them from another method. The container will only start a new transaction when one of the methods is called outside of a transactional context. The following figures illustrate this strategy. In Figure 20, the updateEmpInfo() session bean method has a transaction attribute of Required. The generated entity bean set methods also use the Required transaction attribute. When the request to update employee information comes in, the container starts a transaction. When the session bean invokes the two set methods on the entity bean, the container knows that a transaction already exists, so these updates occur within the existing transaction. Figure 21 illustrates that these same methods can be called independently when needed, and the container will start a new transaction. 99

10 Recommended Architecture Figure 20. Several Methods Wrapped in One Transaction Figure 21. Methods Invoked in Separate Transactions 100 Enterprise Architecture Planning Guide

Component Design Servlets and JSPs In a PowerTier application, JSPs and servlets should avoid using JDBC to access data and avoid demarcating transactions. Web components should call session beans if they need to access persistent data. By doing this, they maintain a clearer boundary between presentation and business logic while gaining the benefits of PowerTier caching. In addition, session beans provide better facilities for demarcating transactions. Web components work especially well for supporting users outside of the firewall. Sun recommends the model-view-controller architecture where the model is the business logic in session beans, the JSPs that generate the HTML provide the view, and servlets act as the controller by implementing the state of the user interface. This pattern restricts JSPs to presentation while using servlets strictly as a web server extension, by providing specialized controller components like authentication. Standalone Clients When making a choice between Web and standalone clients, consider deployment, security, and complexity issues. Web clients require no installation on the client machine and are thus easier to change and upgrade. Web clients can also provide a simple way to access content behind a firewall. While standalone clients do require installation on the client machine, they are generally easier to code and can present a much richer user interface. Standalone clients should contain only presentation logic and delegate business processing to session beans. PowerTier clients should not access persistent data using JDBC, nor should they demarcate transactions. If they will run on desktop machines, they should be kept as lightweight as possible. The PowerTier client JAR files include .class files specific to entity beans. Since your clients will not be accessing entity beans directly, you can create your own script or use a third-party tool to remove these from the JAR file. When designing standalone clients, you have the option of using the lightweight PowerTier-supplied client container. You should use the client container if you have any of the following requirements: n your clients need access to J2EE resources n your clients need to be portable across J2EE containers n you want to reuse code from your standalone clients in Web components 101

10 Recommended Architecture If your application does not require use of the client container, you can create a simpler client that accesses session beans by using naming service lookups. To improve performance when portability is not an issue, clients can use the PowerTier Finder to obtain references to EJBs. A number of the sample applications demonstrate these alternative usages. Server Configuration Options When you run the EJB and Servlet containers collocated within the PowerTier server, you provide configuration settings in several different configuration files. The PowerTier Server and EJB Development Guide and Command Center Guide describe EJB container configuration. Web Application Development Guide covers servlet container configuration. Table 6 lists the main performance and scalability enhancing configuration categories and shows the container to which they apply. Table 6. Performance-Enhancing Configuration EJB Container Servlet/JSP Container Cache Management Class Loading of Servlets Database Connections Load Balancing Between Web Server and Servlet Container Logging Logging Transaction Modes Persistent Servlet Engine Sockets The following sections briefly describe the benefits of these configuration options. For information on how to set the configuration, see the PowerTier Server and EJB Development Guide, the Web Application Development Guide, or the Command Center Guide. Cache Management When core business state is easily identifiable, loading that state into the cache at server startup minimizes network communication and database access. With the shared cache preloaded, the PowerTier server only accesses the database when necessary to synchronize data. An application can load the cache using component code and preload it using server customization code. Whether your application preloads or loads on demand, it will perform best when a large percentage of requests can be satisfied from the server’s cache. 102 Enterprise Architecture Planning Guide

Server Configuration Options To make best use of the PowerTier shared cache, you need to design a strategy for loading objects and clearing them. Server-side cache configuration specifies which types of objects to keep in the cache and which to clear, although you can override the server configuration with component methods. It is also important to configure the cache according to the number of objects you expect to cache. You can set the number of working shared instances for the shared and transactional caches. This setting determines the number of hash buckets that the server will allocate to hold cached objects. Research has shown that the number of objects in the shared cache should not exceed 50 to 70% of the number of hash buckets in the table. You can calculate the working shared instances setting with this formula: Working Shared Instances = Maximum Number of Cached Objects / 0.7 Working instances for the transactional cache should not exceed 70% of the number of hash buckets. You can calculate the working shared instances setting with this formula: Working Txn Instances = Maximum Number of Objects Touched in a Txn / 0.7 Database Connections As mentioned previously, database connections can be a performance bottleneck. To set the number of database connections PowerTier will manage, estimate the maximum number of concurrent database queries and transactions you expect. If the number of active database operations exceeds the number of connections available, the PowerTier server will queue incoming requests until connections free. Little or no performance cost occurs if you allocate too many connections, while the cost of not allocating enough can be prohibitive. Transaction Modes Transactions represent the most costly operations in your application. “Session Beans” on page 99 suggests how to most effectively use transactions in your code. This section covers the settings you can make that determine the default behavior of the J2EE server with respect to determining the point in the transaction at which the server sends the data, locking the database, and sending multiple updates in one remote call. In a transaction that consists of multiple operations, delaying the point at which the application acquires database connections and locks provides the following advantages: n minimizes the time required to complete the transaction 103

10 Recommended Architecture n minimizes the time that data is not available for other processes or threads to modify n minimizes the time that the connection is not available to other clients n reduces the likelihood of database deadlocks The write on commit transactional mode causes the server to send the data upon a transactional commit. Within a transaction, PowerTier uses the locking policies of each type of supported database. In some databases, a lock on one row affects many adjoining rows. Once the server acquires a lock, the lock remains until you commit or roll back the transaction. Read locks prevent other processes from updating a locked object; although other clients can still read the object. Locking during transactional reads can seriously degrade performance. You can set the PowerTier server to read without obtaining locks by default, within your code you can explicitly lock objects when needed. PowerTier always locks the database when modifying data. To read without locks, you need to add an optimistic control attribute to your object model. This allows PowerTier to resolve contentions when two transactions attempt to update the same object that was read optimistically. You also need to provide logic in your code that handles optimistic failures. In addition to the preceding features, you can have the PowerTier server send multiple updates, inserts, and deletes (from within a single transaction) to the database in one call. You control this with the batch writes setting. Batch writes uses array operations for databases that support array operations. When using batch writes, you must disable the database’s relational integrity features and rely on PowerTier to enforce relational integrity. This allows the PowerTier server to re-order database operations within a transaction to achieve the highest performance. You take advantage of optimistic operations by defining optimistic control attributes in your PowerTier object model and setting read locking on a server-wide or transactional scope using ServerMgr and UserTransaction methods, respectively. You control batch writes by setting the buffers size with the BatchWriteBuffSize element in server configuration or by calling DBConnParam.setMaxBatchWriteBufferSize(). Class Loading of Servlets You can configure the servlet container to automatically reload servlets and JSPs when it detects that the source code has changed. The automatic reload feature works well during development when you wish to change and test the implementation. However, during production you should disable this feature since it adds the overhead of checking for changes. 104 Enterprise Architecture Planning Guide

Server Configuration Options For servlets and JSPs that require significant initialization, you can configure the servlet container to load these on start-up. This way, once the plug-in begins accepting requests, users will see a quick response. Persistent Servlet Engine Sockets The PowerTier Servlet Engine consists of a Web server plug-in that forwards requests to distributed servlet containers. At startup, the plug-in opens a specified number of socket connections to the servlet containers. You can configure the number of sockets and whether they are persistent. In a demanding application, you should open enough sockets to handle concurrent requests. Load Balancing Between Web Server and Servlet Container The Servlet Engine distributes requests among servlet containers that support the same context in a round-robin approach. You should have all servlet containers support the same contexts. If one or more servlet containers are on machines with more processing power, you can enter those contexts in the plug-ins configuration file multiple times. This increases the number of requests sent to those containers. Logging Both the EJB and servlet containers provide logging facilities. In a production system, you should either disable logging or set it to log as few details as possible. Related Information See the following sources for related information: Subject Location J2EE design patterns www.java.sun.com Writing EJBs, writing transactions, and PowerTier Server and EJB Development Guide setting transaction modes Setting Servlet Engine configuration Web Application Development Guide Setting server configuration PowerTier Server and EJB Development Guide 105

10 Recommended Architecture 106 Enterprise Architecture Planning Guide

Index A B ActiveServer Pages 33 back-end tier 4 administrative API security 74 bean security requirements 74 alternatives to security measures 69 binding, naming service 47 APIs 16, 18 BMP beans EJB 16 failover 85 JavaServer Pages 19 JDBC 17 JNDI 18 C applet security requirements 71 application 13 cache 9 architecture 13 management 102 architecture choices 22 cache synchronization building 24 messages 89 coding 23 messaging system 88 component coding requirements 23 using 89 deployment 26 certificate authority security requirements 72 management 27 CGI scripts 32 planning 21 client programs 70 security requirements 70 applets 70, 71 services 14 design suggestions 101 application tiers 2, 3, 13 planning security for 70 back-end tier 4 servlets 71 client tier 3 client tier 3 middle tier 4 clusters 77 architecture 13 CMP beans atomic names 47 failover 85 authentication and server security 73 Command Center 11 avoiding security measures 69 component design 97 compound names 47 container 13 collocating servlet and EJB 96 context JNDI 47 Index 107

COS Naming 72 unsupported methods 85 firewalls 69 D Data Dictionary Readers 8 H database 4 hardware requirements 97 batch writes 103 heap manager 10 optimistic access 94 recommendations on connections 103 recommended locking mode 103 I supported 4 tier 4 implicit transaction 52 DDRs 8 initial context, and load balancing 80 development 19 integration testing 26 phases 19 planning 21 tools 5 J Dynamai 5 J2EE 2, 13 APIs 16 application architecture 13 E application building 24 EJB 16 application coding 23 EJB server 9 application component coding requirements 23 eliminating PowerTier security 69 application deployment 26 enterprise development challenges 1 application development overview 13 Enterprise Java Beans 16 application management 27 entity beans 35 application planning 21 introduced 34 application services 14 recommended use 98 application tiers 2, 13 explicit transaction 52 back-end tier 4 benefits 2, 13, 15 client tier 3 F containers 13 failover 83 development phases 19 interaction with cache synchronization 87 Java Transaction API 18 108 Enterprise Architecture Planning Guide

JavaServer Page 19 M JDBC 17 JNDI 18 memory manager 10 middle tier 4 messaging system 88 naming service 14 middle tier 4 remote communication 14 modeling tools 6 Java Naming and Directory Interface 18 multibyte character sets 5 Java servlet 32 Java Transaction API 18 Java Transaction Service 18 N JavaServer Page namespaces 47, 82 benefits 31, 33 naming service 14, 47 introduced 33 binding 47 JBroker 88 bootstrapping 47 JDBC 17 convention 48 JMS 14 differences between 48 JNDI 18 and directory services 48 JNDI (Java Naming and Directory Interface) 45 registering with 47 API 46 resolving names 48 context object 47 security requirements 71 SPI 46 network traffic, limiting 94 URLs 48 jndi.jar 48 JSPs 101 JTS 18 O Object Builder 6, 7 Class Editor 6 L compared to PowerTier Add-Ins for Rose 7 lazy fetch and failover 85 load balancing 77, 105 lookups 82 P naming resolution 81 performance 94 naming scheme 79 limiting database access 94 operations 78 limiting network access 94 overview 77 PowerTier application 93 loadbalance naming scheme 79 performance concerns 69 Index 109

physical memory requirements 97 R PowerTier 2, 11 advantages 2 remote communication 14, 15 application tiers 2 and naming services 11 back-end tier features 4 Remote Method Invocation (RMI) 14, 18 caching 9 runtime processes 9 client-tier features 3 clusters 77 compatible databases 4 S Data Dictionary Readers 8 security deployment tasks 26 database-tier features 4 security for administrative APIs 74 development tools 5 security requirements 71 EJB server 9 applets 71 end-to-end solution 2 applications 70 licenses 5 beans 74 middle-tier features 4 certificate authority 72 modeling tools 6 eliminating 69 product suite 5 servers 73 recommended architecture 96 servlets 71 remote communication and naming services 11 server 10, 85 runtime processes 9 characteristics 85 server clusters 77 estimating memory use 97 Servlet Engine 10 recommended transaction modes 103 Web server 10 server clusters 10, 77 PowerTier Add-Ins for Rose 6 server memory manager 10 benefits 7 server security requirements 73 compared to Object Builder 7 servlet 32 PowerTier server 62 class loading 104 server states 62 recommended use 101 product overview 5 socket connections 105 providerutil.jar 48 Servlet Engine 10 ps-ca command 72 servlet security requirements 71 ps-makeejb 8 session beans introduced 34 recommended use 99 session beans and failover 85 setLockUponRead() 57 110 Enterprise Architecture Planning Guide

discussed 57 stateless session beans and failover 85 T testing 25 multiple machines 26 single machine 25 TIB/Rendezvous 88 TIBCO TIB/Rendezvous messaging system 10 transaction 51 and connection specifications 66 modes 56, 103 recommended design 99 U Unicode 5 unit testing 25 URL for JNDI 48 W Web components 101 Web server 10 write timing 57 overriding 57 performance considerations 57 Index 111

Enterprise Architecture Planning Guide

by Aamir97 on Jun 08, 2010

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Enterprise Architecture Planning Guide Document Transcript