BEA WebLogic 7 server administration

BEA WebLogic 7 Server ™ ® Administration ABOUT THE AUTHORS Ali Akbar works as a software engineer at BEA Systems. H...

Author: Ali Akbar | Keyur Shah

187 downloads 1553 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD

BEA WebLogic 7 Server ™

®

Administration

ABOUT THE AUTHORS Ali Akbar works as a software engineer at BEA Systems. He has vast experience on distributed technologies such as CORBA and J2EE. He enjoys reading at leisure. Ali is married and lives with his wife in Nashua, New Hampshire.

After working with Tata McGraw-Hill on a number of projects as an author and with Wrox Press Ltd., Friends of ED, SAMS, and New Riders Press as technical reviewer, Keyur Shah has now joined hands with McGraw-Hill on this project. He is a Sun Certified Java Programmer with all major Microsoft Certifications, such as MCP, MCSE, MCSD, MCDBA, MCP+I, and MCSE+I. Keyur is currently rendering services to Verizon Communications, USA as Team Lead on the Consumer EOrdering Enterprise Application. He has very extensive experience in training professionals and tech mentoring, and provides consulting services for numerous software application development projects. He can be reached at [email protected].

BEA WebLogic 7 Server ™

®

Administration Ali Akbar Keyur Shah

McGraw-Hill/Osborne New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto

Copyright © 2002 by The McGraw-HIll Companies, Inc. All rights reserved. Manufactured in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. 0-07-222799-0 The material in this eBook also appears in the print version of this title: 0-07-222316-2 All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at [email protected] or (212) 904-4069.

TERMS OF USE This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms. THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise. DOI: 10.1036/0072227990

Want to learn more? ,

We hope you enjoy this McGraw-Hill eBook! If you d like more information about this book, its author, or related books and websites, please click here.

I dedicate this book to my family; without their well wishes, I wouldn’t have done this. —Ali Akbar I would like to convey my special thanks to my friend Manisha, who has always monitored my progress on the book. Thank you so much for always pushing me to devote all possible time and attention toward successful accomplishment of this assignment. You have always been my inspiration for all the projects that I have carried out so far in my career, and this book is as much for you as it is for me. —Keyur Shah

This page intentionally left blank.

For more information about this title, click here.

AT A GLANCE ❖ 1 ❖ 2 ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖ ❖

3 4 5 6 7 8 9 10 11 12 13 14 15 A B C

WebLogic Server Basics . . . . . . . . . . WebLogic Application Server Installation and Configuration . . . . . . . . . . . . WebLogic Console . . . . . . . . . . . . . Application Deployment . . . . . . . . . . WebLogic and J2EE . . . . . . . . . . . . . Application Security . . . . . . . . . . . . WebLogic Server and HTTP Servers . . . WebLogic Clustering . . . . . . . . . . . . WebLogic Performance Tuning . . . . . . WebLogic Node Manager . . . . . . . . . WebLogic Management Architecture . . . Administration Tools . . . . . . . . . . . . WebLogic Integration . . . . . . . . . . . . WebLogic E-Business Platform . . . . . . WebLogic Third-Party Tools . . . . . . . . Troubleshooting Tips . . . . . . . . . . . . Administration Best Practices . . . . . . . A Real-Life Server Configuration . . . . . Glossary . . . . . . . . . . . . . . . . . . . Index

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

1

. . . . . . . . . . . . . . . . . .

35 75 123 145 183 207 229 255 275 289 305 331 351 363 379 387 391 399

. . . . . . . . . . . . . . . . . . . . . . . . .

405

Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.

vii


For more information about this title, click here.

CONTENTS Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xix xxi

❖ 1 WebLogic Server Basics . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 5 6 6 7 11 11 12 12 13 17 19 20 22 23 23 24 29 31 34

Understanding TCP/IP and HTTP . . . . . . . . . . . . WebLogic Web Server . . . . . . . . . . . . . . . . . . . Ports . . . . . . . . . . . . . . . . . . . . . . . . . . Other HTTP Servers . . . . . . . . . . . . . . . . . For Administrators . . . . . . . . . . . . . . . . . . WebLogic Application Server . . . . . . . . . . . . . . . WebLogic 7 Features . . . . . . . . . . . . . . . . . . . . WebLogic System Administrator Infrastructure . . . . . J2EE Components . . . . . . . . . . . . . . . . . . . . . . Servlets . . . . . . . . . . . . . . . . . . . . . . . . . JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource Adapter . . . . . . . . . . . . . . . . . . . Development Environment vs. Production Environment Web Services . . . . . . . . . . . . . . . . . . . . . . . . . WLS Environment and Tools . . . . . . . . . . . . . . . Setting the classpath Option . . . . . . . . . . . . . Starting WebLogic Server . . . . . . . . . . . . . . Tools . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Basics . . . . . . . . . . . . . . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

ix

x

BEA WebLogic 7 Server Administration

❖ 2 WebLogic Application Server Installation and Configuration . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

35 36 37 37 38 38 39 39 40 40 40 40

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

48 49 53 59 60 61 62 65 65 65 65 65 65 66 66 66 66 67 67 68 68 68 71 72 72

❖ 3 WebLogic Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 76 78 79

Acquiring WebLogic Server 7 Software . . . . . . WebLogic Server Terms . . . . . . . . . . . . . . . WLS Domain . . . . . . . . . . . . . . . . . . Server . . . . . . . . . . . . . . . . . . . . . . Machine . . . . . . . . . . . . . . . . . . . . . Cluster . . . . . . . . . . . . . . . . . . . . . . Prerequisites for WebLogic Server 7 . . . . . . . . Requirements for Temporary Space . . . . . Software Requirements . . . . . . . . . . . . Installation Methods . . . . . . . . . . . . . . . . . Installation in Graphical Mode . . . . . . . . Manually Running the Configuration Wizard (Graphical Mode) . . . . . . . . . . . . . . Installation in Console Mode . . . . . . . . . Installation in Silent Mode . . . . . . . . . . . WebLogic Server Directory Structure . . . . . . . . WebLogic Server Configuration File . . . . . . . . Configuration Attributes . . . . . . . . . . . . . . . Setting CLASSPATH . . . . . . . . . . . . . . . . . Database Configuration and Connection . . . . . . DBPing . . . . . . . . . . . . . . . . . . . . . . T3DBPing . . . . . . . . . . . . . . . . . . . . Testing the Configuration and Connectivity . . . . MyIP . . . . . . . . . . . . . . . . . . . . . . . Version . . . . . . . . . . . . . . . . . . . . . . Ping . . . . . . . . . . . . . . . . . . . . . . . . Installing WebLogic Server on Solaris and AIX . . Sun Solaris 8.0 . . . . . . . . . . . . . . . . . . IBM AIX . . . . . . . . . . . . . . . . . . . . . Starting WebLogic Server . . . . . . . . . . . . . . Uninstalling WebLogic Server . . . . . . . . . . . . Upgrading WebLogic Server . . . . . . . . . . . . . Upgrading WebLogic 6.x to 7 . . . . . . . . . Modifying Startup Command Scripts . . . . WebLogic Server Directory Structure . . . . Porting Applications from Version 6.x to 7 . Checklist . . . . . . . . . . . . . . . . . . . . . . . .

Getting Started with WebLogic Console . . . . . . . . . . . . . . . Console Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Configuration . . . . . . . . . . . . . . . . . . . . . . . . .

Contents

Configuring Domain Attributes . . . . . . . . . . . . . Configuring a Server . . . . . . . . . . . . . . . . . . . Configuring a Cluster . . . . . . . . . . . . . . . . . . Configuring a Machine . . . . . . . . . . . . . . . . . . Configuring a Network Channel . . . . . . . . . . . . Configuring Deployments . . . . . . . . . . . . . . . . Services Configuration . . . . . . . . . . . . . . . . . . . . . Configuring JDBC . . . . . . . . . . . . . . . . . . . . Configuring Java Message Service Options . . . . . . Configuring XML Registry . . . . . . . . . . . . . . . Configuring WLEC Connection Pool . . . . . . . . . . Configuring the WebLogic Tuxedo Connector Server Configuring a Jolt Connection Pool . . . . . . . . . . . Configuring Virtual Hosts . . . . . . . . . . . . . . . . Configuring Security . . . . . . . . . . . . . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

79 87 96 96 97 99 99 99 106 116 117 118 119 120 121 121

❖ 4 Application Deployment . . . . . . . . . . . . . . . . . . . . . . . . . .

123 124 125 125 127 129 130 130 131 131 131 133 133 133 133 135 136 136 136 140 141 142 142 143 144

Auto-Deployment . . . . . . . . . . . . Deployment Tools . . . . . . . . . . . . weblogic.Deployer Options . . . Deploy/Activate . . . . . . . . . Undeploy/Deactivation . . . . . Unprepare . . . . . . . . . . . . . Remove . . . . . . . . . . . . . . Cancel . . . . . . . . . . . . . . . List . . . . . . . . . . . . . . . . . Other weblogic.Deployer Options Management Interfaces . . . . . . . . . ApplicationMBean . . . . . . . . ComponentMBean . . . . . . . . Static Deployment . . . . . . . . . . . . Multiple-Server Deployment . . . . . Cluster Deployment . . . . . . . . . . Cluster Setup . . . . . . . . . . . Deployment Phases . . . . . . . . Deployment APIs . . . . . . . . . . . . DeploymentData . . . . . . . . . TargetStatus . . . . . . . . . . . . DeploymentTaskRuntimeMBean DeployerRuntime . . . . . . . . . Checklist . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

xi

xii


❖ 5 WebLogic and J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WebLogics Distributed Architecture . . . . . . . . . . . . . . . . Administering Web Applications . . . . . . . . . . . . . . . . . . Configuring HTTP Parameters . . . . . . . . . . . . . . . . Configuring the Listen Port . . . . . . . . . . . . . . . . . . Setting Up and Maintaining HTTP Access Logs . . . . . . Setting Up Access Logs Using the Administration Console Defining a Virtual Host . . . . . . . . . . . . . . . . . . . . Maintaining Client State . . . . . . . . . . . . . . . . . . . . . . . Servlets as EJB Clients . . . . . . . . . . . . . . . . . . . . . . . . Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Transaction Parameters . . . . . . . . . . . . . Monitoring and Logging Transactions . . . . . . . . . . . . Enterprise Applications . . . . . . . . . . . . . . . . . . . . . . . WebLogic Remote Method Invocation . . . . . . . . . . . . . . . WebLogic RMI-IIOP . . . . . . . . . . . . . . . . . . . . . . . . . WebLogic JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JMS Application . . . . . . . . . . . . . . . . . . . . . . . . Configuring JMS . . . . . . . . . . . . . . . . . . . . . . . . WebLogic JNDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the JNDI Tree . . . . . . . . . . . . . . . . . . . . . Loading Objects in the JNDI Tree . . . . . . . . . . . . . . . Using XML with WebLogic . . . . . . . . . . . . . . . . . . . . . About XML . . . . . . . . . . . . . . . . . . . . . . . . . . . XML and WebLogic . . . . . . . . . . . . . . . . . . . . . . Configuring the Parser and Transformer . . . . . . . . . . Assigning an XML Registry to an Application . . . . . . . Looking at Changes in config.xml . . . . . . . . . . . . . . Configuring the Parser for a Particular Document Type . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

❖ 6 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WebLogic Server 7 Security . . . . . . . . . . . . . . . . Version 7 vs. Version 6.1 Security . . . . . . . . . . . . . WebLogic 7 Security Service . . . . . . . . . . . . . . . . WebLogic Security Framework . . . . . . . . . . . WebLogic Authorization Framework . . . . . . . WebLogic Auditing Framework . . . . . . . . . . Convenience AuditEvent Interfaces . . . . . . . . Keystore Provider . . . . . . . . . . . . . . . . . . Administration and Configuration of Security Providers Creating a Role . . . . . . . . . . . . . . . . . . . . Creating/Adding a User . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

145 146 148 148 153 154 155 156 158 158 159 159 162 164 165 167 168 168 169 170 171 172 173 173 174 175 176 178 179 182 183 184 186 187 187 189 192 192 193 194 194 196

Contents

Creating a Group . . . . . . . . . . . . . . . . . . . . . Configuring and Administering Providers . . . . . . Configuring and Administering Adjudicators . . . . Configuring and Administering Authorizers . . . . . Configuring and Administering a Credential Mapper Configuring and Administering a Keystore . . . . . . Configuring and Administering Role Mappers . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

197 198 200 201 201 203 204 204

❖ 7 WebLogic Server and HTTP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207 208 208 209

. . . . . . . . .

. . . . . . . . .

209 214 219 219 220 224 225 226 228

❖ 8 WebLogic Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . .

229 230 230 231 231 231 232 232 232 233 234 235 237 237 241 242 242 242 243

WebLogic HTTP Server . . . . . . . . . . . . . . . . . . . . What Is a Plug-In? . . . . . . . . . . . . . . . . . . . . . . . . WebLogic and Netscape/iPlanet . . . . . . . . . . . . . . . Installing and Configuring Netscape Enterprise Server/iPlanet FastTrack Server Plug-In . . . . . . Configuring for MIME Types . . . . . . . . . . . . . . WebLogic and Apache . . . . . . . . . . . . . . . . . . . . . WebLogic and Microsoft Internet Information Server . . . Configuring the Microsoft IIS Plug-In by MIME Type Configuring the Microsoft IIS Plug-In by Path . . . . WebLogic Native Plug-in Tool for ISAPI and NSAPI . . . . Setting Up a Proxy to a Secondary HTTP Server . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Round-Robin Load Balancing . . . . . . . . . . . . . . . . . . Weight-Based Load Balancing . . . . . . . . . . . . . . . . . Random Load Balancing . . . . . . . . . . . . . . . . . . . . . Load Balancing for HTTP Session States . . . . . . . . . . . . Parameter-Based Routing for a Clustered Object . . . . . . . . . . Failover Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication in a Cluster . . . . . . . . . . . . . . . . . . . . . . IP Multicast—One-to-Many Communication . . . . . . . . . IP Socket—Peer-to-Peer Communication . . . . . . . . . . . Client Communication in a Cluster . . . . . . . . . . . . . . . J2EE Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP JSP/Servlets Clustering . . . . . . . . . . . . . . . . . Object Clustering . . . . . . . . . . . . . . . . . . . . . . . . . Java Message Service (JMS) Server Clustering . . . . . . . . Configuring a WebLogic Cluster . . . . . . . . . . . . . . . . . . . Configuration Attributes of a Cluster Element in config.xml Cluster Configuration Planning . . . . . . . . . . . . . . . . .

xiii

xiv


Configuring a Server . . . . Configuring a Cluster . . . Troubleshooting Clusters . . . . Checklist . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

244 244 251 252

❖ 9 WebLogic Performance Tuning . . . . . . . . . . . . . . . . . . . . . .

255 256 256 256 257 257 265 268 268 269 269 269 270 271 272 273 274

WLS Performance Tuning . . . . . . . . . . . . . . . . . . . Configuring the Java Compiler . . . . . . . . . . . . . Configuring the Compiler Option in weblogic.xml . . Performance Tuning of WLS Starting Parameters . . Setting config.xml Performance Parameters . . . . . . Weblogic-ejb-jar.xml Performance Parameters . . . . Hardware, Operating Systems, and Network Performance Tuning an Operating System . . . . . . . . . . . . . . Network Performance Tuning . . . . . . . . . . . . . Tuning Java Virtual Machines . . . . . . . . . . . . . . . . . JVM Heap Size . . . . . . . . . . . . . . . . . . . . . . Determining Heap Size . . . . . . . . . . . . . . . . . Specifying Heap Size Values . . . . . . . . . . . . . . Manually Forcing Garbage Collection . . . . . . . . . Monitoring Options . . . . . . . . . . . . . . . . . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

❖ 10 WebLogic Node Manager . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of Node Manager . . . . . . . . . . . . . . . . . . . . Node Manager Architecture . . . . . . . . . . . . . . . . . . . . Node Manager Configuration . . . . . . . . . . . . . . . . . . . Creating a Machine and Adding a Managed Server to That Machine . . . . . . . . . . . . . . . . . . . . . . . . Configuring Node Manager Default Settings in Console Configuring Startup Information for the Managed Server Configuring the Managed Servers Restart Behavior . . . Configuring a Managed Servers Self-Health and Restart Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up the Node Manager Hosts File . . . . . . . . . Configuring SSL for Node Manager . . . . . . . . . . . . Node Manager Environment Variables . . . . . . . . . . Node Manager Command-Line Arguments . . . . . . . . . . . Starting and Stopping the Servers Manually . . . . . . . Starting and Stopping Clusters and Domains . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

275 276 276 277

. . . .

. . . .

278 278 279 280

. . . . . . . .

. . . . . . . .

281 282 283 285 285 287 288 288

Contents

❖ 11 WebLogic Management Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

289 290 290 292 292 292 292 293 295 295 296

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

297 297 298 300 300 300 303 303 304

❖ 12 Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .

305 306 306 306 310 312 312 314 316 318 318 319 320 321 322 322 322 322

Introduction to JMX . . . . . . . . . . . . . . . . . . . . . . Instrumentation Level . . . . . . . . . . . . . . . . . Agent Level . . . . . . . . . . . . . . . . . . . . . . . Distributed Services Level . . . . . . . . . . . . . . . Advantages of JMX . . . . . . . . . . . . . . . . . . . WebLogic Management System . . . . . . . . . . . . . . . WebLogic Domain . . . . . . . . . . . . . . . . . . . WebLogic MBeans . . . . . . . . . . . . . . . . . . . MBean Server . . . . . . . . . . . . . . . . . . . . . . MBean Homes . . . . . . . . . . . . . . . . . . . . . . Administration MBeanHome InterfaceAdmin—MBeanHome . . . . . . . . . . WebLogic Server MBeans . . . . . . . . . . . . . . . . . . WebLogic MBean Types . . . . . . . . . . . . . . . . WebLogic Package Location . . . . . . . . . . . . . . Accessing WebLogic MBeans . . . . . . . . . . . . . . . . Selecting the Client Interface for Accessing MBeans Monitoring WebLogic MBeans . . . . . . . . . . . . . . . Monitoring Scenarios . . . . . . . . . . . . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . .

WebLogic Java Utilities Prerequisites . . . AppletArchiver . DBPing . . . . . . T3DBPing . . . . Deployer . . . . . EJBGen . . . . . . GetProperty . . . myIP . . . . . . . MultiCastTest . . Schema . . . . . . Show Licenses . . System . . . . . . VERSION . . . . Der2Pem . . . . . Pem2Der . . . . . WriteLicense . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

xv

xvi


Administration Using Command-Line Tools Weblogic.Admin . . . . . . . . . . . . HELP . . . . . . . . . . . . . . . . . . . PING . . . . . . . . . . . . . . . . . . . VERSION . . . . . . . . . . . . . . . . LOCK . . . . . . . . . . . . . . . . . . UNLOCK . . . . . . . . . . . . . . . . SHUTDOWN . . . . . . . . . . . . . . FORCESHUTDOWN . . . . . . . . . . CANCEL_SHUTDOWN . . . . . . . . LIST . . . . . . . . . . . . . . . . . . . START . . . . . . . . . . . . . . . . . . LICENSES . . . . . . . . . . . . . . . . Thread Dump . . . . . . . . . . . . . . GETSTATE . . . . . . . . . . . . . . . SERVERLOG . . . . . . . . . . . . . . Checklist . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

323 323 324 325 325 326 326 326 327 327 327 328 328 328 328 329 330

❖ 13 WebLogic Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . .

331 332 333 334 334 335 339 339 339 343 344 345 347 347 350 350

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

Application Integration . . . . . . . . . . . . . . . . . Business Process Management . . . . . . . . . . . . WebLogic Integration Studio . . . . . . . . . . . . . B2B Integration . . . . . . . . . . . . . . . . . . . . . Data Integration . . . . . . . . . . . . . . . . . . . . . WebLogic Integration Installation and Configuration Preconfigured Domains . . . . . . . . . . . . . WebLogic Integration and Configuration Files Configuration Files for Preconfigured Domains Creating a Database Using CONFIGURE . . . Starting the WebLogic Integration Domain . . Sample Application View . . . . . . . . . . . . Stopping WebLogic Integration in Windows . Stopping WebLogic Integration on UNIX . . . Checklist . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

❖ 14 WebLogic E-Business Platform . . . . . . . . . . . . . . . . . . . . . . WebLogic eLink . . . . . . . . WebLogic Express . . . . . . . BEA WebLogic Portal 4.0 . . . Portal Services . . . . . . E-Commerce Services . Personalization Services Campaign Management

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

351 352 353 353 354 354 356 356

Contents

WebLogic Java Adapter for Mainframe eGen Application Generator . . . WebLogic and TUXEDO . . . . . . . . TUXEDO Servers and Clients . . Checklist . . . . . . . . . . . . . . . . .

. . . . .

356 358 359 360 361

❖ 15 WebLogic Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . .

363 364 364 368 370 372 373 377

Deployment and XML Utilities . Sitraka DeployDirector . . . TogetherSoft ControlCenter AltoWeb . . . . . . . . . . . Server Administration Utilities . Testing Tools . . . . . . . . . . . . Checklist . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . . . .

❖ A Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

379 380

. . . . . . . .

. . . . . . . .

381 381 384 384 384 385 385 385

❖ B Administration Best Practices . . . . . . . . . . . . . . . . . . . . . . .

387

❖ C A Real-Life Server Configuration . . . . . . . . . . . . . . . . . . . . . .

391

❖

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

399

❖

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

405

Starting WebLogic Server When Settings Are Incorrect . . . . Starting WebLogic Server When Two Servers Listen on the Same Port Numbers . . . . . . . . . . . . . . . . . . . . . . . Recovering Failed Servers . . . . . . . . . . . . . . . . . . . . . Recovering Security Data . . . . . . . . . . . . . . . . . . Solving Compiling and Program Not Found Problems . . . . CLASSPATH Not Set . . . . . . . . . . . . . . . . . . . . . Reinstalling When a Program Doesn’t Allow You to Continue Replacing a Corrupted Self-Extraction Program . . . . . . . . Resolving Authentication Errors . . . . . . . . . . . . . . . . .

xvii


ACKNOWLEDGMENTS

I

am highly grateful to Drew Sliwkowski and Steve Fanshier at BEA for their valuable comments on some of the chapters in this book. I thank Diana Reid at BEA for extending her cooperation and encouragement in writing this book. I am also grateful to my co-author, Keyur Shah. He is wonderful person to work with. Finally this work would have been impossible without great efforts from Francis Kelly, Laura Stone, and others at McGraw-Hill/Osborne. Thank you all. —Ali Akbar

Thanks very much to everyone at McGraw-Hill/Osborne; Francis Kelly; Laura Stone; my co-author, Ali; and the BEA team of professionals for their support and assistance in writing this book. —Keyur Shah


xix


INTRODUCTION

T

his book is intended for all levels of users—from beginners to seasoned administrators ready to take it to next level. By no means is this book intended to replace WebLogic Server documentation. Rather, it can be used to enhance your skills with WebLogic Administration, especially if you are already familiar with earlier versions of WebLogic Server or other BEA products. This book achieves several objectives: •

It explores the administration opportunities with WebLogic Server.

•

It uncovers ways administrators can leverage features of WebLogic Server 7 to manage routine and mission-critical tasks with ease.

•

It provides step-by-step mechanisms to teach various administration, installation, and configuration activities to administrators.

What Does This Book Cover? Chapter 1, “WebLogic Server Basics,” introduces the basics of WebLogic HTTP Server and other available HTTP Servers. We discuss WebLogic Server as an application server and J2EE components such as Servlets, JSP, and EJB. We also cover development and production environment configuration aspects. Chapter 2, “WebLogic Application Server Installation and Configuration,” navigates you through the process of installing and configuring WebLogic Application Server. Chapter 3, “WebLogic Console,” is designed to help you understand the heart of WebLogic Administration—its tool, Administration Console. Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.

xxi

xxii


Chapter 4, “Application Deployment,” talks in detail about different methods of application deployment on WebLogic servers and clusters. Chapter 5, “WebLogic and J2EE,” deals with proper understanding of various J2EE components and their configuration settings with WebLogic Server. Chapter 6, “Application Security,” describes the security model and configuration of security elements in WebLogic Server 7. Chapter 7, “WebLogic Server and HTTP Servers,” covers useful methods for managing environments and infrastructures that have Web servers from multiple vendors. Proxying requests from WebLogic Server to other Web servers and vice versa is the prime aim of this chapter. Chapter 8, “WebLogic Clustering,” describes the configuration of clusters in WebLogic Server 7. Chapter 9, “WebLogic Performance Tuning,” describes various performance-tuning techniques. Chapter 10, “WebLogic Node Manager,” covers Node Manager, the standalone Java program from BEA that manages servers in the WebLogic domain. Chapter 11, “WebLogic Management Architecture,” briefly describes WebLogic management architecture and introduces JMX. Chapter 12, “Administration Tools,” covers all the command-line tools and WebLogic utilities that can help administer WebLogic Server. Chapter 13, “WebLogic Integration,” covers technologies and tools from BEA for integrating enterprise applications. Chapter 14, “WebLogic E-Business Platform,” covers various e-business products available from BEA and helps you understand how to embark on the e-business initiative with seamless integration into legacy and enterprise applications. Chapter 15, “WebLogic Third-Party Tools,” covers several third-party tools useful for Administering WebLogic Server. Appendix A discusses mechanisms for troubleshooting WebLogic Server. Appendix B covers best practices for administering WebLogic Server. Appendix C provides sample code for CONFIG.XML, a WebLogic domain configuration file.

What Do You Need to Use This Book? To practice the various installation, configuration, and administration tasks explained in this book, you need to have the following: •

Windows 2000, Windows NT, Windows XP Professional, or UNIX (any flavor)

•

WebLogic Server 7

How to Use This Book This book is designed to get you up to speed using BEA WebLogic Server as quickly as possible. A glossary provides a quick reference to help you understand important key

Introduction

terms. The blueprint insert contains a collection of diagrams to help you understand many of the major concepts in this book. NOTE Watch for important information highlighted as a Note, Tip, or Caution. At the end of each chapter is a checklist that summarizes the important concepts covered within that chapter. Use this section to monitor your progress and identify important concepts.

Your Feedback Is Valuable As the reader of this book, you are the most important critic and commentator. We value your opinion and want to know what we are doing right, what we could do better, what areas you would like to see us publish in, and any other words of wisdom you are willing to pass our way. You can e-mail the authors at [email protected] and [email protected]. In addition, check out McGraw-Hill/Osborne’s Web site at www.osborne.com.

xxiii


CHAPTER 1 WebLogic Server Basics


1

2


n this chapter, we will introduce you to the basics of WebLogic Server, with terms and concepts that will be referenced throughout this book. This chapter offers an overview of the following:

I

•

Various ways to use WebLogic Server as an HTTP server

•

The role of WebLogic Server as an application server

•

Major Java 2 Enterprise Edition (J2EE) components such as servlets, JSPs (Java Server Pages), and EJB (Enterprise JavaBeans)

•

The Resource Adapter

•

Details about and differences between development and production environments

•

The environment provided by WebLogic Server for application developers and administrators

WebLogic Application Server comes with an HTTP server. As an administrator, you need to be comfortable with administering the HTTP server, and you must gain the necessary skills to administer server-side Java applications with this server. Organizations have hybrid collections of Web servers installed on their sites to support enterprise applications. Therefore, you should be able to integrate WebLogic Server with other HTTP servers.

UNDERSTANDING TCP/IP AND HTTP HTTP is a protocol that regulates the Way web browsers and servers communicate. The TCP/IP (Transmission Control Protocol/Internet Protocol) suite of protocols is the primary open standard for network communication. HTTP (HyperText Transfer Protocol), part of this suite, is the protocol of the World Wide Web. All the information that resides on the Web as documents or pages is transferred from server to client with the help of HTTP. It is a stateless protocol, meaning that it doesn’t maintain active session state information about each client connected to the server. Rather, it is based on request and response architecture: the client contacts the server only when it needs information, and the server communicates with the client only when it needs to deliver information back to the client. Other protocols in the TCP/IP suite include UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol), FTP (File Transfer Protocol), ARP (Address Resolution Protocol), RARP (Reverse Address Resolution Protocol), SMTP (Simple Mail Transfer Protocol), and NNTP (Network News Transfer Protocol).

WEBLOGIC WEB SERVER Web server software runs HTTP services and is able to host one or more Web sites. Each site is a collection of various documents and applications that form the Web content. This content needs to be delivered to Web clients over the network using HTTP.

Chapter 1:

WebLogic Server Basics

Various HTTP servers are available on the market today, and most are similar in terms of what they provide because HTTP service is a standard feature of the Web. The WebLogic Web server is a Java-powered server capable of delivering not only static content, but also dynamic content with the help of Java-enabled technologies such as JSP and Java servlets. WebLogic Web server hosts and delivers static HTML/HTM files, images, Java applets, XML (Extensible Markup Language) documents, JSP, Java servlets, multimedia files, and other types of files. The way Web servers and browsers communicate is represented in Figure 1-1. The client running the browser software sends a user request to the server using HTTP. The server software (in our case, the WebLogic Server) examines and interprets the request, prepares to locate the appropriate information, locates the information, and then sends an HTTP response to the client. This response is either an HTML document or an image file, which is then interpreted by the client’s browser software and presented on the client’s interface accordingly. NOTE Web server software such as Apache, Microsoft Internet Information Services (IIS), IBM HTTP server, WebLogic Server, JRun, and many others are available to provide HTTP services. Presently, because HTTP services have become a subset of application servers, each vendor dealing with application servers has built-in support for Web content handling and management. Let’s break it down even further. The Web server serves requested contents to the client—contents that are either statically available as HTML or dynamically generated using JSP and servlets. When a client sends a request for information to the Web server, the server maps the URL (Uniform Resource Locator) to a file with the given name on the local file system. Then either it reads the content from the disk and serves it out to the network with the aid of HTTP, or the server-side program generates it dynamically. For example, in the case of a URL that reads http://www.softwareklinic.com/index.html, the Web server software will serve index.html after locating and loading the file from disk to client. The information contained in the document is placed between HTML tags that, along with the requested information, are carried over the network using HTTP. The client software interprets these tags and presents the information in a fashion appropriate for the user.

Figure 1-1.

Web client/server architecture

3

4


Static Web documents are always placed in the respective folder in the appropriate directory. For example, all the static Web documents for the default Web app are placed in the default Web application folder. (Figure 1-2 shows the directory structure of WebLogic 6.1 and 7.0.) The default Web application directory contains documents delivered when the browser doesn’t specify a URI (Uniform Resource Identifier). In other words, if the server is listening on http://server:7001, that URL will respond with documents from the default Web application directory. If the browser requests http://server:7001/otherdocs, another Web application directory serves the otherdocs URI.

Figure 1-2.

Directory structure for WebLogic 6.1 (left) and WebLogic 7.0 (right)

Chapter 1:


Ports WebLogic Server typically listens on port 80, but it can be set to listen on port 7001 instead. You can assign the listener port address to any value ranging between 1024 and 65536 (0–1023 are reserved). Figure 1-3 demonstrates the various communication ports available. If you already have a running server installed at port 80, WebLogic Server can be installed to listen on a port other than 80. It is not possible for WebLogic Server to listen to your client’s requests on the same port as another server. For example, if you are using Windows NT/2000, Microsoft IIS will already be installed and running on port 80. In this case, you will either have to stop (shut down) IIS to free up port 80 for WebLogic Server or you must configure the server to listen on another port. NOTE No two Web servers can be configured to listen at the same HTTP port at the same time, but every Web service can be listened to on a particular port over the network. To access the home page of your WebLogic server, enter the following link into the browser’s address bar: http://localhost:7001. Here, http:// is the protocol, localhost is the computer on which the Web site is hosted, and 7001 is the port at which the WebLogic Web server will be ready to listen for a client’s request.

0 Reserved port numbers

1023 1024 User-defined port numbers

65536

Figure 1-3.

Communication ports

5

6


Other HTTP Servers Table 1-1 provides information about other HTTP servers.

For Administrators If you use WebLogic Server as a Web server, you should be interested in the following aspects of its functionality: •

Security Security is the key to keeping critical data related to systems and customers safe from hackers and pirates. It is the responsibility of administrators to ensure that systemwide security policies and profiles are constructed and implemented to discourage hackers/pirates from breaking into the application/site.

•

Virtual hosting Virtual hosting enables WebLogic Server to host multiple Web sites on a single Web server or a cluster of Web servers.

•

Support for proxy server configuration WebLogic Server can be integrated with other Web servers such as Microsoft IIS, Apache, and Netscape Enterprise Server. Client requests can be redirected or proxied from a WebLogic server to another Web server.

•

Load balancing A cluster of servers can be set up to share the load and provide performance enhancements.

HTTP Server

Vendor

Description

Apache

Apache Software Foundation

IIS 5.0

Microsoft

Netscape Enterprise Server/iPlanet FastTrack Server IBM HTTP Server

Sun/Netscape

Oracle HTTP Server

Oracle

The most popular Web server on the Internet since April 1996. The January 2002 Netcraft Web Server Survey found that 56 percent of Web sites use Apache. A Web server from Microsoft runs on top of operating systems such as Windows NT/ 2000/ XP Professional. It supports HTTP 1.1 and SSL 3.0. Used for hosting ASP-driven Web sites. A Web server from the Sun/Netscape alliance that runs on Windows NT/2000 and various UNIX flavors. Supports HTTP 1.1 and SSL 3.0. An Apache-powered IBM HTTP server that runs on AIX, Linux, zSeries, iSeries, Sun Solaris, HP-UX, and Windows NT. A simple Web HTTPD server (Web listener) based on the Apache HTTP Server (www.apache.org). Oracle Database Server (8.1.7 and above) and Oracle 9iAS (Oracle Internet Application Server) ship with the Oracle HTTP Server.

Table 1-1.

IBM

Other HTTP Servers

Chapter 1:


•

Failover support With the help of a cluster of servers, it is possible to redirect requests that are part of same session to another WebLogic server in the cluster.

•

Session management in Web farms In a cluster environment, client states must be maintained elsewhere in case one of the servers in the cluster is malfunctioning. That way, the application remains intact and doesn’t have to be restarted.

NOTE WebLogic provides plug-ins for Apache, Microsoft IIS, and Netscape Enterprise Server. A WebLogic plug-in is a small piece of software that extends the boundaries and capacities of WebLogic Server implementation. It allows WebLogic Server to communicate with other Web servers, as well as access Web applications that have been deployed on those servers.

WEBLOGIC APPLICATION SERVER Current economic demands require that Web and e-commerce applications help accelerate awareness of companies in growing markets and help them discover new means to reach customers and retain them, as well as ways to introduce new products and provide services to their customers quickly and effectively. To achieve all these goals, solutions need to be built, developed, and deployed that target effective service to customers. This is possible with the help of proven and reliable e-commerce platforms that allow companies to integrate corporate data, legacy applications on mainframes, and other enterprise applications. That’s where WebLogic Server comes into play. WebLogic Server is an industry-leading e-commerce platform. With WebLogic, it is possible to develop and deploy applications that are reliable, scaleable, secure, manageable, and maintainable. WebLogic facilitates the complexities of system-level details, allowing the user to focus on building a business rather than running a server. WebLogic Server is also the leader in implementing features of J2EE 1.3, a standard for developing multi-tier enterprise applications. J2EE provides a complete set of services, such as Java servlets; JSP; EJB; HTTP; Java Message Service (JMS); Java Transaction Service (JTA); Java Naming and Directory Interface (JNDI); Java Connection Architecture (JCA); Internet Inter-ORB Protocol (IIOP); Java Authentication and Authorization Service (JAAS); Java Database Connectivity (JDBC); Simple Object Access Protocol (SOAP); Extensible Markup Language (XML); Universal Description, Discovery, and Integration (UDDI); and Web Services Description Language (WSDL). Table 1-2 lists various services provided by WebLogic Server. WebLogic Server is referred to as middleware because it is responsible for connecting the client with the database servers and for serving the information contained in the databases. WebLogic Server is needed in an enterprise for several reasons. For one, when companies want to decrease the size and complexity of client programs, they need to cache and control data flow for better performance and to enhance the

7

8


Services

Description

EJB

EJB specification, version 2.0, Second Public Draft; EJB provides a mechanism that contains business logic for building reusable Java components. It also helps users build component-based distributed applications. HTTP specification, version 1.1; WebLogic complies with the HTTP V1.1 specifications. A package that enables services to authenticate the users and enforce access control upon them. It is integrated into Java SDK version 1.4. JCA specification, version 1.0; when implemented in WebLogic and Resource Adapters, JCA facilitates connectivity with Enterprise Information Systems (EIS) JDBC specification, version 2.0; JDBC is a Java standard for allowing Java applications to communicate with databases. JMS, version 1.02; aids communication between applications with the help of message exchanges. JNDI, version 1.2.1; naming services as a means for locating objects over the network. JSP specification, version 1.2; JSPs are used for generating dynamic Web content. JTA, version 1.0.1; in a Distributed Transaction System (DTS), JTA is a standard Java interface between the transaction manager and the parties involved. Servlet specification, version 2.3; servlets are server-side Java programs that act as clients to EJB components and have the ability to generate dynamic Web content, process client requests, and communicate with databases. SOAP, version 1.1; a protocol providing an XML/HTTP-based solution for accessing services, objects, and servers in a platform-independent manner. UDDI, version 1.0; UDDI is an industry-standard initiative that enables businesses to locate and communicate with each other. UDDI allows businesses to describe their services, locate businesses that offer desired services, and integrate these services with other businesses. It opens a world of opportunities for enterprises in exchanging services. WSDL, version 1.0; an XML format for specifying Web services as a set of endpoints operating on messages. It’s a specification for describing networked XML-based services. JAXP, version 1.0, SAX version 2.0, DOM Level 2, and W3C Schema; XML is a standard markup language for describing data in structured fashion.

HTTP JAAS JCA JDBC JMS JNDI JSP JTA Servlet

SOAP UDDI

WDSL XML

Table 1-2.

WebLogic Server Services

performance of the entire system, while providing security for both data and users of the system. In client/server applications, the business logic is split across the client and server, but it usually resides in the client application. This increases the complexity of software. In addition, upgrading software or applying any changes is a huge job in itself, as these changes have to be managed with all client systems on the network. This creates the need for software that helps connect the two pieces—client application and databases—

Chapter 1:


while managing all business logic and providing seamless connectivity to the front and back ends. The architecture of Web-based applications is both two and three tiered (see Figures 1-4 and 1-5). In a scenario that involves simply a Web client and a Web server, the architecture is two tiered: client and server. However, if the services are extended to provide the client information from various sources, such as a database, a third tier is added. Web servers do have limitations. They cannot provide more elaborate service to the client other than static pages with static information. To resolve this, a typical piece of software and a development language is needed that helps build logical pages and that contains not only data for presentation but a way to gather information dynamically from the back-end systems and build pages on the fly to deliver to the client. The role of the application server differs from application to application. Not every application requires the same functionality and set of services from an application server. Take scalability, for example. Smaller companies might want an application server that helps them organize their applications for the Web, that provides better control over the way business logic is contained and managed, and that makes it easier to monitor and secure the data. They don’t need multiple servers. On the other hand, large corporations or enterprises may need to manage multiple servers. For them, the scalability of an application server is crucial because they are expecting a huge number of users to visit their Web sites and do business online. WebLogic Server provides everything that’s needed for such business needs; it’s up to the user to make appropriate use of what is provided. Before deciding on an application server, an organization must conduct an in-depth and accurate study of its requirements. Look into factors such as security, scalability, business logic management, and database connectivity to decide which server is appropriate. Keep in mind that not all products from the same family of application servers are written using the same programming framework. While many—though not all—

Figure 1-4.

Two-tier client/server architecture of Web-based applications

9

10


Figure 1-5.

Three-tier client/server architecture of Web-based applications

products are written in Java, some are Microsoft friendly and others are not. However, there is room for all, including support for Java, CORBA, or Microsoft COM+ and the .NET Framework of distributed application development infrastructures. If you are working for an organization that’s looking to run enterprise Java applications in n-tier architecture, you’re going to need to work with an application server, and a place for it in the infrastructure is an inevitable necessity. The application server is the cornerstone of a software architecture designed to tie together different components of a complex application, yet maintain a fundamental modularity in the software. First and foremost, application servers provide the glue that connects information from a database with the end user or client program, which is often running on a Web browser. WebLogic Server provides the means to cache and control data flow for better overall performance and scalability of applications in production. It has the potential to provide security for both data and user traffic. WebLogic Server extracts data from the database to individual applications instead of requiring that each of those applications make a

Chapter 1:


call to the database directly, thereby reducing direct database hits, which adds to the overall performance of the entire system. The Web is automatically three tiered, with a client-centered application, a Web server, and one or more databases. Therefore, managing data along with application functionality is not only an exercise in better application design, but also a downright necessity.

WEBLOGIC 7 FEATURES With each new version of WebLogic Server, new features help ease development, deployment, and administration tasks. In addition, facilities and enhancements help developers make applications more secure, robust, and reliable. Versions of WebLogic Server since 6.x have initiated support for Web services, enhanced and improved the security infrastructure, provided new tools useful to application developers such as EJBGen and Deployer, brought about major enhancements to ease administration of various J2EE components, and made application deployment a more comfortable process. WebLogic Server 7 also includes enhancements concerning administration of caching and clustering. With the help of WebLogic Server 7 cache tags, administrators can configure caching for entire pages, URLs, and file types. The most exciting aspect of the cache tags enhancement is its ease of use—there is no need for administrators to make any changes to the application, and the system can realize an immediate gain in performance. With WebLogic Server 6.x, a multi-home environment was necessary, in which each server within the cluster had its own IP address. So, for example, even if you wanted to set up a cluster environment on a single computer, you needed to set up the multi-home environment, in which multiple IPs exists on a single computer.

WEBLOGIC SYSTEM ADMINISTRATOR INFRASTRUCTURE In the early days of application servers, computer networks within an organization grew as a result of incorporating additional components and systems. Typically, such components as active/intelligent hubs, routers, switches, gateways, PCs, network printers, and storage area networks (SANs) were added to the network, making it complex and expensive. This was tackled by incorporating standards such as management information bases (MIBs) and Simple Network Management Protocol (SNMP) within the products, as has been done with Tivoli. Challenges faced in managing a software deployment task are just as complicated as any network challenges in the enterprise. These issues exist not only in the Java world, but also in the entire Web community. What do network management solutions have to do with Java applications? With Java Management Extensions (JMX), Sun has come up with a standard that allows Java

11

12


developers to integrate their applications with existing network management solutions and infrastructure without using proprietary software. JMX is an API that models system administration functions with the help of Java objects known as MBeans (Management Beans). WebLogic Server implements 100-percent Java standards. System administration in WebLogic Server is implemented from the ground up using the JMX specification.

J2EE COMPONENTS The most basic and necessary components of J2EE applications are •

Servlets

•

JSPs

•

EJBs

•

Resource Adapter

Servlets A Java servlet is a Java program (a class file) that runs in the environment provided by a Java-enabled server, such as WebLogic Server. The most common use of Java servlets on WebLogic Server is to create interactive applications using standard Web browsers for the client-side presentation. WebLogic Server lets users develop and deploy business logic as a server-side process within servlets. Servlet capabilities extend from user interface (UI) generation to access databases, EJBs, messaging APIs, HTTP sessions, and other facilities exposed by WebLogic Server. The Java servlet is simply a Java class (a file containing bytecodes) that is loaded in the Java Virtual Machine (JVM) environment on the WebLogic Server. After the servlet is loaded in the memory, one of its class methods is called to service the client request. A servlet may remain in memory for subsequent client requests and may serve multiple clients; the method is merely accessed once more, without the overhead of reloading and initializing the servlet again. This significantly improves the efficiency of the server. Figure 1-6 demonstrates the structure of a typical Java servlet, where you typically hard-code HTML tags within Java program code. NOTE A Java servlet is a program that runs when the client requests specific information from the server. Consider a Java servlet as a server-side applet designed to work on the server and then return the information to the browser through the Web server. In much the same way that an applet extends the functionality of a browser, the Java servlet extends a server. The applet is an amazing client program, and the servlet is an amazing server program.

Chapter 1:

Figure 1-6.


Servlets coding architecture

WebLogic Server fully supports HTTP servlets as defined in the Servlet 2.3 Specification from Sun Microsystems. HTTP servlets form an integral part of J2EE.

JSP JSP is Sun’s specification for embedding Java with HTML to provide on-the-fly content for Web pages. When you create dynamic content, JSPs are more convenient to write than HTTP servlets because they allow you to embed Java code directly into your HTML pages, in contrast with HTTP servlets, in which you embed HTML inside Java code. JSP is part of the J2EE. JSP enables you to separate the dynamic content of a Web page from its static counterpart. It renders services to two different types of developers: HTML developers, who are responsible for the graphic design of the page, and Java developers, who handle the development of software to create the dynamic content. Because JSP is part of the J2EE standard, JSPs can be deployed on a variety of platforms, including WebLogic Server. In addition, third-party vendors and application developers can provide JavaBean components and define custom JSP tags, which can be referenced from a JSP page to provide dynamic content.

13

14


NOTE Java servlets and JSP reside in a special environment on the application server known as a Web container. In which areas of applications can Java servlets and JSPs be used? Figure 1-7 delivers the concept of coding architecture of JSP, in which the Java scriptlets are embedded within HTML tags. Figure 1-8 provides a JSP example as a proof to the concept demonstrated in Figure 1-8. A Java servlet is a pure Java program written using Java Programming Language (HTML is embedded in the Java code), whereas a scriptlet is a Java code snippet that is embedded within HTML code. Servlets and JSP have inside-out architecture (exactly opposite to each other).

Areas of Application The following shows where servlets can be applied: •

HTML form processing This is the processing of Web-based forms, including those used to store the data to a file or package it and e-mail it to an administrator. Common Gateway Interface (CGI) scripts have conventionally performed these functions. One of the most common CGI scripts in use for this task is the form2email.cgi program. However, servlets provide better performance and scalability than CGI.

•

HTML page counters Popular additions to many Web pages, page counters can track the number of times a user has accessed a given page by incrementing a counter file somewhere on the server. Although popular, they tend to place significant overhead on the server when implemented using CGI scripts.

Figure 1-7.

JSP coding architecture

Chapter 1:


HTML code

Java scriptlet

Java scriptlet

Figure 1-8.

JSP coding example

•

Newsgroups This is a Web-based version of the UseNet groups found on the Internet. A newsgroup is a mechanism that allows users to exchange data by leaving messages for everyone to read. These messages can also be replied to. Threads of conversations take place, in which people reply to replies.

•

Guest books A guest book is a place for guests to a Web site to leave their comments or suggestions for the webmaster. This differs from merely sending the webmaster an e-mail, as other visitors can also see the posted comments.

•

Search engines A site search engine allows the user to find information quickly and easily from within the site, without having to root around for it. Although CGI-based search engines do exist, it has been left to the built-in capabilities of the Web server to provide such functionality.

•

Banner advertising Online advertising is becoming increasingly popular with the more highly accessed sites that sell banner space to advertisers. A banner allows the advertiser to display a small image that, when clicked, will take the user to an alternative site.

15

16


•

Quote generators A quote generator is a small program that, when run, generates a new line of text. For example, UNIX fortune cookies run every time a user logs into the system, presenting the user with a new pearl of wisdom. Web-based generators operate in somewhat the same way, by inserting a new line of text into the Web page every time it is accessed.

•

Random links It is both common and courteous to have a place on a Web site that offers a list of additional places that the user may wish to visit. These lists can sometimes get very long. Instead of having the user wade through lists, webmasters can create one link that users can click to take them to a new link that’s randomly chosen from a list of possible links.

•

Chat programs Chat programs allow users to talk to each other in real time on the Internet. Internet Relay Chat (IRC) is one of the most common protocols for conversing on the Net. A separate program that runs outside the Web environment is required to use IRC (e.g., MSN Messenger or Yahoo Messenger). However, CGI was one of the tools used to bring an HTML version of IRC to the user.

Future Applications When server-side processes are implemented using Java, a whole new world of applications can be realized. Applications that had previously required a sophisticated language solution can be easily implemented for a multiple-platform environment in Java servlets. These are listed here: •

Advanced database accesses Providing access to databases via CGI scripts was never much of a problem; however, controlling the number of sessions and security issues sometimes was.

•

Virtual shopping baskets Virtual shopping baskets allow users to browse a site, adding items to be purchased to a list (or “cart”) as they go. Once the shopper is finished, he or she can visit the virtual checkout for payment and delivery details.

•

Online quizzes In Web-based quizzes, users answer multiple-choice questions as they race against a clock. The server must keep track of the answers as it also keeps an accurate record of the time. All this happens without users having to log into the game beforehand.

•

Dynamic images Dynamic images are generated by drawing on a virtual canvas in the server’s memory. Everything on the canvas is then converted to an image. The image can then be transmitted to the client browser via a .gif or .jpg image file.

•

Advanced HTML filters Before a Web page is delivered to a client, it can be preprocessed, removing any references to words that may be deemed unsuitable by the Web or site administrator. This process can also be extended to replace terms, as opposed to search-and-destroy–type applications.

Chapter 1:


•

Advanced HTML form processing Users have the ability to send files or data in a secure format to the server from a Web-based form.

•

E-mail transmitting servers More sophisticated e-mail distribution list applications are available. Users can sign up to receive e-mail, such as a new joke every day or a different passage from a book.

•

Site analysis In addition to providing weekly and daily statistical information regarding the number of visitors to a Web site, up-to-the-second information can be made available to site administrators. They then have the ability to see who is viewing the pages at any one point in time.

•

News feeds In broadcast systems, the user is informed of an event the second it happens, as opposed to the user having to look for the information. With news feeds, the information finds the user.

EJB EJBs are network-aware components distributed for developing secure, scaleable, transactional, and multi-user components in a J2EE environment of WebLogic Server. These components are then deployed and rolled out on a J2EE-enabled WebLogic Server. This description describes EJBs from a functional point of view—that is, what they do. A more structural explanation would be that EJBs are collections of Java classes, interfaces, and XML files adhering to given rules. It’s worth noting that in J2EE, all the components run inside their own containers. JSP, servlets, and JavaBeans run under Web containers. Similarly EJBs run inside an EJB container, as shown in Figure 1-9. The EJB container provides a standard set of services, such as transaction management, persistence, security, component pooling, resource management, and concurrency. EJBs are the standard for working with server-side components on Java-enabled servers. WebLogic Server has implemented the EJB architecture based on Sun’s EJB specification.

EJB Types EJBs come in four different types: •

Stateless session beans A stateless session bean does not maintain state between method calls. State is considered the result of a prior method call, or setting of an attribute, which is made available in a later part of the application on the Web. With stateless session beans, you cannot depend upon the result of a prior method call when making a new method call. Stateless session beans are often used to access a database or service directly where prior knowledge of events is not required or desirable. Other stateless behavior—for example, returning a list of currently logged-in users—might be modeled with a stateless session bean.

17

18


•

Stateful session beans Stateful session beans remember what happened from prior method calls. A stateful session bean may act stateless, but in most cases, it “remembers” what happened before.

•

Entity beans Entity beans, added into the EJB specification at version 1.1, are essentially stateful session beans with persistent behavior.

•

Message-driven beans Message-driven beans were added into the EJB specification with version 2.0. These are effectively stateful session beans that operate asynchronously. A message bean sits idle, waiting for a message; when one arrives, the bean processes it. Message beans can remember prior state; however, because users have no control over which particular copy of a message bean received their message (many copies of the same bean could be held in memory), prudence dictates avoiding taking advantage of state. Stateful behavior in a message bean should be constrained to reading and working with startuptype information. Message-driven beans are similar to everyday mail handlers. You drop a message into a mailbox, and a mail carrier picks it up and forwards it to someone to read. The reader may send back a message in return, but then again, she may not.

Figure 1-9.

Web and EJB containers

Chapter 1:


EJB Container Services The WebLogic Server container provides certain built-in services to EJBs, which the EJBs use to function. The services that the EJB container provides are shown here: •

Component pooling

•

Resource management

•

Transaction management

•

Security

•

Persistence

•

Concurrency

At times, EJB is used to map database entities to Java objects and encapsulate all functionality within an EJB component. These objects are then used by Java servlets that act as consumers of services that EJBs have to expose.

Resource Adapter To understand the purpose of a Resource Adapter, you first need to know about the connector architecture. With the latest version of J2EE is a new architecture for integration of a J2EE-compliant application server, such as WebLogic with EIS. Figure 1-10 demonstrates that the central component within the WebLogic J2EE connector architecture is the Resource Adapter, which serves as the “connector.” Connector architecture enables both EIS vendors and third-party application developers to join hands and develop Resource Adapters, which can be deployed in any application server that provides support for J2EE 1.3 specifications from Sun Microsystems. Resource Adapters contain the Java components, and if necessary, also the native components Required for interacting with the EIS. When a Resource Adapter is deployed in the WebLogic Server environment, it enables the development of robust J2EE applications that have access to a remote EIS system. Developers of WebLogic Server applications can use HTTP servlets, JSPs, EJBs, and other APIs to develop integrated applications that use the data and business logic of the EIS.

19

20


Figure 1-10.

Resource Adapters

DEVELOPMENT ENVIRONMENT VS. PRODUCTION ENVIRONMENT Development of an application and carrying it to production are two distinctly difficult activities. When the system is under development, typically various groups/teams are working on each piece of the system in an independent, rather disconnected manner. The teams do coordinate if some piece is complete and is deemed usable by other teams, but the development process is often not a well-integrated and connected process. Ideally, a well-constructed system emphasizes integration and tight coupling between various components of the system; but the reality is that it is difficult to attain this in a development environment. In the traditional project development environment, a wide variety of tools exist for different activities during the project’s life cycle. Mostly, these tools do not coexist on the same platform, thereby disconnecting various project activities. In the typical development and production process, some teams design front ends; others build front-end logic; others work at various business layers (middle-tier); some teams are responsible for database administration; and some are responsible for database

Chapter 1:


development, business analysis, and so on. Such an environment can prove difficult for keeping teams working in a truly integrated manner. When developing in Java, you should always make sure that you’re working in a controlled development environment. To avoid Java class conflicts and other problems that can be difficult to diagnose, you need to be aware of all of the environment settings that are in use during development. A common set of tools must be used by all the teams participating in development for source code control and versioning, test frameworks, source code editors, and coding conventions and guidelines. Having a deployment environment preconfigured in development to match the production environment helps ensure high-quality deployments and helps to streamline the application life cycle. You should develop your application by utilizing the J2EE model for application deployment. J2EE applications provide a consistent, portable, and easily maintainable way to deploy your applications. WebLogic Server has a provision for auto-deployment, which is viable for quickly deploying the application on the administration server. We recommend that you use this method of deployment only in a single-server development environment. It is not advisable in a production environment or while deploying components on managed servers. CAUTION You must ensure that auto-deployment is turned off in the production environment. Another mechanism of deploying the applications is known as hot-deployment, or dynamic deployment. In this case, whenever the application undergoes change, it is automatically deployed in the sense that changes are immediately impacted. In addition, this setting is, by default, enabled. CAUTION Dynamic deployment should not be used in a production environment. Instead, a manual or static deployment of applications should occur. In the development environment, dynamic deployment or auto-deployment can be afforded because it is just internal—that is, it’s internal to the teams concerned. However, when in the production environment, great care must be taken to not initiate any steps that can lead to unexpected behavior and user experiences and that can harm organizations’ reputations. Typically, Web applications undergo constant changes, and users don’t want to see these changes every time the contents are added, subtracted, or manipulated on the Web site. Even the functionality of the Web applications can change, which at times involves new business rules. This doesn’t mean that the only point at which we can and should deploy applications is when the server boots, however. At times, bug fixes

21

22


need to be dropped without bringing down the server and without affecting the availability and functionality of the Web site. In such a case, we must perform dynamic deployment. Hence, specific features that we need to apply to specific content are crucial. One more issue crucial in a production environment is the discovery of managed servers. WebLogic Server has an administration server and a managed server. An administration server manages the managed servers. Therefore, you must deploy your applications in the production environment on the managed servers and not use an administration server for that purpose. You can restart the administration server without affecting the clients connected to managed servers, even when the managed servers are running. If you restart the WebLogic administration server while the managed servers are still running, the administration server will detect the presence of the running managed servers if instructed to do so. To instruct the administration server to look for running managed servers, enter the following argument on the command line when starting the administration server: -Dweblogic.management.discover=true

The default value of this attribute is true. Why is it, then, that we have to set it to true? To ensure that either this parameter is not set or at least not set to false. The configuration directory for the domain contains the file running-managed-servers.xml, which is a list of the managed servers that the administration server knows about. When the administration server is instructed to perform discovery upon startup, it uses this list to check for the presence of running managed servers. From a hardware perspective, the way we configure our development servers is a lot different from the way we configure our production servers. Development servers are never under stress and don’t need to be scaleable in terms of supporting a large number of users, whereas the production servers do function under stress and must be scaleable.

WEB SERVICES Web services is a blanket term used for defining the infrastructure required to link applications in a business-to-business (B2B) world. Web services go beyond those things traditionally provided by Web applications and provide a standard mechanism for linking disparate systems in a uniform and well-defined manner. Web services provide a common protocol that Web applications can use to connect to each other over the Internet. Web services will change the way the industry and companies view their applications. Applications that previously were difficult or impossible to combine can be exposed and connected quickly and easily using Web services. A Web service is made up of a number of the following parts and services: •

Web Services Description Language, or WSDL, is used to define the external view of a service. Applications use WSDL to understand how to talk to existing Web services and how to expose functionality as a Web service. WSDL works

Chapter 1:


much like a Remote Procedure Call (RPC) mechanism and is written completely in XML. •

UDDI and Electronic Business XML Initiative (ebXML) provide a mechanism that both registers and searches for a given service. Using WSDL, a Web service makes itself known in the global “marketplace” via the UDDI publish service (by publishing your XML Web service to the UDDI registry). Other Web services can then find an existing service by using the UDDI Inquiry API. UDDI represents simple, typically point-to-point Web services. ebXML provides a mechanism similar to UDDI but with a much broader list of query APIs. It is typically found in more complex applications that require multiple services to interact at one time.

•

SOAP provides the final portion of a Web service, using a mechanism to invoke a Web service that we have found using UDDI and understand via WSDL.

Web services are an interesting new area that focuses on exposing enterprise services through the Web. A point to note is that Web services are a number of interconnected protocols, defined using the Java community process (JCP), but technically not J2EE services.

WLS ENVIRONMENT AND TOOLS Development and production environments differ in the way their applications and availability are managed. The environment that most closely resembles the production environment is that of the User Acceptance Test (UAT). With WebLogic Server, it is possible to change the configuration attributes of domain resources dynamically—that is, while servers are running. One of the strongest features is that, in most cases, the WebLogic Server does not have to be restarted for changes to take effect. When an attribute is reconfigured (when the value is changed), the new value is immediately reflected in both the current runtime value of the attribute and the persistent value stored in the XML configuration file.

Setting the classpath Option To execute various command-line administration tools, you will be required to set the CLASSPATH variable, or the following must be included as values to the -classpath option on the java command line: /weblogic/lib/weblogic_sp.jar /weblogic/lib/weblogic.jar

WebLogic Server provides a default database management system (DBMS) called Cloudscape. To use this DBMS, the following needs to be included in classpath setup: /weblogic/samples/eval/cloudscape/lib/cloudscape.jar

23

24


If you will be using WebLogic Enterprise Connectivity, you will need to include the following: /weblogic/lib/poolorb.jar

where weblogic is the directory in which you installed WebLogic Server. To set the CLASSPATH variable on the command line, specify the following: SET CLASSPATH=C:\bea\weblogic700b\server\lib\weblogic.jar

Starting WebLogic Server To start WebLogic Server from the Start menu, choose Programs | BEA WebLogic Enterprise Platform | WebLogic Platform Beta 7.0 | User Domains | My Domain | My Server. Alternatively, follow these steps: 1. Access the command prompt by choosing Start | Run | CMD. 2. Change the working directory to C:\BEA\User_Domains\MyDomain. 3. Run the setenv.bat file on Microsoft Windows platform, or setenv.sh on the UNIX platform. This file internally calls another file from C:\BEA\WebLogic700b\ Server\Bin called startWebLogic.cmd. (StartWebLogic.cmd is the file that declares necessary environment variables. The environment variables specified in startWebLogic.cmd are used by WebLogic Server as input while starting up.) It further assigns few more variables, such as WL_HOME and JAVA_HOME, sets the CLASSPATH, appends PATH for WebLogic Server bin and Java bin folders, and finally executes weblogic.Server. It also makes sure that the weblogic.jar file is available and that CLASSPATH points to it. Sample startWebLogic.cmd (C:\BEA\User_Domains\MyDomain) @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem

****************************************************************** This script is used to start WebLogic Server for the domain in the current working directory. All this script does is set the DOMAIN_NAME and SERVER_NAME variables, then calls the startWebLogic.cmd script under %WL_HOME%\server\bin. To create your own start script for your domain, all you need to set is DOMAIN_NAME and SERVER_NAME, then call %WL_HOME%\server\bin\startWebLogic.cmd Other variables that startWebLogic takes are: WLS_USER WLS_PW

- cleartext user for server startup - cleartext password for server startup

Chapter 1:

@rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem


STARTMODE

- true for production mode servers, false for development mode JAVA_OPTIONS - Java command-line options for running the server. (These will be tagged on to the end of the JAVA_VM and MEM_ARGS) JAVA_VM - The java arg specifying the VM to run. (i.e. -server, -hotspot, etc.) MEM_ARGS - The variable to override the standard memory arguments passed to java For additional information, refer to Installing and Setting up WebLogic Server (http://e-docs.bea.com/wls/docs70/install/index.html). ******************************************************************

echo off SETLOCAL @rem Set DOMAIN_NAME to the name of the domain you wish to run. set DOMAIN_NAME=mydomain @rem Set SERVER_NAME to the name of the server you wish to start up. set SERVER_NAME=myserver @rem Set WLS_USER equal to your system username and WLS_PW equal @rem to your system password for no username and password prompt @rem during server startup. Both are required to bypass the startup @rem prompt. set WLS_USER=installadministrator set WLS_PW=installadministrator @rem Set Production Mode. When this is set to true, @rem the server starts up in @rem production mode. When set to false, the server starts @rem up in development @rem mode. If it is not set, it will default to false. set STARTMODE= @rem Set JAVA_OPTIONS to the java flags you want to pass to the vm. i.e @rem set JAVA_OPTIONS=-Dweblogic.attribute=value -Djava.attribute=value set JAVA_OPTIONS=

25

26


@rem Call WebLogic Server call "C:\bea\weblogic700b\server\bin\startWebLogic.cmd" ENDLOCAL

Sample startWebLogic.cmd (Under C:\BEA\WebLogic700b\Server\Bin) @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem

****************************************************************** This script is used to start WebLogic Server To create your own start script for your domain, all you need to set is DOMAIN_NAME and SERVER_NAME, then call this script from the domain directory. This script sets the following variables before starting WebLogic Server: WL_HOME JAVA_HOME

PATH CLASSPATH

- The root directory of your WebLogic installation - Location of the version of Java used to start WebLogic Server. This variable must point to the root directory of a JDK installation and will be set for you by the installer. See the WebLogic platform support page (http://e-docs.bea.com/wls/platforms/index.html) for an up-to-date list of supported JVMs on Windows NT. - Adds the JDK and WebLogic directories to the system path. - Adds the JDK and WebLogic jars to the classpath.

Other variables that startWebLogic takes are: WLS_USER WLS_PW ADMIN_URL

- admin username for server startup - cleartext password for server startup - if this variable is set, the server started will be managed server, and will look to the url specified (i.e. http://localhost:7001) as the admin server. STARTMODE - set to true for production mode servers, false for development mode JAVA_OPTIONS - Java command-line options for running the server. (These will be tagged on to the end of the JAVA_VM and MEM_ARGS)

Chapter 1:

@rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem

JAVA_VM MEM_ARGS


- The java arg specifying the VM to run. (i.e. -server, -client, etc.) - The variable to override the standard memory arguments passed to java

jDriver for Oracle users:This script assumes that native libraries required for jDriver for Oracle have been installed in the proper location and that your system PATH variable has been set appropriately. For additional information, refer to Installing and Setting up WebLogic Server (http://e-docs.bea.com/wls/docs70/install/index.html). ******************************************************************

@echo off SETLOCAL set WL_HOME=C:\bea\weblogic700b set JAVA_HOME=C:\bea\jdk131 @rem Check that the WebLogic classes are where we expect them to be :checkWLS if exist "%WL_HOME%\server\lib\weblogic.jar" goto checkJava echo The WebLogic Server wasn't found in directory %WL_HOME%\server. echo Please edit your script so that the WL_HOME variable points echo to the WebLogic installation directory. goto finish @rem Check that java is where we expect it to be :checkJava if exist "%JAVA_HOME%\bin\java.exe" goto runWebLogic echo The JDK wasn't found in directory %JAVA_HOME%. echo Please edit your script so that the JAVA_HOME variable echo points to the location of your JDK. goto finish :runWebLogic if not "%JAVA_VM%" == "" goto noResetJavaVM set JAVA_VM=-hotspot :noResetJavaVM if not "%MEM_ARGS%" == "" goto noResetMemArgs

27

28


set MEM_ARGS=-Xms200m -Xmx200m :noResetMemArgs @echo on set CLASSPATH=%JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar;%CLASSPATH% set PATH=.;%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH% @echo @echo @echo @echo @echo @echo @echo @echo @echo

*************************************************** * To start WebLogic Server, use a username and * * password assigned to an admin-level user. By * * default, this is user: installadministrator * * and password: installadministrator. These * * should both be changed using the WebLogic * * Server console at * * http://[hostname]:[port]/console * ***************************************************

@rem Start Server @echo off if "%ADMIN_URL%" == "" goto runAdmin @echo on "%JAVA_HOME%\bin\java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% -classpath "%CLASSPATH%" -Dweblogic.Domain=%DOMAIN_NAME% -Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea" -Dweblogic.management.username=%WLS_USER% -Dweblogic.management.password=%WLS_PW% -Dweblogic.management.server=%ADMIN_URL% -Dweblogic.ProductionModeEnabled=%STARTMODE% -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server goto finish :runAdmin @echo on "%JAVA_HOME%\bin\java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% -classpath "%CLASSPATH%" -Dweblogic.Domain=%DOMAIN_NAME%

Chapter 1:


-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea" -Dweblogic.management.username=%WLS_USER% -Dweblogic.management.password=%WLS_PW% -Dweblogic.ProductionModeEnabled=%STARTMODE% -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server :finish ENDLOCAL

Tools In this section, we will look at the tools involved in working with WebLogic Server.

Deployment With Java applications, deployment has never been easy. WebLogic provides various options for deploying applications. Use the WebLogic Server Administration Console, the weblogic.Deployer utility, the Marathon utility, or auto-deployment. The weblogic.Deployer utility is further discussed in Chapter 12.

EJBGen WebLogic 7 has an EJBGen tool that works as an EJB 2.0 code generator. While executing this tool, you are required to provide the name of a bean class file with javadoc comment tags, which will then generate the remote and home classes and the deployment descriptor files for an EJB application. This helps reduce the number of EJB files to edit and maintain. EJBGen allows editing to be limited to one file (the bean class) and annotated with javadoc tags. EJBGen is discussed further in Chapter 12.

WebLogic Builder At times, assembling a J2EE application module, creating and editing its deployment descriptors, and later deploying it to WebLogic Server can prove to be a challenging and time-consuming task. WebLogic Builder, as shown in Figure 1-11, facilitates those challenges as a graphical tool used for assembling a J2EE application module, creating and editing its deployment descriptors, and deploying it to a WebLogic server. WebLogic Builder provides a visual editing environment for editing an application’s deployment descriptor XML files. You can view these XML files as you visually edit them in WebLogic Builder, but you won’t need to make textual edits to the XML files. Figure 1-11 shows how we have opened and accessed the descriptor files from within the EJB application module (EAR). The open descriptor files are ejb-jar.xml and weblogic-ejb-jar.xml. The changes you make to the descriptors using this tool are saved in the related archive file (JAR or EAR).

29

30


Figure 1-11.

WebLogic Builder

WebLogic Workshop WebLogic Workshop is an integrated development environment (IDE) that offers a GUI-based approach to developing distributed, interconnected, and loosely coupled enterprise-class Web services. With WebLogic Workshop, you can design Web services as you might draw them on paper and then add code to support the services’ functionality. You can focus on developing your service’s application logic rather than on writing code to support platform infrastructure. Figure 1-12 demonstrates the concept.

Chapter 1:

Figure 1-12.


WebLogic Workshop

CONFIGURATION BASICS At the heart of WebLogic Server is the configuration file config.xml. This file contains configuration information about the entire WebLogic Server domain. Figure 1-13 demonstrates the information recorded within config.xml. The config.xml file is made up of numerous XML elements, each describing various aspects of the WebLogic Server domain. Configuration information related to various J2EE components, such as JSPs, servlets, EJBs, JDBC connections, JMS, JTA, JNDI, and so forth, is stored in this file.

31

32


Figure 1-13.

The config.xml file

You can manipulate config.xml manually by using your favorite editor and check the reflection in the behavior of the configured components when you run the server. You can also use the WebLogic Administration Console to manipulate various parameters related to the WebLogic applications or server, and later check config.xml for their updated values. Exercising this is handy and helps further understanding of the role of config.xml. Following is a sample config.xml file: Sample config.xml --> --> --> --> --> --> --> --> --> --> --> -->
57

58


value="cluster3" /> --> --> --> --> --> --> --> --> --> -->

You can modify this file to suit your requirements and then run the installer using the following syntax and example. Installing on the Windows Platform Open a DOS prompt and change directories to where the installer program is located. The general syntax of the command you need to run is filename.exe -mode=silent -silent_xml=path_to_silent.xml Here’s an example: C:\Softwares> weblogic700_win.exe -mode=silent -silent_xml=D:\silent.xml -log=D:\logs\wls_install.log

Installing on the UNIX Platform Open a console and go to the directory where the installer program is saved. The general syntax of the command you need to run is chmod a+x filename ./filename -mode=silent -silent_xml=/path_to_silent.xml Here’s an example: $ weblogic700_solaris.bin -mode=silent -silent_xml=/home/silent.xml -log=/logs/wls_install.log

Chapter 2:

WebLogic Application Server Installation and Configuration

WEBLOGIC SERVER DIRECTORY STRUCTURE WebLogic Server software is installed under the target folder that you specified during installation. The WebLogic Server directory structure typically looks like this.

This structure is located in the C:\BEA folder. The folder C:\BEA\WebLogic700 contains Common, Samples, Server, and Uninstall folders. •

Common contains files shared by WebLogic Server components.

•

Samples contain sample codes and other examples designed for learning more about WebLogic Server and its features. Directory structure for the Samples folder can be seen next.

•

Server contains server program files (executables).

•

Uninstall contains code required to uninstall/remove WebLogic Server from the computer system.

59

60


WEBLOGIC SERVER CONFIGURATION FILE The WebLogic Server 7 configuration file, config.xml, looks different if you are coming from the world of WebLogic 6.x. It is strongly recommended that you modify config.xml using the WebLogic Domain Administration Console utility. Figure 2-12 provides a glimpse of the Administration Console. BEA also provides a simple tool called XML Editor, which can be acquired from http://dev2dev.bea.com. (To be more precise, you can look for this tool at http:// dev2dev.bea.com/resourcelibrary/utilitiestools/xml.jsp?highlight=utilitiestools.) Figure 2-13 shows the BEA XML Editor tool. NOTE Make sure that you make a backup of the existing config.xml prior to editing it. Do not edit config.xml when the domain is still active and running.

Figure 2-12.

Administration Console

Chapter 2:

Figure 2-13.


BEA XML Editor tool

CONFIGURATION ATTRIBUTES Following are the configurable attributes within the config.xml file: Administrator BridgeDestination COM Domain

Application CachingRealm ConnectorComponent DomainLogFilter

ApplicationManager Cluster CustomRealm EJBComponent

61

62


EJBContainer FileRealm JDBCConnectionPool JDBCMultiPool JMSBridgeDestination JMSDestinationKey JMSDistributedTopic JMSJDBCStore JMSSessionPool JMSTopic JTAMigratableTarget Log MessagingBridge NetworkChannel PasswordPolicy Security ServerStart SNMPAttributeChange SNMPJMXMonitor SNMPStringMonitor SSL UnixRealm WebServiceComponent WTCImport WTCRemoteTuxDom WTCtBridgeGlobal XMLEntitySpecRegistr yEntry XMLRegistryEntry

EmbeddedLDAP FileT3 JDBCDataSource JDBCPoolComponent JMSConnectionConsumer JMSDistributedQueue JMSDistributedTopicMember JMSQueue JMSStore JoltConnectionPool JTARecoveryService Machine MigratableRMIService NodeManager RDBMSRealm SecurityConfiguration ShutdownClass SNMPCounterMonitor SNMPLogFilter SNMPTrapDestination StartupClass WebAppComponent WLECConnectionPool WTCLocalTuxDom WTCResources WTCtBridgeRedirect XMLParserSelectRegistryEntry

ExecuteQueue IIOP JDBCDataSourceFactory JDBCTxDataSource JMSConnectionFactory JMSDistributedQueueMember JMSFileStore JMSServer JMSTemplate JTA LDAPRealm MailSession NetworkAccessPoint NTRealm RMCFactory Server SNMPAgent SNMPGaugeMonitor SNMPProxy SNMPTrapSource UnixMachine WebServer WTCExport WTCPassword WTCServer XMLEntityCache XMLRegistry

SETTING CLASSPATH The CLASSPATH environment variable specifies a list of directories and JAR files in which WebLogic applications and the server can look for class files. Installing WebLogic Server does most of the work for us by creating a file called SETENV.CMD (Windows) or SETENV.SH (UNIX). The file SETENV.CMD internally calls the file C:\bea\weblogic700\ server\bin\setWLSEnv.cmd. Following are the contents of the file setWLSEnv.cmd that sets the class path and performs other path settings:

Chapter 2:


@rem ************************************************************ @rem This script is used to set up your environment for development @rem with WebLogic Server. It sets the following variables: @rem @rem WL_HOME - The root directory of your WebLogic installation @rem JAVA_HOME - Location of the version of Java used to start WebLogic @rem Server. This variable must point to the root directory of @rem JDK installation and will be set for you by the installer. @rem See the WebLogic platform support page @rem (http://e-docs.bea.com/wls/platforms/index.html) for an @rem up-to-date list of @rem supported JVMs on Windows NT. @rem PATH - Adds the JDK and WebLogic directories to the system path. @rem CLASSPATH - Adds the JDK and WebLogic jars to the CLASSPATH. @rem @rem Other variables that setWLSEnv takes are: @rem @rem PRE_CLASSPATH - Path style variable to be added to the beginning of the @rem CLASSPATH @rem POST_CLASSPATH - Path style variable to be added to the end of the @rem CLASSPATH @rem PRE_PATH - Path style variable to be added to the beginning of the @rem PATH @rem POST_PATH - Path style variable to be added to the end of the PATH @rem @rem When setting these variables below, please use short file names(8.3). @rem To display short (MS-DOS) filenames, use "dir /x". File names with @rem spaces will break this script. @rem @rem jDriver for Oracle users: This script assumes that native libraries @rem required for jDriver for Oracle have been installed in the proper @rem location and that your system PATH variable has been set appropriately. @rem @rem For additional information, refer to the WebLogic Server Administration @rem Guide (http://e-docs.bea.com/wls/docs70/adminguide/startstop.html). @rem ******************************************************************* @echo off @rem Set user-defined variables. set WL_HOME=C:\bea\weblogic700 set JAVA_HOME=C:\bea\jdk131 @rem Check that the WebLogic classes are where we expect them to be @if exist "%WL_HOME%\server\lib\weblogic.jar" goto checkJava @echo. @echo The WebLogic Server wasn't found in directory %WL_HOME%\server. @echo Please edit the setWLSEnv.cmd script so that the WL_HOME @echo variable points to the WebLogic installation directory. @echo Your environment has not been set.

63

64


@goto finish @rem Check that java is where we expect it to be :checkJava @if exist "%JAVA_HOME%\bin\java.exe" goto setWLSEnv @echo. @echo The JDK wasn't found in directory %JAVA_HOME%. @echo Please edit the setWLSEnv.cmd script so that the JAVA_HOME @echo variable points to the location of your JDK. @echo Your environment has not been set. @goto finish :setWLSEnv set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar;%WL_HOME%\server\lib\webservices.jar; %CLASSPATH% set PATH=%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH% @rem Import extended environment if exist extEnv.cmd call extEnv.cmd if not "%EXT_PRE_CLASSPATH%" == "" set CLASSPATH=%EXT_PRE_CLASSPATH%;%CLASSPATH% if not "%EXT_POST_CLASSPATH%" == "" set CLASSPATH=%CLASSPATH%;%EXT_POST_CLASSPATH% if not "%EXT_PRE_PATH%" == "" set PATH=%EXT_PRE_PATH%;%PATH% if not "%EXT_POST_PATH%" == "" set PATH=%PATH%;%EXT_POST_PATH% @rem Get PRE and POST environment if not "%PRE_CLASSPATH%" == "" set CLASSPATH=%PRE_CLASSPATH%; %CLASSPATH% if not "%POST_CLASSPATH%" == "" set CLASSPATH=%CLASSPATH%; %POST_CLASSPATH% if not "%PRE_PATH%" == "" set PATH=%PRE_PATH%;%PATH% if not "%POST_PATH%" == "" set PATH=%PATH%;%POST_PATH% @echo. @echo CLASSPATH=%CLASSPATH% @echo. @echo PATH=%PATH% @echo. @echo Your environment has been set. :finish

When executed, this file sets all necessary CLASSPATH and path information. However, it is also possible to set the CLASSPATH manually at the command prompt, as shown here:

Chapter 2:


SET WEBLOGICHOME=C:\BEA\WebLogic700b SET CLASSPATH=%weblogichome%\server\lib\weblogic.jar; %weblogichome%\server\lib\wlepool.jar;%weblogichome%\server\lib\wleorb.jar

You can always amend the CLASSPATH variable by adding few more paths or .jar files to the list.

DATABASE CONFIGURATION AND CONNECTION We can use the utilities DBPing and T3DBPing provided with WebLogic Server installation for configuration and connection.

DBPing The utils.ping utility is used to ensure that WebLogic Server is up and running. Similarly, WebLogic provides another utility called DBPing to perform handshakes with databases. Usually, utilities are provided by the DBMS vendors to test database connectivity. DBPing is a command-line utility provided by WebLogic that aids in testing connection possibilities with the database server and client system using a JDBC driver. It is specifically designed to test connectivity from the command line with databases in a two-tier architecture.

T3DBPing You need to use the T3DBPing utility whenever you want to perform a multi-tier database connection using WebLogic Server. This utility is only for testing multi-tier database connectivity and has no other obvious use in the applications. NOTE Details about these utilities are covered in Chapter 12.

TESTING THE CONFIGURATION AND CONNECTIVITY You can use utilities such as MyIP, Version, and Ping to confirm the configuration and connectivity to WebLogic Server 7.

MyIP This utility returns the IP address of the host on which WebLogic Server is running.

Version This utility is useful for administrators to find out version information for the WebLogic Server installed. The information is presented on the Standard Output (stdout) device.

65

66


Ping Short for Packet Internet Groper, Ping is used to determine whether a specific IP address is accessible in the network or over the internetwork. It sends a request to a specific IP address and looks for a response. If the destination computer system returns a response, it means the handshake was successful; otherwise, it will indicate a problem in the network connectivity, which could be either a hardware connectivity issue or a software settings issue.

INSTALLING WEBLOGIC SERVER ON SOLARIS AND AIX We have already covered the process for installing WebLogic Server on a Microsoft Windows platform. Installing it on Solaris and IBM AIX is not that different, but certain hardware and software requirements must be met.

Sun Solaris 8.0 To install WebLogic Server 7 on Sun Solaris 8.0, your system needs to be configured as follows:

Hardware Requirements •

UltraSPARC 168MHz or better

•

256MB RAM minimum

•

170MB disk space

Software Requirements •

Performance pack (included)

•

Compatible browser (IE 5.0 or 5.5, Netscape 4.7 or 6.2)

•

SunSoft SDK 1.3.1_02 Java 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02) with Java HotSpot Client VM (build 1.3.1_02-b02, mixed mode)

IBM AIX To install WebLogic Server 6.x on IBM AIX, your system needs to be configured as follows:

Hardware Requirements •

RS/6000 PowerPC-270 200MHz or higher

•

64MB RAM minimum

•

200MB disk space

Chapter 2:


Software Requirements •

Performance pack included

•

Compatible browser (IE 5.0 or 5.5, Netscape 4.7 or 6.2)

•

JDK 1.3.0 Java 2 Runtime Environment, Standard Edition (build 1.3.0), Classic VM (build 1.3.0, J2RE 1.3.0 IBM build ca130-20010516 [JIT enabled: jitc])

STARTING WEBLOGIC SERVER Now that you have completed installing WebLogic Server 7 on your system, it is time to get it up and running. To start WebLogic Server, choose Start | Programs | BEA WebLogic Platform 7.0 | WebLogic Server 7.0 | User Projects | Start Server. When you initiate WebLogic Server 7, you will be prompted to provide the username and password. If you want to skip this process in the future, you can create and use a boot identity file, which contains your username and password in an encrypted format. To do this, create a valid boot identity file called boot.properties in the server’s root directory. The server will make use of this file for authentication information while it is being started up. NOTE If you want to specify a different file (or if you do not want to store boot identity files in a server’s root directory), you can specify a filename in the server’s startup command. If a server is unable to access its boot identity file, it will display the standard username and password prompt in its command shell and write a message to the log file.

UNINSTALLING WEBLOGIC SERVER At times, you may need to uninstall existing WebLogic Server software and perform a reinstallation. The easiest way to uninstall WebLogic Server is to delete the entire BEA folder, which will remove all the files and folders related to WebLogic. This will not remove the Start | Program icons, however, but these can be removed manually. NOTE Uninstalling BEA WebLogic will eliminate all user projects and applications in the BEA folder. You can uninstall the WebLogic Server software from your system by choosing Start | Programs | BEA WebLogic Platform 7.0 | Uninstall. You must make sure that WebLogic Server is shut down prior to uninstalling. You need to choose the components listed to uninstall. For UNIX systems, to invoke uninstaller under graphics mode, you need to exercise the following command syntax: WL_HOME/uninstall

67

68


For UNIX systems, to invoke uninstaller under command mode, you need to exercise the following command syntax: uninstall.sh console

UPGRADING WEBLOGIC SERVER Fresh installation is not always the easiest scenario in organizations and upgrading is not always as easy as we’d like it to be, as this process will always have side effects if the vendor has made drastic changes to the product. Hence, before we decide to go for an upgrade, it’s a good idea to perform a proper study on how easy an upgrade will be or precisely what kind of efforts will lead to successful upgrade of the existing system and applications on top of it.

Upgrading WebLogic 6.x to 7 To upgrade an existing WebLogic 6.x infrastructure to the newer WebLogic Server 7, we need to consider a few things and make necessary changes to the required areas. This involves changing WebLogic Server startup command scripts and environment settings in the simplest scenarios. In more complex situations, we need to consider changes to the domain directory or at times only the subsystems being upgraded. Follow these steps to upgrade WebLogic 6.x to 7: 1. Back up the existing 6.x domain prior to beginning the upgrade procedure. This step is very crucial because once you are done installing WebLogic Server 7 and you start it, you cannot downgrade to the previous version. 2. Install WebLogic Server 7 on your system. For installation of WebLogic Server 7, refer to earlier sections in this chapter. 3. Modify your startup command scripts of 6.x such that they work with WebLogic Server 7. The next section addresses this step. 4. One major change with WebLogic Server 7 from 6.x is that of directory structure. You need to study the differences between the directory structures of both versions. 5. Port existing applications to WebLogic Server 7. NOTE At times during upgrade, you may be required to upgrade some of the subsystems, such as security and Tuxedo Connector.

Modifying Startup Command Scripts If you have not already looked at the WebLogic Startup Command Scripts, following is a sample (this file can be found at C:\bea\wlserver6.1\config\mydomain):

Chapter 2:


@echo off @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem @rem

This script can be used to start WebLogic Server. This script ensures that the server is started using the config.xml file found in this directory and that the CLASSPATH is set correctly. This script contains the following variables: JAVA_HOME

- Determines the version of Java used to start WebLogic Server. This variable must point to the root directory of a JDK installation and will be set for you by the WebLogic Server installer. Note that this script uses the hotspot VM to run WebLogic Server. If you choose to use a JDK other than the one included in the disribution, make sure that the JDK includes the hotspot VM. See the WebLogic platform support page (http://e-docs.bea.com/wls/platforms/index.html) for an up-to-date list of supported JVMs on Windows NT.

When setting these variables below, please use short file names (8.3). To display short (MS-DOS) filenames, use "dir /x". File names with spaces will break this script. jDriver for Oracle users: This script assumes that native libraries required for jDriver for Oracle have been installed in the proper location and that your system PATH variable has been set appropriately. For additional information, refer to Installing and Setting up WebLogic Server (http://e-docs.bea.com/wls/docs61/install/index.html).

SETLOCAL cd ..\.. @rem Set user-defined variables. set JAVA_HOME=C:\bea\jdk131 @rem Check that script is being run from the appropriate directory if not exist lib\weblogic.jar goto wrongplace goto checkJDK :wrongplace echo startWebLogic.cmd must be run from the config\mydomain directory. 1>&2 goto finish :checkJDK if exist "%JAVA_HOME%/bin/javac.exe" goto runWebLogic echo. echo Javac wasn't found in directory %JAVA_HOME%/bin. echo Please edit the startWebLogic.cmd script so that the JAVA_HOME

69

70


echo variable points to the root directory of your JDK installation. goto finish :runWebLogic echo on set PATH=.\bin;%PATH% set CLASSPATH=.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar echo off echo. echo *************************************************** echo * To start WebLogic Server, use the password * echo * assigned to the system user. The system * echo * username and password must also be used to * echo * access the WebLogic Server console from a web * echo * browser. * echo *************************************************** @rem Set WLS_PW equal to your system password for no password prompt @rem server startup. set WLS_PW= @rem Set Production Mode. When set to true, the server starts up in @rem production mode. When @rem set to false, the server starts up in development mode. @rem The default is false. set STARTMODE=true echo on "%JAVA_HOME%\bin\java" -hotspot -ms64m -mx64m -CLASSPATH "%CLASSPATH%" -Dweblogic.Domain=mydomain -Dweblogic.Name=myserver "-Dbea.home=C:\bea" -Dweblogic.management.password=%WLS_PW% -Dweblogic.ProductionModeEnabled=%STARTMODE% "-Djava.security.policy==C:\bea\wlserver6.1/lib/weblogic.policy" weblogic.Server goto finish :finish cd config\mydomain ENDLOCAL

You need to perform the following steps to modify the WebLogic startup command script to point to WebLogic Server 7 and work with it: 1. Modify the bea.home property to make it point to your BEA home directory, which contains the license.bea file for WebLogic Server 7. For example: Dbea.home=C:\BEA

2. Modify the WL_HOME variable so that it points to your WebLogic Server 7 installation directory:

Chapter 2:


WL_HOME=c:\BEA\weblogic700\server

3. Modify the PATH variable so that it includes your %WL_HOME% 7.0 home. For example: PATH=%WL_HOME%\bin;%PATH%

4. Modify CLASSPATH so that it points to the WebLogic Server 7 classes. For example: CLASSPATH=%WL_HOME%\lib\weblogic_sp.jar;%WL_HOME%\lib\weblogic.jar

5. Modify or eliminate any WebLogic Server 6.x startup script directory structure tests. For example, if your script tries to verify a relative path, either fix the directory structure test or remove it.

WebLogic Server Directory Structure As discussed, directory structure for WebLogic Server 7 is quite different from that of version 6.x. See Figure 2-14 for a comparison.

Figure 2-14.

Directory structure differences between versions 7.0 and 6.x

71

72


Porting Applications from Version 6.x to 7 Reconfiguring WebLogic startup command scripts and studying the Directory structure is useful when you’re thinking about upgrading an existing WebLogic Server version to 7. However, you must also port the applications that have been residing on these servers and have a clear path and plans for porting these applications. Use the following points to port WebLogic 6.x applications on WebLogic Server 7 (it is assumed that you have already worked out the installation of WebLogic Server 7 on your system and that have also modified the startup command scripts, which can be modified even after porting applications): •

Each 6.x and 7 domain must have its own separate directory. It is not possible to have multiple config.xml files in the same directory. For each 6.x configuration domain that you wish to port to WebLogic Server 7, copy the /config/domain directory to a directory location of your choice. This directory is the location of your new domain and will contain all configuration information for that domain. If your 6.x config directory is not located in the WebLogic Server 6.x distribution, you may reuse your WebLogic 6.x configuration in WebLogic Server 7.

•

Applications will have deployment descriptor files such as web.xml and weblogic.xml because those files may contain file paths to items such as the Java compiler or some other external files. WebLogic Server configurations also depend on a number of files that may be stored on the file system. Typically, these files are persistence repositories (log files, file-based repositories, and so forth) or utilities (Java compiler). They can be configured using fully qualified or relative paths.

NOTE WebLogic Server 7 will not deploy an application that has errors in its deployment descriptor, though previous versions of WebLogic Server would do so.

CHECKLIST This chapter navigated through various methods of installing WebLogic Server. You have gained skills for installing WebLogic Server using Graphical, Console, or Silent mode. Also, you have learned about the directory structure for WebLogic Server 7. You have learned to install, start, and uninstall WebLogic Server on Windows and UNIX platforms. You can test database connectivity using tools such as DBPing and T3DBPing. Also, you can test WebLogic connectivity with utilities such as Ping and MyIP. You have learned the importance of setting the CLASSPATH variable for compiling and executing various WebLogic program files, tools, utilities from BEA, and third parties. You have learned the requirements for upgrading existing installations of WebLogic Server.

Chapter 2:


In addition, you have learned that ■

You can acquire WebLogic Server 7 Software from http://commerce.bea.com/ downloads/products.jsp.

■

WebLogic Server Domain is an administrative unit and represents a logical application.

■

WebLogic Server is an instance of the Java class Weblogic.Server and it runs within the context of JVM (Java Virtual Machine).

■

A WebLogic cluster is a group of servers that performs load balancing activities.

■

WebLogic Server can be installed using one of the three methods: graphical (GUI), console, and silent. Silent mode installation is where WebLogic Server installation is performed without user intervention.

■

There are no special requirements to install WebLogic Server on Sun Solaris and IBM AIX, other than hardware and software prerequisites.

■

Directory structure is more organized in WebLogic 7 than in prior versions.

■

The Configuration file for a WebLogic Server domain is config.xml.

■

WebLogic Server can be started and stopped either from a Windows program group or command prompt.

73

CHAPTER 3 WebLogic Console


75

76


ebLogic Console is a Java Server Page (JSP)–based Web application that’s hosted on the administration server. Console can be invoked from any standard Web browser. It can be used to manage a domain and multiple servers in a domain by graphical user interface without actually knowing the internal implementation of management interfaces and objects. Console allows the user to configure, manage, and monitor servers, clusters, and applications. It can be invoked to create a server, start and stop it, monitor its health, view logs, and configure and deploy an application. It also allows for clusters to be configured and created and applications on clusters to be deployed and undeployed. This chapter covers WebLogic Console in depth. After reading this chapter, you will be able to administer and manage a WebLogic domain using Console.

W

GETTING STARTED WITH WEBLOGIC CONSOLE WebLogic Console is invoked from a standard web browser. You can use the listen address and listen port of an administration server to connect to WebLogic Console. Connect to the Console uniform resource locator (URL) as follows: http://<WebLogic Administration Listen Address>:<WebLogic Administration listen port>/console

By default, WebLogic Server runs on localhost and uses 7001 as a listen port. You should change the listen port for security reasons, even if you are running in development mode. If your administration server is running on localhost and listening on port 8001, you can use this URL to access Console: http://localhost:8001/console. Make sure that the WebLogic administration server is running and listening on the correct port before invoking the Console application. After you have invoked Console on your browser, you’ll see the login dialog box shown in Figure 3-1, which prompts you to enter your username and password. The default username and password for the WebLogic administration server are installadministrator and installadministrator. In fact, you can use a username and password of your choice while starting WebLogic Server in a freshly created domain. Use the same username and password to access Console as you use as system administrator, or enter a username and password that belongs to one of the following security groups: administrators, operators, deployers, or monitors. These groups provide protected access to system administration functions in the Administration Console. Please note that if your browser is configured to send HTTP requests to a proxy server, you may need to configure your browser not to send administration server HTTP requests to the proxy. If the administration server is on the same machine as the browser, ensure that requests sent to localhost or 127.0.0.1 are not sent to the proxy. Once authenticated, you will see the full-screen WebLogic Server Console shown in Figure 3-2.

Chapter 3:

WebLogic Console

Figure 3-1.

WebLogic Console Login dialog box

Figure 3-2.

Administration options are accessed via the WebLogic Server Console

77

78


On the right pane of the Console window, descriptions of various options are available. This options pane is divided into the following subsections: •

Information and Resources

•

Domain Configurations

•

Services Configurations

The left pane in the Console window contains a navigation tree that you can use to navigate to tables of data, configuration pages, monitoring pages, or log files. By selecting a node in the domain tree, you can display a table of data for a resource or configuration and monitoring pages for a selected resource. If a node in the tree is preceded by a plus sign (+), click the plus sign to expand the tree to access additional resources. A number of operations are also accessible by right-clicking a node. When you select a node from the navigation tree, you will see either a tabular listing of configured resources or objects or a tabbed interface in the right pane. We will discuss all the configuration, administration, and monitoring options in detail throughout this chapter.

CONSOLE SETTINGS You can set your preferences for Console and customize the configuration for the Console application by following these instructions: 1. Start WebLogic Server Console. 2. Click Console, the topmost node in the navigation tree, to open the Console Preferences dialog box, as shown in Figure 3-3. 3. Set the following attributes: •

Language The default language is English. You can select a language of your choice from the drop-down box.

•

Auto-Refresh Every This attribute indicates the time interval after which a page automatically refreshes. The default value for an auto-refresh for any page is 10 seconds. You can modify this value to your specifications.

•

Poll For Graph Data Every The default interval for Console to poll graph data is 500 milliseconds. You can configure this value as desired.

•

Remember Last Tab This option is checked by default. If you keep this option checked, console remembers the last tab you used.

•

Use Navigation Tree This option is checked by default. It enables you to use a navigation tree along the left side. Unchecking this option removes the navigation tree from view.

Chapter 3:

Figure 3-3.

WebLogic Console

Console Preferences dialog box

DOMAIN CONFIGURATION Domain configuration includes configuring servers and clusters and deploying the application. We will discuss these topics in the following sections.

Configuring Domain Attributes Console shows only the name of the domain represented by the administration server. Refer back to Figure 3-2 to see the components under mydomain (the default WebLogic domain). Some of the components have a plus sign next to them. You can click the plus sign to see further options available under that domain. In Figure 3-2, mydomain is the name of the domain represented by the administration server, which hosts this Console application. If separate administration servers are running on your system, each with its own active domain, you can switch from managing one domain to the other simply by invoking the URL of the Administration Console on the administration server you want to access.

Domain-Wide General Options Clicking the domain name node (mydomain) displays the Domain Configuration options, shown in Figure 3-4, with the default values for attributes on the General Configuration tab.

79

80


Figure 3-4.

Domain Configuration options

Following are the descriptions of the configuration attributes found on the General Configuration tab of mydomain: •

Console Enabled The Console application is enabled by default. (This is why you can access the Console application in the first place.) Unchecking this option makes Console inaccessible. If you modify this option (check or uncheck it), you must restart the administration server. Throughout the Console, a yellow triangle that appears next to the option indicates that any change to the option requires a server restart to be in effect.

•

Console Context Path This attribute indicates the context path used to access the Console application. The default value for this attribute is console. (This is why you are asked to access Console using URL http://localhost:8001/console, where /console indicates the context path for the Web application). Any change to this attribute will require that you access Console with the modified context path. For example, if you change the context path to myConsole, you will need to access the Console application using http://localhost: 8001/myConsole.

•

Enable Domain Wide Administration Port The administration port is an additional port a user can configure for domain-wide communication with the WebLogic administration server. This option is disabled by default. Enabling

Chapter 3:

WebLogic Console

this option requires that you start administration with Secure Sockets Layer (SSL) as the administration port that always communicates over SSL. •

Domain Wide Administration Port This is the port number for the administration port. You can configure this attribute to your requirement.

Domain-Wide Applications Option In the Domain Configuration options (shown in Figure 3-4), click the Applications tab, as shown in Figure 3-5. This tab shows the following domain-wide options for application deployment: •

Auto Deployed Enabled This option indicates that the auto-deployment of applications through the applications directory is enabled for the domain. The application is deployed by dropping it into the applications subdirectory of the Server Start Directory. This option is available in development mode, but not in production mode.

•

Auto Update Interval This attribute represents the time interval, in milliseconds, during which the application poller polls the applications directory for deployments. For more information on auto-deployment, see Chapter 4.

Domain-Wide Logging Option In the Domain Configuration options (shown back in Figure 3-4), click the Logging tab. The various logging options, shown in Figure 3-6, are as follows: •

File Name This attribute specifies the domain file log. The default domain filename is mydomain.log under server root. You can modify the log filename and specify the full path to the file location.

Figure 3-5.

Domain-wide Applications options

81

82


Figure 3-6.

•

•

Domain-wide logging options

Rotation Type This attribute specifies criteria for moving old log messages to a separate file. After the server renames a file, subsequent messages accumulate in a new file with the name that you specified under File Name. Following are the various options available from the Rotation Type drop-down menu: •

None The default option, it means that messages are accumulated in a single file. You must erase the contents of the file when the size reaches a particular limit. In a production environment, using a huge, single log file is a bad idea.

•

Size When the log file reaches the size that you specify under the FileMinSize attribute of your server’s log entry in your configuration file (config.xml), the server renames the log file FileName.n and writes a fresh log file (using the File Name you specified). For example, if your log file is named mylog, after the size of log file exceeds the specified limit in the configuration file, the server will rename the file myserver.0.

•

Time At each time interval you specify under the TimeSpan attribute of your server’s log entry in the configuration file (config.xml), the server renames the log file to FileName.n. For example, if your log file is named mylog, at the time interval specified in your configuration file, the server will rename your log files as mylog.0, mylog.1, and so forth. Thus, you will have a regular log file for each time span.

File Min Size This is the minimum size in kilobytes that the log file must attain before the file is renamed FileName.n.

Chapter 3:

WebLogic Console

•

Rotation Time This attribute determines the start time for a time-based rotation sequence. After the time specified by this value, the server renames the current log file FileName.n. Thereafter, the server renames the log file at an interval that you specify under the FileTimeSpan attribute of your server’s log element in your configuration file. You can create a recurring start time, such as “every Monday at 09:00,” or a non-recurring start time, such as “9 January, 2002, 09:00.”

•

Number Of Files Limited This attribute limits the number of files that a server creates to store old messages to the maximum number specified in the FileCount attribute of your server’s log element in your configuration file. After the server reaches this limit, it overwrites the oldest file. If you do not enable this option, the server will create new files indefinitely. You must clean out these files regularly.

•

File Count The FileCount attribute specifies the maximum number of log files the server creates when it rotates the log. This attribute is valid only if the isNumberOfFilesLimited attribute of your server’s log element in your configuration file is true and the setRotationType attribute of your server’s log element in your configuration file has legal values set for Size or Time.

Domain-Wide JTA Options In the Domain Configuration options (shown back in Figure 3-4), click the JTA (Java Transactions API) tab. Figure 3-7 shows the various domain-level JTA options available. The options are as follows: •

Timeout Seconds This specifies the timeout value in seconds for a transaction. If the transaction is still in the “active” state after this time, the transaction is automatically rolled back.

•

Abandon Timeout Seconds This specifies the maximum abandon timeout in seconds. The default value for this attribute is 86,400 seconds. You can configure this attribute according to your requirements. During the second phase of the two-phase commit process, the transaction manager will continue to try to complete the transaction until all resource managers indicate that the transaction is completed. Using this attribute, you can set the maximum time that a transaction manager will persist in attempting to complete a transaction during the second phase of the transaction. After the abandon transaction timer expires, no further attempt will be made by the server to resolve the transaction. If the transaction is in a prepared state before being abandoned, the transaction manager will roll back the transaction to release any locks held on behalf of the server.

•

Before Completion Iteration Limit This is the maximum number of cycles the transaction manager will perform before completion of synchronization callback. Nothing prevents a synchronization object from registering another object during Before Completion—even those whose Before Completions have

83

84


Figure 3-7.

Domain-wide JTA options

already been called. For example, an Enterprise JavaBean (EJB) can call another in its ejbStore() method. To accommodate this, the transaction manager calls all synchronization objects, and then repeats the cycle if new objects have been registered. This count sets a limit to the number of cycles that can occur. •

Max Transactions This is the maximum number of simultaneous in-progress transactions allowed on a server. The default value for this attribute is 10,000 transactions.

•

Max Unique Name Statistics This attribute indicates the maximum number of unique transaction names for which statistics will be maintained. A transaction name typically represents a category of business transactions (such as “funds-transfer”).

•

Checkpoint Interval Seconds This indicates the interval at which the transaction manager creates a new transaction log file and checks all old transaction log files to see if they are ready to be deleted. The default is 300 seconds (5 minutes). The minimum is 10 seconds, and the maximum is 1800 seconds.

•

Forget Heuristics This is a Boolean attribute. A check mark in this attribute’s box indicates whether the transaction manager will automatically perform an XAResource forget operation for transaction heuristic completion. If this attribute is not checked, no automatic check is performed by the transaction manager to perform an XAResource forget operation.

Chapter 3:

WebLogic Console

Domain-Wide SNMP Attributes To configure domain-wide SNMP (Simple Network Management Protocol) attributes, select the SNMP tab from the Domain Configuration options (shown back in Figure 3-4). The SNMP tab shows various SNMP configurable attributes at the domain level, as shown in Figure 3-8. Various SNMP options are as follows: •

Enabled This option is off by default. By enabling this option, you ensure that SNMP service is available on the administration server.

•

SNMP Port This is the port that is used for sending SNMP trap notifications to the target SNMP manager. The default port number is 161.

•

MIB Data Refresh Interval This option indicates the minimum amount of time all MIB values are cached before the agent attempts to refresh them. The default refresh interval is 120 seconds.

•

Server Status Check Interval Factor This value defines a multiplier used to calculate the interval at which the server status is checked. If the value of this option is n, the server status check interval is n times the defined MIB Data Refresh Interval.

•

Community Prefix This attribute defines the prefix string that is used to form the SNMP community name. To form a community name, append @ and the server name or domain name to the prefix, as in the following example: SNMP Community Name = CommunityPrefix[@{ServerName | DomainName}]

•

Debug Level This option allows you to specify the debug level. Valid debug values are 0 (no debug), 1 (fatal), 2 (critical), and 3 (noncritical).

•

Targeted Trap Destinations This option allows you to select the Trap destination from the available destinations.

Domain-Wide Security Options The security options are described in Chapter 6 in detail.

Domain-Wide Monitoring Options The monitoring options are described in Chapter 9 in detail.

Right-Clicking Options Right-clicking the mydomain node on the navigation tree along the left side provides the following options: •

Open Selecting this option displays the Domain Configuration options (as shown back in Figure 3-4).

•

Open In New Window Selecting this option opens the Domain Configuration options in a new window.

85

86


Figure 3-8.

Domain-wide SNMP attributes

•

View Domain Log Selecting this option displays a domain-wide log in a tabular form, as shown in Figure 3-9. You can click the Customize This View link to customize the look and feel of the domain log table display. You can choose from the available column names displayed in the domain log, or you can choose the logs for a specific server or servers to be displayed. Additionally, you can choose to display only logs of certain severity and subsystems.

•

Create Or Edit Other Domain This option allows you to configure another domain. Click the Configure A New Domain link shown here to create another domain.

Chapter 3:

Figure 3-9.

WebLogic Console

Domain logs

•

Start This Domain Selecting this option attempts to start all the servers in the running domain.

•

Kill This Domain current domain.

•

Define Policy You can create a security policy by selecting this option. Security policies are discussed in detail in Chapter 6.

•

Define Role You can create a security role by selecting this option. Roles are discussed in detail in Chapter 6.

Selecting this option attempts to kill all the servers in the

Configuring a Server The server is a component in a domain. Here’s how to configure a server and the various options of a server: 1. Start WebLogic Console.

87

88


2. Browse the navigation tree in the Console and click to open the Servers folder and open the dialog box shown in Figure 3-10. The dialog box will display information about configured servers and their status. It will also display the following links: •

Configure A New Server

•

Customize This View feel of the table.

Click this option to create a new server.

This option allows you to customize the look and

Configuring a New Server Click the Configure A New Server option shown in Figure 3-10. The General Configuration tab will appear, as shown in Figure 3-11. In this tab, follow these instructions to configure your server: 1. In the Name field, type in a name for the new server. 2. In the Machine field, assign the new server to any configured machine available in the drop-down menu. Assigning a server to a particular machine helps it to be managed by the node manager. (For more information, see Chapter 10.) 3. In the Cluster field, assign the new server to a preconfigured cluster. A cluster is the logical group of more than one server that acts like a single powerful server. (Cluster configuration is discussed in the section “The Cluster Configuration Tab,” later in this chapter.)

Figure 3-10.

Configured servers in different running states

Chapter 3:

Figure 3-11.

WebLogic Console

Options for configuring a server

4. The Listen Port Enabled option is checked by default. a check mark in the box indicates that the plan port (non-SSL) is enabled for this server. If you disable this option, you will need to enable the SSL port manually. 5. In the Listen Address field, specify the IP address as the listen address for the server. By default, the listen address is localhost. 6. In the Listen Port field, specify the listen port value for this server. The default value for the listen port is 7001, but you can modify it. 7. By default, the WebLogic Plug-In Enabled option is disabled. Check this option to enable the WebLogic plug-in. (For details about plug-ins, see Chapter 7.) 8. In the Startup Mode field, type in the startup mode for the server. The default value for startup mode is RUNNING, which indicates that the server will start in running mode. You can also configure the server mode to STANDBY, which means that the server startup will complete successfully but the server will not be available to serve any of the requests. The server port will not be enabled in standby mode. For the server to serve the external request, you need to change the server from standby mode to running mode.

89

90


9. The value in the External DNSName field sets the DNS name for the current server, which will be sent with HTTP session cookies and also with the dynamic server lists to HTTP proxies. This is required for configurations in which a firewall is performing network address translation. 10. Click the Create button to finish the server configuration process.

Configuration Options Various server configuration options are listed on the Configuration tab. This section will cover the available server options. The Cluster Configuration Tab You can configure various cluster options in the tab shown in Figure 3-12 if this server is part of a cluster. These attributes are explained in detail in Chapter 8. The Memory Configuration Tab You can configure various memory attributes on this tab, shown in Figure 3-13. Following is the description of the options available: •

Low Memory GCThreshold This attribute indicates the threshold level at which the server will try to garbage collect the unreferenced objects once the granularity reporting level has been met. The default value for this attribute is 5.

•

Low Memory Granularity Level This attribute specifies the granularity level at which the low memory condition is reported. Its default value is 5; however, you can configure a value between 1 and 100.

•

Low Memory Sample Size This attribute specifies the total sample size used for LowMemoryTimeInterval. Please note that only one sample is taken at each

Figure 3-12.

Configuring the cluster options

Chapter 3:

Figure 3-13.

WebLogic Console

Memory configuration for a server

LowMemoryTimeInterval. You can configure a value between 1 and 2,147,483,647 for this attribute. The default value is 10. •

Low Memory Time Interval This attribute specifies a time interval after which one sample will be taken up to the low memory sample size and then repeated.

The Deployment Configuration Tab You can configure server-level deployment attributes for the server in this tab, shown in Figure 3-14. In the Staging Mode field, you specify the staging option for the server. Staging is the process of making application files available to the server. If this field is set to Stage (the default value), the administration server will make all the application files available to the managed server. In this process, the administration server copies files from itself to a place on the managed server specified in the Staging Directory Name field. If the Staging Mode field is set to Nostage or Externalstage, the Administrator is responsible for making the application files available to the managed server. These attributes are further explained in Chapter 4. The Tuning Configuration Tab Following is a brief explanation of some of the options available on this tab, shown in Figure 3-15 (the other tuning options for a server are explained in detail in Chapter 9): •

Managed Server Independence Enabled If this option is checked, a managed server will start, even if there is no administration server available to contact. The managed server uses previously cached information to boot itself. (The architecture of the administration server and managed server are discussed in detail in Chapter 11.) If this option is not checked, a managed server will not start in the absence of an administration server.

91

92


Figure 3-14.

Deployment options for a server

Figure 3-15.

Server tuning options

Chapter 3:

•

WebLogic Console

MSI (Managed Server Independence) File Replication Enabled This option indicates whether the replication of configuration files option is enabled for a managed server. With file replication enabled, the administration server copies its configuration file and SerializedSystemIni.dat into the managed server’s root directory every 5 minutes. This option does not replicate a boot identity file. You must enable MSI to replicate configuration files. You should not enable file replication for a server that shares an installation or root directory with another server. Unpredictable errors can occur for both servers.

The Compilers Configuration Tab This tab provides the option to specify a Java compiler of the user’s choice. By default, WebLogic servers use Javac as a Java compiler. The Health Monitoring Configuration Tab Options on this tab allow you to configure health-monitoring attributes for your server. Health monitoring–related options are explained in detail in Chapter 10. The Remote Start Configuration Tab The options on this tab are relevant if you are configuring Node Manager for starting the servers on a machine. These options are explained in detail in Chapter 10.

Server Connections Options Various server connections options are listed on the Connections tab. This section will cover the available server options. The SSL Connections Tab In this tab, shown in Figure 13-16, you can configure various SSL attributes. Some of the options are self-explanatory, but several are explained here: •

Server Private Key Passphrase You can modify the password used to retrieve the server’s private key from the key store. The new password is assigned to the private key when it is generated.

•

Client Certificate Enforced This option indicates whether a client must present a trusted certificate for authentication. It is disabled by default.

•

Client Certificate Requested But Not Enforced This option enables two-way SSL. A description of two-way SSL is beyond the scope of this book. For further reading on SSL, refer to a standard book on SSL.

•

Export Key Lifespan This field specifies the number of times WebLogic Server can use an exportable key between a domestic server and an exportable client before generating a new key. The more secure you want WebLogic Server to be, the fewer times the key should be used before a new key is generated. The default value for this attribute is 500. You can configure this value between 1 and 2,147,483,647.

93

94


Figure 3-16.

SSL Connections tab options

Server Monitoring Options The General tab provides options for monitoring various server internals, as shown in Figure 3-17. Click the respective links to see the current status: •

Monitor All Active Queues

•

Monitor All Connections

•

Monitor All Active Sockets

Server Control Options Options on the Control tab describe server control options, such as start, stop, and so on. These server options are explained in detail in Chapter 10. You can use these options along with the Node Manager to remotely start a managed server. However, you don’t need Node Manager to stop a server. Server Logging Options Use this tab to customize logging options for your server. You can specify the log filename and filter the logs you are interested in having in your log file.

Chapter 3:

Figure 3-17.

WebLogic Console

Monitoring options for a server

Server Deployments Options Use options provided on this tab to target available EJBs, Web applications, JCA connectors, and startup/shutdown classes, as shown in Figure 3-18. The tab displays the available deployed resources that you can select for the server. This is a convenient way to deploy previously deployed resources to a newly configured server.

Figure 3-18.

Web Applications deployment options

95

96


Server Services Options Use this tab to choose available services for this server. For example, Figure 3-19 would show the list of available services if the server runs on a JDBC connection pool. Server Notes Options Using the Notes tab is optional; it enables you to describe your server configuration and add notes for your own records.

Configuring a Cluster To configure a cluster, follow these instructions: 1. Start WebLogic Server. 2. In the left pane of the WebLogic Console screen, click the Clusters node. 3. In the right pane, click Configure A Cluster. 4. Fill in the various configuration values in the Configuration tab shown in Figure 3-20. (Cluster options are explained in detail in Chapter 8.)

Configuring a Machine The term machine refers to the physical machine that hosts the WebLogic Server instances. WebLogic Node Manager is always associated with a machine to manage server instances running on that machine. (A detailed description of machines and Node Manager is provided in Chapter 10.)

Figure 3-19.

Available services for the server

Chapter 3:

Figure 3-20.

WebLogic Console

Configuring a cluster

Follow these instructions to configure a machine. 1. Start WebLogic Console. 2. In the navigation pane, and click the Machines node. 3. In the right pane, click the link Configure A New Machine. 4. Address the various options, as described in Chapter 10, and then click Apply.

Configuring a Network Channel A network channel allows the user to configure more than one listen port for a WebLogic server or cluster. All servers and clusters that use a network channel inherit the basic port configuration of the channel itself. Follow these instructions to create a network channel: 1. Start WebLogic Console. 2. Click the Network Channels node in the navigation pane. 3. Click Configure A New Network Channel in the right pane. 4. Specify the following options in the Configuration tab, shown in Figure 3-21: •

Name

•

Description Enter a description of the network channel.

•

Listen Port Enabled Check this box to specify that you want to enable a plain listen port for this network channel.

•

Listen Port

Enter the name of the network channel.

Enter the listen port number.

97

98


Figure 3-21.

Configuring a network channel

•

SSL Listen Port Enabled Check this box to specify that you want to enable an SSL listen port.

•

SSL Listen Port

•

Cluster Address

•

T3 Enabled Check this option to indicate that you want to enable T3 traffic on this channel.

•

T3S Enabled Check this box to indicate that you want to enable T3 SSL traffic on this channel.

•

HTTP Enabled Check this box to indicate that you want to enable HTTP traffic for this network channel.

•

HTTPS Enabled Check this box to indicate that you want to enable HTTPS.

•

Tunneling Enabled Check this box to indicate that tunneling is enabled. (For details on tunneling, see Chapter 7.)

Enter the SSL listen port number. Enter this channel’s cluster address.

Chapter 3:

•

WebLogic Console

COM Enabled Check this box to indicate that COM traffic is enabled.

5. Click Create.

Configuring Deployments WebLogic Console provides many options for use in deploying applications, EJBs, Web applications, Web services components, connectors, and start and shutdown classes on servers and clusters. Following is the basic procedure for deploying an application to a server or cluster. If you know the type of application you intend to deploy, you can choose the specific node in the navigation pane. Follow these instructions to deploy an archived application (EAR) file: 1. Start WebLogic Console. 2. In the navigation pane, click Applications under the Deployment node. 3. Click the Configure A New Application Link in the right pane. 4. Select the application file/directory in the next window by browsing to the location of the file and clicking the Select link on the right side. 5. A wizard will take you to step 3, where you can choose from available servers and clusters to which you would like the application to be deployed, as shown in Figure 3-22. Choose servers from the Available Servers tab and move them over to the Target Servers list. 6. Enter the name of the application in step 4. 7. Click Configure And Deploy. This will deploy all the application components to the specified targets. You can also configure and deploy any kind of J2EE component on any of the configured targets and servers. For details, see Chapter 4.

SERVICES CONFIGURATION WebLogic Server supports services such as the JDBC Connection Pool. This section describes the configuration of various services required for your application in WebLogic Server.

Configuring JDBC JDBC configuration involves configuring JDBC Connection Pools, MultiPools, Data Sources, Tx Data Sources, and JDBC Data Source Factories. The following sections discuss how to configure these services.

99

100


Figure 3-22.

Configuring an application

Configuring a JDBC Connection Pool Refer to Figure 3-23 and follow these instructions to configure a Connection Pool: 1. Start WebLogic Console. 2. Under the JDBC node in the navigation pane of the Console, click the JDBC Connection Pools node. 3. Click the Configure A New JDBC Connection Pool link in the right pane. 4. Enter the appropriate information for the database Name, URL, Driver Classname, Password to access the database, and other database parameter fields. 5. Click Apply.

Chapter 3:

Figure 3-23.

WebLogic Console

Configuring a JDBC Connection Pool

Configuring a JDBC MultiPool A MultiPool is a pool of connection pools configured for load balancing or high availability. MultiPools are supported for use in nonclustered servers and for local (nondistributed) transactions. Before creating a MultiPool, you must first create connection pools, which you will assign to the MultiPool. Figure 3-24 shows an example configuration of a MultiPool. Follow these instructions to create a JDBC MultiPool: 1. Start WebLogic Console. 2. In the navigation pane, under the JDBC node, click the MultiPools node. 3. Click the Configure A JDBC MultiPool link in the right pane. 4. Set the configuration options: •

Name

•

Algorithm Type An algorithm type allows you to choose from predefined methods of selecting a pool from available JDBC pools. WebLogic Server allows you to set Algorithm values. The default setting is High-Availability. You can also choose Load Balancing, depending on your configuration requirement. If you are configured at High-Availability, the connection

Enter the MultiPool name.

101

102


Figure 3-24.

Configuring a MultiPool

pools will be set up as an ordered list, which means that every time an application asks the MultiPool for a connection, it tries to get a connection from the first pool in its list. If it is unable to get a valid connection, it moves to the next pool. This process is repeated until a valid connection is obtained or until the end of the list is reached. If the end of the list is reached and no connection is made, the server will throw an exception. Note that the MultiPool will move to the next pool in the list only when there is a real problem with the pool—for example, if the database is down or the pool is disabled. When all connections are busy, the MultiPool will behave as a single pool and an exception is thrown. If the algorithm is set to Load Balancing, the MultiPool will distribute the connection requests evenly to its member pools. The Load Balancing algorithm performs the same failover behavior as the High-Availability algorithm. •

ACLName (Access Control List name) An ACL defines the users/ subsystems that have access to this particular resource. ACL has been deprecated in WLS 7.0 and replaced with Role. For details on ACL and Role, see Chapter 6. Specify the ACL that controls access to this resource in this field.

5. Click Create. Add this resource to the list of targets available in your domain by clicking the Targets tab, as shown in Figure 3-25.

Configuring a Data Source A JDBC data source is an object bound to the Java Naming and Directory Interface (JNDI) tree that points to a JDBC connection pool or MultiPool. Applications can use a JDBC data source to get a database connection from a connection pool or MultiPool.

Chapter 3:

Figure 3-25.

WebLogic Console

Adding a MultiPool to available targets

To create a data source, follow these instructions: 1. Start WebLogic Console. 2. Under the JDBC node, click Data Sources. 3. Click the Configure A New JDBC Data Source link in the right pane. 4. Fill in the following options in the window shown in Figure 3-26, and then click Create. •

Name

•

JNDI Name

Enter the name of the data source.

•

Pool Name Enter the name of the connection pool with which this data source is associated.

•

Row Prefetch Enabled Indicate whether you want to enable prefetching by checking this box, which controls row prefetching between a client and WebLogic Server for each ResultSet. When an external client accesses a database using JDBC through WebLogic Server, row prefetching improves performance by fetching multiple rows from the server to the client in one server access. WebLogic Server will ignore this setting and not use row prefetching when the client and WebLogic Server are in the same JVM.

•

Row Prefetch Size Indicate the number of result set rows to prefetch for a client in this field. The optimal value depends on the particulars of the query. In general, increasing this number will increase performance, until a particular value is reached. At that point, further increases will not result in any significant performance increase. Rarely will increased performance result from exceeding 100 rows. The default value should be reasonable for most situations.

Enter the JNDI name you want for this data source.

103

104


Figure 3-26.

•

Configuring a data source

Stream Chunk Size Indicate a data chunk size for streaming datatypes here. Streaming datatypes (for example, those resulting from a call to getBinaryStream()) will be pulled in the StreamChunkSize attribute-sized chunks from WebLogic Server to the client as needed.

Configuring a Tx Data Source A Tx data source supports distributed transactions. It is an object bound to the JNDI tree that points to a JDBC connection pool and not to a MultiPool. Applications can use a Tx data source to get a database connection from a connection pool. To configure a Tx data source, refer to Figure 3-27 as you follow these instructions: 1. Start the WebLogic Console. 2. Under the JDBC node in the navigation pane, click the Tx Data Sources node. 3. Click the Configure A New JDBC Tx Source link in the right pane. 4. Fill in the following options. (Note that most of these options are the same as those described in the preceding section for a data source.) •

Name

•

JNDI Name

•

Pool Name

•

Emulate Two Phase Commit For Non XA-Driver If this option is enabled, non-XA JDBC drivers can emulate participation in distributed transactions using JTA. Choose this option if the JDBC connection is the only participant in the transaction and there is no XA-compliant JDBC

Chapter 3:

Figure 3-27.

WebLogic Console

Configuring a Tx data source

driver available. With more than one resource participating in a transaction, where one of them (the JDBC driver) is emulating an XA resource, you may see heuristic failures. If this Tx data source is associated with an XA connection pool, or if only one resource is participating in the distributed transaction, this setting is ignored. •

Row Prefetch Enabled

•

Row Prefetch Size

•

Stream Chunk Size

Configuring a JDBC Data Source Factory A JDBC data source factory is an instance of a JDBC data source bound to the WebLogic Server JNDI tree as a resource factory. Using resource factories enables the EJB to map a resource factory reference in the EJB deployment descriptor to an available resource factory in a running WebLogic Server. The EJB can then use a JDBC data source factory to get a database connection from a connection pool. To configure a JDBC data source factory, follow these instructions: 1. Start the WebLogic Console. 2. Under the JDBC node in navigation pane, click the JDBC Data Source Factories node. 3. Click the Configure A New JDBC Data Source Factory link in the right pane.

105

106


4. Fill in the following options in the dialog box (shown in Figure 3-28): Name of this configuration

•

Name

•

User Name

•

URL

•

Driver Class Name

•

Factory Name

•

Properties

Database username

The connection URL for the database Database driver class

Name of the database connection factory

Default connection properties

Configuring Java Message Service Options Java Message Service (JMS) is Sun Microsystems’ Java specification for an asynchronous messaging service. A detailed description of JMS is beyond the scope of this book. Please look for JMS documentation at http://www.sun.com or consult a good book on JMS.

Configuring a JMS Connection Factory A JMS connection factory (not to be confused with a JDBC connection factory) enables JMS clients to create JMS connections. A connection factory supports concurrent use, enabling multiple threads to access the connection factory simultaneously. After defining a JMS server, you can configure one or more connection factories to create connections with predefined attributes. Consult documentation on JMS for a detailed understanding of these topics.

Figure 3-28.

Configuring a JDBC data source factory

Chapter 3:

WebLogic Console

Follow these instructions to configure a JMS connection factory through the WebLogic Console: 1. Start the WebLogic Console. 2. Under the JMS node in the navigation pane, click the Connection Factories node. 3. Click the Configure A New JMS Connection Factory link in the right pane. 4. Fill in the following options in the window that appears, as shown in Figure 3-29: The name of the connection factory.

•

Name

•

JNDIName The name assigned to the connection factory, which will be used to look up the connection factory within the JNDI namespace.

•

Client Id This attribute specifies the client ID for a durable subscriber that uses this connection factory.

Figure 3-29.

Configuring a JMS connection factory

107

108


•

Default Priority The default priority is used for messages for which a priority is not explicitly defined. All messages with a default priority of –1 that are produced on a connection created with this factory will receive this value.

•

Default Time To Live This attribute specifies the default maximum length of time, in milliseconds, that a message will exist. It is generally used for messages for which a priority was not explicitly defined. A value of 0 indicates that the message has an infinite amount of time to live. All messages with a DefaultTimeToLive value of –1 that are produced on a connection created with this factory will receive this value.

•

Default Time To Deliver This attribute specifies the delay, in milliseconds, between when a message is produced and when it is made visible at its destination. All messages produced by a producer created with this factory that have a DefaultTimeToDeliver of –1 will use this value.

•

Default Delivery Mode The default delivery mode is used for messages for which a delivery mode is not explicitly defined. All messages with a DefaultDeliveryMode of null that are produced on a connection created with this factory will receive this value.

•

Default Redelivery Delay This attribute specifies the delay, in milliseconds, before rolled-back or recovered messages are redelivered. All messages consumed by a consumer created with this factory that have a DefaultRedeliveryDelay of –1 will use this value.

•

Message Maximum This attribute defines the maximum number of messages that may exist for an asynchronous session and that have not yet been passed to the message listener. A value of –1 indicates that there is no limit on the number of messages. In this case, however, the limit is set to the amount of remaining virtual memory.

•

Overrun Policy The overrun policy applies to multicast messages. When the number of outstanding messages reaches the MessagesMaximum attribute value, messages are discarded based on the specified policy. If set to KeepNew, the most recent messages are given priority over the oldest messages, and the oldest messages are discarded as needed. If set to KeepOld, the oldest messages are given priority over the most recent messages, and the most recent messages are discarded as needed. Message age is defined by the order of receipt, not by the JMS timestamp value.

•

Allow Close In On Message This attribute indicates whether or not a connection factory creates message consumers that allow a close() method to be issued within its onMessage() method call. If selected (true), a close() method call from within an onMessage() method call will succeed instead of blocking forever. If the acknowledge mode of the

Chapter 3:

WebLogic Console

session is set to AUTO_ACKNOWLEDGE, the current message will still be acknowledged automatically when the onMessage() call completes. If not selected (false), it will cause the stop() and close() methods to hang if called from onMessage(). •

Acknowledge Policy This attribute works around a change in the JMS specification. At one time, the specification allowed users to acknowledge only messages before and including the message being acknowledged. It was changed to acknowledge any message received (even those received after the message being acknowledged). An acknowledge policy of ACKNOWLEDGE_PREVIOUS retains the old behavior (all messages up to and including the message being acknowledged). An acknowledge policy of ACKNOWLEDGE_ALL yields the new behavior, in which all messages received by the given session are acknowledged regardless of which message is being used.

•

Load Balancing Enabled This option indicates whether or not a producer is created using a connection factory that allows load balancing. If true, the associated message producers will be load balanced on every send() or publish(). If false, the associated message producers will be load balanced on the first send() or publish().

•

Server Affinity Enabled This indicates whether or not JMS front ends connected to and running in the same JVM as a WebLogic Server will first attempt to load balance consumers or producers across those physical destinations served by any JMS servers that are also running in the same JVM.

5. Click Create when you’re done.

Configuring a JMS Template A JMS template provides an efficient means of defining multiple destinations, such as queues and topics with similar attribute settings. With a JMS template, it is not necessary to re-enter every attribute setting each time you define a new destination. You can simply use the JMS template and override any setting that requires a new value. In addition, you can dynamically modify shared attribute settings simply by modifying the template. Follow these instructions and see Figure 3-30 to configure a JMS template: 1. Start the WebLogic Console. 2. Under the JMS node in the navigation pane, click the Templates node. 3. Click the Configure A New JMS Template link in the right pane. 4. Name the template and choose the destination keys from the available tab. 5. Click Create.

109

110


Figure 3-30.

Configuring a JMS template

Configuring Destination Keys Destination keys define the sort order for a specific JMS destination (queue or topic). Use the following instructions and refer to Figure 3-31 to create a destination key: 1. Start the WebLogic Console. 2. Under the JMS node in the navigation pane, click the Destination Keys node. 3. Click Create New JMS Destination Key in the right pane.

Figure 3-31.

Configuring a destination key

Chapter 3:

WebLogic Console

4. Fill in the appropriate values in the dialog box. 5. Click Create.

Configuring Distributed Destinations You can configure multiple physical WebLogic JMS destinations (queues and topics) as members of a single distributed destination set that can be served by multiple WebLogic Server instances within a cluster. Once configured, your producers and consumers are able to send and receive to the distributed destination. WebLogic JMS then distributes the messaging load across all available destination members within the distributed destination. When a destination member becomes unavailable, traffic is redirected toward other available destination members in the set. To configure a distributed destination, follow these instructions and refer to Figure 3-32: 1. Start the WebLogic Console. 2. Under the JMS node in the navigation pane, click the Distributed Destinations node. 3. At this point, you can click the Create A New JMSDistributed Topic link if you want to configure a distributed topic or the Configure A New Distributed Queue link if you want to configure a distributed queue. In Figure 3-32, Create A New JMSDistributed Topic was chosen. 4. Enter the name of the destination, the JNDI name, and the load-balancing algorithm. 5. Click Create.

Figure 3-32.

Configure a distributed topic

111

112


Configure a JMS Server A JMS server manages connections and message requests on behalf of JMS clients. Follow these instructions and refer to Figure 3-33 to configure a new JMS server: 1. Start the WebLogic Console. 2. Under the JMS node in the navigation pane, click the Servers node. 3. Click the Configure New JMS Server link in the right pane. 4. Select the appropriate options. 5. Click Apply. 6. Choose the available servers from the Targets tab to host this JMS server, as shown in Figure 3-34.

Configuring a JMS Bridge A messaging bridge communicates with configured source and target bridge destinations. For each mapping of a source destination to a target destination, whether it is another WebLogic JMS implementation, a third-party JMS provider, or a non-JMS (general) messaging provider, you must configure a messaging bridge instance. Each instance defines the source and target destination for the mapping, a message-filtering selector, a quality of service (QOS), transaction semantics, and reconnection parameters. Follow these instructions and refer to Figure 3-35 to configure a JMS bridge: 1. Start the WebLogic Console 2. Under the Messaging Bridge node in the navigation pane, click the Bridges node. 3. Click Configure A New Messaging Bridge link in the right pane.

Figure 3-33.

Configure a JMS server

Chapter 3:

Figure 3-34.

Choosing the targets from available servers

Figure 3-35.

Configuring a destination bridge

WebLogic Console

113

114


4. Configure the following options: Name of this configuration.

•

Name

•

Source Destination pull-down menu.

Choose the source destination from the

•

Target Destination pull-down menu.

Choose the target destination from the

•

Selector You can configure a message selector here. The message selector enables you to filter the messages that are sent across the messaging bridge. Only messages that match the selection criteria are sent across the messaging bridge. For queues, messages that do not match the selection criteria are left behind and accumulate in the queue. For topics, messages that do not match the connection criteria are dropped.

•

Quality Of Service This option allows you to choose the quality of service value out of these predefined values: 1 (exactly once), 2 (at most once), and 3 (duplicates okay).

•

QOS Degradation Allowed This option indicates whether the bridge allows the degradation of its QOS when the configured QOS is not available.

•

Maximum Idle Time This option defines the maximum amount of idle time for the messaging bridge.

•

Asynchronous Mode Enabled This option indicates whether the messaging bridge will work in asynchronous messaging mode.

•

Durability Enabled This option indicates whether the messaging bridge allows durable messages.

•

Started This option indicates the started and stopped state of the messaging bridge. If the value is true, the bridge is in working condition. If the value is false, the bridge is temporarily stopped.

5. Select the target for the destination bridge from the available targets in the Targets tab. 6. Click Create.

Configuring JMS Bridge Destinations Each WebLogic messaging bridge consists of two destinations that are being bridged: a source destination from which messages are received and a target destination where messages are sent. For each source/target destination to be mapped, whether it’s a WebLogic JMS implementation or a third-party JMS provider, you must configure a JMS bridge destination instance. To configure a JMS bridge destination, refer to Figure 3-36 and follow these instructions: 1. Start the WebLogic Console.

Chapter 3:

WebLogic Console

2. Under the Messaging Bridge node in the navigation pane, click the JMS Bridge Destinations node. 3. Click the Configure A New JMS Bridge Destination link in the right pane. 4. Configure the following options in the dialog box: Name of the JMS Bridge Destination Configuration.

•

Name

•

Adapter JNDI Name The JNDI name of the adapter used to communicate with the specified destination. This name is specified in the adapter’s deployment descriptor file and is used by the WebLogic Server Connector container to bind the adapter in WebLogic Server JNDI.

•

Adapter Classpath Defines the CLASSPATH of the bridge destination, which is mainly used to connect to a different release of WebLogic JMS. When connecting to a destination that is running on WebLogic Server 6.0 or earlier, the bridge destination must supply a CLASSPATH that indicates the locations of the classes for the earlier WebLogic Server implementation.

•

Connection URL Specify the connection URL for a JMS bridge destination here. This attribute is only applicable to JMS destinations.

Figure 3-36.

Configuring JMS bridge destinations

115

116


•

Initial Context Factory Specify the initial context factory name for a JMS bridge destination. This attribute is only applicable to JMS destinations.

•

Connection Factory JNDI Name Specify the connection factory’s JNDI name for a JMS bridge destination. This attribute is only applicable to JMS destinations.

•

Destination JNDI Name Specify the destination JNDI name here for a JMS destination bridge.

•

Destination Type JMS destination.

•

User Name Specify an optional username that the adapter will use to access the bridge destination.

•

User Password

Specify the destination type (Queue or Topic) for the

Specify the password for the username.

5. Click Create.

Configuring XML Registry XML Registry is a data management system that is responsible for providing and managing various services for the XML components, such as schemas (DTD and XSD), style sheets (XSL), and instance documents (WSDL, WSFL, and XML). XML Registry can be used to obtain an XML component automatically, to search or browse for an XML component, to deposit an XML component with or without related data, and to register an XML component without deposit. XML Registry options are described in detail in Chapter 5. To configure XML Registry, follow these steps and refer to Figure 3-37: 1. Start the WebLogic Console.

Figure 3-37.

Configuring XML Registry

Chapter 3:

WebLogic Console

2. Under the XML node under Services in the navigation pane, click the XML Registry node. 3. Click Configure A New XML Registry in the right pane. 4. You will see a dialog box with configurable options. Configure the XML Registry attributes, according to the information provided in Chapter 5. 5. Click Create.

Configuring WLEC Connection Pool WebLogic Enterprise Connectivity (WLEC) uses connection pools to enable WebLogic Server clients to connect to BEA Tuxedo domains. A WLEC connection pool is a set of IIOP (Internet Inter Object Protocol) connections to a BEA Tuxedo domain. WebLogic Server creates the WLEC connection pools at startup and assigns connections to WebLogic Server clients as needed. Use the following instructions and refer to Figure 3-38 to configure a WLEC connection pool: 1. Start the WebLogic Console. 2. Under the Services node in the navigation pane, click the WLEC node. 3. Click Configure A New WLEC Connection Pool in the right pane.

Figure 3-38.

Configuring a WLEC connection pool

117

118


4. Configure the following options. Use the Targets tab to select the available servers onto which you wish to deploy this resource: Enter the name of the WLEC connection pool.

•

Name

•

Primary Addresses Enter the list of addresses for IIOP listener/handlers used to establish a connection between the WLEC connection pool and the WLE domain. The format of each address is //hostname:port. The addresses must match the ISL addresses defined in the UBBCONFIG file. Multiple addresses are separated by semicolons.

•

Domain

•

Minimum Pool Size Enter the number of IIOP connections to be added to the WLEC connection pool when WebLogic Server starts. The default value for this attribute is 1.

•

Maximum Pool Size Enter the maximum number of IIOP connections that can be made from the WLEC connection pool. The default value for this attribute is 1.

Enter the name of the domain to which this pool is connected.

5. Click Create.

Configuring the WebLogic Tuxedo Connector Server To configure a WTC server, follow these instructions and refer to Figure 3-39: 1. Start the WebLogic Console. 2. Under the Services node in the navigation pane, click the WebLogic Tuxedo Connector node. 3. Click Configure A New WTC Server in the right pane. 4. Provide the following options: •

Name

•

Deployment Order The priority the server uses when it deploys an item. The priority is relative to other deployable items of the same type. For example, the server prioritizes and deploys all startup classes before it prioritizes and deploys EJBs. Items with the lowest deployment order value are deployed first. (Please note that there is no guarantee on the order of deployments with equal deployment order values, nor is there a guarantee of ordering across clusters.)

The name of the WTC server.

5. Click Create.

Chapter 3:

Figure 3-39.

WebLogic Console

Configuring the WTC server

Configuring a Jolt Connection Pool Jolt connection pools allow you to connect WebLogic server clients to BEA Tuxedo domains. The server creates the jolt connection pools at startup and assigns connections to WebLogic server clients as needed. To configure a jolt connection pool, follow these instructions and refer to Figure 3-40: 1. Start the WebLogic Console. 2. Under the Services node in the navigation pane, click the Jolt node.

Figure 3-40.

Configuring a Jolt connection pool

119

120


3. Click Configure A New Jolt Connection Pool in the right pane. 4. Provide the following options in the dialog box: Name of the connection pool.

•

Name

•

Minimum Pool Size The minimum number of connections to be added to the jolt connection pool when WebLogic Server starts.

•

Maximum Pool Size The maximum number of connections that can be made from the jolt connection pool.

•

Recv Timeout Defines the amount of time the client waits to receive a response before timing out.

•

Security Context Enabled connection pool.

Defines the state of the security context for this

5. Click Create.

Configuring Virtual Hosts A WebLogic server can have more than one Web server running on it. A virtual host is described as a Web server on a WebLogic server. You can target a Web application to any of the Web servers on WebLogic Server. To configure a virtual host, follow these instructions and refer to Figure 3-41: 1. Start the WebLogic Console. 2. Under the Services node in the navigation pane, click the Virtual Hosts node. 3. Click Configure A New Virtual Host in the right pane.

Figure 3-41.

Configuring a virtual host

Chapter 3:

WebLogic Console

4. Specify the name of the virtual host you are about to create, identify the name of hosts you want this Web server to serve in the Virtual Host Names field, and select a default Web application name out of already deployed applications. 5. Click Create.

Configuring Security Configuration of security and security-related attributes is discussed in detail in Chapter 6. Read that chapter to learn about the various administrative functions related to security configurations.

CHECKLIST This chapter described the WebLogic Console in detail. Console is a Web application that lives in the administration server and is a complete UI tool for administration. After reading through this chapter, you should be able to perform most of the administration tasks that use WebLogic Console. You can configure, administer, and monitor a WebLogic domain. You should understand how to accomplish these tasks: ■

Configuration, administration, and monitoring of WebLogic Server 7 using Console

■

WebLogic Console general settings

■

WebLogic Console domain-wide options

■

Configuration and monitoring of servers and clusters

■

Configuration of machine and network channel

■

Configuration of application deployments

■

Configuration of JMS options

■

Configuration of JDBC options

■

Configuration of WLEC options

■

Configuration of virtual hosts

121

CHAPTER 4 Application Deployment


123

124


pplication deployment is the process of making a Java 2 Enterprise Edition (J2EE) application available to the WebLogic application server so that it can make the application accessible to the client. It is also the final step in a J2EE application life cycle. The WebLogic application server provides many ways to deploy an application, and every deployment method is suited to a different scenario. An application developer can easily copy the application and drop it into the applications directory, or the developer can use the Console to configure and install an application. System administrators can use the weblogic.Deployer command-line deployment utility, which can be easily adopted into a scripting environment, or configure the application in config.xml. This chapter covers different methods of deployment in detail. After reading the chapter, you should feel fairly comfortable with deploying and configuring an application on a single server, on multiple servers, and on a cluster. Keep in mind that an application is always targeted (deployed) to a server. In this chapter, the target will be interchangeably used as server or cluster (of servers). The word application will be used for all kinds of J2EE deployable units, such as EAR (enterprise application archive) files, WAR (Web application archive) files, JAR (Java archive) Enterprise JavaBeans (EJBs), or exploded applications. To refresh your memory about the different kinds of J2EE deployable units, please see Chapter 5.

A

AUTO-DEPLOYMENT Auto-deployment is the easiest way to deploy an application, which makes it a favorite for developers. The auto-deployment feature is available only when running WebLogic Server in development mode. In fact, WebLogic Server by default starts with autodeployment enabled. To auto-deploy an application, the user quickly copies the application and drops it into the applications directory, which lives in the server root directory, which is the directory in which the server is started. The applications directory is created as part of the WebLogic installation. To deploy an application using the auto-deployment method, follow these steps: 1. Copy the application you want to deploy. 2. Paste the application into the applications subdirectory that’s under the directory that hosts the server configuration file (the server root directory). The moment an application is dropped into an application directory, a thread picks up the application and deploys it to the administration server. Undeploying an application with auto-deployment is also quite simple. Delete the application from the applications subdirectory and it becomes undeployed from the administration server. Users can quickly deploy, undeploy, and redeploy an application with much ease using the auto-deployment process.

Chapter 4:

Application Deployment

Auto-deployment may be the easiest way to deploy an application, but it isn’t a solution to every deployment need. It doesn’t cover deployments to multiple servers or clusters, partial deployments, and the like. In addition, auto-deployment is inappropriate for production environments because the administrator is unable to adequately control changes to domain configuration.

DEPLOYMENT TOOLS WebLogic 7 ships with a comprehensive deployment command-line utility called weblogic.Deployer, which uses new deployment APIs built into WebLogic 7. WebLogic Server 7 still supports weblogic.deploy, a command-line tool for application deployment that was included in prior versions. weblogic.deploy is deprecated in version 7, and we will not cover this in our discussions in the following sections. weblogic.Deployer is a comprehensive tool used to deploy, undeploy, and redeploy an application or a component to a single server, multiple servers, or a cluster. This tool has a -help switch you can use to display all the deployment options available. Type the following at the command prompt: Java weblogic.Deployer –help

This command will display all the options provided by the tool.

weblogic.Deployer Options Table 4-1 describes all the options available in the weblogic.Deployer command-line tool. Option

Explanation

-help -version -adminurl

Prints a help message with a summary of all the options available in the tool. Prints version information. Indicates the administration server URL. The URL for the administration server must be presented with the deployment request because every deployment request is routed through the administration server. Indicates the username. A person deploying an application should have valid credentials for deployment. Specifies the password of the user deploying the application. Displays additional information throughout the deployment process and prints notification information about prepare and activate. Displays debug-level messages to the output. Displays syntax for example usage of this tool.

-username -password -verbose -debug -examples

Table 4-1.

Options Available in the weblogic.Deployer Tool

125

126


Option

Explanation

-upload

Causes the specified source file(s) to be copied to the administration server. It is used when initiating a deployment request from a machine other than the one hosting the administration server. Please note that for the deployment process to succeed, source files of the application should be available to the administration server. Causes the specified files to be removed from the application while the application is active. Valid for exploded applications. Signifies that the tool is running on a different machine than the administration server. Sets the StagingMode attribute on ApplicationMBean to nostage. If this option is specified, the administration server will not stage source files and the application will be deployed from the source path. Sets the StagingMode attribute value to external_stage on ApplicationMBean. Setting this value will result in the application being deployed from the StagingPath. It allows you to specify a staging directory and put the source files in that directory. Results in the administration server staging source files to the default staging area. (Staging options are discussed in detail in later sections in this chapter.) Results in the tool returning immediately—without waiting for completion of the deployment process. If you specify this option, you will see only the task ID and not the result of deployment on standard output. Specifies the maximum time in seconds the tool should wait before exiting. The tool will wait for the time specified by this option, print the current deployment status, and exit. Specifies the location of the file or directory that contains the application source to be deployed. Specifies the name of the application and results in the creation of ApplicationMBean with the name specified in this option. Specifies a comma-separated list of the server and/or cluster names. Each target may be qualified with a J2EE component name. This enables different components of the application to be deployed on different servers. Specifies a unique identifier for the deployment task and provides a way to later track deployment status. Activates the <source> application on the with the . Deactivates the application on the . Deactivates the application on the and unloads the classes. Deactivates the application on the and deletes all the staged files from the staging area. If no more targets are associated with this application, all the relevant MBeans will be deleted. Attempts to cancel the task if it has not yet completed. Lists the status of the task . Additionally, you can specify a comma-separated list of files that are to be redeployed as positional arguments.

-delete_files -remote -nostage

-external_stage

-stage -nowait

-timeout -source -name -targets

-id -activate -deactivate -unprepare -remove

-cancel -list Comma-separated list of files as positional arguments

Table 4-1.

Options Available in the weblogic.Deployer Tool (continued)

Chapter 4:


The weblogic.Deployer tool uses activate and deactivate interchangeably with deploy and undeploy. The term remove not only deactivates or undeploys an application, it removes the archive or application file/data from the staging directory, as well as deletes the ApplicationMBean from the system if no more targets are associated with this application. The sections that follow will describe the deployment/undeployment process in detail.

Deploy/Activate Deploying an application means activating a J2EE application to a J2EE-compliant application server. You can deploy an application from a machine other than the one that hosts the administration server on the local area network (LAN). If you deploy an application from a remote system, you need to specify the –upload option on the command line so that source files are uploaded to the administration server by the tool. (For details about WebLogic Server architecture, see Chapter 11.) The name of the application also needs to be provided so that the application can be referenced later by that name. To deactivate or remove the application, you need to provide the name of the application you used while deploying, as well as the URL for the administration server, username, password, and the location (source) of the application. Requests for deploy or activate checks the parameters provided on the command line. Every new deployment creates an ApplicationMBean, which contains all the attributes of that application. The ApplicationMBean is stored in the Java Management Extensions (JMX) server and remains there even if an application is deactivated. The remove operation deletes an ApplicationMBean from a JMX MBean server, provided that the application is no longer targeted to a server. Requests from weblogic.Deployer go to DeployerRuntimeMBean, which is a singleton and creates DeploymentTaskRuntimeMBean for every deployment request. Please note that for an application, there is only one ApplicationMBean, but every request of activate/deactivate or remove will result in creation of new DeploymentTaskRuntimeMBean. (For a more detailed description of JMX and MBeans, see Chapter 11.) Start the WebLogic Server; in this chapter we will use a server named myserver as an example. You should substitute it with the name of your server. For our purposes, we will use localhost as the listen address and 8001 as the listen port; however, you can use any IP address and port number you wish. Type the following command at the command prompt to initiate deployment: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -source C:\test\exploded\exploded_war -name sample_app -targets myserver –activate

127

128


The various options are •

-adminurl Administration server URL. Note that the administration server should be up and running for the deployment process to succeed.

•

-username Username for the administration server.

•

-password Password for the administration server.

•

-verbose Displays more details about the internal deployment process.

•

source Location of the application to be deployed.

•

-name Name for the server to remember for this application.

•

-targets Name of the WebLogic server that the application will be deployed on.

•

-activate Deployment option for activation.

Once you have made the request, you will see notifications about internal deployment processes. The -verbose option ensures that you will receive step-by-step information about the state of your application, as shown in Figure 4-1. You can verify the deployment by accessing it through your Web browser, as shown in Figure 4-2. Launch the browser and type the following on the address bar: http://localhost:7001/exploded_app/exploded_war_jar_ear.jsp.

Figure 4-1.

Activating an application

Chapter 4:

Figure 4-2.


Accessing the deployed application

Deployment Phases Once a request is sent to the WebLogic server for deployment and all the necessary management interfaces are created, the application goes through these phases: •

Preparation Phase Application files are staged from the source to the staging directory if the staging is on and classes loaded. You will see notifications like this: Preparing... Prepared...

•

Activation Phase Once an application is prepared, it is ready for activation. Activation makes modules available to the external world. Once an application is activated, it is immediately available for use. You will see the following notifications: Activating... Activated...

Undeploy/Deactivation Undeploy or deactivate disengages the application from the container, which makes the application unavailable to the external world. Deactivate makes the application unavailable, but it doesn’t delete management interfaces for the application, which remains targeted to the server. ApplicationMBean and ComponentMBean still exist. These interfaces are reused if the application is redeployed.

129

130


Let us now deactivate the application we just activated. Type following at the command prompt: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -name war -targets myserver –deactivate

Notice that the only things that have changed from the activate command is that there is no source and that it has a deactivate request. The application is no longer accessible. Try to access the application again with the browser. Type http:// localhost:7001/ exploded_war/exploded_war_jar_ear.jsp. You get a 404 error indicating that the application is no longer available to the external client. (See Figure 4-3.)

Unprepare The unprepare operation deactivates the application from the target and unloads the classes. The only difference between deactivate and unprepare is that deactivate keeps the classes loaded. Enter the following command to unprepare an application from target myserver: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -name war -targets myserver –unprepare

Remove The remove operation deactivates the application on the server, unprepares the application on the server, unstages the application and deletes all the staged files from the staging

Figure 4-3.

Accessing an application after deactivation

Chapter 4:


area, and deletes all the MBeans if the application is not targeted to any other server. A remove command looks like this: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -name war -targets myserver -remove

Cancel Cancel attempts to abort a deployment for a task ID on a given target. This is possible only if the target server has not begun processing the deployment. Once a deployment reaches the target server, the cancel command is ineffective. This is the typical cancel command: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -id 1 -targets myserver -cancel

List This option allows a user to list all the tasks or a specific task and see its status. Note that at any given moment, task status is not guaranteed if the task is explicitly deleted by the user. A task gets cleaned up from time to time, but you should be able to list a freshly triggered task and its status. java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -id 1 -list

Other weblogic.Deployer Options This section describes other basic deployment options not described in earlier sections.

Staging Options Staging is the process of making application source files available on a server. In WebLogic Server versions prior to 7, a user had no control over staging. The administration server was responsible for staging all the application data to the managed servers. WebLogic Server 7 gives users the option to stage the application data themselves or let the administration server stage it for them. Three staging options are available in version 7: stage, nostage, and external_stage. The stage option indicates that you want the administration server to stage the application data to a managed server’s default staging directory (the default staging directory is at server root/servername/stage). This option gives the administration server full control over staging.

131

132


The nostage option means that the administration server will not stage the application and will use the application’s source path to deploy it. The path specified in the source must be valid on the target server. The user is responsible for making the application available on the targeted server at the exact location specified by the -source option. The external_stage option implies that the administration server will not stage application files; instead, it expects application data to reside on the target server’s staging area. You can specify your own staging directory. You can further specify staging preference either at server level or at application level. By default, the administration server has nostage, and the managed server defaults to stage. You can override all these options at both the server and the application level.

The -upload Option This option is useful if a user is initiating a deployment task from a remote client. The –upload option indicates to the system that a client is a remote client and that application files must be uploaded to the administration server before the actual deployment starts. This gives the user flexibility to deploy to a server or multiple servers from a remote machine.

The -remote Option This option indicates that the path of the file is relative to the user’s current directory. If not specified, the path is relative to the server root on the remote system.

The -examples Option This is a quite useful option for quickly checking the syntax for activate/deactivate and remove options.

The -timeout Option A user can specify timeout for the tool. The tool is synchronous, so it will wait until a deployment has happened on the server. The -timeout option gives users the flexibility to wait for the timeout specified in seconds and exits after the time limit, irrespective of the state of deployment. The timeout is also forwarded to the deployment framework and could be used to automatically cancel the request if it is a cluster deployment and the request times out.

The -nowait Option This option will make the tool to print the deployment task and exit as soon as the deployment request is delivered to the server.

Chapter 4:


MANAGEMENT INTERFACES The deployment process results in the creation of objects by the WebLogic framework. These objects are exposed to the user as interfaces. Following is a description of relevant interfaces.

ApplicationMBean An application is specified by ApplicationMBean interface. An ApplicationMBean has attributes, which can be configured for a particular application, as shown in Table 4-2.

ComponentMBean This interface specifies different configurable attributes for components or modules. Table 4-3 describes ComponentMBean attributes.

STATIC DEPLOYMENT Static deployment involves the configuration of an application with modules and target information in config.xml. Applications get deployed when servers start up. This method of deployment requires a high level of familiarity with WLS and a thorough Attribute

Type

Description

Name Components

String String

Path

String

StagingMode TwoPhase

String Boolean

LoadOrder StagingPath StagedTarget

Integer String String

Specifies the name of the application. Specifies the type of component on an application. A component can be an EJB type or Web application type. An application can have multiple components. The component is represented by another management interface, CompoentMBean, which has many attributes. Specifies the location of source files on the administrative server. Path can be either absolute or relative. A relative path is always assumed relative to the server root, the location where the server is started. Specifies the staging mode for the application. Specifies whether the application is to be deployed using the new application deployment model in WebLogic 7. If not specified, the application will be deployed using old deployment APIs, characteristic of WebLogic 6.x and earlier. Specifies the order in which the application should be deployed. Enables the user to specify the staging path on the application. Keeps the information if a particular target is staged for this application or not. If a target is already staged, an application will not be staged again when the server restarts.

Table 4-2.

ApplicationMBean Attributes

133

134


Attribute

Type

Description

Name

String

URI

String

Application

String

Specifies the name of the component, which can either be an EJBComponent or WebappComponent type. Specifies the URI of the component. It is normally the name of the JAR file or the directory in case of an exploded application that contains the component. Specifies the name of the application to which this component belongs.

Table 4-3.

ComponentMBean attributes

knowledge of management interfaces and MBeans. Static deployment is the best way to deploy in a production environment. With some knowledge of management interfaces for applications and components, you can easily configure an application in config.xml. Let’s configure a simple application in config.xml: <Application Name="war" Path="C:\test\exploded" TwoPhase="true"> <WebAppComponent Name="sample_app" Targets="myserver" URI="exploded_war"/>

The administration server parses the entries in config.xml and creates a corresponding management interface called management MBean or MBean for each element. The above entries for static deployment of an application named war resulted in the creation of the application MBean named sample_app. It is easy to decipher the config.xml entries for an application after familiarizing yourself with MBean attributes for ApplicationMBean and ComponentMBean. Remember that every element and attribute in config.xml should start with an uppercase letter. Once a server is running, you can access or modify different attributes using WebLogic Console or a client program such as WebLogic.Admin. The preceding example shows only WebAppComponent inside the application. An enterprise application (EAR) can contain multiple EJBs and Web components. You can configure an EJB in the following manner: <EJBComponent Name="Jar1.jar" Targets="myserver" URI="Jar1.jar"/>

Multiple EJB and WebApp components can be part of one EAR and can be configured in the following manner: <Application Name="app_name" Path="C:\test\exploded" TwoPhase="true"> <WebAppComponent Name="component1 " Targets="target1" URI="URI1"/> <WebAppComponent Name="component2 " Targets="target1" URI="URI2"/> ......

Chapter 4:


<EJBComponent Name="EJB1" Targets="target1" URI="URI1"/> <EJBComponent Name="EJB2" Targets="target1" URI="URI2"/> ......

MULTIPLE-SERVER DEPLOYMENT The domain is the highest management element in WebLogic administration, and WebLogic handles multiple servers under the domain element. You can have as many servers as you want under a domain; however, a WebLogic server domain typically means that you have one administration server and/or one or more managed server(s). The administration server hosts a Web application called WebLogic Console to administer and manage the WebLogic domain. All the deployment requests are routed through the administration server. Deployment to multiple servers should also be initiated through the administration server, which keeps a master copy of all the applications to be deployed. (For more information on WebLogic management architecture, please see Chapter 11.) You can deploy to multiple servers either statically or dynamically using the weblogic.Deployer tool or the Console. Static deployment to multiple servers requires configuring multiple targets in config.xml for the components. To target a WebApp to server1 and server2, config.xml entries for the application will look like this: <WebAppComponent Name="component1 " Targets="server1,server2,..." URI="URI1"/>

You can deploy to as many servers as you like, provided the administrative server is configured in the domain. Managed servers will pick up the application at bootup time, and all the applications targeted to that managed server will be deployed. Note that only the administration server has config.xml. All the other servers get their configuration details from the administrative server at bootup time. (Please see Chapter 11 for details.) To deploy to multiple servers using weblogic.Deployer, you should specify comma-separated server lists under the –targets option. A multiple deployment request for an application using weblogic.Deployer will look like this: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -source C:\test\exploded\exploded_war -name war -targets server1,server2,... –activate

The application will be deployed to a managed server whenever it comes up. If a server is not up, weblogic.Deployer will report a failure indicating the reason that the server is not running, and the server that isn’t currently running will receive the deployment when it starts up.

135

136


CLUSTER DEPLOYMENT A cluster is a group of servers that behave like a single powerful server. A cluster is required in a highly scalable, fault-tolerant environment, in which scalability and failover are critical to the business application. WebLogic 7 introduces the concept of a two-phase deployment, which is more relevant to cluster deployment.

Cluster Setup Before you deploy an application to a cluster, you must ensure that the cluster is configured and set up properly. You can use WebLogic Installer to create cluster configuration. WebLogic Server 7 has a handy wizard that can help you create multiple-server configurations. (See Chapter 8 for more information.) Here is the minimal config.xml, which contains the configuration for a two-node cluster: <ApplicationManager Name="mydomain"/> <Server ListenAddress="localhost" ListenPort="8001" <Server Cluster="mycluster" ListenPort="8002" Name="myserver1" <Server Cluster="mycluster" ListenPort="7009" Name="myserver2" <XMLRegistry DocumentBuilderFactory= "WebLogic.apache.xerces.jaxp.DocumentBuilderFactoryImpl" Name="MyXML Registry" SAXParserFactory= "WebLogic.apache.xerces.jaxp.SAXParserFactoryImpl" TransformerFactory= "WebLogic.apache.xalan.processor.TransformerFactoryImpl" WhenToCache="cache-at-initialization"/>

Deployment Phases Two-phase deployment on a cluster means either deployment should succeed on all or none of the servers. The two phases are the prepare phase and the commit phase. In phase one, when a deployment is targeted to a cluster, WebLogic internal service sends the information about the upcoming deployments to all the members of a cluster. All

Chapter 4:


the cluster members prepare the application and send prepare succeeded or prepare failed notification back to internal service. Phase two occurs if all the members of the cluster have successfully prepared the application. At that point, internal service sends notification for committing the deployment and completing the deployment process. Two-phase deployment results in cluster consistency and ensures that a homogenous cluster is maintained. Any of the following deployment methods can be used to deploy a cluster: •

weblogic.Deployer

•

Static deployment

•

Console

Cluster Deployment Using weblogic.Deployer To use weblogic.Deployer to deploy to a cluster, first ensure that all the members of the cluster are up and running. Specify the cluster name as the target. Here is what your command should look like for deploying to a cluster: java weblogic.Deployer -adminurl http://localhost:8001 -username installadministrator -password installadministrator -verbose -source C:\test\exploded\exploded_war -name war -targets clusterName –activate

Static Deployments to a Cluster To enact a static deployment on a cluster, configure the application as described in the section “Static Deployment,” earlier in this chapter, and specify the cluster name as the target. All the servers in the cluster will pick up the deployment at bootup time. Please note that two-phase deployment is not relevant for static deployments. A clustered server will get the deployment while starting.

Deployment Using Console Console is a convenient tool to deploy, undeploy, or redeploy an application and check its status. It is a comprehensive WebLogic administration tool that can be used to administer a single server, multiple servers, or cluster. It is covered in detail in Chapter 3. Suppose we start a single WebLogic server on localhost and port 8001, and bring up Console. Enter the following to access Console Web application: http://localhost:8001/ console. Once you have logged in to Console, you will see the main page, as shown in Figure 4-4. Follow these steps to deploy an application with Console: 1. In the navigation pane along the left side of the Console, browse to Deployments and then Applications. 2. Click Configure A New Application in the right pane. 3. The next screen will ask you to choose an application to configure, as shown in Figure 4-5.

137

138


Figure 4-4.

WebLogic Server Console main page

You will then follow a number of steps to complete the deployment process: Step 1 Browse to the location of your application (shown in Figure 4-5) and click the Select icon. The Deployment Wizard launches, as shown in Figure 4-6.

Figure 4-5.

Choose an application to deploy.

Chapter 4:

Figure 4-6.


Deployment Wizard

Step 2 Select the application you want to deploy. If the application is not available on the administration server, upload the application file to the administration server as shown in step 1. Step 3 On the left side of the window, you’ll see a list of available target servers you can select for deployment. Click the arrow in the middle of the panel to select your target. The selected target will appear in the Target Servers area. (Notice that you can also choose clusters to deploy.) Step 4 You are asked to name the application. By default, the name of the file or directory you chose will be displayed. However, you can name the application whatever you wish. Step 5 Here you can either go ahead and configure the application or cancel the process. Click Continue to complete the deployment process. Figure 4-7 shows the final screen of the deployment process. It tells you the status of deployment and features Deployment Status By Target. This option displays the status of deployment for every target to which you have chosen to deploy. The Deployment Activity display shows the overall summary of the deployment, start time, and end time.

139

140


Figure 4-7.

Deployment status

Note that the deployment is done asynchronously. The console will update the deployment status as it detects changes.

Undeploy/Deactivate in Console To undeploy an application, follow either of these steps: •

Click the Undeploy button (which replaces the Configure And Deploy button that was shown back in Figure 4-6).

•

Click the Targets tab. You’ll see a screen where you can deselect the targets from target servers by clicking the left arrow button and clicking the Apply icon. The application will be deactivated.

Remove an Application in Console To remove an application, follow these steps: 1. From the navigation tree on the left side of Console, click the Tasks node at the bottom of the tree. You will see a list of tasks. 2. Click the Purge Tasks button, shown in Figure 4-8, to delete the application.

DEPLOYMENT APIS Up to this point, you have seen and worked with various deployment tools provided by WebLogic Server. BEA also exposes deployment APIs for you to take advantage of

Chapter 4:

Figure 4-8.


Purging the deployment task

and write your own program to deploy an application based upon your needs. We have already discussed ApplicationMBean and ComponentMBean. Some other classes exposed by BEA are discussed here.

DeploymentData This class describes targets involved in an application deployment. DeploymentData objects are used when invoking deployments via DeployerRuntimeMBean methods. The object defines the list of target servers, clusters, and virtual hosts that apply to a specific deployment request and may also be used to identify files to refresh as part of the deployment. •

public DeploymentData()

•

public DeploymentData(String [] files) object with a list of files.

Creates an empty deployment object.

•

public void AddModuleToTargets(String target, string module) Adds a module to a configured target.

•

public void addTarget(String target, String[]modules) Adds an array of modules to a target.

•

public void addTargetsForComponents(ApplicationMBean mbean,String compName) Adds targets to components based on ApplicationMBean configuration.

•

public String[] getTarget() clusters, and virtual hosts.

•

public String[] getModules()

•

public String[] getFiles()

Creates a DeploymentData

Returns an array of targeted servers, Returns a list of modules.

Returns a list of files.

141

142


TargetStatus This class encapsulates the status of deployment for all the targets in a deployment request. Every target in the deployment task has a corresponding TargetStatus object. Returns the target name associated with

•

public String getTarget() the TargetStatus object.

•

public int getState() Returns the state of deployment for a particular target.

A target can have the following statuses: •

public static int STATE_INT Represents initial state and has a value of 0.

•

public static int STATE_IN_PROGRESS progress and has a value of 1.

•

public static int STATE_FAILED and has a value of 2.

•

public static int STATE_SUCCESS succeeded and has a value of 3.

Represents deployment in

Represents that deployment has failed Represents that deployment has

DeploymentTaskRuntimeMBean Every deployment request results in the creation of a DeploymentTaskRuntimeMBean. DeploymentTaskRuntimeMBean encapsulates the information about the task, the targets involved, the TargetStatus, and DeploymentData. Following are some of these methods: •

Public DeploymentTaskRuntimeMBean (ApplicationMBean object, DeploymentData data, String id, int task)id represents the task ID. A user has the option to specify the task ID for tracking purposes. If a user doesn’t specify an ID, the system generates one and gives it back to the user. This task represents the type of task you want to execute, such as activate, deactivate, and remove.

•

Public DeploymentTaskRuntimeMBean(String path, ApplicationMBean object, DeploymentData data, String id, int task) Constructor has a path and an additional argument that represents location of the source files.

•

Public String getApplicationName() application.

•

Public long getBeginTime()

•

Public long getEndTime() completed.

Returns the name of the

Returns the time the task was started.

Returns the time when the task was

Chapter 4:


Returns the source location.

•

Public String getSource()

•

Public int getTask() Returns the type of task represented by this object.

•

Public String getId Returns the task ID.

•

Public int getState() Returns the state of the task.

A task can have the following states: •

TASK_INITIATED Indicates that a task has been initiated and has a value of 0.

•

TASK_RUNNING Indicates that a task has been initiated and is still running, with a value of 1.

•

TASK_FAILED Indicates that a task has been failed and has a value of 2.

•

TASK_COMPLETED Indicates that a task has been completed and has a value of 3.

For complete APIs, visit javadocs at http://edocs.bea.com/wls/docs70/javadocs/index.html.

DeployerRuntime This class is a singleton and resides on the administration server. It initiates every deployment task by creating a DeploymentTaskRuntimeMBean for every deployment request. Following are descriptions of some of the methods and fields in this class: •

Public DeploymentTaskRuntimeMBean activate (String source, String name, String stagingMode, DeploymentData data, String id) Deploys an application to the targets specified in the DeploymentData where •

source The location of application files.

•

name The name of the application.

•

staging mode Staging mode can be stage, nostage, or external_ stage, as described.

•

data Where the information about modules and targets is encapsulated.

•

id User associates a task with an ID.

•

Public DeploymentTaskRuntimeMBean activate (String source, String name , String stagingMode, DeploymentData data, String id, Boolean start_task) This method is similar to activate()except there is an additional argument start_task. If start_task is true, the method returns without waiting for the actual task to start.

•

Public DeploymentTaskRuntimeMBean deactivate (String name, DeploymentData data, String id) Undeploys the application name with id from targets specified in the DeploymentData.

•

Public DeploymentTaskRuntimeMBean deactivate (String name, DeploymentData data, String id,Boolean starttask) This is

143

144


similar to the preceding deactivate() method except that it has an additional argument starttask. If starttask is true, the program returns immediately. •

Public DeploymentTaskRuntimeMBean remove (String name, DeploymentData data, String id) Removes an application name with an ID from the server.

•

Public DeploymentTaskRuntimeMBean[] list() all the tasks involved in the deployment.

•

Public DeployerRuntimeMBean getDeployerRuntime() DeployerRuntimeMBean to a singleton.

This method lists Returns

CHECKLIST In this chapter, we discussed application deployment. We went through the process of deployment to a single server, multiple servers, and clusters in great detail. We also covered the different deployment methods and using API for deployment. Here are the tasks you should understand from this chapter: ■

Deploy J2EE applications on WebLogic Server

■

Activate, deactive, unprepare, and remove an application on WebLogic Server

■

Auto-deployment

■

Static deployment

■

Dynamic deployment

■

Deployment using weblogic.Deployer

■

Cluster deployment

■

Multiple -server deployment

■

Deployment using WebLogic Console

■

Deployment interfaces and APIs

■

Deployment management interfaces

CHAPTER 5 WebLogic and J2EE


145

146


J

ava 2 Enterprise Edition (J2EE) is the key to developing enterprise applications using WebLogic Server. WebLogic Server supports all J2EE services, such as Enterprise JavaBeans (EJB), Remote Method Invocation (RMI), Java Naming and Directory Interface (JNDI), Java Database Connectivity (JDBC), Java Message Service (JMS), Java Transactions API (JTA), and so on. This focus of this chapter is to learn about these services and how WebLogic supports users in implementing them. Concepts covered in this chapter include distributed WebLogic architecture, Web application administration, client state maintenance, servlets as EJB clients, transactions, enterprise applications, WebLogic RMI, WebLogic RMI-IIOP (RMI over Internet Inter-ORB Protocol), WebLogic JMS, WebLogic JNDI, and XML with WebLogic. We will also participate in configuring various services.

WEBLOGIC’S DISTRIBUTED ARCHITECTURE Distributed architecture focuses on centralizing Web server facilities, business components, and access to back-end systems. It brings to our attention various technological benefits, such as caching and connection pooling, which help us utilize our organizational and system resources in a more optimized manner. Two major kinds of modern architectures are covered here: two-tier client/server architecture and three-tier, commonly known as n-tier, architecture. Although distributed application architecture may have started out as two-tier, manageability and maintainability of application logic and business logic has forced us to move onto a more scaleable architecture. Three-tier, or n-tier, architecture makes that possible. Two-tier solutions have been adopted by and implemented in organizations for years, but with the widespread use of Internet applications, system architecture has had to undergo changes. Two-tier solutions are not capable of serving users and applications over the Internet. Moreover, with facilities being exposed through the Internet, the number of users being able to access an application has grown to a level that demands a new level of infrastructure to accommodate all users. NOTE Distributed applications are able to serve multiple users concurrently and, depending on their design, make more optimal use of processing resources. There are problems with both two-tier and three-tier models. Two-tier architecture has limitations in what it can accomplish, and three-tier architecture is not scaleable. To overcome these obstacles, we need a kind of architecture in which the clients are thin, so that minimum to no logic is applied there, and one in which we have intelligent Web servers that can host application logic and data access mechanisms. This way, Web servers can communicate with the back-end systems, providing a scaleable solution.

Chapter 5:

WebLogic and J2EE

It takes great effort to provide a 24/7 solution in an n-tier architecture. Administrators are on their toes, working around various mechanisms to keep the show going. They must interact with business analysts, source code controllers, application component designers, developers, integrators, database administrators, and even front-end developers. As administrators, it becomes especially difficult to manage when we must use a combination of tools and technologies from various vendors. This is the key to manageability and maintainability issues. WebLogic provides a set of tools and products that help us manage our business systems from a central location. Figure 5-1 demonstrates application logic layers that an administrator must deal with. Java servlets, JSP, and HTML/XML form the presentation components residing within the Web container in WebLogic Server. These components are hosted on WebLogic Server. EJB is hosted within the EJB container on WebLogic Server. It supports both types of beans—entity beans and session beans. EJB forms the business layer for your enterprise application. The EJB container hosts various business beans, which expose methods that are called and used by the client: JavaMail, JMS, JDBC, JNDI, XML, TCP/IP, JTA, WebLogic Enterprise Connectivity (WLEC), RMI, Secure Sockets Layer (SSL), and RMI-IIOP all form various application services.

Figure 5-1.

Application logic layers

147

148


ADMINISTERING WEB APPLICATIONS Web applications usually require that various components of the Web be grouped together. These components include Java applets, servlets, Java Server Pages (JSP), and static resources such as HTML and image files. Web applications can access external resources such as EJB and JSP tag libraries. Once the components are designed and developed, they need to be configured and deployed by the administrator on the application server. The administrator needs to configure and manage various areas of WebLogic Server, which includes setting up HTTP parameters, configuring the listen port, configuring a virtual host, setting up access logs, preventing Denial-of-Service (DoS) attacks, setting up WebLogic Server for HTTP tunneling, and applying usage of native I/O for serving static files that are valid only on a Windows platform. We will explore these aspects of administering Web applications in this section.

Configuring HTTP Parameters Following are the HTTP operating parameters available for configuration with WebLogic Server 7: •

Default Server Name

•

Enable Keepalives

•

Send Server Header Enabled

•

Duration

•

Secured HyperText Transfer Protocol (HTTPS) Duration

•

Wireless Application Protocol (WAP) Enabled

•

Post Timeout Secs

•

Max Post Time

•

Max Post Size

•

External DNS Name

All the parameters can be found on the Administration Console of your server configuration on the HTTP tab, as shown in Figure 5-2, except the external Domain Name Service (DNS) address, which is present in the General tab, as shown in Figure 5-3. Let’s discuss these parameters and the situations in which they impact the server. First, we’ll look at some sample applications found on the Web.

Chapter 5:

Figure 5-2.

WebLogic and J2EE

HTTP configuration tab

From the navigation pane on the left side of the Console, click the examplesServer node under examples\Server to access the server configuration settings URL. You’ll see the page shown in Figure 5-4. On the examples page, you’ll see a link to open the WebLogic Server Admin Console. Click the link, and you’ll see the interface shown in Figure 5-5.

Default Server Name When WebLogic Server redirects a request, it sets the host name returned in the HTTP response header with the string specified with the default server name, which is useful when using firewalls or load balancers, or when you want the redirected request from the browser to reference the same host name that was sent in the original request.

149

150


Figure 5-3.

General configuration tab

HTTP Keepalives HTTP operates on what is called a request-response paradigm. This means that when a client generates a request for information and it passes it over to the server, the server will send an appropriate response. With each request a client makes, a new socket connection will be established with the server, over which the request is sent, and then read from that connection to get the response and drop the connection. How HTTP keeps alive with version 1.0 and 1.1 of HTTP differs. With HTTP 1.0, if the browser supports keep-alive, it will add header information to the request, stating Connection: keep-alive

Once the server receives this request and generates a response, it also adds a header to the response generated and sent over to the client: Connection: keep-alive

This means that both the client and the server intend to keep the connection open, and hence it is not dropped. This will go on until either the client or the server instructs the conversation to end and the server drops the connection.

Chapter 5:

Figure 5-4.

WebLogic and J2EE

WebLogic examples

In HTTP 1.1, all the connections are kept alive by default unless specified explicitly in the header as Connection: close

NOTE The keep-alive extension to HTTP 1.0 and the persistent connection feature of HTTP 1.1 provide long-lived HTTP sessions that allow multiple requests to be sent over the same TCP connection. With WebLogic Server, this HTTP parameter is defaulted to true. It can be switched to false to make HTTP behave the same as in version 1.0.

Send Server Header Enabled If set as false, the server name is not sent with the HTTP response. This header is especially useful for wireless applications where there is limited space for headers.

151

152


Figure 5-5.

Administration Console

Duration This parameter is effective when the HTTP keep-alive feature is turned on. It defines the number of seconds that WebLogic Server should wait before closing an inactive HTTP connection. It is useful in that it saves server resources. For instance, if a particular connection has been established by the client and HTTP keep-alive is on, and there has been no activity between client and server, effectively the connection is inactive and it is a waste of resources. The server allows a maximum number of concurrent connections, and if too many connections are inactive, the server may run out of resources. This parameter helps drop the inactive connections.

HTTPS Duration This parameter defines the number of seconds that WebLogic Server waits before closing an inactive HTTPS connection.

Chapter 5:

WebLogic and J2EE

WAP Enabled When WAP Enabled is selected, the session ID no longer includes JVM information. This may be necessary when using URL rewriting with WAP devices that limit the size of the URL to 128 characters. Selecting WAP Enabled may affect the use of replicated sessions in a cluster.

Post Timeout Secs This attribute sets the timeout (in seconds) that WebLogic Server waits between receiving chunks of data in HTTP POST data. It is used to prevent DoS attacks that attempt to overload the server with POST data.

Max Post Time This attribute sets the time (in seconds) that WebLogic Server waits for chunks of data in HTTP POST data. If the value for this parameter is less than 0, it means that it is unlimited.

Max Post Size This attribute sets the size of the maximum chunks of data in HTTP POST data. If the value for this parameter is less than 0, it means that it is unlimited.

External DNS Name If your system includes an address translation firewall that sits between the clustered WebLogic Servers and a plug-in to a Web server front end, such as the Netscape (proxy) plug-in, set this attribute to the address used by the plug-in to talk to your server.

Configuring the Listen Port You need to understand some additional parameters that will be helpful in administering WebLogic Server. Here, we will discuss the parameter Listen Port. Every service— HTTP, FTP, and SSL—needs a specific port on which to listen to the request/response. HTTP service is, by default, assigned port 80. Similarly, FTP service listens on port 21. Each service has its own default port number where it can listen to requests. At times, we may need to change the port number on which a service listens, either to accommodate another service or for security reasons. WebLogic Server’s HTTP service listens on port 7001 when you perform installation. What difference does it make whether it’s configured to default port number 80 or custom port number 7001? There is a difference, in that the user can gain access to the site if the HTTP port number is different from the default of 80. For example, if you want to access the ExamplesServer on your local machine where WebLogic Server is installed, you must use the following URL: http://kshah:7001/examplesWebApp/index.jsp. Here, http:// is the protocol, kshah is the machine name, 7001 is the bound port for HTTP

153

154


service, examplesWebApp is the name of application, and index.jsp is the default Web document. If you intend to change the port number at which WebLogic Server waits to listen to client requests, you must configure the WebLogic Server using the Administrative Console, as shown in Figure 5-6. NOTE If the port number assigned for HTTP is 80, the client doesn’t need to include the port number when accessing the Web server. http://kshah/exampleWebApp/index.asp is all the user will need to supply, which eliminates the need for port number.

Setting Up and Maintaining HTTP Access Logs It is useful for administrators to have proper configuration for recording HTTP access activities over the server. Logs contain useful pieces of information that can help administrators answer what, why, and how about the activities and problems taking place on a WebLogic server. WebLogic maintains a log of access activities in a text file in either of the following formats: •

Common log format Used by default for recording information in the log file; it uses standard conventions.

•

Extended log format

Figure 5-6.

Follows the customized path of recording information.

Changing the listen port for WebLogic Server

Chapter 5:

WebLogic and J2EE

You can define which information recorded in the log file you want to access, and you have total control over what is contained in the logs. Logs reside as operating system files, and hence are subject to the space quota allocated to the partition in which they are created. How do we tackle this problem? As WebLogic Server will be running 24/7, at some point we may encounter a situation in which either nothing is being logged to the log file or the WebLogic server is locked up and can’t find enough space to record log info. Thankfully, a facility called ROTATE LOGS is available, which lets us specify the fate of recycling a log file—we can determine whether this information should be subject to size or time restrictions. We can configure log parameters such that when the log reaches a certain size, we can truncate (empty) the log and reuse the same file. The alternative is that we can truncate the log every few days or hours.

Setting Up Access Logs Using the Administration Console To configure WebLogic Server to record HTTP access logs (shown in Figure 5-7), follow these steps: 1. Select the Servers node in the left pane. The node expands and displays a list of servers. 2. Select a server. In our case, select examplesServer.

Figure 5-7.

HTTP access log setup

155

156


3. Open the Logging tab. 4. Select the HTTP tab to see the parameters that can be configured for controlling the behavior and type of logs we want to use. 5. Check the Enable Logging box. 6. Enter values for the Logfile Name. The default name for the log as set for examplesServer is ./examplesServer/access.log. Change it to Activities.log. 7. The default format is Common, which can be changed to Extended. Select Common or Extended from the Format drop-down list. 8. In the Rotation Type field, choose Size or Date. •

Size Rotates the log when it exceeds the value entered in the Log Buffer Size parameter.

•

Date Rotates the log after the number of minutes specified by the Rotation Period parameter.

9. If you have selected Size as the Rotation Type, set the Max Log File Size K Bytes field to the maximum number of bytes you want your log file to hold. 10. Set the Flush Every parameter to the number of seconds after which the access log writes out log entries to the disk file. 11. If you have selected Date as the Rotation Type, set the Rotation Time to the first date when you want the log file to rotate. (This is effective only if Rotation Type is set to Date.) Enter the date using the java.text.SimpleDateFormat, MM-dd-yyyy-k:mm:ss. (See the javadocs for the java.text.SimpleDateFormat class for more details.) 12. If you have selected Date as the Rotation Type, set the Rotation Period to the number of minutes after which the log file will rotate.

Defining a Virtual Host Defining virtual hosts allows your single server to host a number of different Web sites. With virtual hosts, you can map multiple IP addresses, hosts (such as special.domain.com), domains (such as www.example.com), and languages to different root folders within the folder. WebLogic will respond to HTTP requests as though each site were on a separate machine. Advantages of this virtual hosting method include these: •

Having SSL certificates for online stores and encrypting private data

•

Being compatible with older browsers and search index robots

•

Using standard IP address resolution

•

Routing requests slightly faster because the browser sends the IP address directly

To define a virtual host, use the Administration Console to do the following: •

Create a new virtual host.

Chapter 5:

WebLogic and J2EE

1. Expand the Services node in the left pane. The node expands and displays a list of services. 2. Click the Virtual Hosts node. If any virtual hosts are defined, the node will expand and display a list of virtual hosts. 3. Click Create A New Virtual Host in the right pane. 4. Enter a name to represent this virtual host. 5. Enter the virtual host names, one per line. Only requests matching one of these virtual host names will be handled by the WebLogic Server or cluster targeted by this virtual host. 6. (Optional) Assign a default Web application to this virtual host. 7. Click Create. •

Define logging and HTTP parameters: 1. (Optional) Click the Logging tab and fill in HTTP access log attributes. (For more information, see “Setting Up and Maintaining HTTP Access Logs,” earlier in this chapter.) 2. Select the HTTP tab and fill in the HTTP Parameters.

•

Define the servers that will respond to this virtual host. 1. Select the Targets tab. 2. Select the Servers tab. You will see a list of available servers. 3. Select a server in the Available column and use the right arrow button to move the server to the chosen column.

•

Define the clusters that will respond to this virtual host (optional). You must have previously defined a WebLogic cluster. 1. Select the Targets tab. 2. Select the Clusters tab. You will see a list of available servers in the cluster. 3. Select a cluster in the Available column and use the right arrow button to move the cluster to the chosen column. The virtual host is targeted on all of the servers of the cluster.

•

Target Web applications to the virtual host. 1. Click the Web Applications node in the left pane. 2. Select the Web application you want to target. 3. Select the Targets tab in the right panel. 4. Select the Virtual Hosts tab. 5. Select Virtual Host in the Available column and use the right arrow button to move the virtual host to the chosen column.

157

158


MAINTAINING CLIENT STATE HTTP is the protocol of the Web. However, it has a design constraint that makes it a stateless protocol. Here, the term stateless means that each request/response instruction cycle is extremely independent and isolated. For each request that the client frames to send to the server, a new socket connection is established. Once the server receives a response from the server, it drops the connection. Hence, for any client, the server keeps the session duration valid only until the client request is not served. This mechanism of dropping a client connection is quite authenticated, as the server has numerous clients to be served, and if it holds the connection for each client, its potential is not fully exploited to serve many clients. Various techniques are available to maintain a client state, including hidden variables, client cookies, session variables on a server, and URL rewriting. How does WebLogic Server know which session is associated with each client? When an HttpSession is created in a servlet, it is associated with a unique ID. The browser must provide this session ID with its request for the server to find the session data again. The server attempts to store this ID by setting a cookie for the client. Once the cookie is set, the servlet includes the cookie containing the ID each time the browser sends a request to the server. The server automatically parses the cookie and supplies the session data when the servlet calls the getSession() method. If the client does not accept cookies, the only alternative is to encode the ID into the URL links in the pages sent back to the client. For this reason, you should always use the encodeURL() method when you include URLs in your servlet response. WebLogic Server detects whether or not the browser accepts cookies and does not unnecessarily encode URLs. WebLogic automatically parses the session ID from an encoded URL and retrieves the correct session data when you call the getSession() method. Using the encodeURL() method ensures no disruption to your servlet code, regardless of the procedure used to track sessions.

SERVLETS AS EJB CLIENTS EJB clients can be Java applications, applets, servlets, JSPs, and even other EJBs. Servlets and JSP clients are particularly useful when clients are outside a firewall; they provide all the benefits of EJB along with a thin client HTML interface. To access an EJB, your client code performs the following actions: •

Creates an InitialContext object, optionally passing a Properties object to the InitialContext constructor.

•

Obtains a reference to the home object implementation through a JNDI lookup.

•

Obtains a reference to the remote object implementation by calling either a create or finder method on the home object reference.

•

Calls one or more of the EJB business methods.

Chapter 5:

WebLogic and J2EE

Your client performs these actions differently, depending on the level of security in force for the desired EJB: •

No authentication Simple access to unsecured EJBs or bean methods.

•

Web authentication

•

Custom authentication Secure access to EJBs and bean methods as well; in this case, the servlet must acquire the username and password, passing them as properties when creating an InitialContext instance.

Secure access to EJBs and bean methods.

TRANSACTIONS You need to understand and handle two issues from the administration point of view: •

Configuring transaction parameters

•

Monitoring and logging transactions

Configuring Transaction Parameters WebLogic provides the framework for dealing with business transactions with the help of JTA. WebLogic JTA provides the following support for business transactions: •

Creates a new, unique identifier for every new transaction initiated by the client application.

•

Supports an optional transaction name describing the business process the transaction represents. The transaction name makes statistics and error messages more meaningful.

•

Works with the WebLogic Server infrastructure to track objects that are involved in a transaction and, therefore, need to be coordinated when the transaction is ready to commit.

•

Notifies the resource managers—which are often databases—when they are accessed on behalf of a transaction. Resource managers then lock the accessed records until the end of the transaction.

•

Orchestrates the two-phase commit when the transaction completes, which ensures that all the participants in the transaction commit their updates simultaneously. It coordinates the commit with any databases that are being updated using Open Group’s XA protocol. Many popular relational databases support this standard.

•

Executes the rollback procedure when the transaction must be stopped.

•

Executes a recovery procedure when failures occur. It determines which transactions were active in the machine at the time of the crash and then determines whether the transaction should be rolled back or committed.

159

160


•

Manages transaction timeouts. If a business operation takes too much time or is only partially completed due to failures, the system takes action, such as database locks, to issue a timeout for the transaction and free resources automatically.

As you have learned to configure various aspects of WebLogic Server, it is necessary for you, the administrator, to learn how to configure transactions-related attributes, such as •

Transaction timeouts and limits

•

Behavior of transaction manager

•

Transaction log file prefix

It is important that you have a clear understanding of the various J2EE components that participate in transactional activities. J2EE components such as EJB, JDBC, and JMS participate in transactions. EJB uses JTA for transaction support. JDBC provides standard interfaces to access relational databases from Java applications. Here, JTA provides transaction support on connections retrieved with the help of JDBC driver and transaction data sources. JMS uses JTA to support transactions across multiple data resources. All JTA configuration parameters can be found on the Administration Console. To access and configure these parameters, you need to start the Administration Console. Then you need to open the JTA tab to access various configurable parameters. When you select the domain, you will see the JTA tab under the Configuration tab in the right pane (as shown in Figure 5-8). The following parameters can be set for JTA: •

Timeout Seconds

•

Abandon Timeout Seconds

•

Before Completion Iteration Limits

•

Max Transactions

•

Max Unique Name Statistics

•

Checkpoint Interval Seconds

•

Forget Heuristics

Timeout Seconds Defines the amount of time, in seconds, a transaction may be active before the system forces a rollback. The minimum value for this parameter is 1; the maximum is 2,147,483,647. Abandon Timeout Seconds Defines the amount of time, in seconds, that a transaction coordinator attempts to complete a transaction. Meaning, once it crosses this duration, the transaction coordinator abandons the transaction. The minimum value for this parameter is 1; the maximum is 2,147,483,647.

Chapter 5:

Figure 5-8.

WebLogic and J2EE

Configuring transactions

Before Completion Iteration Limits Indicates the number of beforeCompletion callbacks that are processed before the system forces a rollback. Max Transactions Defines the maximum number of transactions that can be active on one server at any given time. Max Unique Name Statistics Indicates the maximum number of unique transaction names that may be tracked by a server at one time. Checkpoint Interval Seconds Relates to the way transaction log files are managed. While logging transactions to files, log files fill up or we may want to reuse these files once they reach a specific size. This parameter specifies the interval at which the transaction manager creates a new transaction log file and checks all old transaction log files to see if they are ready to be deleted. Default value for this parameter is 300 seconds (5 minutes). The minimum is 10 seconds; the maximum is 1800 seconds (30 minutes). Forget Heuristics Specifies whether or not the transaction manager should instruct a resource to forget any transaction with a heuristic outcome.

161

162


NOTE The settings performed for JTA are at domain level. This means that the settings you make for JTA will be applicable to all servers in the domain. You can configure all parameters before running the application, even at runtime, with the exception of TransactionLogFilePrefix.

Monitoring and Logging Transactions All transaction information must be logged to track any mishaps or retrieve information from system or network failures. Monitoring and logging transactions per server is a major consideration when talking about JTA transaction parameter configuration and monitoring and logging transactions. When you configure JTA transaction parameters, the configurations apply to all running servers in the domain. However, monitoring and logging is specific to a server, and it doesn’t apply to all servers. (See Figure 5-9.) To view transaction statistics, you must perform the following: 1. Start the Administration Console. 2. Expand the Servers node. 3. Select the server for which you want to observe the transaction statistics.

Figure 5-9.

Monitoring transaction statistics

Chapter 5:

WebLogic and J2EE

4. Select the Monitoring tab. 5. Select the JTA tab. Here, you will see the total of transaction statistics. You can also view the transaction statistics by resource or name, or monitor all active transactions. To view transaction statistics by name, click Monitor All Transactions By Name. This will provide the requested information, as shown in Figure 5-10. To set log file prefixes, as shown in Figure 5-11, complete the following steps: 1. Start the Administration Console. 2. Expand the Servers node. 3. Select the server for which you want to observe transaction statistics. 4. Select the Logging tab. 5. Select the JTA tab on the Logging tab. 6. Specify the Transaction Log File Prefix for the server. 7. Click Apply.

Figure 5-10.

Monitoring transaction statistics by name

163

164


Figure 5-11.

Setting log file prefix

The default path is ./ (the current directory), which you can further customize according to your requirements and environment setting discipline.

ENTERPRISE APPLICATIONS Enterprise applications are the lifeblood of your business—they bring employees together to collaborate and share information and provide vital links to customers, partners, and suppliers. You rely on these applications for fast, easy access to the information you need to make informed business decisions and to maintain the highest levels of customer satisfaction. Enterprise applications are built by leveraging J2EE technologies to the center of it all, EJB. EJBs are the reusable Java components that implement business logic and enable you to develop distributed business applications using component-based architecture. EJB components comprise the following: •

Remote interface

•

Home interface

•

Bean class

Following are the types of EJBs: •

Stateful session beans

•

Stateless session beans

Chapter 5:

•

•

WebLogic and J2EE

Entity beans, which contain •

Container-managed persistent EJB

•

Bean-managed persistent EJB

Message-driven beans

WebLogic provides various tools for creating and configuring EJBs: •

Ant (a Java-based build tool) enables you to create skeleton deployment descriptors

•

WebLogic Builder

•

EJBGen

•

weblogic.Deployer

•

WebLogic EJB deployment descriptor editor

•

BEA XML Editor

As an administrator, your role doesn’t involve designing, developing, testing, or packaging EJB applications. You are required to deploy, configure, and administer the applications on the WebLogic application server. However, you will need to have a fair amount of knowledge about the architecture of enterprise applications, EJBs, JNDI, JDBC, and all other related areas that are involved in deploying and configuring EJBs.

WEBLOGIC REMOTE METHOD INVOCATION RMI is a Java-oriented technology used to implement applications using a client/server framework. Typically, a client needs to obtain socket connection and to listen for connections. However, with WebLogic, the client runtime does not have implementation of server sockets, and therefore does not have to listen for connections. Rather, it obtains these connections through WebLogic Server, which ensures that only the server is aware of client sockets. Hence, whenever intending to host a remote object on the client, you must connect the client to WebLogic Server. WebLogic Server processes requests on behalf of the client. WebLogic Server hosts the RMI registry and provides server infrastructure for RMI clients. The overhead for the RMI registry and server communications is minimal because registry traffic is multiplexed over the same connection as JDBC and other kinds of traffic. Clients use a single socket for RMI; scaling for RMI clients is linear in the WebLogic Server environment. The WebLogic RMI registry is created when WebLogic Server starts up and calls to create new registries by simply locating the existing registry. Objects that have been bound in the registry can be accessed with a variety of client protocols, including the standard rmi://, as well as http:// or https://. In fact, all the naming services use JNDI. For generating and compiling remote objects, WebLogic provides a tool called WebLogic RMI compiler (weblogic.rmic). It is a command-line utility that can be

165

166


invoked after appropriate CLASSPATH settings. Use weblogic.rmic to generate dynamic proxies on the client side for custom remote object interfaces in your application and provide hot code generation for server-side objects. Table 5-1 lists the weblogic.rmic compiler options. Option

Description

-help

Prints a description of all the available options.

-version

Prints version information for the WebLogic RMI compiler.

-dispatchPolicy

Specifies a configured execute queue that the service should use to obtain execute threads in WebLogic Server.

-idl

Generates IDLs (Interface Definition Language) for remote interfaces.

-idlOverwrite

Overwrites existing IDL files, if any exist.

-idlVerbose

Displays verbose information for IDL information.

-idlStrict

Generates IDL according to the Object Management Group (OMG) standard.

-idlNoFactories

Prevents generation of factory methods for value types.

-idlDirectory

Specifies the directory where IDL files will be created (default is current directory).

-clusterable

Marks the service as clusterable (can be hosted by multiple servers in a WebLogic Server cluster). Each hosting object, or replica, is bound into the naming service under a common name. When the service stub is retrieved from the naming service, it contains a replica-aware reference that maintains the list of replicas and performs load balancing and fail-over between them.

-loadAlgorithm

Used only in conjunction with -clusterable. Specifies a service-specific algorithm to use for load balancing and fail-over (default is weblogic.cluster.loadAlgorithm). Must be round robin, random, or weight based.

-callRouter

This cluster-specific option used in conjunction with -clusterable specifies the class to be used for routing method calls. This class must implement weblogic.rmi.cluster.CallRouter. If specified, an instance of the class is called before each method call and can designate a server to route to based on the method parameters. Returns a server name or null. Null means that you use the current load algorithm.

-stickToFirstServer

This cluster-specific option is used in conjunction with -clusterable to enable “sticky” load balancing. The server chosen for servicing the first request is used for all subsequent requests.

-methodsAreIdempotent

This cluster-specific option used in conjunction with -clusterable indicates that the methods on this class are idempotent (ideal). It allows the stub to attempt recovery from any communication failure, even if it cannot ensure that failure occurred before the remote method was invoked. By default (if this option is not used), the stub retries only on failures that are guaranteed to have occurred before the remote method was invoked.

Table 5-1.

WebLogic Remote Method Invocation Compiler (RMIC) Options

Chapter 5:

WebLogic and J2EE

Option

Description

-replicaListRefreshInterval <seconds>

This cluster-specific option used in conjunction with -clusterable specifies the minimum time to wait between attempts to refresh the replica list from the cluster (default is 180 seconds).

-iiop

Generates IIOP stubs from servers.

-iiopDirectory

Specifies the directory where IIOP proxy classes are written.

-commentary

Emits commentary.

-nomanglednames

Causes the compiler to produce proxies specific to the remote class.

-keepgenerated

Allows you to keep the source of generated stub and skeleton class files when you run the WebLogic RMI compiler.

Table 5-1.

WebLogic Remote Method Invocation Compiler (RMIC) Options (continued)

You need to perform the following steps to write your own RMI classes: 1. Write a remote interface. 2. Implement the remote interface. 3. Compile the Java class. 4. Compile the implementation class using the RMI compiler: $ java weblogic.rmic examples.rmi.hello.HelloImpl 5. Write client code that invokes remote methods.

WEBLOGIC RMI-IIOP Java programs can communicate over the network using an RMI framework in which the Java client and server run on a JVM (Java Virtual Machine) on different computers. Java RMI has been designed specifically for Java-to-Java communication. At times, a Java program needs to be designed to communicate with non-Java programs, such as the one designed according to CORBA specifications and written using such language as C++. Internet-Inter ORB Protocol (IIOP) extends RMI, which makes it possible for Java programs to communicate with CORBA clients and execute methods of CORBA objects. RMI is an easy way of programming distributed applications, but with it, we cannot achieve interoperability. However, with CORBA, we can achieve interoperability, as well as addresses more complex distributed application development issues. The ideal scenario would be to bring together the best of both worlds. RMI-IIOP makes use of the RMI programming model and JNDI for locating objects. One issue that always needs to be addressed is security and authentication. How would you take care of client identity when there is a lack of standards for propagating client identity? With WebLogic, the default identity of a client wanting to connect over IIOP is GUEST. Still, we have one provision to set the username and password within

167

168


config.xml file. However, this imposes a restriction of a single identity for all clients connecting over IIOP. The following settings are required in config.xml for CORBA clients to communicate with WebLogic Server: •

DefaultIIOPUser

•

DefaultIIOPPassword

•

IIOPEnabled

The following code snippet extracted from config.xml will help you understand how to apply these parameters. One note about IIOPEnabled is that it is set to true by default. Therefore, you will first need to set this to false in config.xml before disabling IIOP. <Server Name="myserver" NativeIOEnabled="true" DefaultIIOPUser="KeyMan" DefaultIIOPPassword="Test123" ListenPort="7001">

For supporting RMI-IIOP with WebLogic Server, you don’t need any additional configuration—except it is important to note that all remote objects must be bound to the JNDI tree. WebLogic JNDI tree configuration will be explained later in this chapter in the section “Viewing the JNDI Tree.”

WEBLOGIC JMS JMS is a messaging service that is centered on the concept of destination. When you send a message, it is not delivered to the recipient directly; instead, it is delivered to the destination. Any user who wants to read the message must connect to the messaging service to get the message; or the consumer can subscribe at the destination, meaning that the message is sent to the destination and is then forwarded to the consumer, as shown in the following illustration:

JMS Application A JMS application comprises the following components: •

JMS client

Chapter 5:

•

Non-JMS client

•

Messages

•

JMS providers

•

Administered objects

WebLogic and J2EE

JMS clients are Java programs developed to send and receive messages. If the organization already has an existing messaging system and services that predate JMS, clients will be designed to use the native messaging system’s API instead of JMS. In such a situation, you would have to work with both JMS and non-JMS clients. Messages are application specific and can be used for intercommunicating information by its clients. Messaging systems are also known as Message-Oriented-Middleware. These enable Java clients to consume services by providing a layer called JMS Provider that implements JMS for specific products. Administered objects are preconfigured JMS objects created by an administrator for use by clients.

Configuring JMS As an administrator, you are required to define the following configuration attributes with the aid of the Administration Console: •

Enable JMS.

•

Create a JMS server.

•

Create and configure values for the JMS server, connection factories, destinations (queues and topics), destination templates, destination sort order, persistent stores, session pools, and connection consumers.

•

Set up custom JMS applications.

•

Define thresholds and quotas for applications.

•

Enable required JMS features such as server clustering, concurrent message processing, destination sort ordering, persistent messaging, and message paging.

You can configure the following using the Administration Console, as shown in Figure 5-12: •

JMS server

•

Connection factories

•

Templates

•

Destination keys

•

Stores

•

Virtual destinations

169

170


Figure 5-12.

JMS configuration attributes

Configuring the JMS Server The JMS server is the component that manages connections and message requests on behalf of clients. To configure a new JMS server, you are required to do the following: 1. Start up the WebLogic Administration Console. 2. Locate the JMS node and expand it. 3. Right-click the Servers node. 4. Click Configure New JMS Server. 5. Supply values for parameters such as the name of the JMS server, and the persistent store, paging store, and temporary template. 6. Once you have supplied values for all the parameters, click Create to create the new JMS server.

WEBLOGIC JNDI A naming service is the means by which names are associated with objects, and objects in the system can be located with the help of these names. It is a primary facility in any computing system. Simply speaking, when you want to read your resume, you specify a filename such as RESUME.DOC, and the operating system knows what file you mean when you call it up.

Chapter 5:

WebLogic and J2EE

Usually, you’ll find that naming services are extended by another useful service called a directory service. The directory service allows the object to be looked up by its name and also allows the object to have attributes. The simplest way to understand a directory object is in context. For example, a directory object in a computing environment can be useful in representing a printer, a person, a computer, or a network. Each directory object has respective attributes that represent the object itself. A directory service, then, is a service that exposes various functionalities for creating, adding, removing, and modifying the attributes associated with directory objects in a directory. JNDI (Java Naming and Directory Interface) provides an interface that allows us to use existing naming services such as LDAP (Lightweight Directory Access Protocol) and DNS. With the help of JNDI, it is possible for components in distributed applications to locate each other. In the simplest terms, think of a client application wanting to locate and execute methods of a remote object running on a remote system on the network. The client application can query the JNDI and lookup for the remote object’s location, and, upon gaining the necessary information, it can execute a method of a remote object on a remote server machine.

Viewing the JNDI Tree As an administrator, you must be aware of the usefulness of JNDI, viewing the JNDI tree, and loading an object in the JNDI tree. To view the JNDI tree, you must do the following: 1. Start WebLogic Administration Console. 2. Select a domain from the navigation pane. 3. Expand the Servers node. 4. Right-click a server and choose View JMDI Tree. Figure 5-13 shows the contents of the JNDI tree.

Figure 5-13.

Contents of the JNDI tree

171

172


The tree can be used to browse the naming for the selected server. The information contained in the tree-naming context and bound objects can be useful in developing and debugging applications. To understand this further, let us expand the WebLogic naming tree node, where we will further expand the JDBC node. JDBC naming context contains bound objects called JDBCServices. The information pertaining to JDBCServices, such as bind name and class name, it’s toString() version, and hash code, is presented. This information can be useful in developing and debugging applications.

Loading Objects in the JNDI Tree You need to use the Administration Console to load various J2EE services and components, such as RMI, EJB, JMS, and JDBC Data Sources, into the JNDI tree. To load an object in a JNDI tree, you must select the name under which you want the object to appear. You will then be required to provide the name in the JNDI Name attribute field when you create the object. Once the object is loaded in the virtual machine, it is the responsibility of JNDI to provide a path to the object. Let’s consider configuring a JDBC data source and associating it with the JNDI name. A JDBC data source is an object bound to the JNDI tree that points to a JDBC connection pool or MultiPool. Applications can use a JDBC data source to get a database connection from a connection pool or MultiPool. Carry out the following steps to create a JDBC data source and load the object into the JNDI tree: 1. Start WebLogic Administration Console. 2. Expand the Domain node and further expand the Services node. 3. In the left pane, click to expand the JDBC node. 4. Click the Data Sources node. The data sources table in the right pane shows all the data sources defined in your domain. If no data sources are defined, you can always configure a new one by clicking the link provided in the right pane. 5. When you click Configure A New JDBC Data Source Text, a dialog box will display in the right pane, showing the tabs associated with configuring a new data source. 6. Enter values in the Name, JNDI Name, and Pool Name attribute fields. 7. Click Create to create a data source with the attributes you specified on the Configuration tab. The new data source will be added under the Data Sources node in the left pane. 8. Click the Targets tab and complete the following steps for the Servers and Clusters tabs. 9. Select one or more target servers in the Available column to which you want to assign the data source.

Chapter 5:

WebLogic and J2EE

10. Click the right arrow to move the target servers you selected to the chosen column. 11. Click Apply to save your changes.

USING XML WITH WEBLOGIC XML is a subsystem of WebLogic Server. It allows us to use standard parsers, WebLogic FastParser, XSLT Transformer, Document Type Definitions (DTDs), and XML schemas for converting and processing XML files.

About XML XML’s main purpose is the interchange of hierarchical data. XML makes it easier for different companies, different departments within the same company, different applications, or even different portions of the same program to communicate in a well-ordered, yet flexible way. For example, let’s say that you’d like to send your client an invoice. Ideally, you’d like to send it electronically from your accounting software so that your client can easily import it into their system. How would you go about doing this? You could send the information as an Adobe Acrobat document, a Microsoft Word file, or a plain text file. Although this is convenient for humans, it isn’t as easy for a computer to extract information from any of these formats. You could also work with the client’s accounting department to come up with a custom format, such as a comma-delimited file. However, what happens if the client later decides to change the file format to accommodate another vendor? You’ll have to make changes to your invoice generator program as well. XML offers a solution. Your accounting program can e-mail your client a copy of the invoice in XML, which your the client could then read into her own system. Because XML is flexible and fairly forgiving, minor changes to the format won’t make the two systems unable to exchange information. XML is a new way to transmit structured data over the Web. XML works closely with data. It describes and represents data. XML is a meta-language, and we can use it to define different tag-based languages. Although XML is not a solution in itself, it is used to define solutions. Languages such as WML, MathML, DickML, and JaneML are designed and developed using XML standards and concepts. Here are the main reasons for a wide acceptance of XML: •

It is the universal data format for integrated electronic business solutions.

•

It provides self-describing data—the key to success.

•

It provides complete integration of all traditional databases and formats.

•

It performs modifications to data presentation—no reprogramming required.

•

It has a one-server view of distributed data.

•

It allows for internationalization.

173

174


•

It is open and extensible.

•

It is a future-oriented technology.

XML and WebLogic WebLogic uses XML as its main source for storing and documenting configuration information within XML files—for example, web.xml and config.xml. WebLogic also has support for XML applications that require one or more XML parsers to be installed on your system. When the XML application needs to parse and transform XML documents, by default, a built-in XML parser and transformer is used. However, it is possible for you to make use of an external parser and transformer if you configure the XML Registry to accommodate this.

The XML Registry Simply speaking, an XML Registry is a data management system that is responsible for managing and providing various services for XML components. By XML components, we mean schemas (DTD and XSD), style sheets (XSL), and instance documents (WSDL, WSFL and XML). The XML Registry can be used to obtain an XML component automatically, to search or browse for an XML component, to deposit an XML component with or without related data, and to register an XML component without deposit. Being an administrator, you are required to create, configure, and use the XML Registry with the help of the Administration Console. You can also manipulate the config.xml file to administer the XML Registry, but that means you need to dig into the file details, which presents you with a lot more complex possibilities to explore. The Administration Console makes your life simpler. Following are the benefits of using the XML Registry: •

The changes you make to the configuration of the XML Registry can be dynamically applied and activated, but you must be using Java API for XML Processing (JAXP) in your XML application in order for this to be the case.

•

XML application code doesn’t have to be changed when you make changes to the XML Registry.

•

You can use the XML Registry to specify a local copy of an entity or you can specify that WebLogic Server cache a copy of the entity from the Web for a specific duration and utilize the cached copy.

How the XML Registry Works The XML Registry is the system through which organizations can submit and register their XML documents. Registered organizations can submit and register their XML documents with help of a contact (a submitter of the XML document). This registry can be accessed by anyone authorized to pick up registered documents based on the metadata information. With WebLogic Server, it is possible to register any number of XML Registries with the exception that only one registry can be associated with

Chapter 5:

WebLogic and J2EE

a particular instance of WebLogic Server. In such situations, the WebLogic Server running the XML application will make use of a built-in parser and transformer for XML components. After you have the XML Registry associated with an instance of WebLogic Server, your XML applications that use WebLogic Server will have all configurable options made available. Two types of entries can be configured in an XML Registry: •

Parsers and transformers

•

External entity resolution

Configuring the Parser and Transformer WebLogic Server 7 has a built-in parser called Apache Xerces and a transformer called Apache Xalan. Apache Xerces and Xalan are the default parser and transformer for WebLogic XML applications. WebLogic supports only the following versions of the Xerces parser: •

Xerces 1.2.2

•

Xerces 1.2.3

•

Xerces 1.3.0

•

Xerces 1.3.1

•

Xerces 1.4.0

•

Xerces 1.4.1

•

Xerces 1.4.2

•

Xerces 1.4.3

•

Xerces 1.4.4

NOTE If you are intending to use a default parser and transformer for your XML applications, you won’t need to perform the configuration tasks explained in this section. To view the parser for your XML applications, you must do the following: 1. Start WebLogic Server and invoke the Administration Console. 2. Expand the XML node, which will display a list of XML Registries already created and available. To configure a new XML Registry for your XML applications: 1. Start WebLogic server and invoke the Administration Console. 2. Right click the XML node and select Configure A New XML Registry. 3. You’ll see a page where you can input the necessary information to be stored as the new XML Registry for XML applications, as shown in Figure 5-14.

175

176


Figure 5-14.

New XML Registry configuration

4. The first input required for the new XML Registry is the name of the registry, which must be unique. The default provided is MyXML Registry, which can be changed to MyXercesXML Registry. 5. You can change the following additional parameters (shown here with values) that affect the document builder, parser, and transformer: •

DocumentBuilderFactory Weblogic.apache.xerces.jaxp .DocumentBuilderFactoryImpl

•

SAXParserFactory

•

Transformer Factory

•

When To Cache Select one of three values from the drop-down box: Cache-On-Reference (our default selection), Cache-At-Initialization, or Cache-Never.

Weblogic.apache.xerces.jaxp.SAXParserFactoryImpl Weblogic.apache.xalan.processor.TransformerFactoryImp

6. After confirming the creation process of the new XML Registry, the associated administrative applet will refresh the navigation tree in the left pane and will list the newly created and configured XML Registry, as shown in Figure 5-15. If we use Apache parsers and transformers instead of WebLogic defaults, we can create another XML Registry that will expose these for use in XML applications. Table 5-2 lists the parameters and associated values.

Assigning an XML Registry to an Application After we have created and configured the XML Registry with the parser and transformer we intend to use for our XML applications, the next step is to configure the application

Chapter 5:

Figure 5-15.

WebLogic and J2EE

New XML Registry configuration screen

server that will make use of the XML Registry and the information contained within it. To perform these settings, do the following: 1. Select the server from the Servers node (in our case, ExamplesServer). 2. Select the Services tab in the right pane. 3. On the Services tab, select the XML tab that specifies the name of the XML Registry currently assigned for use to our server. As more than one registry has been created, we can change the XML Registry for our server. From the XMLRegistry drop-down menu, select MyApacheXML Registry, as shown in Figure 5-16.

Parameter

Value

Name DocumentBuilderFactory SAXParserFactory Transformer Factory When To Cache

MyApacheXML Registry org.apache.xerces.jaxp.DocumentBuilderFactoryImpl org.apache.xerces.jaxp.SAXParserFactoryImpl org.apache.xalan.processor.TransformerFactoryImpl Cache-At-Initialization

Table 5-2.

Apache Xerces Parser and Transformer Configured in a New XML Registry

177

178


Figure 5-16.

The newly created XML Registry is listed in the navigation tree.

NOTE You need to restart the server to see the effects of the changes you make. How do you know whether or not to restart the server? Carefully look at the interface of the Administration Console once you’ve applied the changes. If the change requires you to restart the server or if you have to manipulate some parameter that will not impact until you restart the server, you will see a flashing exclamation symbol within a triangle.

Looking at Changes in config.xml So far, we have created and configured XML Registry information with the help of the Administration Console. Whenever you make changes using the Administration

Chapter 5:

WebLogic and J2EE

Console, the WebLogic configuration file config.xml is updated in the background with the information provided and applied. You may observe these changes for the newly created XML Registry by opening this file in any of your favorite editors. <XMLRegistry DocumentBuilderFactory="org.apache.xerces.jaxp.DocumentBuilderFactoryImpl" Name="MyApacheXML Registry" SAXParserFactory="org.apache.xerces.jaxp.SAXParserFactoryImpl" TransformerFactory="org.apache.xalan.processor.TransformerFactoryImpl" WhenToCache="cache-at-initialization" /> <XMLRegistry Name="MyXercesXML Registry" /> <XMLRegistry Name="examplesXMLRegistry">

These code snippets, extracted from a config.xml file, demonstrate and support the XML Registry task we just performed. In the first tag for the XML Registry are a lot of additional parameters and values; for the remaining two tags, there is no additional information. WebLogic will understand that it is supposed to use a default parser and transformer when no information is available in the XML Registry tag. For practice, you can try to add one more XML Registry tag in the config.xml file and then restart your server. You will see the new manually added XML Registry in the Administration Console (see Figure 5-17).

Configuring the Parser for a Particular Document Type The purpose behind configuring the parser for a particular document type is for you to use the document’s system ID, public ID, or root element tag for identifying the document type. Consider that WebLogic Server will search for only the first 1000 bytes of an XML document when it is identifying its document type. If it doesn’t find the DOCTYPE identifier in the first 1000 bytes, it will use the parser that you have configured for parsing XML documents. To configure the parser for a particular document type, perform the following steps: 1. Start the WebLogic administration server and invoke the Administration Console in your browser at http://localhost:7001/console. You will be required to provide a user ID and password for working as an administrator. 2. In the left pane, under MyDomain, right-click the XML node under the Services node. Then select Configure A New XML Registry from the drop-down menu. 3. You will now be required to provide information, including the unique registry name in the Name field. If you intend to configure default parsers and transformers for your server, provide the factory class names in the DocumentBuilderFactory, SaxParserFactory, and Transformer Factory fields. (These fields are optional.) 4. Click the Create button to create the XML Registry. The XML Registry is created and the same will be listed under the XML node in the left pane.

179

180


Figure 5-17.

The Administration Console after manually configuring config.xml

5. Now provide document type information. Right-click the XML Parser Select Registry entry node under the XML Registry node, which is under the XML node in the left pane. Select Configure A New XMLParserSelectRegistryEntry from the drop-down menu and provide the document type information in the window that appears in the right pane, shown in Figure 5-18. 6. There are two ways to enter the document type information: •

You may use either the Public Id or the System Id field to specify the document type. For example, for car.xml, enter -//BEA Systems, Inc.// DTD for cars//EN in the Public Id field. You can confirm this in the following listing of the car.xml file. <JDBCConnectionPool CapacityIncrement="1" DriverName="com.pointbase.jdbc.jdbcUniversalDriver" InitialCapacity="1" MaxCapacity="10" Name="petstorePool" Password="petstore" Properties="user=petstore" RefreshMinutes="0" ShrinkPeriodMinutes="15" ShrinkingEnabled="true" Targets="petstoreServer" TestConnectionsOnRelease="false" TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost/demo" /> <JDBCConnectionPool CapacityIncrement="1" DriverName="com.pointbase.jdbc.jdbcUniversalDriver" InitialCapacity="1" MaxCapacity="10" Name="petstoreopcPool" Password="petstoreopc" Properties="user=petstoreopc" RefreshMinutes="0" ShrinkPeriodMinutes="15" ShrinkingEnabled="true" Targets="petstoreServer"

Appendix C:

A Real-Life Server Configuration

TestConnectionsOnRelease="false" TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost/demo" /> <JDBCConnectionPool CapacityIncrement="1" DriverName="com.pointbase.jdbc.jdbcUniversalDriver" InitialCapacity="1" MaxCapacity="10" Name="petstoresupplierPool" Password="petstoresupplier" Properties="user=petstoresupplier" RefreshMinutes="0" ShrinkPeriodMinutes="15" ShrinkingEnabled="true" Targets="petstoreServer" TestConnectionsOnRelease="false" TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost/demo" /> <JDBCTxDataSource EnableTwoPhaseCommit="true" JNDIName="datasource-petstorePool" Name="PetstoreDataSource" PoolName="petstorePool" Targets="petstoreServer" /> <JDBCTxDataSource EnableTwoPhaseCommit="true" JNDIName="datasource-petstoreopcPool" Name="PetstoreOPCDataSource" PoolName="petstoreopcPool" Targets="petstoreServer" /> <JDBCTxDataSource EnableTwoPhaseCommit="true" JNDIName="datasource-petstoresupplierPool" Name="PetstoreSupplierDataSource" PoolName="petstoresupplierPool" Targets="petstoreServer" /> <JDBCTxDataSource EnableTwoPhaseCommit="true" JNDIName="jdbc/CatalogDataSource"

393

394


Name="CatalogDataSource" PoolName="petstorePool" Targets="petstoreServer" /> <JMSConnectionFactory JNDIName="jms/QueueConnectionFactory" Name="Queue" Targets="petstoreServer" XAServerEnabled="true" /> <JMSConnectionFactory JNDIName="jms/TopicConnectionFactory" Name="Topic" Targets="petstoreServer" /> <JMSJDBCStore ConnectionPool="petstorePool" Name="petstoreJDBCStore" PrefixName="petstore" /> <JMSServer Name="examplesJMSServer" Store="petstoreJDBCStore" Targets="petstoreServer" > <JMSQueue JNDIName="jms/ASYNC_SENDER_QUEUE" Name="JPS_ASYNC_SENDER_QUEUE"/> <JMSQueue JNDIName="jms/opcApplication/SUPPLIER_PO_MDB_QUEUE" Name="SUPPLIER_PO_MDB_QUEUE"/> <JMSQueue JNDIName="jms/opcApplication/ORDER_APPROVAL_MDB_QUEUE" Name="ORDER_APPROVAL_MDB_QUEUE"/> <JMSQueue JNDIName="jms/opcApplication/JPS_ORDER_QUEUE" Name="JPS_ORDER_QUEUE"/> <JMSQueue JNDIName="jms/opcApplication/customerrelations/ CR_MAIL_ORDER_APPROVAL_MDB_QUEUE" Name="CR_MAIL_ORDER_APPROVAL_MDB_QUEUE"/> <JMSQueue JNDIName="jms/opcApplication/MAILER_MDB_QUEUE" Name="MAILER_MDB_QUEUE"/> <JMSQueue

Appendix C:


JNDIName="jms/Queue" Name="Queue"/> <JMSTopic JNDIName="jms/opcApplication/INVOICE_MDB_TOPIC" Name="INVOICE_MDB_TOPIC"/> <JMSTopic JNDIName="jms/Topic" Name="Topic"/> <MailSession JNDIName="mail/JPSMailSession" Name="PetstoreMailSession" Properties="mail.user=joe;mail.host=mail.mycompany.com" Targets="petstoreServer" />

<Application Deployed="true" Name="tour" Path="C:/bea/weblogic700/samples/server/stage/petstore"> <WebAppComponent Name="tour" Targets="petstoreServer" URI="tour.war" /> <Application Deployed="true" Name="petstore" Path="C:/bea/weblogic700/samples/server/stage/petstore/petstore.ear" TwoPhase="true"> <EJBComponent Name="asyncSenderEjb" Targets="petstoreServer" URI="asyncSenderEjb.jar"/> <EJBComponent Name="cartEjb" Targets="petstoreServer" URI="cartEjb.jar"/> <EJBComponent Name="catalogEjb" Targets="petstoreServer" URI="catalogEjb.jar"/> <EJBComponent Name="customerEjb" Targets="petstoreServer"

395

396


URI="customerEjb.jar"/> <EJBComponent Name="petstoreEjb" Targets="petstoreServer" URI="petstoreEjb.jar"/> <EJBComponent Name="signonEjb" Targets="petstoreServer" URI="signonEjb.jar"/> <EJBComponent Name="uidgenEjb" Targets="petstoreServer" URI="uidgenEjb.jar"/> <WebAppComponent Name="petstore" Targets="petstoreServer" URI="petstore.war"/> <Application Deployed="true" Name="petstoreadmin" Path= "C:/bea/weblogic700/samples/server/stage/petstore/petstoreadmin.ear" TwoPhase="true"> <EJBComponent Name="asyncSenderEjb" Targets="petstoreServer" URI="asyncSenderEjb.jar"/> <WebAppComponent Name="petstoreadmin" Targets="petstoreServer" URI="petstoreadmin.war"/> <Application Deployed="true" Name="petstoreopc" Path="C:/bea/weblogic700/samples/server/stage/petstore/opc.ear" TwoPhase="true"> <EJBComponent Name="mailerEjb" Targets="petstoreServer" URI="mailerEjb.jar"/> <EJBComponent Name="opcEjb" Targets="petstoreServer" URI="opcEjb.jar"/> <EJBComponent

Appendix C:


Name="poEjb" Targets="petstoreServer" URI="poEjb.jar"/> <Application Deployed="true" Name="petstoresupplier" Path= "C:/bea/weblogic700/samples/server/stage/petstore/supplier.ear" TwoPhase="true"> <EJBComponent Name="suppPOEjb" Targets="petstoreServer" URI="suppPOEjb.jar"/> <EJBComponent Name="supplierEjb" Targets="petstoreServer" URI="supplierEjb.jar"/> <WebAppComponent Name="supplier" Targets="petstoreServer" URI="supplier.war"/> <Server JavaCompiler="C:/bea/jdk131/bin/javac" ListenPort="7001" Name="petstoreServer" IIOPEnabled="false" > <ExecuteQueue Name="default" ThreadCount="15" /> <WebServer DefaultWebApp="tour" LogFileName="logs/access.log" LoggingEnabled="true" Name="petstoreServer" /> <SSL ListenPort="7002" ServerCertificateFileName="democert.pem" ServerPrivateKeyAlias="demokey" ServerPrivateKeyPassPhrase="pkpassword" Enabled="true"

397

398


/> <StartupClass Arguments="port=7001" ClassName="com.bea.estore.startup.StartBrowser" FailureIsFatal="false" Name="StartBrowser" Targets="petstoreServer" Notes="On Windows, this class automatically starts a browser after the server has finished booting." /> <ShutdownClass ClassName="com.bea.shutdown.stopPointBaseServer" Name="StopPointBaseServer" Targets="petstoreServer" Notes="This class automatically stops PointBase when the server is shut down." />

GLOSSARY Access Control List (ACL) Used to authenticate users and manage access to network services. The WebLogic implementation of ACLs is based on the java.security.acl package. Each entry in an ACL contains a set of permissions associated with a particular principle. Applet A client-side Java program, usually embedded in an HTML page and viewed with a Web browser. Application A J2EE application is a J2EE-compliant program that encompasses business logic and needs a J2EE-compliant application server such as WebLogic Server to run it. Authentication Used to verify the identity of a user or computer. Also the technology that guarantees the source of information to a recipient. Authorization A process for checking the permissions for a user, group of users, or a machine to a given resource on the system. BEA Systems The company that makes WebLogic Server. Bytecode A compiled Java program that can be run (interpreted) on any computer with a Java Virtual Machine (JVM). CAB Microsoft version of storing data in compressed format. CAB stands for Cabinet files.


399

400

CLASSPATH

CLASSPATH The Java runtime needs to locate classes to execute them. The locations where JRE can look for these classes are defined in an operating system variable called CLASSPATH. Cluster A group of multiple WebLogic Server instances that behave like a single logical unit. Configuration Repository An XML file named config.xml that contains the entire configuration information for a WebLogic domain. config.xml is required only to start WebLogic Server. A managed server gets its configuration from WebLogic Server. Console A Web application provided by BEA that is an integral part of WebLogic Server. It is a complete GUI-based application for configuring, managing, and administering a WebLogic domain. Credential Defines the level of access that the user or application has to the resource. DBMS Database Management Systems; typically used as a repository or warehouse for holding data. Applications can store transactional data and retrieve presentation data to/from databases using the DBMS. Deployment A process of making a J2EE application available to the external world by deploying the application on a J2EEcompliant application server such as WebLogic Server. DLL Dynamically Linked Library. A DLL is a library module containing a collection of classes or functions that can be dynamically used by applications at runtime. EAR A type of JAR (Java Archive) file that is used to package one or more EJB modules, Web application modules, JCA resource adapter modules, and application client modules. EJB Server-side JavaBean middle-tier components holding business rules. EJB components are deployed in the EJB container, such as WebLogic Server, IBM WebSphere Server, and so on. Encryption Computer encryption is based on the science of cryptography. It is a mechanism useful in safeguarding data while it travels over the wire. The two types of encryption are symmetric and asymmetric.

Load Balancing

Garbage Collector (GC) Java provides a mechanism that automatically performs memory management activities and releases programmers from doing the same from within the programs. Garbage Collector is a background process that performs dynamic allocation and deallocation of memory to Java applications and objects at runtime. Groups A number of users in a WebLogic domain can be classified into various groups. A group represents a group of WLS users that have similar authorization credentials. Hypertext Transfer The primary protocol of the Web. The Hypertext Transfer Protocol (HTTP) Protocol is an application-level protocol that is most appropriate for distributed, collaborative, hypermedia information systems. HTTPS The secured version of HTTP. It uses Secure Sockets Layer (SSL) for sending encrypted data over the wire. JAR Java Archive files are used for packaging application modules. You can bundle almost any type of file in the JAR. JAR is the utility available for packaging or unpacking application modules and files. Java Management Sun’s specification to manage applications written in the Extension (JMX) Java language. Java Virtual Machine The runtime environment for executing Java bytecodes. (JVM) It is the component technology that provides hardware and software independence. It is an abstract computing machine. JavaBeans JavaBean component architecture is useful for manufacturing “Write Once Run Anywhere” reusable components using the Java programming language. JDBC A technology and Java standard for accessing data from any relational database from the Java programming language. Load Balancing A technique used to distribute the load evenly across various devices available in the cluster over the network so that no single device is overwhelmed with the requests to be served. Distributed processing and communications activity is evenly distributed across a computer network.

401

402

Management Beans (MBeans)

Management Beans Special JavaBeans as described in the JMX specification that (MBeans) represent management attributes for a resource or Java program. Multicast Multicasting is transmitting a single message to selected multiple recipients. It is not the same as broadcasting, which is sending a single message to everyone. If you have information (a lot of information, usually) that should be transmitted to various (but usually not all) hosts over an Internet, you would use a multicast. A simple example of a multicast is sending an e-mail message to a mailing list. Facilities such as teleconferencing and videoconferencing use multicasting, which requires more robust protocols and networks. Multithreading The ability of an operating system to execute different parts of programs called threads. Multi-Tier Application The logical hierarchy of business activities represented as Architecture three distinct layers, each performing its role in making applications more manageable. The layers are presentation layer, business layer, and data-source layer. Network A group of interconnected devices such as computer systems, printers, tape devices, laptops, routers, gateways, and so on. Sharing resources and communication remain some of the most important keys to a company’s continued health. Port On computer system and telecommunication devices, generally a specific channel whereby one device can be connected to another device. Systems can have hardware ports or software ports. Hardware ports are physical in nature and are necessary for attaching hardware devices. Software ports helps two software programs communicate over wire. Proxy A resource, person, or agency that has authority to act on behalf of another. Proxy Server A computer program that acts as an intermediary between a Web browser and a Web server. To give users rapid access to popular Web destinations, ISPs use proxy servers as cache engines to store frequently requested pages, rather than going out and fetching them repeatedly from the intra- or internetwork.

WAR

Realm A logical grouping of users, groups, and ACLs (Access Control Lists), it determines the scope of security data. A realm is the region to which a security ID or permission applies. Role The capacity in which a user accesses a resource on the system. RSA Rivest, Shamir, and Adelman. A standard for achieving industry-strength encryption. It implements public key encryption and is developed by RSA Data Security, Inc. Stub/Skeleton An interface between the client and the remote object, the stub helps marshal parameters to the remote reference layer and unmarshal parameters from the remote reference layer. The stub uses object serialization techniques for passing a copy of parameters across components. The stub is a client-site proxy for a remote object. It initiates calls to the remote object. The skeleton is a server-side entity and dispatches calls to the actual remote object implementation. Unicode A standard; a character coding system designed to support the worldwide interchange, processing, and display of the written texts of the diverse languages (English, French, Arabic, Japanese, Chinese, and so on) of the modern world. In addition, it supports classical and historical texts of many written languages. Uniform Resource Typically describes (1) the mechanism used to access the Identifier (URI) resource, (2) the specific computer that the resource is housed in, and (3) the specific name of the resource (a filename) on the computer. Universal Resource The protocol (such as HTTP or FTP), the domain name (or IP Locator (URL) address), and additional path information (folder/file) for a particular location. On the Web, a URL may address a Web page file, an image file, or any other file supported by HTTP. (Example: http://localhost/foryourhome/homefamily.asp.) User An entity that accesses a WebLogic Server instance. WAR Web Application Archive. The archive contains Web application modules packaged as Java servlets, HTML (and support files), and Java Server Pages.

403

INDEX ❖

A

Abandon Timeout Seconds option domain configuration, 83 transactions and JTA configuration parameters, 160 AcceptBackLog attribute, config.xml performance parameters, 264 access decision providers, authorization framework, 190–191 access logs, HTTP, 154–156 ACLs (Access Control Lists), defined, 399 activate command, weblogic.Deployer, 127–129 activation phase, weblogic.Deployer, 129 addresses, multicast. See multicast addresses adjudication providers, authorization framework, 191 adjudicators See also application security; security providers configuration and administration, 200, 201 administered objects, JMS (Java Message Service), 169

administering Web applications, 148–157 See also applications; J2EE components HTTP access logs, 154–156 HTTP parameters, 148–153 Listen Port, 153–154 overview, 148 virtual hosts, 156–157 Administration Console adjudicators, 200, 201 authentication providers, 198–200 authorizers, 201 config.xml file, 60 config.xml file and XML Registry, 179, 180 credential mappers, 201–202 deployment and XML tools, 364 groups, 197 HTTP access logs, 155–156 HTTP parameters, 152 JMS (Java Message Service), 169–170 JNDI (Java Naming and Directory Interface), 172–173 keystores, 203 Node Manager and, 277


405

406


role mappers, 204 roles, 194–195 security providers, 198–200 transactions and JTA configuration parameters, 160–161 users, 196–197 WebLogic JAM (Java Adapter for Mainframe), 357, 358 Administration MBeans, 299 See also MBeans (Management Beans) Administration MBeanHome interface, 300, 301 administration options, WebLogic Console, 77, 78 Administration server, starting in SSL mode, 283–284 administration tools, 305–330 Java utilities, 306–322 overview, 306 summary, 330 weblogic.Admin utility, 323–329 administrative best practices, 387–389 administrative functions, 6–7 failover support, 7 load balancing, 6 proxy servers, 6 security, 6 session management in Web farms, 7 virtual hosting, 6 administrative infrastructure, WebLogic Server, 11–12 AdminMBeanHome interface, MBeans (Management Beans), 297 agent-level specification, JMX (Java Management Extension), 292 AIX platform, installing WebLogic Server, 66–67 AltoWeb Application Platform, 370–372 See also deployment and XML tools; third-party tools TomCat server, 371–372 Apache HTTP Server, described, 6

Apache HTTP Server plug-in, 219 See also HTTP servers Apache Xerces parser and Xalan transformer, XML Registry, 175–176, 177, 179–182 AppletArchiver, 306–309 See also administration tools; Java utilities described, 307 applets, defined, 399 application integration, 332 See also WebLogic Integration application logic layers, J2EE components, 147 application options, domains configuration, 81 application security, 183–205 overview, 184 security providers, 187–204 summary, 204–205 version 7 security model, 184–186 version 7.0 versus version 6.1 security models, 186 application server, 7–11 See also Web server software; WebLogic Server client/server architecture, 8–9, 10 programming frameworks, 9–10 scalability, 9 Application View Console, WebLogic Integration, 347–348 ApplicationMBeans See also MBeans (Management Beans) attributes, 133 deployment management interfaces, 133 weblogic.Deployer, 127 applications See also administering Web applications; J2EE components accessing via proxy plug-ins, 250–251

Index

assigning XML Registry to, 176–178 defined, 399 deploying, 123–144 deploying to cluster targets, 248–249 enterprise, 164–165 JMS (Java Message Service), 168–169 porting from version 6.x to 7.0, 72 archiving, AppletArchiver, 306–309 auditing framework, 192–193 See also application security; security providers convenience AuditEvent interfaces, 192–193 interfaces, 192 overview, 192 authentication defined, 399 troubleshooting tips, 385 authentication framework, 187–188 See also application security; security framework; security providers Identity Assertion providers, 187, 188–189 JAAS LoginModules, 187, 188 Principal Validation providers, 187, 189 authentication providers, Administration Console and, 198–200 authorization, defined, 399 authorization framework, 189–192 See also application security; security providers access decision providers, 190–191 adjudication providers, 191 components, 190 overview, 189–190 parametric authorization, 189 role-mapping providers, 191–192 security policies, 189 authorizers See also application security; security providers configuring and administering, 201

Auto Deployed Enabled option, domains configuration, 81 Auto Update Interval option, domains configuration, 81 auto-deployment, 124–125 See also deployment development environment, 21

❖

B

B2B (business-to-business) integration, 334–335 See also WebLogic Integration balancing. See load balancing banner ads, servlets and, 15 BEA home directory console-mode installation, 51 graphical-mode installation, 42 BEA Systems, defined, 399 bea.home property, startup command scripts, 70 beans clustered EJBs and entity, 241–242 EJB, 17–18 Before Completion Iteration Limit option, domains configuration, 83–84 Before Completion Iteration Limits option, transactions and JTA configuration parameters, 161 best practices, administrative, 387–389 binary converting to XML, 338–339 converting XML to, 338 binding, JNDI (Java Naming and Directory Interface), 236 boot.properties file, starting WebLogic Server, 67 BPM (Business Process Management), 333 See also WebLogic Integration bridges, JMS (Java Message Service) configuration, 112–116

407

408


Builder. See Format Builder; WebLogic Builder bytecode, defined, 399

❖

C

CABs (cabinet files), defined, 399 cache tags, WebLogic Server, 11 campaign management, WebLogic Portal, 356 cancel command, weblogic.Deployer, 131 CANCEL_SHUTDOWN command, weblogic.Admin utility, 327 certificates, starting administration server in SSL mode, 283–284 certificates conversion, Der2Pem and Pem2Der utilities, 322 chat programs, servlets and, 16 Checkpoint Interval Seconds option domains configuration, 84 transactions and JTA configuration parameters, 161 child/parent relationships, MBean servers, 298 CLASSPATH environment variable, 23–24, 62–65 See also installing WebLogic Server clustering and, 252 defined, 400 SETWLSENV.CMD file, 62–64 troubleshooting tips, 384–385 upgrading WebLogic Server, 71 client state maintenance, 158 client/server architecture application server, 8–9, 10 Web server software, 3 clients cluster communication, 235–236 JMS (Java Message Service), 169 Cloudscape DBMS, WebLogic Server, 23–24 cluster communication, 232–237 See also clustering clients, 235–237

IP Multicast (one-to-many), 233–234 IP Socket (peer-to-peer), 234–235 JNDI naming conflicts, 236–237 overview, 232 Cluster Configuration tab, server configuration, 90 cluster deployment, 136–140 See also clustering; deployment cluster setup, 136 config.xml file, 136 deactivate command, 140 deployment phases, 136–140 deployment status, 139–140 Deployment Wizard, 138–140 purging deployment tasks, 140, 141 removing applications, 140 static deployment, 137 undeploy command, 140 WebLogic Console, 137–140 weblogic.Deployer, 137 cluster heartbeats, IP Multicast (one-to-many), 233–234 cluster-wide JNDI updates, IP Multicast (one-to-many), 233 clustered EJBs, entity beans, 241–242 clustering, 229–253 CLASSPATH environment variable, 252 communication, 232–237 config.xml file and cluster configuration, 242–251 defined, 39, 400 deploying applications to cluster targets, 248–249 deployment, 136–140 EJBs, 241–242 failover support, 232 HTTP JSP/servlets, 237–240 J2EE, 237–242 JMS (Java Message Service), 242 JSP. See HTTP JSP/servlets clustering licenses, 251 load balancing, 230–231 multicast addresses and, 252

Index

object, 241–242 overview, 230 parameter-based routing, 232 rules for services, 243 server configuration, 96 server versions and, 251 servlets. See HTTP JSP/servlets clustering starting clusters, 248 summary, 252–253 thread counts and, 252 troubleshooting, 251–252 clusters defined, 39 monitoring, 273 starting/stopping via Node Manager, 288 command-line tools. See weblogic.Admin utility Community Prefix options, domains configuration, 85 CompileCommand parameter, weblogic.xml file, 256–257 Compilers Configuration tab, server configuration, 93 compiling, troubleshooting tips, 384 ComponentMBeans See also MBeans (Management Beans) attributes, 134 deployment management interfaces, 133 concurrency strategy, weblogic-ejb-jar.xml performance parameters, 267 Configuration MBeans, 299 See also MBeans (Management Beans) configuration repository. See config.xml file Configuration tab, server configuration, 90–93 Configuration Wizard console-mode installation, 53 graphical-mode installation, 43, 44 manually running, 48–49

configuring domains. See domains configuration configuring JDBC. See JDBC configuration configuring servers. See server configuration configuring services. See services configuration config.xml file, 31–33, 60–62 See also WebLogic Server Administration Console, 60 Administration Console and XML Registry, 179, 180 cluster configuration, 242–251 cluster deployment, 136 configuration attributes, 61–62 defined, 400 domains and, 293 IP Socket (peer-to-peer), 234 management architecture, 293 multiple server deployment, 135 performance parameters, 257–265 PET STORE example, 391–398 samples, 32–33, 391–398 static deployment, 133–134 troubleshooting tips, 380 WebLogic Integration, 343 XML Editor tool, 60, 61 XML Registry and Administration Console, 179, 180 XML Registry and viewing changes to, 178–179 config.xml file and cluster configuration, 242–251 See also clustering accessing applications via proxy plug-ins, 250–251 attributes, 242–243 deploying applications to cluster targets, 248–249 multicast addresses, 245, 246 overview, 242 planning cluster configuration, 243 proxy plug-ins, 247, 248 replication groups, 246, 247

409

410


rules for clustering services, 243 server configuration, 244 Server Console, 244–245 starting clusters, 248 config.xml performance parameters, 257–265 See also performance tuning AcceptBackLog attribute, 264 ExecuteQueue attributes, 259–262 JDBCConnectionPool element, 264–265 NativeIOEnabled attribute, 258–259 overview, 257 StuckThreadMaxTime and StuckThreadTimerInterval attributes, 262–263 ThreadPoolPercentSocketReaders attribute, 263–264 connection factories JDBCData Source, 105–106 JMS (Java Message Service) configuration, 106–109 connection pools JDBC configuration, 100, 101 Jolt configuration, 119–120 WLEC configuration, 117–118 Connections tab, 93–96 See also domains configuration; server configuration; WebLogic Console SSL Connections tab, 93, 94 Console Context Path option, domains configuration, 80 Console Enabled option, domains configuration, 80 Console Preferences dialog box, WebLogic Console, 78, 79 Console. See Administration Console; WebLogic Console console-mode installation, 49–53 See also installing WebLogic Server; WebLogic Console BEA home directory, 51 components, 52

Configuration Wizard, 53 installation types, 51–52 product directory, 52–53 consoles, defined, 400 container services, EJB, 18, 19 ControlCenter, 368–370 See also deployment and XML tools; third-party tools convenience AuditEvent interfaces, auditing framework, 192–193 convoying, round-robin load balancing, 231 cookies, client state maintenance, 158 corrupted self-extraction programs, replacing, 385 credential mappers See also application security; security providers configuring and administering, 201–202 credentials, defined, 400

❖

D

data integration, 335–339 See also WebLogic Integration converting binary to XML, 338–339 converting XML to binary, 338 data translation, 335–339 Format Builder, 335–337 XML, 335–339 data sources, 102–106 See also JDBC configuration; services configuration; WebLogic Console JDBCData Source connection factories, 105–106 JNDI (Java Naming and Directory Interface), 102, 103 Tx, 104–105 database configuration, 65 WebLogic Integration, 344–345 database locking, weblogic-ejb-jar.xml performance parameters, 267

Index

database selection, WebLogic Integration, 342 DBMS (Database Management Systems), defined, 400 DBPing utility, 310–312 See also administration tools; Java utilities database configuration and connection, 65 pinging Oracle, 310 deactivate command cluster deployment, 140 weblogic.Deployer, 127, 129–130 Debug Level option, domains configuration, 85 default server name, HTTP parameters, 149 demonstration key and certificates, starting administration server in SSL mode, 283–284 deploy command, weblogic.Deployer, 127–129 DeployDirector, 364–368 See also deployment and XML tools; third-party tools Deployer. See weblogic.Deployer deploying applications to cluster targets, 248–249 deployment, 123–144 See also J2EE components ApplicationMBeans, 133 auto-deployment, 124–125 cluster, 136–140, 248–249 defined, 400 DeployerRuntime class, 143–144 DeploymentData class, 141 DeploymentTaskRuntimeMBean class, 142–143 development environment, 21–22 management interfaces, 133 multiple server, 135 overview, 124 phases, 129, 136–140 purging tasks, 140, 141 static, 133–135

summary, 144 TargetStatus class, 142 tools, 29, 125–132 weblogic.Deployer, 125–132 Deployment Configuration tab, server configuration, 91 deployment options, server configuration, 92, 95 deployment phases cluster deployment, 136–140 weblogic.Deployer, 129 deployment tools, 29 weblogic.Deployer, 125–132 Deployment Wizard, cluster deployment, 138–140 deployment and XML tools, 364–372 See also third-party tools; tools Administration Console, 364 AltoWeb Application Platform, 370–372 EJBGen tool, 364 overview, 364 Sitraka DeployDirector, 364–368 TogetherSoft ControlCenter, 368–370 WebLogic Builder, 364 weblogic.Deployer, 364 deployments configuration, 99 See also domains configuration; WebLogic Console DeployPlugin utility, WebLogic Native Plug-in Tool for ISAPI and NSAPI, 226, 227 Der2Pem utility See also administration tools; Java utilities certificates conversion, 322 destination keys, JMS (Java Message Service) configuration, 110–111 development environment, 20–22 See also WebLogic Server deployment, 21–22 discovery of managed servers, 22 managed servers, 22

411

412


directory service. See JNDI (Java Naming and Directory Interface) directory structure upgrading WebLogic Server, 71 WebLogic Server, 4, 59 discovery of managed servers, development environment, 22 distributed architecture, J2EE components and, 146–147 distributed configuration, WebLogic JAM (Java Adapter for Mainframe), 357 distributed destinations, JMS (Java Message Service) configuration, 111 distributed-services level, JMX (Java Management Extension), 292 DLLs (Dynamic Linked Libraries), defined, 400 domain locations, graphical-mode installation, 45, 46 domain templates, graphical-mode installation, 44 Domain Wide Administration Port option, domains configuration, 81 domains, 293–295 See also management architecture config.xml file and, 293 JMX (Java Management Extension) components, 296 managed servers and, 293 preconfigured, 339, 343–344 starting/stopping via Node Manager, 288 domains configuration, 79–99 See also WebLogic Console Abandon Timeout Seconds option, 83 application options, 81 attributes, 79–87 Auto Deployed Enabled option, 81 Auto Update Interval option, 81 Before Completion Iteration Limit option, 83–84

Checkpoint Interval Seconds option, 84 Community Prefix options, 85 Console Context Path option, 80 Console Enabled option, 80 Debug Level option, 85 deployments configuration, 99 Domain Wide Administration Port option, 81 Enable Domain Wide Administration port option, 80–81 File Count option, 83 File Min Size option, 82 File Name option, 81 Forget Heuristics option, 84 general options, 79–81 JTA options, 83–84 logging options, 81–83 Max Transactions option, 84 Max Unique Name Statistics option, 84 MIB Data Refresh Interval option, 85 mydomain, 79–81 network channel configuration, 97–99 Number of Files Limited option, 83 right-clicking options, 85–87 Rotation Time option, 83 Rotation Type option, 82 server configuration, 87–96 Server Status Check Interval Factor option, 85 Size option, 82 SNMP options, 85, 86 SNMP Port option, 85 Targeted Trap Destinations option, 85 Time option, 82 Timeout Seconds option, 83 duration option, HTTP parameters, 152 dynamic deployment, development environment, 21

Index

❖

E

e-business platform, 351–361 eLink, 352 overview, 352 summary, 361 TUXEDO, 359–360 WebLogic Express, 353 WebLogic JAM (Java Adapter for Mainframe), 356–359 WebLogic Portal, 353–356 e-commerce services, WebLogic Portal, 354–356 EAR, defined, 400 ebXML (Electronic Business XML Initiative), Web services, 23 eGen application generator, WebLogic JAM (Java Adapter for Mainframe), 358–359 EJBGen tool, 29, 314–316 See also administration tools; Java utilities deployment and XML tools, 364 EJBs, 17–19 See also J2EE components container services, 19 containers, 18 defined, 400 enterprise applications, 164–165 entity beans, 18 message-driven beans, 18 object clustering, 241–242 overview, 17 servlets as EJB clients, 158–159 stateful session beans, 18 stateless session beans, 17 static deployment, 134–135 types of, 17–18 weblogic-ejb-jar.xml performance parameters, 265–268 Electronic Business XML Initiative (ebXML), Web services, 23 eLink, e-business platform, 352

Emprix e-test suite, 374–377 See also testing tools; third-party tools Enable Domain Wide Administration port option, domains configuration, 80–81 encodeURL() method, client state maintenance, 158 encryption, defined, 400 enterprise applications, 164–165 See also applications; J2EE components EJBs, 164–165 Enterprise Server. See Netscape Enterprise Server/iPlanet FastTrack Server plug-in entity beans clustered EJBs, 241–242 EJBs, 18 environment variables, Node Manager, 285 -examples option, weblogic.Deployer, 132 ExecuteQueue attributes, 259–262 See also config.xml performance parameters configuring, 260 QueueLength attribute, 259 QueueLengthThresholdPercent attribute, 259 ThreadCount attribute, 260–262 ThreadsIncrease attribute, 259 ThreadsMaximum attribute, 259 ThreadsMinimum attribute, 259 external DNS name, HTTP parameters, 153

❖

F

factories. See connection factories failed servers, recovering, 381–384 failover support administrative functions, 7 clustering, 232 farms. See Web farms FastTrack Server. See Netscape Enterprise Server/iPlanet FastTrack Server plug-in File Count option, domains configuration, 83

413

414


File Min Size option, domains configuration, 82 File Name option, domains configuration, 81 file-based persistence, HTTP JSP/servlets clustering, 239 file-based replication, HTTP JSP/servlets clustering, 239 fileRealm.properties file, WebLogic Integration, 344 finding programs, troubleshooting tips, 384 FORCESHUTDOWN command, weblogic.Admin utility, 327 Forget Heuristics option domains configuration, 84 transactions and JTA configuration parameters, 161 form processing, servlets and HTML, 14 Format Builder, data integration, 335–337

❖

G

garbage collection, JVM (Java Virtual Machine) tuning, 269, 272–273 Garbage Collectors (GCs), defined, 401 getProperty utility, 316–317 See also administration tools; Java utilities getSession() method, client state maintenance, 158 GETSTATE command, weblogic.Admin utility, 328 graphical-mode installation, 40–49 See also installing WebLogic Server BEA home directory, 42 Configuration Summary, 48, 49 Configuration Wizard, 43, 44 configuring WebLogic Server as service, 47, 48 domain locations, 45, 46 domain templates, 44

installation types, 42–43 Installation Wizard, 41 manually running Configuration Wizard, 48–49 passwords and usernames, 46, 47 server types, 44–45 usernames and passwords, 46, 47 groups, 197 See also application security; security providers defined, 401 guest books, servlets and, 15

❖

H

health checking, managed servers, 281–282 Health Monitoring Configuration tab, server configuration, 93 heap size, JVM (Java Virtual Machine) tuning, 269–273 heartbeats, cluster, 233–234 HELP function, weblogic.Admin utility, 324–325 -help switch, weblogic.Deployer, 125 home directory, WebLogic Integration, 341 home page, WebLogic Server, 5 hosts trusted, 282–283 virtual. See virtual hosts hosts file, Node Manager, 282–283 hot-deployment, development environment, 21 HTML form processing, servlets, 14 HTML page counters, servlets, 14 HTTP (HyperText Transfer Protocol) access logs, 154–156 defined, 401 Web server software and, 2–3 HTTP JSP/servlets clustering, 237–240 See also clustering; J2EE clustering file-based persistence, 239

Index

file-based replication, 239 in-memory replication, 238–239 JDBC-based persistence, 240–241 overview, 237 session states, 237 HTTP parameters, 148–153 See also administering Web applications; J2EE components Administration Console, 152 default server name, 149 duration, 152 external DNS name, 153 General tab, 150 HTTP tab, 148, 149 HTTPS duration, 152 keepalives, 150–151 max post size, 153 max post time, 153 overview, 148–149 post timeout secs, 153 send server header enabled, 151 WAP (Wireless Appliction Protocol) enabled, 153 HTTP servers, 2, 6, 8, 207–228 Apache HTTP Server plug-in, 219 HttpProxyServlet, 208 Microsoft IIS (Internet Information Server) plug-in, 219–225 Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 209–219 overview, 208 plug-ins, 208 proxies to secondary, 226–227 summary, 228 WebLogic Native Plug-in Tool for ISAPI and NSAPI, 225–226 HTTP session states, load balancing for, 231 HttpProxyServlet, HTTP servers, 208 HTTPS, defined, 401 HTTPS duration, HTTP parameters, 152

❖

I

IBM AIX platform, installing WebLogic Server, 66–67 IBM HTTP Server, described, 6 Identity Assertion providers, authentication framework, 187, 188–189 IIS. See Microsoft IIS (Internet Information Server) plug-in in-memory replication, 238–239 See also HTTP JSP/servlets clustering configuring, 239 load-balancing hardware, 238, 239 overview, 238 proxy requirements, 238, 240 session states, 238 weblogic.xml file, 239 initial-bean-in-free-pool element, weblogic-ejb-jar.xml performance parameters, 267 InitialCapacity attribute, JDBCConnectionPool element, 264, 265 Installation Wizard, graphical-mode installation, 41 installer program, WebLogic Integration, 339–343 installing WebLogic Server, 40–58, 66–67 See also uninstalling WebLogic Server CLASSPATH environment variable, 23–24, 62–65 console-mode installation, 49–53 graphical-mode installation, 40–49 IBM AIX platform, 66–67 overview, 40 platforms and installer programs, 41 silent-mode installation, 53–58 Sun Solaris platform, 66 instrumentation-level specification, JMX (Java Management Extension), 290–291 Integration. See WebLogic Integration

415

416


Internet Information Server. See Microsoft IIS plug-in IP Multicast (one-to-many), 233–234 See also cluster communication; clustering cluster heartbeats, 233–234 cluster-wide JNDI updates, 233 overview, 233 IP Socket (peer-to-peer), 234–235 See also cluster communication config.xml file, 234 native sockets, 234, 235 overview, 234 reader threads, 235 iPlanet FastTrack Server. See Netscape Enterprise Server/iPlanet FastTrack Server plug-in ISAPI, WebLogic Native Plug-in Tool for NSAPI and, 225–226 isolation-level element, weblogic-ejb-jar.xml performance parameters, 268

❖

J

J2EE clustering, 237–242 See also clustering HTTP JSP/servlets clustering, 237–240 JMS (Java Message Service), 242 object clustering, 241–242 overview, 237 J2EE components, 12–20, 145–182 See also applications; Java; WebLogic Server administering Web applications, 148–157 application logic layers, 147 client state maintenance, 158 deployment, 123–144 distributed architecture and, 146–147 EJBs, 17–19

enterprise applications, 164–165 JMS (Java Message Service), 169–170 JNDI (Java Naming and Directory Interface), 170–173 JSPs, 13–14 overview, 146 resource adapters, 19, 20 RMI (Remote Method Invocation), 165–167 RMI-IIOP (Internet-Inter ORB Protocol), 167–168 servlets, 12–13, 14–17 servlets as EJB clients, 158–159 summary, 182 transactions, 159–164 XML, 173–182 JAAS LoginModules, authentication framework, 187, 188 JAM. See WebLogic JAM (Java Adapter for Mainframe) JARs (Java Archive files) defined, 401 Java utilities and, 306 weblogic-ejb-jar.xml performance parameters, 265–268 Java compiler, performance tuning, 256 Java utilities, 306–322 See also administration tools; J2EE components AppletArchiver, 306–309 DBPing, 310–312 Der2Pem utility, 322 EJBGen tool, 29, 314–316 getProperty utility, 316–317 JAR files, 306 listed, 307 MultiCastTest utility, 318 myIP utility, 318 overview, 306 Pem2Der utility, 322 prerequisites, 306 Schema utility, 319–320 Show Licenses utility, 320–321 T3DBPing utility, 312

Index

utils.system utility, 321 VERSION utility, 322 weblogic.Deployer, 125–132, 312–313 WriteLicense utility, 322 JavaBeans, defined, 401 JDBC, defined, 401 JDBC configuration, 99–106 See also services configuration; WebLogic Console connection pools, 100, 101 data sources, 102–106 MultiPools, 101–102, 103 JDBC-based persistence, HTTP JSP/servlets clustering, 240–241 JDBCConnectionPool element, 264–265 See also config.xml performance parameters; performance tuning configuring, 265 InitialCapacity attribute, 264, 265 MaxCapacity attribute, 264, 265 overview, 264 PreparedStatementCacheSize attribute, 264 JDBCData Source connection factories, data source configuration, 105–106 JMS (Java Message Service), 169–170 See also J2EE components administered objects, 169 Administration Console, 169–170 applications, 168–169 clients, 169 clustering, 242 configuring, 106–116, 169–170 messages, 169 providers, 169 server configuration, 170 JMS (Java Message Service) configuration, 106–116, 169–170 See also services configuration; WebLogic Console bridge destinations, 114–116 bridges, 112–116 connection factories, 106–109

destination keys, 110–111 distributed destinations, 111 servers, 112, 113 templates, 109–110 JMX (Java Management Extension), 290–292 See also management architecture advantages of, 292 agent-level specification, 292 defined, 401 distributed-services level, 292 domain components, 296 instrumentation-level specification, 290–291 MBeans (Management Beans) and, 290–291 overview, 290 JNDI (Java Naming and Directory Interface), 170–173 See also J2EE components Administration Console, 172–173 binding, 236 client communication in clusters, 235–237 cluster-wide updates, 233 data sources, 102, 103 loading objects in trees, 172–173 naming conflicts and client cluster communication, 236–237 overview, 170–171 updating, 236, 237 viewing trees, 171–172 Jolt connection pools configuration, 119–120 See also services configuration; WebLogic Console JSP/servlets clustering. See HTTP JSP/servlets clustering JSPs, 13–14 See also J2EE components; servlets; WebLogic Console coding architecture, 14 coding example, 15

417

418


JTA options domains configuration, 83–84 transactions and JTA configuration parameters, 160–161 JVM (Java Virtual Machine), defined, 401 JVM (Java Virtual Machine) tuning, 269–273 See also performance tuning determining heap size, 270–271 garbage collection, 269, 272–273 heap size, 269–273 overview, 269 specifying heap size values, 271–273

❖

K

keepalives, HTTP parameters, 150–151 keys and certificates, starting administration server in SSL mode, 283–284 keystore provider, 193 See also application security; security providers keystores See also application security; security providers configuring and administering, 203

❖

See also administering Web applications; J2EE components; ports load balancing, 230–231 See also clustering administrative functions, 6 defined, 401 for HTTP session states, 231 in-memory replication, 238, 239 overview, 230 random, 231 round-robin, 230–231 weight-based, 231 load-balancing hardware, in-memory replication, 238, 239 localhost, WebLogic Console, 76 LOCK command, weblogic.Admin utility, 326 locking databases, weblogic-ejb-jar.xml performance parameters, 267 logging and monitoring transactions, 162–164 logging options domains configuration, 81–83 server configuration, 94 login dialog box, WebLogic Console, 76, 77 Login modules, authentication framework, 187 logs, HTTP access, 154–156

L

licenses cluster, 251 Show Licenses utility, 320–321 WriteLicense utility, 322 LICENSES command, weblogic.Admin utility, 328, 329 LIST command weblogic.Admin utility, 327–328 weblogic.Deployer, 131 Listen Port, 153–154

❖

M

machines defined, 38–39 Node Manager creation, 278 server configuration, 96–97 mail session configuration, WebLogic Integration, 343 managed servers defined, 293 development environment, 22 domains and, 293

Index

health checking, 281–282 Node Manager and, 278, 279–282 restart behavior, 280–282 management architecture, 289–304 config.xml file, 293 domains, 293–295 JMX (Java Management Extension), 290–292 MBeans (Management Beans), 295–304 overview, 290, 292–293 summary, 304 Management Beans. See MBeans max post size, HTTP parameters, 153 max post time, HTTP parameters, 153 Max Transactions option domains configuration, 84 transactions and JTA configuration parameters, 161 Max Unique Name Statistics option domains configuration, 84 transactions and JTA configuration parameters, 161 max-beans-in-cache element, weblogic-ejb-jar.xml performance parameters, 267 max-beans-in-free-pool element, weblogic-ejb-jar.xml performance parameters, 265, 266 MaxCapacity attribute, JDBCConnectionPool element, 264, 265 MBean servers, 295, 297–298 child/parent relationships, 298 ObjectName naming convention, 297–298 overview, 297–298 MBeans (Management Beans), 295–304 See also management architecture accessing, 300–303 Administration MBeanHome interface, 300, 301 Administration type, 299 AdminMBeanHome interface, 297 Configuration type, 299

defined, 402 JMX (Java Management Extension) and, 290–291 location of, 300 MBeanHome interface, 296–297, 300–303 MBeanServer interface, 300 monitoring, 303–304 overview, 295 Runtime type, 299–300 selecting client interface for accessing, 300–303 servers, 295, 297–298 types of, 298–300 WebLogic.management.configuration API, 300 Memory Configuration tab, server configuration, 90–91 memory requirements, WebLogic Server, 40 message-driven beans, EJBs, 18 messages, JMS (Java Message Service), 169 MIB Data Refresh Interval option, domains configuration, 85 Microsoft IIS (Internet Information Server), described, 6 Microsoft IIS (Internet Information Server) plug-in, 219–225 configuring by MIME type, 220–224 iisforward.dll file, 224–225 iisproxy.dll file, 220, 224, 225 iisproxy.ini file, 224 MIME types testing, 224 overview, 219 proxying by path, 224–225 testing configuration, 224, 225 middleware, WebLogic Server as, 7–8 MIME types configuration Microsoft IIS (Internet Information Server) plug-in, 220–224 Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 214–218 MIME types testing Microsoft IIS (Internet Information Server) plug-in, 224

419

420


Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 219 monitoring and logging transactions, 162–164 monitoring MBeans (Management Beans), 303–304 monitoring options, server configuration, 94, 95, 273 multi-tier application architecture, defined, 402 multicast addresses clustering and, 252 config.xml file and cluster configuration, 245, 246 multicasting defined, 402 IP Multicast (one-to-many), 233–234 MultiCastTest utility, 318 See also administration tools; Java utilities multiple server deployment, 135 See also deployment config.xml file, 135 weblogic.Deployer, 135 MultiPools, JDBC configuration, 101–102, 103 multithreading, defined, 402 mydomain, domains configuration, 79–81 myIP utility, 318 See also administration tools; Java utilities testing configuration and connectivity, 65

❖

N

n-tier distributed architecture, 146–147 naming service. See JNDI (Java Naming and Directory Interface) Native Plug-in Tool for ISAPI and NSAPI, 225–226 See also HTTP servers

native sockets, IP Socket (peer-to-peer), 234, 235 NativeIOEnabled attribute, config.xml performance parameters, 258–259 Netscape Enterprise Server, described, 6 Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 209–219 See also HTTP servers installing and configuring, 209–212 MIME types configuration, 214–218 MIME types testing, 219 obj.conf file, 209–212, 218 tags, 210 overview, 209 proxying by path, 209, 210 testing, 213–214 network channel configuration, 97–99 See also domains configuration; WebLogic Console networks defined, 402 performance tuning, 269 newsgroups, servlets and, 15 Node Manager, 275–288 Administration Console and, 277 architecture, 276, 277 command-line arguments, 285–286 configuration, 277–285 creating machines and adding managed servers, 278 default settings, 278–279 environment variables, 285 functions of, 276 hosts file, 282–283 managed servers, 278, 279–282 managed servers health checking, 281–282 managed servers restart behavior, 280–282 overview, 276 root directories and, 279 SSL (Secure Sockets Layer), 283–285 starting/stopping clusters and domains, 288

Index

starting/stopping servers manually, 287–288 startup information, 279–280 summary, 288 trusted hosts, 282–283 notes options, server configuration, 96 -nowait option, weblogic.Deployer, 132 NSAPI, WebLogic Native Plug-in Tool for ISAPI and, 225–226 Number of Files Limited option, domains configuration, 83

❖

O

obj.conf file, Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 209–212, 218 tags, Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 210 object clustering, 241–242 See also J2EE clustering EJBs, 241–242 overview, 241 ObjectName naming convention, MBean servers, 297–298 operating systems tuning, 268–269 See also performance tuning Sun Solaris platform, 269 Windows NT/2000, 268 Oracle HTTP Server, described, 6

❖

P

page counters, servlets and HTML, 14 parameter-based routing for clustered objects, 232 See also clustering parametric authorization, authorization framework, 189 passwords. See usernames and passwords PATH variable, startup command scripts, 71

paths, proxying by. See proxying by path Pem2Der utility See also administration tools; Java utilities certificates conversion, 322 performance tuning, 255–274 See also Tuning Configuration tab config.xml performance parameters, 257–265 Java compiler, 256 JVM (Java Virtual Machine) tuning, 269–273 networks, 269 operating systems, 268–269 overview, 256 starting parameters, 257 summary, 274 weblogic-ejb-jar.xml performance parameters, 265–268 weblogic.xml compiler option, 256–257 persistence file-based, 239 JDBC-based, 240–241 personalization services, WebLogic Portal, 356 PET STORE, config.xml file sample configuration, 391–398 phases, deployment, 129, 364–368 PING utility testing configuration and connectivity, 66 weblogic.Admin utility, 325 pinging Oracle, DBPing utility, 310 Planet Fast Track Server, described, 6 plug-ins HTTP server, 208 WebLogic Server, 7 pools. See connection pools; MultiPools portal services, WebLogic Portal, 354 porting applications from version 6.x to 7.0, 72 See also upgrading WebLogic Server

421

422


ports, 5 defined, 402 Listen Port, 153–154 starting WebLogic Server with two servers listening on same number, 381 post timeout secs, HTTP parameters, 153 preconfigured domains, WebLogic Integration, 339, 343–344 preparation phase, weblogic.Deployer, 129 PreparedStatementCacheSize attribute, JDBCConnectionPool element, 264 Principal Validation providers, authentication framework, 187, 189 product directory, console-mode installation, 52–53 production environment. See development environment programming frameworks, application server, 9–10 proxies, defined, 402 proxies to secondary HTTP servers, 226–227 See also HTTP servers proxy plug-ins accessing applications via, 250–251 config.xml file and cluster configuration, 247, 248 proxy requirements, in-memory replication, 238, 240 proxy servers administrative functions, 6 defined, 402 proxying by path Microsoft IIS (Internet Information Server) plug-in, 224–225 Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 209, 210 purging deployment tasks, cluster deployment, 140, 141

❖

Q

QueueLength attribute, ExecuteQueue attributes, 259 QueueLengthThresholdPercent attribute, ExecuteQueue attributes, 259 quote generators, servlets and, 16

❖

R

random links, servlets and, 16 random load balancing, 231 See also clustering; load balancing reader threads, IP Socket (peer-to-peer), 235 realms, defined, 403 recovering failed servers, 381–384 See also troubleshooting tips Registry. See XML Registry reinstallations, troubleshooting tips, 385 Remote Method Invocation. See RMI -remote option, weblogic.Deployer, 132 Remote Start Configuration tab, server configuration, 93 remove command, weblogic.Deployer, 127, 130–131 removing applications, cluster deployment, 140 replication file-based, 239 in-memory, 238–239 replication groups, config.xml file and cluster configuration, 246, 247 repository, configuration. See config.xml file resource adapters, 19, 20 See also J2EE components resource discovery, WebLogic Portal, 354, 355 restart behavior, managed servers, 280–282 right-clicking options, domains configuration, 85–87

Index

RMI (Remote Method Invocation), 165–167 See also J2EE components classes creation, 167 options, 166–167 overview, 165–166 WebLogic RMI compiler, 165–166 RMI-IIOP (Internet-Inter ORB Protocol), 167–168 See also J2EE components role mappers, 204 See also application security; security providers role-mapping providers, authorization framework, 191–192 roles, 194–195 See also application security; security providers defined, 403 root directories, Node Manager and, 279 Rotation Time option, domains configuration, 83 Rotation Type option, domains configuration, 82 round-robin load balancing, 230–231 See also clustering; load balancing convoying, 231 routing, parameter-based for clustered objects, 232 RSA encryption, defined, 403 rules for clustering services, 243 Runtime MBeans, 299–300 See also MBeans (Management Beans)

❖

S

scalability, application server, 9 Schema utility, 319–320 See also administration tools; Java utilities scripts, startup command and, 68–71 search engines, servlets and, 15

security administrative functions, 6 application, 183–205 security framework, 187–189 See also application security; security providers authentication framework, 187–188 security policies, authorization framework, 189 security providers, 187–204 See also application security adjudicators, 200, 201 administration and configuration of, 194–204 auditing framework, 192–193 authorization framework, 189–192 groups, 197 keystore provider, 193 overview, 187 roles, 194–195 security framework, 187–189 users, 196–197 self-extraction programs, replacing corrupted, 385 send server header enabled, HTTP parameters, 151 server administration tools, 372–373 See also third-party tools; tools server configuration, 87–96 See also domains configuration; WebLogic Console Cluster Configuration tab, 90 clusters, 96 Compilers Configuration tab, 93 Configuration tab, 90–93 Configure a New Server option, 88–90 config.xml file and cluster configuration, 244 Connections tab, 93–96 control options, 94 Deployment Configuration tab, 91 deployment options, 92, 95

423

424


Health Monitoring Configuration tab, 93 JMS (Java Message Service), 170 logging options, 94 machines, 96–97 Memory Configuration tab, 90–91 monitoring options, 94, 95, 273 notes options, 96 overview, 87–88 Remote Start Configuration tab, 93 services options, 96 Tuning Configuration tab, 91–93 Server Console, config.xml file and cluster configuration, 244–245 Server Status Check Interval Factor option, domains configuration, 85 server types, graphical-mode installation, 44–45 ServerLog command, weblogic.Admin utility, 329 servers defined, 38 JMS (Java Message Service) configuration, 112, 113 managed. See managed servers MBean (Management Bean), 295, 297–300 monitoring, 273 multiple deployment, 135 recovering failed, 381–384 starting/stopping manually via Node Manager, 287–288 WebLogic. See WebLogic Server service, configuring WebLogic Server as, 47, 48 services server configuration options, 96 Web, 22–23 WebLogic Server, 8 services configuration, 99–121 See also WebLogic Console JDBC configuration, 99–106 JMS (Java Message Service) configuration, 106–116

Jolt connection pools configuration, 119–120 virtual hosts configuration, 120–121 WLEC connection pools configuration, 117–118 WTC (WebLogic Tuxedo Connector) server configuration, 118–119 XML Registry configuration, 116–117 servlets, 12–13, 14–17 See also J2EE components; JSPs areas of application, 14–16 banner ads and, 15 chat programs and, 16 clustering. See HTTP JSP/servlets clustering coding architecture, 13 as EJB clients, 158–159 future applications, 16–17 guest books and, 15 HTML form processing and, 14 HTML page counters and, 14 newsgroups and, 15 quote generators and, 16 random links and, 16 search engines and, 15 session beans, EJB, 17–18 session management in Web farms, administrative functions, 7 session states HTTP JSP/servlets clustering, 237 in-memory replication, 238 load balancing for HTTP, 231 SETENV.BAT file, starting WebLogic Server, 24 SETWLSENV.CMD file, CLASSPATH environment variable, 62–64 Show Licenses utility, 320–321 See also administration tools; Java utilities SHUTDOWN command, weblogic.Admin utility, 326 silent-mode installation, 53–58 See also installing WebLogic Server

Index

overview, 53–54 sample silent.xml file, 55–58 silent.xml file parameters, 54–55 UNIX platform, 58 Windows platform, 58 Sitraka DeployDirector, 364–368 See also deployment and XML tools; third-party tools Size option, domains configuration, 82 skeletons, defined, 403 SNMP options, domains configuration, 85, 86 SNMP Port option, domains configuration, 85 software requirements, WebLogic Server, 40 Solaris platform installing WebLogic Server, 66 operating systems tuning, 269 SSL (Secure Sockets Layer), 283–285 See also Node Manager configuration, 284–285 overview, 283 starting administration server in SSL mode, 283–284 SSL Connections tab, 93, 94 See also Connections tab; server configuration; WebLogic Console staging options, weblogic.Deployer, 131–132 START command WebLogic Integration, 343 weblogic.Admin utility, 328 starting administration server in SSL mode, 283–284 See also Node Manager; SSL (Secure Sockets Layer) keys and certificates, 283–284 starting clusters, config.xml file and cluster configuration, 248 starting parameters, performance tuning, 257 starting WebLogic Integration, 345–346

starting WebLogic Server, 24–29, 67 See also WebLogic Server boot.properties file, 67 with incorrect settings (troubleshooting tips), 380 SETENV.BAT file, 24 STARTWEBLOGIC.CMD file, 24 STARTWEBLOGIC.CMD file examples, 24–29 with two servers listening on same port number, 381 starting/stopping clusters and domains, Node Manager, 288 starting/stopping servers manually, Node Manager, 287–288 startup command scripts, 68–71 See also upgrading WebLogic Server bea.home property, 70 PATH variable, 71 WL_HOME variable, 70–71 startup information, Node Manager, 279–280 stateful session beans, EJB, 18 stateless session beans, EJB, 17 states client state maintenance, 158 load balancing for HTTP session, 231 static deployment, 133–135 See also deployment cluster deployment, 137 config.xml file, 133–134 EJBs, 134–135 static Web documents, Web server software and, 4 STOP command, WebLogic Integration, 344 stopping WebLogic Integration, 347–350 stopping/starting clusters and domains, Node Manager, 288 stopping/starting servers manually, Node Manager, 287–288 stubs, defined, 403

425

426


StuckThreadMaxTime and StuckThreadTimerInterval attributes, config.xml performance parameters, 262–263 Sun Solaris platform installing WebLogic Server, 66 operating systems tuning, 269 system administrator infrastructure, WebLogic Server, 11–12 System utility, 321 See also administration tools; Java utilities

❖

T

T3DBPing utility, 312 See also administration tools; Java utilities database configuration and connection, 65 Targeted Trap Destinations option, domains configuration, 85 TargetStatus class, deployment, 142 TCP/IP suite, WebLogic Server and, 2 templates, JMS (Java Message Service) configuration, 109–110 testing configuration and connectivity, 65–66 myIP utility, 65 Ping utility, 66 VERSION utility, 65 testing configurations Microsoft IIS plug-in, 224, 225 Netscape Enterprise Server/iPlanet FastTrack Server plug-in, 213–214 testing tools, 373–377 See also third-party tools; tools Emprix e-test suite, 374–377 listed, 374 third-party tools, 363–377 See also tools deployment and XML tools, 364–372 server administration tools, 372–373

summary, 377 testing tools, 373–377 thread counts, clustering and, 252 ThreadCount attribute, ExecuteQueue attributes, 260–262 ThreadPoolPercentSocketReaders attribute, config.xml performance parameters, 263–264 ThreadsIncrease attribute, ExecuteQueue attributes, 259 ThreadsMaximum attribute, ExecuteQueue attributes, 259 ThreadsMinimum attribute, ExecuteQueue attributes, 259 Time option, domains configuration, 82 -timeout option, weblogic.Deployer, 132 Timeout Seconds option domains configuration, 83 transactions and JTA configuration parameters, 160 TogetherSoft ControlCenter, 368–370 See also deployment and XML tools; third-party tools TomCat server, AltoWeb Application Platform, 371–372 tools, 29–31 administration, 183–208 command-line. See weblogic.Admin utility deployment, 29, 125–132 DeployPlugin utility, 226, 227 EJBGen, 29, 314–316 server administration, 372–373 testing, 373–377 third-party, 363–377 WebLogic Builder, 29, 30 WebLogic Native Plug-in Tool for ISAPI and NSAPI, 225–226 TransactionLogFilePrefix exception, JTA configuration parameters and, 162 transactions, 159–164 See also J2EE components Administration Console and, 160

Index

configuring parameters, 159–162 monitoring and logging, 162–164 trees, JNDI (Java Naming and Directory Interface), 171–173 troubleshooting tips, 379–385 authentication, 385 CLASSPATH environment variable, 384–385 clustering, 251–252 compiling, 384 config.xml file, 380 finding programs, 384 recovering failed servers, 381–384 reinstallations, 385 replacing corrupted self-extraction programs, 385 starting WebLogic Server with incorrect settings, 380 starting WebLogic Server with two servers listening on same port number, 381 trusted hosts, Node Manager and, 282–283 Tuning Configuration tab See also performance tuning server configuration, 91–93 TUXEDO (Transactions for UniX, Enhanced for Distributed Operations), 359–360 See also e-business platform servers and clients, 360 Tuxedo Connector. See WTC (WebLogic Tuxedo Connector) server configuration Tx data sources, 104–105 See also data sources; services configuration; WebLogic Console

❖

U

UAT (User Acceptance Test), WebLogic Server, 23 UDDI, Web services, 23

undeploy command cluster deployment, 140 weblogic.Deployer, 127, 129–130 Unicode, defined, 403 uninstalling WebLogic Server, 67–68 See also installing WebLogic Server UNIX platform silent-mode installation, 58 TUXEDO (Transactions for UniX, Enhanced for Distributed Operations), 359–360 UNLOCK command, weblogic.Admin utility, 326 unprepare command, weblogic.Deployer, 130 updating JNDI (Java Naming and Directory Interface), 236, 237 upgrading WebLogic Server, 68–72 CLASSPATH environment variable, 71 directory structure, 71 modifying startup command scripts, 68–71 overview, 68 porting applications from version 6.x to 7.0, 72 version 6.x to 7.0, 68 -upload option, weblogic.Deployer, 132 URIs (Uniform Resource Identifiers), defined, 403 URLs (Uniform Resource Locators) defined, 403 WebLogic Console, 76 User Acceptance Test (UAT), WebLogic Server, 23 usernames and passwords graphical-mode installation, 46, 47 WebLogic Console, 76 users, 196–197 See also application security; security providers defined, 403

427

428


utilities. See tools utils.dbping. See DBPing utility utils.system utility, 321 See also administration tools; Java utilities

❖

V

version 7 security model, 184–186 See also application security version 6.1 comparison, 186 VERSION utility, 322 See also administration tools; Java utilities testing configuration and connectivity, 65 weblogic.Admin utility, 325 versions, upgrading WebLogic Server, 68–72 virtual hosts, 156–157 See also administering Web applications; J2EE components administrative functions, 6 virtual hosts configuration, 120–121 See also services configuration; WebLogic Console

❖

W

WAP (Wireless Appliction Protocol) enabled, HTTP parameters, 153 WAR (Web Application Archive), defined, 403 Web farms, session management in, 7 Web server software, 2–4 See also application server; WebLogic Server client/server architecture, 3 HTTP (HyperText Transfer Protocol), 2–3 static Web documents, 4

Web services, 22–23 See also WebLogic Server ebXML (Electronic Business XML Initiative), 23 UDDI, 23 WSDL (Web Services Description Language), 22–23 WebLogic Builder, 29, 30 See also tools deployment and XML tools, 364 WebLogic Console, 75–121 See also console-mode installation; JSPs administration options, 77, 78 attributes, 78 cluster deployment, 137–140 Console Preferences dialog box, 78, 79 domains configuration, 79–99 localhost, 76 login dialog box, 76, 77 overview, 76–78 services configuration, 99–121 settings, 78 starting/stopping servers manually via Node Manager, 287–288 summary, 121 URL, 76 usernames and passwords, 76 WebLogic Express, e-business platform, 353 WebLogic Integration, 331–350 application integration, 332 Application View Console, 347–348 B2B (business-to-business) integration, 334–335 BPM (Business Process Management), 333 configuration files for preconfigured domains, 343–344 config.xml file, 343 data integration, 335–339 database configuration, 344–345 database selection, 342

Index

fileRealm.properties file, 344 home directory, 341 installation and configuration, 339–350 installer program, 339–343 mail session configuration, 343 overview, 332 preconfigured domains, 339, 343–344 product directory, 341 START command, 343 starting, 345–346 STOP command, 344 stopping, 347–350 stopping on UNIX, 350 stopping via command line, 349 stopping via menus, 348–349 summary, 350 WebLogic Integration Studio, 334 wlai.properties file, 344 WebLogic JAM (Java Adapter for Mainframe), 356–359 See also e-business platform Administration Console, 357, 358 distributed configuration, 357 eGen application generator, 358–359 overview, 356–357 WebLogic Native Plug-in Tool for ISAPI and NSAPI, 225–226 See also HTTP servers DeployPlugin utility, 226, 227 WebLogic Portal, 353–356 See also e-business platform campaign management, 356 e-commerce services, 354–356 overview, 353 personalization services, 356 portal services, 354 resource discovery, 354, 355 WebLogic RMI compiler, RMI (Remote Method Invocation), 165–166 WebLogic Server, 1–73 administrative functions, 6–7 administrative infrastructure, 11–12

administrative tools, 305–330 application security, 183–205 application server, 7–11 cache tags, 11 CLASSPATH environment variable, 23–24, 62–65 Cloudscape DBMS, 23–24 clustering, 39, 229–253 configuring as service, 47, 48 config.xml file, 31–33, 60–62 database configuration and connection, 65 deployment, 123–144 development environment, 20–22 directory structure, 4, 59 distributed architecture, 146–147 downloading, 36–37 e-business platform, 351–361 environment, 23–31 features, 11–20 home page, 5 HTTP servers, 2, 6, 207–228 installing, 40–58, 66–67 J2EE components, 12–20, 145–182 key aspects, 34 machines, 38–39 management architecture, 289–304 memory requirements, 40 as middleware, 7–8 n-tier distributed architecture, 146–147 Node Manager, 275–288 performance tuning, 255–274 plug-ins, 7 ports, 5 prerequisites, 39–40 recovering failed servers, 381–384 servers, 38 services, 8 software requirements, 40 starting, 24–29, 67 starting with incorrect settings, 380 starting with two servers listening on same port number, 381

429

430


system administrator infrastructure, 11–12 TCP/IP suite, 2 terminology, 37–39 testing configuration and connectivity, 65–66 third-party tools, 363–377 tools, 29–31 troubleshooting tips, 379–385 UAT (User Acceptance Test), 23 uninstalling, 67–68 upgrading, 68–72 Web server software, 2–4 Web services, 22–23 WebLogic Console, 75–121 WebLogic Integration, 331–350 WebLogic Server, 23–31 WLS domain, 37–38 XML Editor tool, 60, 61 WebLogic Workshop, 30, 31 See also tools weblogic-ejb-jar.xml performance parameters, 265–268 See also performance tuning concurrency strategy, 267 database locking, 267 initial-bean-in-free-pool element, 267 isolation-level element, 268 max-beans-in-cache element, 267 max-beans-in-free-pool element, 265, 266 overview, 265–266 weblogic.Admin utility, 323–329 See also administration tools CANCEL_SHUTDOWN command, 327 FORCESHUTDOWN command, 327 GETSTATE command, 328 HELP function, 324–325 LICENSES command, 328, 329 LIST command, 327–328 LOCK command, 326 overview, 323 PING utility, 325

ServerLog command, 329 SHUTDOWN command, 326 START command, 328 UNLOCK command, 326 VERSION utility, 325 weblogic.Deployer, 125–132, 312–313 See also administration tools; deployment; Java utilities activate command, 127–129 activation phase, 129 ApplicationMBeans, 127 cancel command, 131 cluster deployment, 137 deactivate command, 127, 129–130 deploy command, 127–129 deployment phases, 129 deployment and XML tools, 364 -examples option, 132 -help switch, 125 list command, 131 multiple server deployment, 135 -nowait option, 132 options, 125–126 preparation phase, 129 -remote option, 132 remove command, 127, 130–131 staging options, 131–132 -timeout option, 132 undeploy command, 127, 129–130 unprepare command, 130 -upload option, 132 WebLogic.management.configuration API, MBeans (Management Beans), 300 weblogic.xml file CompileCommand parameter, 256–257 in-memory replication, 239 JDBC-based persistence, 240 weight-based load balancing, 231 See also clustering; load balancing Windows NT/2000, operating systems tuning, 268 Windows platform, silent-mode installation, 58

Index

wlai.properties file, WebLogic Integration, 344 WLEC connection pools configuration, 117–118 See also services configuration; WebLogic Console WL_HOME variable, startup command scripts, 70–71 WLS. See WebLogic Server WLS domain, defined, 37–38 Workshop, WebLogic, 30, 31 WriteLicense utility, 322 See also administration tools; Java utilities WSDL (Web Services Description Language), 22–23 See also Web services WTC (WebLogic Tuxedo Connector) server configuration, 118–119 See also services configuration; WebLogic Console

❖

X

XML, 173–182 See also J2EE components converting binary to, 338–339 converting to binary, 338 data integration, 335–339

deployment and XML tools, 364–372 overview, 173–174 Registry, 174–182 XML Editor tool, 60, 61 See also config.xml file XML Registry, 174–182 Administration Console, 179, 180 Apache Xerces parser and Xalan transformer, 175–176, 177, 179–182 assigning to applications, 176–178 configuration, 116–117 configuring parser for particular document types, 179–182 viewing changes to config.xml file, 178–179

431

INTERNATIONAL CONTACT INFORMATION AUSTRALIA McGraw-Hill Book Company Australia Pty. Ltd. TEL +61-2-9900-1800 FAX +61-2-9878-8881 http://www.mcgraw-hill.com.au [email protected] CANADA McGraw-Hill Ryerson Ltd. TEL +905-430-5000 FAX +905-430-5020 http://www.mcgraw-hill.ca GREECE, MIDDLE EAST, & AFRICA (Excluding South Africa) McGraw-Hill Hellas TEL +30-1-656-0990-3-4 FAX +30-1-654-5525 MEXICO (Also serving Latin America) McGraw-Hill Interamericana Editores S.A. de C.V. TEL +525-117-1583 FAX +525-117-1589 http://www.mcgraw-hill.com.mx [email protected] SINGAPORE (Serving Asia) McGraw-Hill Book Company TEL +65-863-1580 FAX +65-862-3354 http://www.mcgraw-hill.com.sg [email protected]

SOUTH AFRICA McGraw-Hill South Africa TEL +27-11-622-7512 FAX +27-11-622-9045 [email protected] SPAIN McGraw-Hill/Interamericana de España, S.A.U. TEL +34-91-180-3000 FAX +34-91-372-8513 http://www.mcgraw-hill.es [email protected] UNITED KINGDOM, NORTHERN, EASTERN, & CENTRAL EUROPE McGraw-Hill Education Europe TEL +44-1-628-502500 FAX +44-1-628-770224 http://www.mcgraw-hill.co.uk [email protected] ALL OTHER INQUIRIES Contact: Osborne/McGraw-Hill TEL +1-510-549-6600 FAX +1-510-883-7600 http://www.osborne.com [email protected]

BEA WebLogic 7 server administration

BEA WebLogic Server Administration Kit

BEA WebLogic Server Bible

BEA WebLogic Platform 7

BEA WebLogic Platform 7

BEA Weblogic(R) Server Bible

BEA WebLogic Server 8.1 Unleashed

BEA WebLogic Server 8 for Dummies

Professional J2EE Programming with BEA WebLogic Server

BEA WebLogic Server 8 for Dummies

BEA WebLogic Server 8 for Dummies

Oracle Weblogic Server 11gR1 PS2: Administration Essentials

Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days

Professional Oracle WebLogic Server

BEA WebLogic Workshop 8.1 Kick Start

Oracle WebLogic Server 12c: First Look

Oracle WebLogic Server 12c: First Look

Pro Ubuntu Server Administration

Pro Ubuntu Server Administration

Ubuntu Server Administration

Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications

SQL Server 2008 Administration

Microsoft Windows Server 2008 Administration

Microsoft Windows Server Administration Essentials

Linux Apache Web Server Administration

Administering SQL Server 7

Osborne Media Ubuntu Server Administration

Beginning SQL Server 2005 Administration

Pro SQL Server 2008 Administration

Professional SQL Server 2005 Administration

Microsoft Windows Server 2008 Administration

BEA WebLogic 7 server administration

BEA WebLogic Server Administration Kit

BEA WebLogic Server Bible

BEA WebLogic Platform 7

BEA WebLogic Platform 7

BEA Weblogic(R) Server Bible

BEA WebLogic Server 8.1 Unleashed

BEA WebLogic Server 8 for Dummies

Professional J2EE Programming with BEA WebLogic Server

BEA WebLogic Server 8 for Dummies

BEA WebLogic Server 8 for Dummies

Oracle Weblogic Server 11gR1 PS2: Administration Essentials

Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days

Professional Oracle WebLogic Server

BEA WebLogic Workshop 8.1 Kick Start

Oracle WebLogic Server 12c: First Look

Oracle WebLogic Server 12c: First Look

Pro Ubuntu Server Administration

Pro Ubuntu Server Administration

Ubuntu Server Administration

Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications

SQL Server 2008 Administration

Microsoft Windows Server 2008 Administration

Microsoft Windows Server Administration Essentials

Linux Apache Web Server Administration

Administering SQL Server 7

Osborne Media Ubuntu Server Administration

Beginning SQL Server 2005 Administration

Pro SQL Server 2008 Administration

Professional SQL Server 2005 Administration

Microsoft Windows Server 2008 Administration

Recommend Documents