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!
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
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.
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
This page intentionally left blank.
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
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
xix
This page intentionally left blank.
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
BEA WebLogic 7 Server Administration
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
This page intentionally left blank.
CHAPTER 1 WebLogic Server Basics
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
1
2
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
•
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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.
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
•
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:
WebLogic Server Basics
•
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
BEA WebLogic 7 Server Administration
•
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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:
WebLogic Server Basics
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
BEA WebLogic 7 Server Administration
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
- 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
BEA WebLogic 7 Server Administration
@rem Call WebLogic Server call "C:\bea\weblogic700b\server\bin\startWebLogic.cmd" ENDLOCAL
****************************************************************** 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)
- 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
BEA WebLogic 7 Server Administration
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%
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
BEA WebLogic 7 Server Administration
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 Server Basics
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
BEA WebLogic 7 Server Administration
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 <Application Deployed="true" Name="DefaultWebApp" Path=".\applications" TwoPhase="false"> <WebAppComponent Name="DefaultWebApp" Targets="myserver" URI="DefaultWebApp" /> <Application Deployed="true" Name="certificate" Path=".\applications" TwoPhase="false"> <WebAppComponent Name="certificate" Targets="myserver" URI="certificate.war" /> <ApplicationManager Name="mydomain" /> <JTA Name="mydomain" /> <PasswordPolicy Name="wl_default_password_policy" /> <SNMPAgent Name="mydomain" /> <Security GuestDisabled="false" Name="mydomain" PasswordPolicy="wl_default_password_policy" Realm="wl_default_realm" RealmSetup="true" /> <SecurityConfiguration Credential= "{3DES}3WOUyKIzNNk3WJRlIpgHtfjs 57CUC3t2cXoeQqSzH1w4G4V/jhBQAn v8jQNAwV2sOwz2IXE7d5B34d05T08j 0f5SwTzS9xBH" Name="mydomain" /> <Server ListenPort="7001" Name="myserver" NativeIOEnabled="true" ServerVersion="7.0.0.0"> <ExecuteQueue Name="default" ThreadCount="15" /> <JTAMigratableTarget Cluster="" Name="myserver" UserPreferredServer="myserver" /> <SSL Enabled="true" ListenPort="7002" Name="myserver" ServerCertificateChainFileName="ca.pem" ServerCertificateFileName="democert.pem" ServerKeyFileName="demokey.pem" /> <ServerDebug Name="myserver" /> <ServerStart Name="myserver" /> <SystemDataStore Credential= "{3DES}+cGRcNRxlWhCRWY+Gd1dL3rO ZqEUWe+bfKIIIfJStns=" Name="myserver" /> <WebServer DefaultWebApp="DefaultWebApp" LogFileName=".\myserver\access.log" LoggingEnabled="true" Name="myserver" />
33
34
BEA WebLogic 7 Server Administration
CHECKLIST In this chapter, you acquired necessary information about WebLogic Server and useful skills required for a quick start to administering the WebLogic application server. Here are the key aspects related to WebLogic Server: ■
HTTP service is built into WebLogic Server.
■
WebLogic Server is the platform of choice for deploying and running J2EE enterprise Java applications.
■
WebLogic Server has two types of containers: the Web container and the EJB container.
■
Java servlets, JSPs, and static pages can be deployed and run in Web containers.
■
EJBs can be deployed and run in EJB containers.
■
With J2EE 1.3, resource adapters can now be used to connect to EIS.
■
Development and production environments are different animals.
■
Setting the CLASSPATH variable enables applications to locate the relevant application-specific Java classes.
■
The config.xml file contains all configurations settings for the WebLogic domain.
CHAPTER 2 WebLogic Application Server Installation and Configuration
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
35
36
BEA WebLogic 7 Server Administration
n this chapter, we provide the information you need to install and configure WebLogic Server 7 on various platforms, such as Microsoft Windows and UNIX flavors. We cover various products, including Caldera OpenUnix, Compaq TRU64 UNIX, HP-UX, IBM OS/400, IBM AIX, Windows 2000/NT, Linux, Sun Solaris, Miracle UNIX, and SCO UnixWare. And we go through all the steps you need to perform for initiating and completing installation of WebLogic Server 7 on one or more platforms, such as Microsoft Windows and Linux.
I
ACQUIRING WEBLOGIC SERVER 7 SOFTWARE Acquiring WebLogic Server 7 software for evaluation purposes is a fairly simple and painless task. You can download evaluation editions of various BEA products, such as WebLogic Server, WebLogic WorkShop, WebLogic Portal, WebLogic Integration, Tuxedo, WebLogic Enterprise, MessageQ, and others, from http://commerce.bea.com/downloads/ products.jsp or http://commerce.beasys.com/downloads/weblogic_server.jsp. You can also visit http://www.bea.com and click the Download button to route you to the download page. Here’s how to download WebLogic Server 7: 1. Click the link WebLogic Server Downloads. Select the platform for which you want to download WebLogic Server software. Downloads are available for Microsoft Windows 2000, Sun Solaris, and HP-UX operating systems. NOTE WebLogic Server 7 is bulky software, approximately 90MB in size. To initiate download, you need to have a fast Internet connection, such as cable, DSL, or T1/T3. Downloading the software through a dial-up connection is not advisable. You must set up an account with BEA to log on and initiate download. If you are restricted from downloading material from the Web due to security constraints imposed by a firewall, you can order a CD-ROM from BEA. 2. After selecting the platform for which you want to perform the download, you see a page providing information about the file size, minimum requirements, description of software, documentation links, and release notes. Click the Proceed To Download button. 3. You need to be registered with BEA to download the software. If you are not already a registered user, proceed with registration and continue downloading. Accept the license agreement. 4. Either select the HTTP download method or use the download manager software called DigitalWizard from InstallShield Software Corporation, shown in Figure 2-1. Click the link to download using the download manager, and it downloads a DigitalWizard component into the download folder on your hard drive. When you execute the link, the DigitalWizard download manager starts and helps you download WebLogic Server.
Chapter 2:
Figure 2-1.
WebLogic Application Server Installation and Configuration
DigitalWizard start screen
You can also request an evaluation version of WebLogic Server 7 on CD-ROM by navigating to http://contact2.bea.com/bea/www/evalcd/login.jsp?PC=ECD-WLSD and ordering it online. You will receive a set of two CD-ROMs containing product software and documentation, printed documents, an installation guide, an introduction to WebLogic Server, release notes, a license, and a limited warranty. NOTE The evaluation version that you download from the Web site or from CD-ROM is licensed for 60 days’ usage. It allows up to 20 simultaneous client connections.
WEBLOGIC SERVER TERMS The internal architecture of WebLogic Server is becoming more and more like BEA Tuxedo, a transaction monitor. If you are familiar with Tuxedo, you will recognize many of the following terms.
WLS Domain A WLS domain is an administrative unit that typically represents a logical application. It is the most basic administration unit for all the WebLogic Server instances running.
37
38
BEA WebLogic 7 Server Administration
The application can be an online store, a human resources Web site, or an online brokerage application. A domain is made up of an administration server, zero or more managed servers, zero or more machines, and zero or more clusters. Figure 2-2 shows a general domain structure. For decentralizing administration for WebLogic Server, you may also choose to define multiple domains based on separation of responsibilities for administrators, application boundaries, and also the geographical location of servers. You may also decide to use only one domain to centralize all WebLogic Server administration activities. Administration for the domain and the resources for the application are done through the Administration Console, a Web-based configuration console.
Server A server is an instance of the Java class weblogic.Server running within a Java Virtual Machine (JVM). An administration server is the server that maintains all the configuration information for a domain. A managed server retrieves its configuration information at startup time from the administration server. Therefore, you must have an administration server up and running to start a managed server. However, once the managed servers are running, you can shut down your administration server and your managed servers will run fine.
Machine A machine is a physical piece of hardware that may contain zero or more servers running on it, multiple CPUs, and multiple IP addresses. WebLogic Server allows you to define two different types of machines: a regular machine and a UNIX machine. A regular machine definition consists of the name of the machine, but a UNIX machine definition also defines a post-bind user ID and a post-bind group ID. Because certain
Figure 2-2.
WebLogic domain structure
Chapter 2:
WebLogic Application Server Installation and Configuration
ports are protected on a UNIX machine and only processes running as root can access them, WLS needs to boot as root. However, it is not wise to have WLS continue running as root, so you can specify the user ID and the group ID under which WLS should run after it has booted. Machine definitions will also play a role in state replication within a cluster.
Cluster A cluster is a group of servers that act as one. All the servers within the cluster should be configured the same, which allows for load balancing, because client requests can be directed to any server in the cluster. Many services have failover capabilities, so if a server goes down, the client’s request can be redirected to another server within the cluster, and the client does not know the difference.
PREREQUISITES FOR WEBLOGIC SERVER 7 Software and hardware requirements are based on the complexity of the application that needs to be supported, the number of concurrent users that an application server needs to support, and the level of performance demanded by the applications under load. You need to know what operating system platforms are supported; and for each one, you need to know the type of patch to be applied. The version of Java Development Kit (JDK) running on the machine is significant. You need to be aware of minimum requirements for installing WebLogic Server. Consider the following parameters as a part of analyzing system requirements for installing WebLogic Server: •
Platform
•
Hard drive
•
Memory
•
Display settings
WebLogic Server is available for various platforms that include operating system platforms from Caldera, Compaq, IBM, HP, Intel, Microsoft, Red Hat, SuSE, Siemens, Silicon Graphics, and Sun Microsystems. WebLogic Server on a Microsoft Windows platform needs approximately 165MB of hard disk space to install on the system, and about 110MB of space is needed by the installer program. On a UNIX platform, the server requires 160MB of hard disk space to install WLS and about 128MB of space for the WebLogic installer program. NOTE These space requirements also account for the amount of space needed for JDK, examples, and samples bundled with WebLogic Server.
39
40
BEA WebLogic 7 Server Administration
Requirements for Temporary Space The minimum memory requirement for installing WebLogic Server 7 is 128MB for both Windows and UNIX systems. WebLogic Server is bundled in an executable file that needs to be extracted in a temporary location on the hard drive. By default, the installation program will utilize the temporary folder configured for the operating system. For Microsoft Windows, it will use the folder assigned to the variable TMP; for UNIX systems, it will use the /tmp folder for extracting temporary files.
Software Requirements To install and run WebLogic Server 7, you must have JDK 1.3.1 installed on the system. This is required for an appropriate Java runtime environment. Also, you will need browser software installed on the system to have access to the WebLogic Administration Console. You must have Internet Explorer 5 or higher or Netscape Navigator 4.7 or higher installed. Other software requirements involve various service packs and patches for the operating system and WebLogic Server to make sure that you have the latest software and updates installed to avoid any glitches the software had in the past.
INSTALLATION METHODS Once you are done with studying the system requirements, organizing and arranging necessary hardware and software resources, and downloading the software or acquiring it from BEA representatives, the next step is to install the software on the destined platform. The BEA installer program provides the following methods for installing WebLogic Server: •
Graphical
•
Console
•
Silent
Installation in Graphical Mode The graphical mode of installation is the interactive way to install WebLogic Server. It provides a GUI-based wizard that navigates the user through the installation procedure step by step. This mode of installation is available in both Windows and UNIX. The GUIbased installer works well with Windows and is the default way of starting the installer. With UNIX, it depends on whether the console attached to the machine supports a Java-based GUI. If the console under UNIX doesn’t support a Java-based GUI, it will default to console-based installation.
Chapter 2:
WebLogic Application Server Installation and Configuration
To perform WebLogic installation in graphical mode, complete the following steps: Step 1: Locate the installer program. You can obtain the installer program from the BEA Web site or the CD-ROM. Download or copy the installer program file to a directory on your machine. Table 2-1 shows the installer programs available for respective platforms. Step 2: Start the GUI mode installer. To start the GUI mode installer for the Microsoft Windows platform, open the folder with the installer program and double-click the file. You will be introduced to the installation wizard, shown in Figure 2-3.
Figure 2-3.
Installation wizard introduction
41
42
BEA WebLogic 7 Server Administration
Step 3: Read the license agreement. When you click Next, you will be taken to the license agreement screen. Select Yes to continue the installation process. Step 4: Choose a BEA home directory. Click Next and you’ll see the screen for selecting the folder where BEA WebLogic Server will be installed, as shown in Figure 2-4. Choose the home directory for BEA WebLogic Server. You can use the folder where BEA WebLogic Server is already installed, or you can create a new Home folder for the server installation. Click Next to continue. Step 5: Select the installation type. You can opt for typical installation or custom installation, for which you can select the components you want to install and leave out the ones you don’t want. If you select the typical installation, the installer will proceed with its own plan and options about components for installing them. If you opt for a custom installation, you have the option to install WebLogic Server or WebLogic Server with Server Examples, as shown in Figure 2-5. If you choose custom installation, you can also choose to install the WebLogic Server product installation directory. During the installation process, the installer
Figure 2-4.
Selecting BEA home directory
Chapter 2:
Figure 2-5.
WebLogic Application Server Installation and Configuration
Custom installation of components
extracts and copies all the necessary files to the destination folder. Once the installer completes this task, the next step is to decide whether you want to let it run Configuration Wizard for creating your application domain, or do this later by manually running the Configuration Wizard. Step 6: Run the Configuration Wizard. The Configuration Wizard is a stand-alone Java application that helps you create new, customized WebLogic Server domains. It is the Configuration Wizard that will install the default Web application under the /applications folder, store logs for the server in the domain under /logs, and create shell and command files such as setEnv.cmd, setEnv.sh, setExamplesEnv.cmd, setExamplesEnv.sh, startWebLogic.cmd, startWebLogic.sh, startManagedWebLogic.cmd, startManagedWebLogic.sh, startExamplesServer.cmd, startExamplesServer.sh, startPetStore.cmd, startPetStore.sh, demokey.pem, democert.pem, and Windows Start menu items. You will be given a choice of whether or not you want to run the Configuration Wizard that will let you set up your application domain with the kind of configuration you desire for the domain, as shown in Figure 2-6. Select Yes and click Next to continue.
43
44
BEA WebLogic 7 Server Administration
Figure 2-6.
Running Configuration Wizard
Step 7: Select the domain type and name. Choose from three domain templates, as shown in Figure 2-7: WLS Examples, WLS Petstore, and WLS Domain. You will also have to provide the domain name for the type of domain you select. •
WLS Examples configures a typical WebLogic domain with prebuilt examples and sample applications.
•
WLS Petstore configures a typical WebLogic domain with a J2EE benchmark application from Sun called Petstore.
•
WLS Domain configures a typical WebLogic Server domain with no custom applications installed.
Step 8: Select a server type.
Specify the type of server configuration you want to use:
•
Single Server (Standalone Server)
•
Admin Server With Managed Server(s)
Chapter 2:
Figure 2-7.
WebLogic Application Server Installation and Configuration
Domain template types
•
Admin Server With Clustered Managed Server(s)
•
Managed Server (With Owning Admin Server Configuration)
For now, select the Single Server option. You also will need to provide a directory for the mydomain domain. The default location s C:\BEA\user_projects\mydomain, as shown in Figure 2-8. You have the option to change the location at a later time. (If the directory already exists, it will confirm before overwriting it.) You will be asked to provide the following information: •
Server Name (the default is myserver)
•
Server Listen Address
•
Server Listen Port (the default is 7001)
•
Server SSL Listen Port (the default is 7002)
45
46
BEA WebLogic 7 Server Administration
Figure 2-8.
Choosing a domain location
Step 9: Set up the username and password. Set up the username and password for administering WebLogic Server, as shown in Figure 2-9. You can add more users at a later time. NOTE A password must be at least eight characters. You may want WebLogic Server to start as soon as the operating system is started. With Microsoft Windows, it is possible to configure the program as a service. The benefit is that you can start and stop the program from the Services facility under the Control Panel.
Chapter 2:
Figure 2-9.
WebLogic Application Server Installation and Configuration
Setting up the username and password
WebLogic Server can be configured to run as a service on Windows NT, Windows 2000, and Windows XP Professional (see Figure 2-10). It can be configured automatically while you are installing the product or manually any time later. The benefit of WebLogic Server being configured as a service is that it can be controlled through the Services menu in the Control Panel. NOTE Our recommendation is not to install WebLogic Server as a service while you are learning the product. It is important for you to handle WebLogic Server manually without aid of a Windows service.
47
48
BEA WebLogic 7 Server Administration
Figure 2-10.
Set up WebLogic Server as a Windows service.
With Windows, whenever you install a new program, a shortcut is provided in the Start menu to launch the program. You will be presented with the choice to let the installer program create a program group and launch icons related to WebLogic in the Start menu. Select No for now. Next, you will see a display of the Configuration Summary (see Figure 2-11), which is information about all the options and their values you have selected in the Configuration Wizard. Click the Create button to let the Configuration Wizard use the configuration information provided by you and create a WebLogic domain with custom applications. It just takes a moment to configure the domain and application selected. It will ask if you wish to create another domain. For now, choose No. Choose End Configuration Wizard, and click on Next to complete the configuration.
Manually Running the Configuration Wizard (Graphical Mode) During the installation of WebLogic Server, if you decide not to configure the domain at the same time, you can do it later. Running the Configuration Wizard from the command line can do this. Invoke the Configuration Wizard by choosing Start | Programs | BEA WebLogic Platform 7.0 | Configuration Wizard.
Chapter 2:
Figure 2-11.
WebLogic Application Server Installation and Configuration
Configuration Summary
You can also invoke the Configuration Wizard from the command line in Microsoft Windows or UNIX: 1. Log in to the target Windows or UNIX system. 2. Open a command-line shell. 3. Go to the \common\bin subdirectory of the WebLogic Server installation directory. For example: cd c:\bea\weblogic700\common\bin
4. Invoke the dmwiz.cmd or dmwiz.sh script to start the Configuration Wizard.
Installation in Console Mode Console-mode installation is meant specifically for UNIX platforms and is especially intended for consoles that don’t support Java-based graphics. Let’s navigate through the steps to continue with the console-mode installation of WebLogic Server: 1. Log in to the target UNIX system. 2. Open the command-line shell (such as csh, bash, or sh).
49
50
BEA WebLogic 7 Server Administration
3. If you want to install WebLogic Server by downloading it from the BEA Web site, go to http://commerce.beasys.com/downloads/weblogic_server.jsp and download the WebLogic Server installer program for your platform. Change the working directory to the location where you have downloaded the installer program, and invoke the program using the following set of commands: chmod a+x filename.bin ./filename.bin -mode=console
or $ sh filename.bin –mode=console
Here, filename.bin is the name of the WebLogic Server installation file. 4. If you want to install WebLogic Server from the CD-ROM, you will be required to insert the WebLogic Server CD-ROM into the CD-ROM drive. •
Change the working directory to the location that contains the filename.bin file.
•
Invoke the installation procedure by entering the following command:
./filename.bin -mode=console
or $ sh filename.bin –mode=console
Here, filename.bin is the name of the WebLogic Server installer program file specific to your platform. Note that you can include the path to the log file if you are interested in logging the entire installation process to a file. For example, ./weblogic700_solaris.bin -mode=console -log=/nfs/home1/logs/wls_install.log
or $ sh weblogic700_solaris.bin –mode=console –log=/nfs/home1/logs/wls_install.log
NOTE These steps are the same as for graphical mode with the exception that you will not see graphics, and the installation process will not be performed with mouse clicks. Rather, you will be working with a classic menu with each option numbered. You will need to press an appropriate number key for the option you want to select and instruct the installer program to continue. Step 1: Read the Welcome screen. As soon as the installation program is run from the command line, it will welcome you to WebLogic Server installation. To continue installation, press ENTER or type next on the console.
Chapter 2:
WebLogic Application Server Installation and Configuration
Step 2: Read the license agreement. You must either accept or reject the license agreement by typing yes or no. You will not be able to proceed with the installation unless you accept the agreement. Step 3: Choose a BEA home directory. Choose the directory under which the WebLogic Server will be installed and where all the sample applications and examples will be placed. It is possible that this is the first time that you are performing installation on the system. In this case, the BEA installer program will display the following: Choose BEA Home Directory: New BEA home directory = => Input New BEA home directory Enter a value OR [Exit][Previous][Next]>_
You must input the complete path for the folder where you are installing WebLogic Server. It is not mandatory to have created the directory previously. The installer program will create the directory automatically if it doesn’t find the one mentioned at the prompt. The home folder may already exist on the system due to prior installation of WebLogic Server. In this case, the BEA installer program will display the following: Specify BEA Home Directory = [/home1/bea] Select Option: 1 - Input new 2 - Reset to default Enter a number OR [Exit][Previous][Next]> 1
If you don’t want to disturb the existing installation of WebLogic Server and want the installation to be performed in a new folder, type 1 and press ENTER to continue, which will display the following prompt: Choose BEA Home Directory: Specify BEA Home Directory = [/home1/bea] Input new Enter a value OR [Exit][Previous][Next]> /home/beahome2
Step 4: Choose an installation type. Choose the type of installation you want to perform: typical or custom. The following will be displayed on the console: ->1| Typical Installation (Install all software components, including program files and examples.)
51
52
BEA WebLogic 7 Server Administration
2| Custom Installation (Choose software components to install and optionally create custom application domains. Recommended for advanced users.) => Enter index numbers to select
Step 5: Select components. The WebLogic installer program asks you to select components in the situation for which you previously selected a custom installation. The following will be displayed on the console: Choose Components: Release 7.0 |-----WebLogic Server [0] x |-----Server [0.0] x |-----Server Examples [0.1] x => Enter number exactly as it appears in brackets to toggle selection
The installer program has selected all components for installation by default. You can override this with a custom installation. To select or deselect any of the listed components, you must type the number precisely the way it appears in square brackets ([]). Press ENTER to continue when you are done selecting components. Step 6: Choose the product directory. Choose the product directory as a part of custom installation. Specify the directory where WebLogic Server will be installed. Specify Product Installation Directory= [/home/bea/weblogic700] Select Option: 1 - Input new 2 - Reset to default Enter a number OR [Exit][Previous][Next]>
Do one of the following: •
Press ENTER or type 2 to accept the current selection. If you enter 2 at the initial prompt, you accept the default product directory (/home/bea/weblogic700, in this example).
•
Enter 1 to enter a new product installation directory. The following text will be displayed:
Choose Product Directory: Specify Product Installation Directory = [/home/bea/weblogic700] Input new Enter a value OR [Exit][Previous][Next]>
Enter the full path to the directory where you want to install the WebLogic Platform software. For example:
Chapter 2:
WebLogic Application Server Installation and Configuration
/home3/weblogic700
When you press ENTER, the pathname you entered will be shown as follows: Choose Product Directory: ->1| Yes, use this product directory [/home3/weblogic700] 2| No, select another product directory Enter index numbers to select Enter a value OR [Exit][Previous][Next]>
Verify that your entry is correct, and then type 1 or press ENTER to proceed with the installation. Step 7: Copy the required files to the home directory. The BEA installer program will start copying required files on the basis of the options selected to the target BEA home directory. Step 8: Launch the Configuration Wizard. The Configuration Wizard is used for creating typical or custom WebLogic domains. You will be provided with the following options: ->1 - Yes, run Configuration Wizard to create my application domain 2 - No, skip Configuration Wizard
You can always launch the Configuration Wizard manually later. For the time being, we will launch the Configuration Wizard as a part of the installation process itself. To continue the launch of the Configuration Wizard, press 1 and ENTER. To run the Configuration Wizard from the command mode, use the following steps: 1. Log in to the target Windows or UNIX system. 2. Open a command-line shell. 3. Go to the \common\bin subdirectory of the WebLogic Server installation directory. For example: cd c:\bea\weblogic700\common\bin
4. Invoke the dmwiz.cmd or dmwiz.sh script with the -mode=console argument: dmwiz.cmd -mode=console
Installation in Silent Mode In most situations in a production environment in which WebLogic Server is installed on multiple systems, it’s a good idea to prepare a file that contains answers to all prompts and questions presented to the user while installing the application. The installer is capable of reading the values required for each prompt from the answer or properties file and can perform the installation automatically, without the user’s intervention.
53
54
BEA WebLogic 7 Server Administration
The silent mode of installation is a way to store configuration settings once in a configuration file. Using this configuration file, it is possible to duplicate the installation on numerous machines without the user’s intervention. These settings are stored in an XML configuration file, which is a text file. The configuration file contains information required by the BEA installer program. such as the BEA home, the installation directory path, whether to run the Domain Wizard, a domain name, a server name, a username, a password, the listen port, the cluster name, the cluster port, and whether to install WebLogic Server as an NT Service. The configuration parameters you specified during the GUI-mode installation are retrieved from the XML file during silent-mode installation. This installation technique allows the WebLogic Server administrator to define the install configuration once and use it again and again on multiple machines. During silent-mode installation, no prompts appear and no inputs are required from the user; all information that the installer program needs is taken from the XML properties file. NOTE The silent-mode configuration file must be saved as silent.xml. Two steps are involved in silent-mode installation: 1. Create a template file containing configuration settings. 2. Start the installation process that will use the values specified in the template file. Table 2-2 shows a list of parameters for which we must supply the values in the silent XML file. Parameter
The mode of installation. The default is silent and should not be modified. Full path for the BEA home directory. Full path for the product directory. Full path to the domain directory. The default domain name. The default server name. Administrative username to start the server. Administrative password to authenticate the administrative username. System IP or DNS name for server. The default TCP/IP port number. The default SSL listen port.
Table 2-2.
Silent.XML File Parameters
Chapter 2:
WebLogic Application Server Installation and Configuration
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
BEA WebLogic 7 Server Administration
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.
WebLogic Application Server Installation and Configuration
BEA XML Editor tool
CONFIGURATION ATTRIBUTES Following are the configurable attributes within the config.xml file: Administrator BridgeDestination COM Domain
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:
WebLogic Application Server Installation and Configuration
@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
BEA WebLogic 7 Server Administration
@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:
WebLogic Application Server Installation and Configuration
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
BEA WebLogic 7 Server Administration
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:
WebLogic Application Server Installation and Configuration
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
BEA WebLogic 7 Server Administration
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:
WebLogic Application Server Installation and Configuration
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
BEA WebLogic 7 Server Administration
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:
WebLogic Application Server Installation and Configuration
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
BEA WebLogic 7 Server Administration
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:
WebLogic Application Server Installation and Configuration
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
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
75
76
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
•
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
•
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
123
124
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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:
Application Deployment
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
BEA WebLogic 7 Server Administration
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.
Application Deployment
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
BEA WebLogic 7 Server Administration
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:
Application Deployment
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
BEA WebLogic 7 Server Administration
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:
Application Deployment
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
BEA WebLogic 7 Server Administration
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"/> ......
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
BEA WebLogic 7 Server Administration
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:
Application Deployment
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
BEA WebLogic 7 Server Administration
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.
Application Deployment
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
BEA WebLogic 7 Server Administration
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.
Application Deployment
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
BEA WebLogic 7 Server Administration
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:
Application Deployment
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
BEA WebLogic 7 Server Administration
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
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
145
146
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
•
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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.
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.
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
•
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
BEA WebLogic 7 Server Administration
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: •
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
Apache Xerces Parser and Transformer Configured in a New XML Registry
177
178
BEA WebLogic 7 Server Administration
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
BEA WebLogic 7 Server Administration
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.
Chapter 5:
Alternatively, you can specify the Root Element Tag name of the document. For the car.xml example, enter CAR in the Root Element Tag field. If your XML document defines a namespace, be sure to enter the fully qualified root element tag, such as VEHICLES:CAR.
7. Set the DocumentBuilderFactory or SaxParserFactory field to the appropriate Factory parser classes. For example, you can enter weblogic.xml.babel.jaxp .SAXParserFactoryImpl in the SaxParserFactory field. To WebLogic, this means that the FastParser will be able to parse this document type. Also remember that you don’t have to provide any information in the Parse Class Name field, as it is meant only for backward compatibility. 8. Continue by clicking the Create button, which will then create the XMLParserSelect registry entry.
Figure 5-18.
Configuring an XML parser using the Administration Console
181
182
BEA WebLogic 7 Server Administration
9. Select the name of the server in the left pane under the Servers node to associate the new XML Registry. 10. Select the Services tab in the right pane. 11. Select the XML tab. The window to configure XML properties of WebLogic Server appears in the right pane. 12. In the XML Registry field, select the XML Registry name that you want to associate with this server, and click the Apply button. 13. You will now be required to restart your server to have the new settings take effect.
CHECKLIST This chapter demonstrated the various ways to configure J2EE services and components supported and extended by WebLogic Server. You have acquired the skills necessary for configuring WebLogic Server HTTP parameters and configuring various J2EE components such as enterprise applications, JNDI, JMS, JTA, RMI, RMI-IIOP, and the XML Registry. We covered ■
Understanding distributed WebLogic architecture
■
Configuring HTTP parameters to help administer a Web server
■
Setting up and maintaining logs, which are important for finding facts if something goes wrong in the system
■
How a virtual host extends capabilities of your Web site
■
The importance of monitoring and logging information
■
Configuring JMS (Java Messaging Service)
■
Configuring and viewing the JNDI tree and objects under it
■
The exchange of data between disparate systems with the help of XML
■
How WebLogic is integrated with XML
CHAPTER 6 Application Security
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
183
184
BEA WebLogic 7 Server Administration
pplication security involves securing the critical data on the computer and maintaining the security and data integrity during data transactions. Any compromise of security can prove disastrous. Thus, security issues must be addressed as early as possible in the application design process. WebLogic Server provides comprehensive services to secure applications at different points. WebLogic 7 has a powerful security framework and provides a modular approach to security. It provides separate authentication, authorization, and encryption services plug-ins, which permit users to employ third-party or custom-implemented security services for their applications. This chapter covers the administration aspects of security features. It does not cover the programming aspects of security features in WebLogic applications, though some exposure to programming features will be covered when required. The focus of this chapter is on security features of WebLogic Server 7 and will not cover the deprecated features of prior versions; however, earlier versions may be cited for examples.
A
WEBLOGIC SERVER 7 SECURITY Java 2 Enterprise Edition (J2EE) addresses security issues; unfortunately, J2EE security methods are complex and time-consuming. They closely tie business logic to the implementation of security, which makes the whole process costly both in terms of time and resources. WebLogic Server 7 simplifies security by decoupling the implementation of security features with business logic. A user is given the flexibly to use the custom implementation of authentication, authorization, and encryption special programming interfaces (SPIs) into the WebLogic Server 7 security framework. Figure 6-1 describes this security framework. The following security features are included in WebLogic Server 7: •
Allow for single sign-on across the WebLogic server domain that contains your application resources. Single sign-on allows users to log on to the domain once per session rather than requiring them to log on to each resource or application separately.
•
Use J2EE standards and extend the standards where applicable to create a seamless framework that unifies security enforcement and presents security as a service to other WebLogic server components.
•
Are in a modular, pluggable architecture, into which an administrator can easy integrate a third-party security provider’s SPIs. Security architecture allows for the integration of external public key infrastructure (PKI) that supports key retrieval and revocation mechanisms such as certificate revocation list (CRL) and the Online Certificate Status Protocol (OCSP) into the WebLogic server environment.
•
Provide authorization via entitlement, which allows for security decisions based on business logic rather than programmatic constraints.
•
Support the dynamic computation of roles based on the context of request.
Chapter 6:
Figure 6-1.
Application Security
WebLogic Server 7 security model
•
Provide detailed auditing records for use in establishing trust.
•
Enable end-to-end security from Web browser to the mainframe.
•
Use a unified security administration model. The security for Enterprise JavaBeans (EJBs), servlets, Java Server Pages (JSPs), Web pages, and WebLogic Server resources such as (JMS) Destinations and Java Database Connectivity (JDBC) connection pools are managed in the same manner through the WebLogic Server Administration Console. The user can combine all these resources into an application for which she can also establish security. In addition, third-party security providers can be configured and managed though the WebLogic Server Administration Console.
•
Provide data integrity and privacy through the Secure Sockets Layer (SSL) protocol. The updated SSL capabilities also support the Transport Level Security (TLS v1) protocol.
185
186
BEA WebLogic 7 Server Administration
•
Provide integrated storage for security information, such as users, group, role mappings, and authorization information.
•
Are consistent across BEA products. The security framework is embedded in WebLogic Server and is then leveraged by other products such as BEA WebLogic Portal and BEA WebLogic Integration.
VERSION 7 VS. VERSION 6.1 SECURITY The security framework has been totally replaced in version 7. Users who are considering migrating to version 7 should also consider leveraging the security features in version 7. Table 6-1 gives a summary of updated features in version 7 as compared to version 6.1.
Version 6.1 Features
Version 7 Features
JNDI Authentication
JNDI authentication replaced by Java Authentication and Authorization Service (JAAS) authentication, which provides single sign-on. JAAS authentication enhanced to provide LoginModules for Internet Inter-ORB Protocol (IIOP), BEA implementation of RMI (T3), and Common Security Interoperability version 2 (CSI v2) clients. A BEA-supplied auditing provider allows users to customize the data they want to record and is available by default. A user doesn’t have to implement weblogic.security.Audit and can customize auditing needs by implementing the Auditing SPI. No specific system password is used in version 7. ACLs used in WebLogic 6.1 is deprecated and replaced by roles. Still used, but instead of assigning ACLs to a resource that allows a user or group access to that resource, the user now assigns an entitlement. All security realms are deprecated in version 7. BEA-provided authentication and authorization providers supply the functionality offered by the file, catching, and LDAP realms. The realm adapter is available to allow users to continue to employ the existing security realms as they migrate to the new authentication and authorization scheme. Support for multiple security providers. Lets you add and remove security providers; a new feature that was unavailable in previous releases. Keystore for storing digital certificates and public keys. Uses Sun implementation of keystore. A feature of JDK 1.3. Keystore is used to store public keys for public certificates. A new feature that was not available in previous versions. Provides enhanced SSL support and is updated to provide the Java Secure Socket Extension (JSSE) standard and the Transport Layer Security protocol (TLS v1).
JAAS Authentication
Auditing
System Password Access Control List (ACL) Users and Groups Security Realms: File Realm, Catching Realm, Lightweight Data Access Protocol (LDAP), Windows NT, UNIX, and RDBMS Security Realms Concept of Security Provider was not available in prior versions Keystore feature was not available in prior versions
SSL protocol
Table 6-1.
A Comparison of Security Features Between Versions 6.1 and 7
Chapter 6:
Application Security
WEBLOGIC 7 SECURITY SERVICE Security providers are modular components that handle specific aspects of security, such as authentication and authorization. WebLogic Server 7 ships with both. Users can write custom security providers and plug into the WebLogic security framework or integrate a third-party security product.
WebLogic Security Framework The WebLogic security framework is initialized at the startup of the WebLogic Server, at which time it •
Initializes all security services
•
Provides access to all security services
•
Retrieves the WebLogic Server boot and kernel identities
WebLogic Authentication Framework Authentication necessarily means establishing the identity of user or system process. The WebLogic authentication framework consists of a default authentication provider and APIs for building the custom authentication provider and delivers a common approach for client identity authentication across WebLogic application containers. It seamlessly supports the augmentation or replacement of WebLogic out-of-the-box authentication providers with third-party version(s) that support the WebLogic Authentication SPI. WebLogic Server security architecture supports certificate-based authentication directly with WebLogic Server, HTTP certificate-based authentication, authentication proxied through an external Web server, perimeter-based authentication (Web server, firewall, and VPN), and multiple security token types and multiple protocols (SOAP, IIOP, and CSIv2). In the WebLogic Server security architecture, an authentication provider is used to provide these services. A complete authentication provider contains the following components (as shown in Figure 6-2): •
Login module
•
Identity assertion provider
•
Principal validation provider
These components are created through implementations of the JAAS LoginModule interface and the IdentityAsserter and PrincipalValidator SPIs, respectively. An implementation of the JAAS LoginModule interface is the part of an authentication provider that contains the actual authentication behavior. The user can include additional LoginModules if needed, but only one is required. Implementation of the IdentityAsserter SPI is necessary if a user wants to establish a client’s identity through the use of clientsupplied tokens, and an identity assertion provider must also have one LoginModule associated with it. The PrincipalValidator SPI is necessary to protect the principals that LoginModules store within the subject.
187
188
BEA WebLogic 7 Server Administration
Figure 6-2.
WebLogic authentication framework
In addition to these three components, an authentication provider needs to supply an implementation of the AuthenticationProvider SPI, which exposes the services of the custom authentication provider to the WebLogic security framework. The AuthenticationProvider SPI also provides support for user and group management.
JAAS LoginModules The LoginModule interface is based on JAAS, which uses a Subject as a container for authentication information. All LoginModules are responsible for authenticating users within the security realm and for populating the JAAS Subject with the necessary Principals (users/groups). The primary benefit of the LoginModule interface is that it allows you to implement and plug in different kinds of authentication technologies for use with a single application. For example, one type of LoginModule may perform a username/passwordbased form of authentication (such as the one included in WebLogic). Others may interface with hardware devices such as smart cards or biometric devices. The WebLogic security framework is designed to support multiple LoginModules for multipart authentication. Therefore, for example, if you want an administrator to use both a retina scan and a username/password-based form of authentication to access a system, you can create and use two LoginModules as part of your custom authentication provider. You can also have dependencies across LoginModule instances or share credentials across these instances.
Identity Assertion Providers While LoginModules seek proof of an entity’s identity based on usernames/passwords or identification devices inside the request, identity assertion involves establishing a client’s identity through the use of client-supplied tokens that may exist outside the request. Thus, the function of an identity assertion provider is to validate and map a token to a username. Identity assertion providers support perimeter authentication by passing tokens in HTML headers or cookies. The WebLogic authentication provider
Chapter 6:
Application Security
provides support for identity assertion using X509 certificates and CSI v.2, but you can write custom authentication providers that support additional token types as well. Other client-supplied tokens you may want to support are Kerberos, SAML, and Microsoft Passport. You can create custom identity asserter providers by implementing the IdentityAsserter Security Service Provider Interface (SSPI) and, if desired, one or more associated LoginModules. When used with a LoginModule, identity assertion providers support single sign-on. For example, the identity asserter provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.
Principal Validation Providers Principal validation involves verifying the authenticity of principals associated with Java Authentication and Authorization Service (JAAS). When you create a principal validation provider by implementing the PrincipalValidator security SPI, the WebLogic security framework will use it to verify the authenticity of the subject’s principals during the WebLogic Server’s demarshalling of Remote Method Invocation (RMI) client requests for each invocation. Such verification provides an additional level of trust and may reduce the likelihood of malicious principal tampering. WebLogic Server 7 ships with a default authentication provider. It is up to the user to implement a custom authentication provider or plug in a third-party authentication provider if he so chooses. To learn how to configure an authentication provider, see “Administration and Configuration of Security Providers,” later in this chapter.
WebLogic Authorization Framework The WebLogic authorization framework contains a default authorization provider that authorizes a user to employ a specific resource. WebLogic Server security architecture supports the following: •
Security policies Also known as dynamic role associations, allow for the late binding of role associations to principals. This occurs after considering the context of a request.
•
Parametric authorization Allows an authorization decision about a protected resource to be determined based on the context of the request.
The authorization SSPIs that define the mechanisms used to support security policies and parametric authorization are based on a delegated authorization design that results in the point of enforcement being moved to the provider of the functionality (that is, the SSPI implementation), rather than within WebLogic Server itself. The methods defined in the authorization SSPIs are designed specifically to support a capabilities-based authorization mechanism, which may be particularly useful if you want to incorporate authorization products from third-party security vendors. However, the authorization SSPIs also handle permission-based implementations.
189
190
BEA WebLogic 7 Server Administration
A complete authorization provider contains the following components (as shown in Figure 6-3): •
An access decision provider
•
An adjudication provider
•
A role-mapping provider
These components are created through implementations of the AccessDecision, Adjudicator, and RoleMapper SSPIs, respectively. An implementation of the AccessDecision interface is the part of an authorization provider that contains the actual authorization behavior by answering the question “is access allowed?” with either PERMIT, DENY, or ABSTAIN. An implementation of the Adjudicator SSPI is necessary if you have multiple access decision providers that may return conflicting results. In cases like these, adjudication providers determine the final answer by weighing each access decision provider’s answer. An implementation of the RoleMapper SSPI allows you to obtain a computed set of roles so that access decision providers can answer the “is access allowed?” question for resources that use role-based security. In addition to these three components, any authorization provider needs to supply an implementation of the AuthorizationProvider SSPI, which exposes the services of the custom authorization provider to the WebLogic security framework. Similarly, if you create adjudication or role-mapping providers, you must supply implementations of the AdjudicationProvider and RoleProvider SSPIs, respectively, to expose these services to the WebLogic security framework.
Access Decision Providers Access decision providers are asked whether a subject has permission to perform a given operation on a resource, with specific parameters in an application. Given this
Figure 6-3.
Authorization provider
Chapter 6:
Application Security
information, access decision providers should respond with an answer of PERMIT, DENY, or ABSTAIN. All authorization providers require an access decision provider because it is this feature that answers the “is access allowed?” question.
Adjudication Providers When multiple access decision providers are configured, each may return a different answer to the “is access allowed?” question for a given resource. Answers returned will be PERMIT, DENY, or ABSTAIN. Determining what to do if multiple access decision providers do not agree on an answer is the primary function of an adjudication provider. In other words, adjudication providers resolve authorization conflicts by weighing each access decision provider’s answer and returning a final result: •
If all access decision providers return PERMIT, then PERMIT.
•
If any access decision providers return DENY, then DENY.
•
If some access decision providers return ABSTAIN and others return PERMIT, then PERMIT if unanimous permit is not required; otherwise, DENY.
Adjudication providers may also specify what should be done when an answer of ABSTAIN is returned from a single authorization provider, based on a specific security policy. If you are planning to use multiple authorization providers, you will need an adjudication provider. You can create custom adjudication providers for use with your authorization providers by implementing the AdjudicationProvider SSPI (which ties the adjudication provider into the WebLogic security framework) and the Adjudicator SSPI (which provides the actual security-related behavior for a custom adjudication provider).
Role-Mapping Providers Role-mapping providers support security policies (dynamic role associations) by obtaining a computed set of roles granted to a requestor for a given resource. They supply authorization providers with this role information so that the authorization provider can answer the “is access allowed?” question for resources that use role-based security (that is, Web application and EJB container resources). Using role-mapping providers is optional; but if you create a role-mapping provider, the WebLogic security framework will use business logic and the current operation parameters (obtained from the J2EE and WebLogic deployment descriptor files) to determine which roles (if any) apply to a particular subject at the moment in which access is required for a given resource. If multiple role-mapping providers are configured, the WebLogic security framework will intersect the set of roles returned by all rolemapping providers.
191
192
BEA WebLogic 7 Server Administration
You can create custom role-mapping providers by implementing the RoleProvider SSPI (which ties the role-mapping provider into the WebLogic security framework) and the RoleMapper SSPI (which provides the actual security-related behavior for a custom role-mapping provider).
WebLogic Auditing Framework The auditing framework consists of a default audit provider and APIs to write custom audit providers. An audit provider audits the information about an operating request and the outcome of that request, and then stores that information. It helps in determining the functioning and health of an application. If configured, the WebLogic server framework will call through an auditing provider before and after security operations (such as authentication or authorization) have been performed, enabling audit event recording. The decision to audit a particular event is made by the auditing provider itself and can be based on specific audit criteria and/or severity levels. The records containing the audit information may be written to output repositories such as an LDAP back end, a database, or a simple file. Auditing providers may also decide to implement actions, such as paging security personnel. The auditing SSPI comprises three interfaces: •
AuditProvider Exposes the services of a custom auditing provider to the WebLogic security framework.
•
AuditChannel Determines the security event that should be audited and performs the actual audit of information based on quality of service (QOS) policies.
•
AuditEvent Facilitates implementations of the AuditChannel interface to call the correct security component (authentication, authorization, or management) and operation (login, security operation, or logoff). The AuditEvent interface also specifies the severity level from which an audit decision can be made.
Together, implementations of the AuditProvider, AuditChannel, and AuditEvent SSPIs provide the actual behavior for a custom auditing provider. SSPIs that may be implemented to provide additional support for an auditing provider include a series of convenience AuditEvent interfaces, as shown in Figure 6-4.
Convenience AuditEvent Interfaces The convenience AuditEvent interfaces, which help auditing providers determine the type of event objects more efficiently, are described here: •
AuditAtnEvent Interface for determining the instance types of extended authentication-event type objects.
•
AuditAtzEvent Interface for determining instance types of extended authorization-event type objects.
Chapter 6:
Figure 6-4.
Application Security
Audit provider
•
AuditAtzRedeployEvent Interface for determining instance types of extended authorization-event type objects.
•
AuditMgmtEvent Interface for determining instance types of extended security management event type objects.
•
AuditRoleEvent Interface for determining instance types of extended role-mapping event type objects.
Keystore Provider A standard J2EE provider, a keystore is a password-protected database of private and public keys of certificates. JDK1.3 ships with reference implementation of keystore. One can write a custom keystore by implementing the necessary interfaces, as shown in Figure 6-5. WebLogic Server ships with reference implementation of keystore from Sun.
Figure 6-5.
Keystore provider architecture
193
194
BEA WebLogic 7 Server Administration
ADMINISTRATION AND CONFIGURATION OF SECURITY PROVIDERS WebLogic Server’s Administration Console has detailed and easy-to-use options for configuring and administering security features.
Creating a Role A client accesses the resources in a capacity of a role. For example, a client with a deployer role will have all the privileges and accesses to deploy an application. The Administration Console provides an easy way to create a role. 1. Log in to the Console application. 2. Browse the left pane of the Console window. 3. In the Security node, click Realms. 4. Browse the default security realm and click Roles to open the page shown in Figure 6-6, which displays all default roles and role mappers. Default roles are •
Deployer
•
Operator
•
Anonymous
•
Admin
•
Monitor
Figure 6-6.
Default roles and the option to create a role
Chapter 6:
Application Security
To create a new role follow, follow these instructions: 1. Click Configure A New Role in the right pane. The window shown in the following illustration will open.
2. Type Part Time Operator in the name Field and then click Apply. (You can actually name the role anything you like.) The role will be added to the list of the roles, as shown next.
3. To configure the conditions for the part time operator role, click the Conditions tab, as shown next, and modify the conditions for the role created.
4. When you’re done, click Apply.
195
196
BEA WebLogic 7 Server Administration
Creating/Adding a User To create a user, follow these instructions: 1. Log in to the Console application. 2. Browse the left pane navigation tree and click the Security node. 3. Under Realms, click the Users node. Then click Configure A New User in the pane on the right; you should see a screen like the following illustration.
4. Enter information for the following options, and then click Apply. •
Name
Name of the user
•
Description Description of the user
•
Password Password for the user
•
Confirm Password Type in the password again
5. To add the user to a group, click the Groups tab, select the group from the Possible Groups table, and add it to the Current Groups table, as shown in the following illustration. Click Apply.
Chapter 6:
Application Security
6. To change the password for the user, click the General tab, shown in the following illustration, and click Change (next to the Password field). Then click Apply.
Creating a Group To create a group, follow these instructions: 1. Log in to the Console application. 2. Browse the navigation tree and click Security. 3. Browse Realms and click the Groups node. Then click Configure A New Group in the right-hand pane to display the following screen.
4. Configure the following options. •
Name
•
Description
Name of the group Description of the group
5. Click Apply. 6. To change the membership of the group, click the Membership tab and modify the membership. You can move a group from Current Group to Possible Groups, and vice versa, by selecting a group and using the left and right arrow buttons.
197
198
BEA WebLogic 7 Server Administration
Configuring and Administering Providers The Administration Console provides an easy way to configure and administer security providers in a WebLogic Server domain. Browse to Security\Realms\myrealm\Providers. Under this node, you will find the following providers: •
Adjudicators
•
Auditors
•
Authentication Providers
•
Authorizers
•
Credential Mappers
•
Keystore
•
Role Mappers
To configure authentication providers, follow these steps: 1. Log in to the Console application. 2. Browse the navigation tree and click Security. 3. Browse the Realms node and click myrealm, and then Providers. 4. Click Authentication Providers. You will see the types of authentication providers that can be configured, as shown in Figure 6-7. •
iPlanet Authenticator
•
Active Directory Authenticator
•
Realm Adapter Authenticator
•
Default Authenticator
•
Default Identity Asserter
•
Open LDAP Authenticator
•
Novell Authenticator
You will also see that DefaultAuthenticator and DefaultIdentityAsserter are already configured. Let’s configure a new iPlanet Authenticator. 1. Click the Configure A New IPlanet Authenticator link. 2. Configure the following attributes, shown in Figure 6-8: •
Name
•
Control Flag Determines how the login sequence will use the authentication provider. A REQUIRED value means this authentication
Name of the provider
Chapter 6:
Figure 6-7.
Application Security
Authenticator provider options
provider is required to succeed. Regardless of whether it succeeds, the authentication will proceed to other authentication providers that have been configured as part of the login sequence. A REQUISITE value also requires this authentication provider to succeed. If it succeeds, authentication proceeds to other authentication providers; if it fails, control immediately returns to the application (authentication does not proceed). A SUFFICIENT value does not require this authentication provider to succeed. If it succeeds, control immediately returns to the application (but authentication does not proceed to other authentication providers). If it fails, authentication proceeds
Figure 6-8.
Configuring iPlanet General tab options
199
200
BEA WebLogic 7 Server Administration
to other authentication providers, which have been configured as part of the login sequence. An OPTIONAL value does not require this authentication provider to succeed. Regardless of whether it succeeds, the authentication will proceed to other authentication providers, which have been configured as part of the login sequence. 3. Click Create. 4. To configure LDAP options for the authenticator, click the iPlanet LDAP tab and configure following options: Host name or IP address of the LDAP server
•
Host
•
Port Port number on which LDAP server is listening
•
SSL Enabled Checkbox to indicate that the user wants to enable SSL to connect to LDAP
•
Principal Distinguished Name (DN) of the LDAP user
•
Credential (Principal)
•
Cache Enabled
•
Cache Size
•
Cache TTL Time to live (TTL) of the LDAP cache in seconds (default cache TTL is 60 seconds)
Credential (password) to authenticate the LDAP user Enables the cache for the LDAP request
Size of the LDAP cache in KBs (default cache size is 32KB)
5. Click Apply.
Configuring and Administering Adjudicators WebLogic Server has a default adjudicator. You can configure a new default adjudicator to replace the existing one. To configure a new default adjudicator, follow these steps: 1. Log in to the Console application. 2. Browse the navigation pane and click Security. 3. Browse the Realms\myrealms node and click Providers. 4. Click the Adjudicators node. 5. Click the Replace With A New Default Adjudicator link. 6. Enter the name of the adjudicator and select the Require Unanimous Permit checkbox, shown in Figure 6-9. Keeping this option checked requires all authorization providers to vote PERMIT in order for the adjudication provider to vote PERMIT. If the attribute is disabled, ABSTAIN votes are ignored. 7. Click the Create button.
Chapter 6:
Figure 6-9.
Application Security
Creating a new adjudicator
Configuring and Administering Authorizers To configure an authorizer, follow these steps: 1. Log in to the Console application. 2. In the navigation tree, click Security. 3. Browse the Realms\myrealms nodes and click Providers. 4. Click the Authorizers node. 5. Click the Configure A New Default Authorizer link. 6. Enter the name of the authorizer, as shown in Figure 6-10, and select the Policy Deployment Enabled checkbox. Enabling this option indicates that this authorization provider will store policies that are created while deploying a Web application or EJB. 7. Click the Create button.
Configuring and Administering a Credential Mapper To configure the credential mapper, follow these steps: 1. Log in to the Console application. 2. In the navigation tree, click Security. 3. Browse the Realms\myrealms nodes and click Providers. 4. Click the Credential Mappers node.
201
202
BEA WebLogic 7 Server Administration
Figure 6-10.
Configuring an authorizer
5. Click the Configure A New Default Credential Mapper link to open the window shown in Figure 6-11. 6. Enter the name of the credential mapper. 7. Select the Credential Mapping Deployment Enabled checkbox. This checkbox indicates if this Credential Mapper provider will store credential maps created while deploying a resource adapter. 8. Click Create.
Figure 6-11.
Options for creating a credential mapper
Chapter 6:
Application Security
Configuring and Administering a Keystore To configure and administrate a keystore, follow these steps: 1. Log in to the Console application. 2. In the navigation tree, click Security. 3. Browse the Realms\myrealms nodes and click Providers. 4. Click the Key Stores node. 5. Click the Configure A New Default Key Store link to open the window shown in Figure 6-12. 6. Enter the name of the keystore and configure the following options: •
Name
•
Version
•
Description
•
Private Key Store Location
•
Private Key Store Pass Phrase
•
Root CA Key Store Location
•
Root CA Key Store Pass Phrase
7. Click the Create button.
Figure 6-12.
Options for creating a new keystore
203
204
BEA WebLogic 7 Server Administration
Figure 6-13.
Configuring a role mapper
Configuring and Administering Role Mappers To configure a role mapper, follow these steps: 1. Log in to the Console application. 2. In the navigation tree, click Security. 3. Browse the Realms\myrealms nodes and click Providers. 4. Click the Role Mappers node. 5. Click the Configure A New Default Role Mapper link to open the window shown in Figure 6-13. 6. Enter the name of the role mapper and click Create.
CHECKLIST In this chapter, we discussed the new security model for WebLogic Server 7 in detail. We covered the new security framework and security providers available. After reading this chapter, you should have an understanding of new security framework options in WebLogic Server 7, and you should be able to administer and configure authentications providers, authorizers, credential mappers, role mappers, adjudicators, and keystore. You should also be able to create different roles and create users and groups. Here are the key concepts you should understand from this chapter: ■
Security features in WebLogic Server 7
■
Version 7 security versus Version 6.1
■
WebLogic security framework
■
Configuration and administration of authentication providers
■
Configuration and administration of authorization providers
Chapter 6:
■
Configuration and administration of auditor providers
■
Configuration and administration of keystore providers
■
Configuration and administration of users and groups
■
Configuration and administration of roles and policies
■
Configuration and administration of role mappers
Application Security
205
CHAPTER 7 WebLogic Server and HTTP Servers
Copyright 2002 by The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
207
208
BEA WebLogic 7 Server Administration
his chapter focuses on one of the crucial wings of administration. It provides the information an administrator needs to change and deploy WebLogic Server, leveraging existing infrastructure and installations of other Web servers such as Microsoft Internet Information Server (IIS), Apache, or NetScape/iPlanet. We will cover how to proxy client requests from other Web servers to WebLogic Server and also how to proxy requests from clients of WebLogic Server to a secondary HTTP server.
T
WEBLOGIC HTTP SERVER There are numerous players in the Web server arena, including WebLogic, Microsoft Internet Information Server (IIS), IBM WebSphere, Netscape Enterprise Server (NES), Apache, and many others. WebLogic was not an early server in the industry, but it has proved to be very strong and has captured a huge portion of the Web server market. As it was a latecomer, many organizations already had a Web server in place when WebLogic came on the scene. However, because of its popularity, many organizations have been looking to switch over to WebLogic Server. However, this presents a whole host of issues with which to contend. It’s not just a matter of shifting to a new product. If there are already applications running on the existing Web server environment and more are tacked on with the installation of the WebLogic server, the real challenge lies in how those applications are linked and how they can be integrated while relying on different technologies. As an administrator, when an organization asks you to make WebLogic Server its primary Web server, you may also want to configure WebLogic Server to pass on, or proxy, certain requests to a secondary HTTP server, such as to a Netscape Enterprise, an Apache, or a Microsoft IIS server. Any request that gets proxied can be redirected to a specific uniform resource locator (URL). You can even proxy to another Web server on a different machine. You have to proxy requests based on the URL of the incoming request. The HttpProxyServlet (provided as part of the WebLogic Server distribution) takes an HTTP request, redirects it to the proxy URL, and sends the response to the client’s browser back through WebLogic Server. To use the proxy, you must configure it in a Web application and deploy that Web application on the WebLogic server that is redirecting requests. In order to use WebLogic as a proxy to other Web servers, you must install Web server plug-ins for the other Web servers.
WHAT IS A PLUG-IN? A plug-in is a small piece of software with which we can extend the boundaries and capacities of WebLogic Server implementation. With the help of plug-ins, it becomes possible for WebLogic Server to communicate with other Web servers and to access Web applications that have been deployed on those servers. WebLogic Server comes equipped with plug-ins for the following Web servers: •
Microsoft IIS
•
Apache
•
Netscape Enterprise Server/iPlanet FastTrack Server
Chapter 7:
WebLogic Server and HTTP Servers
WEBLOGIC AND NETSCAPE/IPLANET The Netscape Enterprise Server (also known as iPlanet FastTrack Server) Web server plug-in allows client requests to be proxied when they originate from a Netscape Enterprise server being redirected to a WebLogic server capable of handling requests that require the dynamic functionality of WebLogic Server. If you are working in an environment in which Netscape Enterprise Server is required to serve static information to the clients, WebLogic Server can generate dynamic pages using HTTP servlets and Java Server Pages (JSPs). The Netscape Enterprise Server plug-in operates as an NSAPI (Netscape Application Programming Interface) module within Netscape Enterprise Server. The NSAPI module is loaded as soon as the NES server is started. The role of the NSAPI module is similar to HTTP servlets, with the exception that it is written in code native to the application instead of Java. Proxying the request is based on either the URL of the request, known as proxying by path, or on the basis of MIME types (file extensions like .jhtml and .jsp).
NOTE You can also obtain WebLogic Server services with the help of the NES plug-in and the HTTP tunneling facility exposed by WebLogic Server.
Installing and Configuring Netscape Enterprise Server/iPlanet FastTrack Server Plug-In The Netscape Enterprise Server plug-in is available as a library module for various platforms such as IBM AIX, Compaq Tru64 UNIX, HP-UX, RedHat Linux, Solaris, and Windows NT and 2000. This support is for WebLogic Server 6.0 and above. Following is how to install and configure the NES plug-in: 1. Locate the library module for the platform on which you are running Netscape Enterprise Server/iPlanet FastTrack Server. It is distributed as a shared object file (.so) for UNIX-flavored platforms and as a Dynamically Linked Library (DLL) file (.dll) for Microsoft platforms. These modules are available in the /lib or /bin folder when you install WebLogic Server. For the purpose of this chapter, we will use the example of a DLL distribution. 2. Copy the file proxy36.dll to the C:\Netscape\Servers\bin folder, where Netscape Enterprise Server is installed. Next, in the obj.conf file, you need to define what requests will be proxied to WebLogic Server. NES plug-in uses the information contained in obj.conf to identify how it should proxy the client request to WebLogic Server—that is, by path or MIME type. 3. Locate the file obj.conf under the \config folder for the NES Server instance. Look under the path C:\Netscape\Servers\https-KEYMAN\config. If you have
209
210
BEA WebLogic 7 Server Administration
NES installed on some other platform, you must use the following information to locate the file: NETSCAPE_HOME\https-NSTANCE_NAME\config\obj.conf Here, NETSCAPE_HOME is C:\Netscape, https-NSTANCE_NAME is https-KEYMAN, and config\obj.conf is what we are looking for. 4. Add the following lines to the obj.conf file. These lines must be in the beginning section of the file: Init fn="load-modules" funcs="wl_proxy,wl_init"\ shlib=/usr/local/netscape/plugins/SHARED_LIBRARY Init fn="wl_init".
The function "load-modules" tags the shared library for loading when NES starts up. The values "wl_proxy" and "wl_init" identify the functions that the Netscape Enterprise Server plug-in executes. 5. If you want to proxy client requests through URLs (i.e., to proxy by path), you will be required to create a separate
