Configuring WebLogic and J2EE Services

The Services node in the navigation tree contains subnodes for each of the WebLogic and J2EE services provided by WebLogic Server. Each service may control multiple resources that are individually configured and monitored. The services available on WebLogic Server 8.1 are

• jCOM

• JDBC

• JMS

• Messaging Bridge

• XML

• JTA

• SNMP

• WTC

• WLEC (deprecated)

• Jolt

• Virtual Hosts

• Mail

• FileT3 (deprecated)

Each of the WebLogic and J2EE services is individually created and configured from the WebLogic Administration Console. Many of the services must be deployed on WebLogic Server after being created. The initial console page for each service enables you to create a new instance of the service. After a service instance has been created, the Target and Deploy tab on the console page becomes enabled for a service that requires deployment. Figure 35.30 shows an example of the Deploy and Target console page for a JDBC MultiPool.

The following resources include a Target and Deploy tab on their console page:

• JDBC MultiPool

• JMS Connection Factories

• JMS Foreign JMSServer

• Messaging Bridge

• XML Registry

• WTC Service

• Jolt Connection Pool

• Virtual Host

• Mail Session

In addition to the resources listed, the JDBC Connection Pool and JDBC DataSource combine creating and deploying on a target server or cluster as the final step in creating the new instance. Also, the Domain Log Filters configuration includes a Targets tab that enables you to specify the servers on which you would like to use the domain log filter. The form to target servers for the domain log filter has the same format. However, in this case, you are not deploying the filter; you are requesting the server to use the filter.

The following sections provide a brief description for each of the services, as well as instructions for configuring and monitoring the resources used by that service.

Configuring the jCOM Service

The jCOM service enables Microsoft COM clients, such as Microsoft Excel, to call methods on Java classes deployed on WebLogic Server. The console page for jCOM configuration includes a Define Security Policy button to define access for the COM class via a security policy. Figure 35.31 shows the console page for defining a security policy.

To create the policy statement, select a condition from the Policy Condition list that must be met, and then click the Add button. A pop-up window will display specific to the selected condition. The additional information for the specific policy condition is entered on the pop-up window. Figure 35.32 shows the pop-up window for the User Name of the Caller Is policy condition. To configure the policy, type a username in the text field, and then click the Add button. Repeat this for as many usernames as necessary. When all the usernames have been added, click the OK button to store the policy condition.

Configuring the JDBC Service

The JDBC service contains the resources used by Java Database Connectivity. The resources for JDBC are

• Connection pools

• MultiPools

• Data sources

• Data source factories

The initial console page for each of the JDBC services provides a link to configure a new instance for the selected service type. The following sections provide instruction for configuring the JDBC resources.

Configure a JDBC Connection Pool

A JDBC connection pool manages the connections between your applications and the database. The JDBC connection pool encapsulates the JDBC driver. The configuration for a JDBC connection pool requires you to select the database type and database driver that are associated with the new connection pool. A JDBC data source links an entry in the JNDI tree to a JDBC connection pool. The application looks up a JDBC data source to gain access to the connection pool. A connection pool is a very efficient way to manage the open connections between applications and the database. During the startup of WebLogic Server, the configured connection pools are registered and immediately create JDBC connections. The applications borrow connections from the connection pool, use them, and return them to the connection pool by closing the JDBC connection.

Figure 35.33 shows the console page that is displayed after clicking the Configure a New JDBC Connection Pool link. The first step is to choose a database by selecting the database type and database driver. The default database type is PointBase and the default database driver is PointBase's Driver (Type 4XA) Versions:4.X.

After selecting the database type and driver for the installed database, click the Continue button at the bottom right of the console page. The next step is to define the connection properties, as shown in Figure 35.34.

The third step for connection pool configuration is to test the driver configuration. This console page includes a Test Driver Configuration button to test the database connection.

The fourth and final step is to create and deploy the connection pool on the targeted WebLogic Server. Figure 35.35 shows the Create and Deploy page for a system that has only one WebLogic Server.

Configure a JDBC MultiPool

A JDBC MultiPool is a pool of connection pools that are configured for load balancing or high availability. The required configuration to create a MultiPool is the name and algorithm type for the MultiPool. The algorithm type is either High-Availability or Load-Balancing. After the MultiPool has been created, the Pools tab becomes enabled. The Pools Configuration page enables you to select from a list of available connections pools to include as part of the MultiPool. Figure 35.36 shows the console page for the Pools tab.

The configured MultiPool must be targeted for deployment before it can be used, as shown earlier in this chapter in Figure 35.30.

Configure a JDBC Data Source

A JDBC data source provides a link between a JNDI tree and a connection pool. The configuration for a JDBC data source is its JNDI name and the associated connection pool. The final step in creating a new JDBC connection pool is to target and deploy on a server.

The JDBC connection pool must be associated with a connection pool and deployed on a server before it can be used. The application looks up the JDBC data source name using JNDI to retrieve a data source object. The connection request made on the data source is supplied by the associated connection pool.

Configure a JDBC Data Source Factory

An enterprise application deployed on WebLogic Server might provide a supplemental deployment descriptor named weblogic-application.xml, which is used to configure application scoping. Within the deployment descriptor, you can configure JDBC connection pools and associated data sources that are created when the application is deployed. Data sources and connection pools created in this manner are known as application-scoped data sources and application-scoped connection pools.

A JDBC data source factory provides the default connection pool values for an application-scoped connection pool. An enterprise application that creates application-scoped connection pools requires that a data source factory be created before it can be deployed. The Administration Console help for JDBC data source factories contains a Tasks link for "Creating and Configuring a JDBC Data Source Factory." The console help also provides direct links to the related topics "Application-Scoped JDBC Data Sources and Connection Pools" and the e-docs "Resource Factories" in Programming WebLogic EJB.

Configuring the JMS Service

The JMS service contains the resources used by the Java Messaging Service. The resources for JMS are

• Connection factories

• Templates

• Destination keys

• Stores

• Distributed destinations

• Servers

• Foreign JMS servers

The initial console page for each of the JMS services provides a link to configure a new instance for the selected service type. The following sections provide instruction for configuring the JMS resources.

JMS Thresholds and Quotas

The threshold and quotas enable you to define the maximum messages/byte quotas, the upper and lower message/byte thresholds, the maximum allowable message size, and whether message and/or byte paging is enabled for the JMS resource. The Threshold & Quotas tab is located on the configuration page and is enabled after the JMS resource has been created. The following JMS resources allow configuration for Thresholds & Quotas:

• JMS templates

• JMS distributed topics

• JMS distributed queues

• JMS servers

Configure a JMS Connection Factory

Connection factories are objects that enable JMS clients to create JMS connections. A connection factory is thread-safe; it allows multiple threads to access the JMS connections simultaneously. After you've defined a JMS server, you can configure multiple connection factories to create connections with attributes predefined by that connection factory. The configuration for a JMS connection factory is organized on three tabs:

• General

• Transactions

• Flow Control

The general configuration is where you specify the name and JNDI name for the connection factory, as well as configure the attributes that control the delivery of messages by JMS connections created by this factory. After the JMS connection factory has been created, it must be targeted and deployed on a server before it can be used. The Administration Console help for the JMS connection factory provides a step-by-step guide titled "Configuring a JMS Factory." The related topics in e-docs are "WebLogic JMS Fundamentals," "Managing WebLogic JMS," and "Developing a WebLogic JMS Application."

Configure JMS Templates

The JMS template attributes are inherited by the JMS destinations that use them, with the exception of the Name attribute, which is used by only the JMS template. The General Configuration page for a JMS template enables you to specify its name and choose from existing JMS destination keys to inherit from the JMS template. Figure 35.37 shows the configuration console page for a JMS template.

The General Configuration page is used to create a JMS template. After the template has been created, the Override, Redelivery, and Expiration Policy tabs become enabled.

The last tab on the JMS template configuration page is Expiration Policy. The expiration policy applies to expired messages found on a JMS destination. The choices are (none), Discard, Log, and Redirect. The (none) and Discard settings have the same effect: The expired message is removed from the system without being logged. The Log setting specifies that a log message be written to the server log file when the expired message is removed. The Redirect option indicates that the message is moved to the error destination defined for the topic. When the expiration policy is set to Log, the Expiration Logging Policy setting enables you to specify what information about the message is logged. See the online help for detailed information about the valid logging policy details.

Configure JMS Destination Keys

You create JMS destination keys to define the sort order for messages that arrive on a specific JMS destination. The JMS queues and JMS topics that you create use the JMS destination key to order the messages that arrive at that destination. The Administration Console help for the JMS destination key provides a step-by-step guide for "Configuring a JMS Destination Key." The related topics in e-docs are the same as those specified for "Configuring a JMS Connection Factory."

Configure JMS Stores

A JMS store is a physical repository for storing persistent message data and durable subscribers. A JMS store can also be used for paging messages to disk when memory has been exhausted. A store is created either as a JMS JDBC store or a JMS file store. A JMS JDBC store is associated with the JDBC connection pool that provides the database connection. A JMS file store is associated with an existing directory on the file system. A file store enables you to specify the synchronous write policy that defines how the store will write data to the disk. The Administration Console help for JMS JDBC Store contains a task link for Creating a JMS JDBC Store. The Administration Console help for JMS File Store contains a task link for Creating a JMS File Store. Each task link provides a step-by-step guide for creating the respective JMS store. A direct link for the related topic on e-docs, "WebLogic JMS Fundamentals," is provided on the Administration Console help for either type of JMS store.

Configure JMS Distributed Destinations

JMS distributed destinations enable you to configure multiple physical JMS destinations as members of a single distributed destination that can be served by multiple WebLogic Server instances in a cluster. You can add multiple JMS topics to a distributed topic, and add multiple JMS queues to a distributed queue. See the section "Configure JMS Servers" later in this chapter for information on configuring physical JMS topics and JMS queues.

The console page for the Members tab enables you to configure a new distributed topic member for a distributed topic and configure a new distributed queue member for a distributed queue. The member configuration for a distributed queue is used to map a distributed queue member name to a physical JMS queue. The member configuration for a distributed topic is used to map a distributed topic member name to a physical JMS topic.

Configure JMS Servers

A JMS server manages connections and message requests on behalf of JMS clients. A JMS server contains the configuration for one or more JMS destinations, which are JMS queues or JMS topics. A JMS queue provides point-to-point communication. A JMS topic acts as a publish/subscribe repository for messages. After the JMS server has been created, the Configure Destinations link is added to the bottom of the general configuration console page for the JMS server. This link enables you to create and configure physical JMS queues and JMS topics. The JMS server also supports session pools that enable an application to process messages concurrently. JMS session pools are rarely used because they are not a required part of the J2EE specification and do not support JTA user transactions. The JMS session pools are superceded by message-driven beans (MDBs).

The Administration Console help for JMS destinations provides a step-by-step guides named "Creating a JMS Topic" and "Creating a JMS Queue."

Configure Foreign JMS Servers

A foreign JMS server maps foreign JMS connection factories and foreign JMS destinations into the local WebLogic JNDI tree. This allows foreign JMS connection factories and destinations to appear in the WebLogic JNDI tree as local JMS objects. The configuration for the foreign JMS server specifies the information that allows WebLogic Server to reach the remote JNDI provider. After the foreign JMS server has been created, the Configure Foreign JMSConnectionFactories and Configure Foreign JMSDestinations links are added to the bottom of the configuration console page for the foreign JMS server. These links enable you to specify the mapping between the local JNDI name and the remote JNDI name for the JMS connection factory or JMS destination, respectively. The Administration Console contains a Tasks link named Creating a Foreign JMS Server. The Administration Console help also provides a direct link to the related topic in e-docs: "Using Foreign JMS Providers with WebLogic Server."

Configuring the Messaging Bridge Service

Each WebLogic messaging bridge consists of two destinations that are being bridged. Messages are received from the source destination and forwarded to the target destination. For each source and target destination being bridged, whether it is a WebLogic JMS implementation or a third-party JMS product, you must configure a JMS bridge destination instance. The Messaging Bridge service contains subnodes in the navigation tree that enable you to configure the messaging bridge and the bridge destinations.

• Bridges

• JMS bridge destinations

• General bridge destinations

The initial console page for each of the Messaging Bridge resources provides a link to configure a new instance of the selected resource type. The following sections provide instruction for configuring the Messaging Bridge resources.

Configure a Messaging Bridge

A messaging bridge transfers messages between two message providers. The console page for configuring bridges includes three tabs under the Configuration tab:

• General

• Connection Retry

• Transactions

The General Configuration page is used to create the bridge. Two significant attributes of the messaging bridge configuration are the Source Bridge Destination and the Target Bridge Destination. A messaging bridge cannot be created unless those values are specified. The source and target bridge destinations define the JMS destinations that are being bridged. The bridge sends messages to the target destination that it read from the source destination. The values for the source and target are chosen from a list of the JMS bridge destinations that have been created. After the messaging bridge has been created, the Connection Retry and Transactions tabs become enabled. The messaging bridge must be targeted for deployment on a server before it can be used. The Administration Console help contains a Configuring a Messaging Bridge Instance link that leads you to a step-by-step guide.

Configuring JMS Bridge Destinations

The JMS bridge destination is used by the WebLogic messaging bridge to connect to a JMS messaging product. The configuration for the JMS bridge destination specifies the name of the bridge destination within the domain and the configuration for the resource adapter used to communicate with the specified destination. The attributes referencing the adapter include its JNDI name, the adapter's CLASSPATH, and the properties to pass to the adapter. The default resource adapter JNDI name is eis.jms.WLSConnectionFactoryJNDIXA. The resource adapter must be deployed as a connector module.

Configuring General Bridge Destinations

The general bridge destination is used by the WebLogic messaging bridge to connect to a non-JMS messaging product. A custom adapter must be provided by the third-party vendor to access non-JMS source or target destinations. The Administration Console help for general bridge destinations provides Configuring General Bridge Destinations and Configuring a Messaging Bridge Instance links. The related topic link on the console help page is "Simple Access to Remote or Foreign JMS Providers."

Configuring the XML Service

The XML Registry enables you to configure the XML resources used by WebLogic Server. The Administration Console help for XML registries provides a brief overview of the XML registry for WebLogic Server, as well as related task links for "Configuring a Parser or Transformer Other Than the Built-In," "Configuring a Parser for a Particular Document Type," and "Configuring External Entity Resolution." The related topic on e-docs that the Administration Console help provides a direct link to is "Administering WebLogic Server XML."

The attributes for configuring an XML registry specify the class names for the document builder factory, SAX parser factory, and transformer factory. The default parsers are from the Apache Xerces project and the default transformer is from the Apache Xalan project, which are the industry standard Java classes for XML. In addition to the Java class names for the XML factories, the name of the XML registry is specified and the choice for when to cache is selected as cache-on-reference, cache-at-initialization, or cache-never. The default is cache-on-reference.

Configuring the JTA Service

The JTA service node in the navigation tree is a direct link to the domain configuration tab for JTA. Refer to the "JTA Configuration for the Domain" section earlier in this chapter for information about configuring the JTA service.

Configuring the SNMP Service

The Simple Network Management (SNMP) service is defined by the following six resources, as shown on the Administration Console home page in Figure 35.2 earlier in this chapter:

• Agent

• Proxies

• Monitors

• Log filters

• Attribute changes

• Trap destinations

The SNMP service node in the navigation tree is a direct link to the domain configuration tab for the SNMP agent. Refer to the "SNMP Configuration for the Domain" section earlier in this chapter for information for configuring the SNMP agent. The navigation tree and the Administration Console home page provide links to the console pages for the SNMP resources. The initial console page for each of the SNMP resources provides a link to configure a new instance of the selected resource type. The following sections provide instruction about configuring the SNMP resources.

Configure SNMP Proxies

WebLogic Server uses an SNMP master agent that acts as a proxy for other SNMP agents. The SNMP proxy is configured with a root object identifier (OID). If the SNMP agent receives a request containing OIDs that fall below this root in the OID tree, WebLogic Server forwards the request to the SNMP proxy. The Administration Console help for SNMP proxies includes a link to the step-by-step guide named "Configure an SNMP Proxy." The console help also provides direct links to the e-docs "WebLogic SNMP Management Guide" and "WebLogic SNMP MIB Reference."

Configure SNMP Monitors

The WebLogic SNMP agent enables you to configure Java Management Extension (JMX) monitors. The JMX monitors poll WebLogic resources at a specified interval to check for the occurrence of conditions or the crossing of thresholds. The three monitors that you can create for WebLogic SNMP are

• Gauge monitor

• String monitor

• Counter monitor

The monitor is configured with an MBean type, which is effectively the WebLogic Server subsystem that is being monitored. When the monitor detects that a chosen attribute is beyond a threshold for a gauge or counter monitor, or fails a string comparison for a string monitor, an SNMP trap is generated. The configuration page for each of the SNMP monitors provides the same list of the Monitored MBean Type, which is a very extensive list. Figure 35.38 shows a portion of the available selections.

Configure SNMP Log Filters

The subsystems and modules deployed on a WebLogic Server instance generate log messages to communicate status information. The log messages are broadcast as JMX notifications. A WebLogic SNMP agent uses log filters to specify the criteria for which log messages it wants to receive. The configuration for an SNMP log filter specifies the minimum severity level for messages that will be selected, as well as lists of subsystem names, user IDs, and messages IDs that it is interested in selecting. The severity level is specified from the ordered list:

• Info

• Warning

• Error

• Notice

• Critical

• Alert

• Emergency

All messages at the specified level or a higher level are selected by the SNMP agent using this log filter.

The selection criteria can also be specified as a message substring that must be matched in the message text. The messages that are selected by the SNMP agent generate an SNMP log notification trap. The Administration Console help provides a link to the step-by-step guide, "Configure a Notification Log Filter." The related topics from e-docs are "WebLogic SNMP MIB Reference" and "WebLogic SNMP Management Guide."

Configure SNMP Attribute Change Traps

The SNMP Attribute Change trap enables you to configure the SNMP agent to send a trap immediately after an attribute has been changed. This is in contrast to the SNMP monitors introduced earlier in this chapter that generate traps by polling for changes. The configuration for an SNMP Attribute Change trap enables you to specify the attribute MBean type, the name of a specific instance of an attribute MBean, or an attribute name that is registered in the WebLogic Server MIB. The configuration also enables you to choose on which servers to enable trap generation. The Administration Console help for this page includes a direct link to the e-docs named "WebLogic SNMP MIB Reference." That reference is used to select the configured attribute name for this Attribute Change trap. The console help also provides a link to the step-by-step guide, "Configuring an Attribute Change."

Configure SNMP Trap Destinations

SNMP trap destinations specify the community name used by the SNMP agent. The community name provides the credentials for sending trap notifications to the target SNMP manager. The Administration Console help provides a link to the step-by-step guide, "Creating a Trap Destination."

Configuring the WTC Service

The WebLogic Tuxedo Connector (WTC) provides bi-directional integration between WebLogic applications and Tuxedo. It allows WTC clients to access Tuxedo services and allows Tuxedo clients to invoke WebLogic Server applications. The general configuration for WTC is simply the name of the WTC service. After the WTC service has been created, it must be deployed on WebLogic Server instances. The Contents tab on the WTC console page enables you to configure the following:

• Local Tuxedo access point

• Remote Tuxedo access point

• Exported service

• Imported service

• Passwords

• Resources

• Tuxedo queuing bridge

• Redirections

Each of the preceding items is listed as a tab for the contents of the WebLogic Tuxedo Connector. There is a separate Administration Console help for each of the configurable items to guide you through the configuration process.

Configuring the WLEC Service

The WebLogic Enterprise Connectivity (WLEC) has been deprecated by the WebLogic Tuxedo Connector. Refer to the section "Configuring the WTC Service" earlier in this chapter for configuring WTC.

Configuring the Jolt Service

Jolt is a Java-based client API that manages requests to the WebLogic Tuxedo Services through a Jolt Service Listener (JSL) running on the Tuxedo server. The Jolt client class library can be used by servlets running in WebLogic Server to provide the interface to the BEA Tuxedo services. The configuration for Jolt is maintained by a Jolt connection pool. A Jolt connection pool stores the primary addresses and failover addresses that are used to establish a connection to the Tuxedo domain. Jolt provides connection failure handling by using two lists of JSL addresses for each connection pool. The primary addresses are used to establish a connection between this Jolt connection pool and the Tuxedo domain. The failover addresses are used if a connection defined in the Primary Addresses field cannot be established. The addresses are specified in the standard URL format of //hostname:port. Multiple addresses are separated by semicolons.

Like the Addresses tab, the User tab becomes enabled after a Jolt connection pool has been created. Each network connection is authenticated through a security identity that is established as a security context in WebLogic Server using the values specified as the User configuration for the Jolt connection pool.

Configuring the Virtual Hosts Service

Virtual hosting enables you to specify which hosts will be served by the Web applications on this server. At least one hostname must be entered in the Virtual Host Names list to create a virtual host. After the virtual host has been created, the Logging tab becomes enabled.

Like the Logging tab, the HTTP tab also becomes enabled after a virtual host has been created. The virtual host must be targeted and deployed on WebLogic Server instances before it can be used.

Configuring the Mail Service

WebLogic Server includes the JavaMail API version 1.1.3 reference implementation from Sun Microsystems. The JavaMail API enables you to add email capabilities to your WebLogic Server applications.

Your WebLogic Server modules and applications access JavaMail through JNDI. The mail session object bound in the JNDI tree provides the configured session properties to the Web application. The configuration for the mail session is therefore its JNDI name and a list of properties. The mail session must be targeted for deployment on WebLogic Server instances before it can be used.