Spring 1.2.x Integration with WebLogic Server

Pages: 1, 2, 3, 4

Enterprise Spring

The non-invasive IoC development model of the Spring Framework relies on, and is designed to complement, the feature set available to a J2EE application server. Indeed, in demanding production environments the quality of service provided by the underlying application server infrastructure is all-important to the continued reliability, availability, and performance of the Spring application. WebLogic Server 9.0 provides enterprise-class features that can enhance all aspects of your Spring application. In this section, we describe in some detail these features and how to leverage them in your Spring application.

Cluster management and deployment

A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. WebLogic Server clusters provide an enterprise class deployment platform for Spring applications, and while other technology offerings support similar features, none have the richness and ease of use provided by WebLogic Server. See Understanding Cluster Configuration and Application Deployment for a full discussion on the configuration and management of WebLogic Server clusters.

Commonly Spring applications are packaged as webapps and in this scenario you do not need to change your application to take advantage of WebLogic Server clustering. You would simply deploy your application to the servers in the cluster and reap the benefits of enhanced scalability and availability.

Spring session replication

Spring Web applications habitually store information—such as order ids and user information—in HTTP sessions. To support automatic replication and failover for servlets and JSPs within a cluster, WebLogic Server supports several mechanisms for preserving HTTP session state. These can be used non-invasively with Spring Web applications simply by providing an appropriate weblogic.xml deployment descriptor with your application. Get more information on configuring the various types of session persistence available with WebLogic Server 9.0.

Clustered Spring remoting

Spring provides powerful remoting support, allowing you to export and consume remote services with ease while still leveraging a consistent, POJO-based programming model. Vanilla Spring supports proxying POJO calls through a single RMI interface to the appropriate Spring bean. However this support was limited to JRMP (Sun's RMI implementation) or to using specific remote interfaces with JndiRmiProxyFactoryBean. With the certification of Spring 1.2.5 on WebLogic Server 9.0, we have extended the JndiRmiProxyFactoryBean and associated service exporter—so that it supports POJO proxying with any J2EE RMI implementation, including RMI-IIOP and T3. Included with this support is a WebLogic RMI deployment descriptor that enables clustering on the proxy RMI interface, so POJO calls can be load-balanced across a WebLogic Server cluster. The client configuration of such support looks something like this:

<bean id="proProxy"


   <property name="jndiName" value="t3://${serverName}:${rmiPort}/order"/>


   <property name="jndiEnvironment">


         <prop key="java.naming.factory.url.pkgs"> 





   <property name="serviceInterface"



The service exporter will look something like this:

<bean id="order-pro"   class="org.springframework.remoting.rmi.JndiRmiServiceExporter">

   <property name="service" ref="petStore"/>

   <property name="serviceInterface"


   <property name="jndiName" value="order"/>


The clustered descriptor is automatically included and requires nothing more than appropriate cluster configuration and the deployment of your Spring application to all cluster members. Get more information on failover support.

Console support for Spring components

Included in the Spring on WebLogic Server kit is a WebLogic Server console extension that displays the Spring beans, attributes, and operations defined in your application. It is built on the WebLogic console extension portal framework, which can transform the look and feel, functionality, and layout of the WebLogic Administration console without the need for modifying server or console code. Console extensions are deployed when they are copied to the yourdomain/console-ext directory and your server is restarted. For more details on deploying the console extension, consult the Spring on WebLogic Server kit.

The console extension works by automatically creating (JMX) management interfaces for Spring beans that are not MBeans (as is the case for most Spring beans) and is done by configuring an MBeanExporter in the applicationContext.xml and specifying which beans to expose via the assembler. This feature is a great example of Spring and WebLogic Server working seamlessly and non-invasively together. To JMX-enable your Spring application you only have to change the application context deployment descriptor—to Spring-enable your console you only have to deploy two jars to your existing domain.

To enable the Spring Console extension in WebLogic Server's Administration console, you need exactly two jar files—both are supplied as part of the Spring WebLogic package. Specifically, the jar files that are required are called spring-ext-server.jar and spring-ext-client.jar. The spring-ext-server.jar needs to be copied into the yourdomain/console-ext directory. The related spring-ext-client.jar file needs to be deployed with your Web application (in the case of a .WAR file, place the spring-ext-client.jar into the WEB-INF/lib directory of your Web application).

With those two files in place, all that remains to be done is to define a few beans in your Spring XML configuration file. The first Spring bean that absolutely must be defined is the com.interface21.wl9.jmx.mediator.Mediator bean. This is the bean that (as the name implies) mediates between your application and WebLogic Server's MBeanServer and Administrative console. It is a really simple bean definition, as the following example shows:

<!-- WLS console adapter bean -->

<bean id="consoleAdapter" 


  <property name="applicationName" value="my_app_name"/>


This bean has to be 'plugged-in' (or dependency injected) into the second bean that (again) absolutely must be configured - the MBeanExporter. The remit of the MBeanExporter class is to simply export any number of disparate beans that have been defined in the Spring application context to the BEA WebLogic MBeanServer (or indeed any configured MBeanServer). Note that there is no need for those beans that are exported by the MBeanServer to be coded for JMX. The Spring JMX infrastructure code takes care of generating ModelMBeans to describe the beans that are to be exported for management via JMX. An example of a typical MBeanExporter bean definition can be found below:

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">

  <property name="assembler" ref="assembler"/>

  <property name="server" ref="server"/>

  <property name="beans">


      <!-- these are the beans that are to be exported... -->

      <entry key="my_app_name:type=MaintenanceControl" 


      <entry key="my_app_name:type=ExceptionMonitor" 


      <entry key="my_app_name:type=RequestStatistics" 




  <property name="registrationBehaviorName" 


  <property name="listeners">


    <!-- notice how we 'plug-in' the Mediator bean

           that was defined previously... -->

    <ref bean="consoleAdapter"/>




Take note that in the above bean definition, another bean ('assembler') is being injected into the 'assembler' property of the MBeanExporter. The definition of this bean can be seen below:

<bean id="assembler" class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">

 <property name="interfaceMappings">


    <prop key="my_app_name:type=MaintenanceControl">fully.qualified.management.interface.name</prop>

    <prop key="my_app_name:type=ExceptionMonitor">fully.qualified.management.interface.name</prop>

    <prop key="my_app_name:type=RequestStatistics">fully.qualified.management.interface.name</prop>




It is beyond the scope of this article to actually describe the full breadth of Spring's JMX offerings. Suffice to say the InterfaceBasedMBeanInfoAssembler bean that is defined above is one possible strategy for controlling what methods and properties of your beans are actually exposed for management as JMX operations and attributes. The InterfaceBasedMBeanInfoAssembler uses (arbitrary) interfaces to decide which methods and properties are to be exported. For more information consult the references section at the end of this paper.

The second property of note on the bean definition of the MBeanExporter is the server property. This is where one injects an instance of WebLogic Server's MBeanServer into the MBeanExporter. The MBeanExporter will export all of the beans it has been configured to export into this specific server. The bean definition follows:

<!-- WebLogic 9 MBeanServer -->

<bean id="server" 


  <property name="jndiName" 



In this definition of the server bean, the MBeanServer instance is actually being sourced from JNDI (using the value specified for the jndiName property to do the lookup in the context). The fact that the MBeanServer is being sourced from JNDI is of no concern to the MBeanExporter - this transparent sourcing of dependencies into the objects that require them is one of the big value-adds of the dependency injection approach (and Spring's injection support is quite sophisticated as evidenced by the easy-to-use-and-configure JndiObjectFactoryBean seen above).

The final, and most interesting, part of the MBeanExporter configuration is the beans property. The beans property is a simple mapping of (JMX) ObjectNames to the beans that are to be exported for management to the previously injected MBeanServer instance. The strategy for choosing the ObjectNames under which your beans are actually exported to the MBeanServer is totally configurable. In this case, the default strategy of simply using the keys of the beans map as the ObjectNames is used (see the extensive JavaDoc that comes with the Spring distribution for a thorough rundown of the various ObjectName strategies).

Web services enablement

Another facet of Spring’s remoting capability is its support for RPC-style Web services. WebLogic Server provides Ant-based tools to generate JAX-RPC stubs based on the WSDL description of a Web service. Web service clients use these generated stubs to obtain a remote interface representing server-side operations. Spring simplifies this procedure by providing a JaxRpcPortProxyFactoryBean.

We found that configuring the JaxRpcPortProxyFactoryBean correctly in a WebLogic Server environment was a little tricky, so to save you some time this snippet demonstrates how to configure proxy generation for a document literal wrapped Web service that contains complex types.

Most of the attributes are self-explanatory. A few attributes are of note:

  • The serviceInterface is the byproduct of Spring’s setter injection. This class will represent the Web services operations.

  • The customProperties property allows for custom WebLogic Server Web service stub properties.

  • The jaxRpcService value is set to WebLogic Server’s generated JAX-RPC implementation service. The JAX-RPC service is responsible for Web service authentication and loading complex type mapping. To satisfy the latter, WebLogic Server’s JAX-RPC service implementation must be configured as a Spring bean. This ensures the execution of the JAX-RPC service constructor; this is where type mapping files are loaded.

Setting lookupServiceOnStartup to false on JaxRpcPortProxyFactoryBean turns off JAX-RPC service lookup during startup. Instead, the lookup will be fetched upon first access. This is required for clients that communicate with WebLogic Server reliable request/response Web services where the client must also be a Web service. Often in these cases, the originating client is deployed along with the Web service client. Because Web service activation does not occur until application deployment is finalized, the client Web service is not available for Spring’s context loading.

<!-- reliable asynchronous Web service for sending new

  medical records to medrec -->

<bean id="reliableClientWebServicesPortType"



   <property name="wsdlDocumentUrl"


   <property name="portName" value="PhysicianWebServicesPort"/>

   <property name="jaxRpcService">

      <ref bean="generatedReliableService"/>


   <property name="serviceInterface"


   <property name="username" value="medrec_webservice_user"/>

   <property name="password" value="weblogic"/>

   <property name="customProperties">


         <prop key="weblogic.wsee.complex">true</prop>




<!-- allows the jaxRpcService class to execute its

  constructor which loads in type mappings -->

<bean id="generatedReliableService"



See WebLogic Server's Overview of Invoking Web Services and Remoting and Web Services Using Spring for further information.

Pages: 1, 2, 3, 4

Next Page »