Proxy
There are many ways in which you can accomplish a Web Cluster: Hardware load balancer, Web server with proxy plug-in, WebLogic with HttpClusterServlet. Using HttpClusterServlet you need to deploy the web application to the machine that is going to serve as the main gateway to your cluster.
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.proxy.HttpServlet
</servlet-class>
</servlet>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>
10.0.10.12:7001:7002|10.10.10.15:7001:7002
</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo </param-name>
<param-value>ON</param-value>
</init-param>
Once the cluster servlet has been configured and deployed, requests to the server will be mapped to the appropriate server in the cluster. The HttpClusterServlet supports the DebugConfigInfo initialization parameter, which is useful for debugging the servelt’s configuration. If you have specified this initialization parameter for the HttpClusterServlet, the servlet returns the details of its configuration whenever you invoke a servlet along with the query parameter __WebLogicBridgeConfig, instead of passing the request through to the cluster.
WebLogic provides integration with these web servers in the form of a web server proxy plug-in. This plug-in allows the web server to communicate with the WebLogic Server (or Cluster). You then can have the web server serving up the usual static content, while it passes requests for JSPs and servlets to WebLogic.
WebLogic Server can be configured so that its built-in web server services requests for servlets and JSPs, while other requests for static web resources are redirected to a secondary server.
<servlet>
<servlet-name>ProxyServlet </servlet-name>
<servlet-class>
weblogic.t3.srvr.HttpProxyServlet
</servlet-class>
<init-param>
<param-name>redirectURL</param-name>
<param-value>http://someserver:port</param-value>
</init-param>
</servlet>
JTA
The configuration settings for JTA are persisted in the domain’s config.xml file. The JTA attributes apply at the domain level, while the monitoring and logging tasks at the individual server level. JTA settings include:
1. Timeout Seconds
2. Abandon Timeout Seconds
3. Before Completion Iteration Limit
4. Max Transactions
5. Max Unique Name Statistics
6. Checkpoint Interval Seconds
7. Forget Heuristics
A heuristic occurs when a resource makes a unilateral decision (without waiting for a decision from resource manager). 4 ways:
1. HeuristicCommit
2. HeuristicRollback
3. HeuristicMixed
4. HeuristicHazzard
Log files for the transaction log cannot be viewed because they are in binary format. You can locate the transaction files in the server’s folder in the domain’s directory. Transaction log files are critical, so you should ensure that log files are stored on HA file system such as RAID disk, dual-ported SCIS disk, or a SAN.
Security
At the JVM level, WebLogic use the standard Java Security Manager to prevent untrusted code from performing unwanted actions. Using a security policy file, you can configure the JVM so that all threads running on the JVM have restricted access to sensitive runtime operations. The security policy file encapsulates a set of permissions that are granted to all classes loaded within the current instance of the JVM.
In order to use the Java Security Manager, you need to supply two options from the command line when starting WebLogic Server:
1. Use the –Djava.security.manager option to ensure that the default security manager is installed
2. Use the –Djava.security.policy option to specify the location of a security policy file
At the connection level, WebLogic provides two security features: filtering and SSL. WebLogic comes preconfigured with a useful connection filter that can process a number of filter rules defined using the Administration Console in the Connection Filter Rules setting. Format is:
target localAddress localPort action protocolList
WebLogic defines a standard set of SSPIs that provide high-level security services. Two important features: Modular and Pluggable.
A security realm is a logical grouping of users, groups, roles and security policies, along with a complete set of security providers. By default, WebLogic Server comes equipped with two such realms: the legacy compatibility realm and the new default realm (default name myrealm). Legacy realm supports for WebLogic 6.x type security configurations, and myrealm is standard implementation of the security providers. Only one realm can be active only, this active realm controls all aspects of the domain’s security.
Global Roles are available to all resources within a security domain. A default set of global roles is created automatically when you create a new domain; it is used to grant access to various operations:
1. Admin
2. Deployer
3. Operator
4. Monitor
Unlike global roles, most roles are scoped, meaning that they apply to a particular resource or branch of a JNDI tree.
Any implementation of the SPPIs requires some kinds of security provider database that can act as a repository for the domain’s security data. WebLogic relies on an embedded LDAP server to persist all of its information about users, groups, policies, roles and user credentials. In the default setup, the Admin Console holds a master LDAP repository, and this repository is then replicated to all Managed Servers.
JAAS-style authentication:
1. Subject
2. LoginContext
3. CallBackHandler
4. LoginModule
5. PrivilegedAction
JMX
WebLogic makes a different between 3 Means:
1. Configuration MBeans
2. Runtime MBeans
3. Security MBeans (reflect the SSPIs)
The MBean Server running on a WebLogic Server instance can be reached through the weblogic.management.MBeanHome interface. Two implementations:
1. Local Home interface
2. Administration Home interface
Use the getMBeanHome() method on the weblogic.management.Helper class or JNDI tree. Once you obtain a home interface, there are several ways to access the underlying MBean Server: JMX interface or a wrapper around the MBeanServer interface like Administration Tool.
The weblogic.Admin tool can be used to view and manipulate JMX data. For example, retrieve the attribute values of a named DataSource MBean:
java weblogic.Admin –url http://10.0.10.10:7001 –username system –password pass GET –pretty –mbean “myClusterDomain:Location=ServerA, Name=MyDataSource, Type=JDBCDataSourceConfig”
A notification listener is a handler that is triggered when the MBean it is registered with sends one or more JXM notifications. Use addNotifiationListener() method to register listener on MBeans. It is a instance of a class that implements the javax.management.NotificationListener interface.
Monitor MBeans monitor attributes in other MBeans at specified intervals and derive a value from this observation called the derived gauge. 3 types: CounterMonitor, GaugeMonitor, StringMonitor.
JMS
A JMS server implements the actual messaging facilities. Each JMS server lives on a single WebLogic instance and hosts a number of messaging destinations. Note multiple JMS servers may be hosted by the same WebLogic instance.
A JMS destination represents a delivery target for any message. It is a virtual channel that acts as an intermediary between the message producer and its consumers.
A connection factory encapsulates a set of configuration properties for connections to the JMS server. A JMS client must use the connection factory to obtain a connection to a JMS server. A connection factory is independent of the JMS servers in the domain, and may be targeted to any number of WebLogic instances.
A template is a convenience mechanism that allows you to define a set of characteristics that then can be shared by multiple destinations.
A destination key can be used to set the sort order for messages that have arrived at a physical destination. Sorting only occurs if there are multiple messages waiting at a destination.
The JMS standard requires that JMS sessions be single-threaded. This means that a JMS listener cannot concurrently process multiple messages within a single JMS session. To circumvent this problem, the specification allows for a pool of server-side sessions, a feature that enables an application to process messages concurrently.
Quotas allow you to restrict the number of messages that can be held in memory. These limits can be specified in terms of either the maximum number of messages or the maximum cumulative size of the messages (in bytes).
Unless messaging paging has been enabled, all messages that arrive at the JMS server, regardless of whether they are persistent, are held in memory. This is an important aspect of the JMS server that you need to keep in mind when architecting a solution. WebLogic supports 2 types of paging: byte paging and message paging.
In general, producers send messages at a much faster rate than consumers can handle them, and in some situations, overactive producers can swamp consumers. WebLogic provides a flow control feature that allows the JMS server or destination to throttle(节流) the producers by suppressing the rate at which the messages are produced. In fact, the flow control mechanism uses the same “paging” thresholds defined for the JMS server or destination to decide if the server is still armed. For advanced flow control: Blocking Send Policy and Send Timeout.
By default, WebLogic JMS guarantees up-to-message integrity via synchronous writes to a file store. When you configure a JDBC store, the JMS server creates two tables for private use: JMSStore and JMSState.
The delivery mode indicates whether the messages are stored in a persistent store. If a persistent delivery mode is used, the message will be stored so that the system can guarantee once-and-only-once delivery.
The JMS standard provides 3 acknowledge modes for non-transacted JMS sessions:
1. AUTO_ACKNOWLEDGE
2. CLIENT_ACKNOWLEDGE
3. DUPS_OK_ACKNOWLEDGE
WebLogic JMS provides two additional acknowledge modes:
1. NO_ACKNOWLEDGE
2. MULTICAST_NO_ACKNOLEDGE
In general, a JMS topic will have subscribers running on different hosts within a domain. The more subscribers, the more network resources needed by the JMS server to deliver the messages, a potential risk of using multicasting is that the JMS messages are not guaranteed to be delivered to all subscribers within the host group.
If the MDB implements bean-managed transactions, you must explicitly code for duplicate message because message acknowledgment will occur outside the scope of the transaction.
Because WebLogic JMS is a “singleton” service in the cluster, it need not be enabled on all members of the cluster. Typically, it will be pinned to a single server in the cluster and then will be accessible to all JMS clients of that cluster.
Distributed destination is a cluster-specific destination representing one or more physical destinations, typically referred to as the members of the distributed destination.
MDB are the best way of concurrently handling messages arriving at a topic or queue. MDSs that listen to a non-distributed queue implement asynchronous, reliable delivery within a cluster.
WebLogic messaging bridges are supplied as resource adapters. 3 different bridge adapters:
1. jmx-xa-adp.rar
2. jms-notran-adp.rar
3. jms-notran-adp51.rar