Spring 2.0.1 and BEA WebLogic Server 9.2 Integration
Pages: 1, 2, 3, 4

Security

The WebLogic Server security system supports and extends Java EE security while providing a rich set of security providers that can be customized to deal with different security databases or security policies. Besides using standard Java EE security, application programmers can use a wide array of proprietary extensions that allow an application to tightly integrate with the security system. WebLogic Server comes with several security providers offering, for example, choices of authentication databases that include most of the popular LDAP servers, Active Directory, native Windows, and a built-in authentication solution. The built-in providers can be augmented with custom providers to integrate with nearly any authentication database, authorization mechanism, and credential mapping service. Since Spring applications deployed as webapps leverage Java EE security, you can get the benefit of WebLogic Server security without any changes to your application.

Seasoned Spring users will also be aware of Spring Security—Spring's own security framework. Currently, you can use either Spring Security, WebLogic Server security, or both in your application since each is mutually independent of the other. More on this later.

Distributed transactions

Spring provides infrastructure for transaction management. Along with support for various database vendors, Spring also supports distributed transactions through a Java EE vendor's JTA implementation. Spring's JTA manager can be configured to work in conjunction with WebLogic Server’s JTA implementation through the WebLogicJtaTransactionManager.

WebLogicJtaTransactionManager delegates responsibilities directly to WebLogic Server’s Java Transaction API. WebLogic Server’s JTA TransactionManager interface is available to clients and bean providers through JNDI, and Spring manages this interaction. The transaction manager also enables scope of transactions; transactions can operate within and between clusters and domains.

The most powerful feature of WebLogicJtaTransactionManager is its ability to manage distributed transactions and the two-phase commit protocol for enterprise applications. By employing WebLogicJtaTransactionManager, applications can take advantage of transaction monitoring through the WebLogic Administration Console. The WebLogicJtaTransactionManager also allows for per-database isolation levels, which enable complex transaction configuration. Here's an excerpt from applicationContext-service.xml:

<bean id="serviceFacade" class="com.bea.medrec.web.service.ServiceFacadeImpl">

    <!-- .... -->

</bean>

<!-- spring's transaction manager delegates to WebLogic Server's transaction manager -->

<bean id="transactionManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager"> <property name="transactionManagerName" value="javax.transaction.TransactionManager"/>

</bean>



<aop:config>

    <aop:advisor advice-ref="txAdvice"

                 pointcut="execution(* com.bea.medrec.web.service.ServiceFacade.*(..))"/>

</aop:config>

<tx:advice id="txAdvice" transaction-manager="transactionManager">

    <tx:attributes>



        <tx:method name="activate*" propagation="REQUIRED"/>

        <tx:method name="deny*" propagation="REQUIRED"/>

        <tx:method name="update*" propagation="REQUIRED"/>



        <tx:method name="process*" propagation="REQUIRED"/>

        <tx:method name="get*" propagation="REQUIRED" read-only="true"/>



        <tx:method name="search*" propagation="REQUIRED" read-only="true"/>

        <tx:method name="saveRecord" propagation="REQUIRED"/>



        <!-- ... -->

    </tx:attributes>

</tx:advice>

For more information, see Overview of Transactions in WebLogic Server Applications and Implementing Transaction Suspension in Spring.

Message-Driven POJOs

Message-Driven POJOs (MDP) are a substitute for Java EE's Message-Driven Beans (MDB). They have the advantage that, just like POJOs, they do not require any platform-specific API extension or scaffolding. They simply require the implementation of standard JMS APIs:

public class RegistrationMessageListener implements MessageListener {

    public void onMessage(Message message) {

        // Fetch Registration information from ObjectMessage.

        // Process new reg by invoking service (DI)

        // ...    }

}

As with most things in Spring, configuration of the MDP container is naturally simple. Here's an excerpt from applicationContext-jms.xml:

<!-- JMS ConnectionFactory and Queue -->



<jndi:jndi-lookup id="jmsConnectionFactory" jndi-name="com.bea.medrec.messaging.MedRecQueueConnectionFactory"/>

<jndi:jndi-lookup id="registrationQueue" jndi-name="com.bea.medrec.messaging.RegistrationQueue"/>



<!-- MDP -->



<bean id="registrationMessageListener" class="com.bea.medrec.service.messaging.RegistrationMessageListener">

    <!-- ... properties... -->

</bean>



<!-- MDP container -->

<bean id="registrationMessageListenerContainer"



          class="org.springframework.jms.listener.DefaultMessageListenerContainer">

    <property name="connectionFactory" ref="jmsConnectionFactory"/>

    <property name="concurrentConsumers" value="5"/>



    <property name="destination" ref="registrationQueue"/>

    <property name="messageListener" ref="registrationMessageListener"/>

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



</bean>

For a more detailed discussion of implementing MDPs on WebLogic Server, take a look here.

JPA and AOP configuration

We have definied a Web service tier that allow us to switch Web service implementations easily between RMI, the Spring HTTP invoker, Hessian/Burlap, and JAXPRC. If we want to transfer objects using a serializable mechanism when invoking the remote service, the objects themselves must be serializable. Unfortunately OpenJPA's Find result is a private List implementation and doesn't support Serializable, so we need to wrap these Lists with something more suitable such as ArrayList or LinkedList from the Java SE collections library. We can use the spring aop to help us do that without having to change the application source code:

@Aspect

public class ReturningValuePostProcessorAspect {

    @Pointcut("execution(java.util.List com.bea.medrec.dao.PatientDao.*(..))")

    public void postProcessPatientDao() {

    }



    @Pointcut("execution(java.util.List com.bea.medrec.dao.RecordDao.*(..))")

    public void postProcessRecordDao() {

    }



    @Pointcut("execution(java.util.List com.bea.medrec.dao.UserDao.*(..))")

    public void postProcessUserDao() {

    }

}

Here's the associated ReturningValuePostProcessor class.

@Aspect

public class ReturningValuePostProcessor {

    public ReturningValuePostProcessor() {

    }



    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessPatientDao()")

    public Object postProcessPatientDao(ProceedingJoinPoint pjp) throws Throwable {

        return doPostProcess(pjp);

    }



    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessRecordDao()")

    public Object postProcessRecordDao(ProceedingJoinPoint pjp) throws Throwable {

        return doPostProcess(pjp);

    }



    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessUserDao()")

    public Object postProcessUserDao(ProceedingJoinPoint pjp) throws Throwable {

        return doPostProcess(pjp);

    }



    private Object doPostProcess(ProceedingJoinPoint pjp) throws Throwable {

        Object retVal = pjp.proceed();

        if (retVal == null) {

            return null;

        }

        if (!(retVal instanceof List)) {

            return retVal;

        } else {

            //noinspection unchecked

            return new ArrayList((List) retVal);

        }

    }

}

And here's an excerpt from applicationContext-jpa.xml that puts it all together:

<bean id="patientDao" class="com.bea.medrec.dao.jpa.PatientDaoImpl"/>



<bean id="recordDao" class="com.bea.medrec.dao.jpa.RecordDaoImpl"/>

<!-- ... -->

<bean id="returningValuePostProcessor" class="com.bea.medrec.dao.jpa.ReturningValuePostProcessor"/>

<aop:aspectj-autoproxy/>

Java Management Extensions

Java Management Extension (JMX) is a specification for monitoring and managing Java applications. It enables a generic management system to monitor an application, raise notifications when the application needs attention, and change the state of your application to remedy problems. Spring offers extensive JMX support, which includes the ability to expose WebLogic Server’s MBeanServer through Spring’s MBeanServerConnectionFactoryBean. The MBeanServerConnectionFactoryBean is a convenience factory whose byproduct is an MBeanServerConnection. During application deployment, the connection is established and cached to be later operated on by referencing beans.

The MBeanServerConnectionFactoryBean can be configured to return WebLogic Server’s Runtime MBean Server, which exposes monitoring, runtime control, and the active configuration of a specific WebLogic Server instance. This includes access to WebLogic Server’s Diagnostics Framework. Additionally, the Runtime MBean provides access to runtime MBeans and active configuration MBeans for the current server.

The MBeanServerConnectionFactoryBean can also be configured to obtain a connection to WebLogic Server’s Domain Runtime MBean Server. The Domain Runtime MBean Server provides admission to domain-wide services such as application deployment, JMS servers, and JDBC data sources. It is also a single point for accessing the hierarchies of all runtime MBeans and all active configuration MBeans for all servers in the domain. This MBean Server also acts as a single point of access for MBeans that reside on managed servers.

Additionally, the MBeanServerConnectionFactoryBean can be configured to obtain a connection to WebLogic Server’s Edit MBean Server. The Edit MBean Server provides the entry point for managing the configuration of the current WebLogic Server domain.

Note that WebLogic Server’s Domain Runtime MBean Server is not active during deployment. Because of this, the bean needs to be configured using Spring’s lazy initialization, which fetches the bean when it’s invoked.

Here is an example of configuring Spring’s MBeanServerConnectionFactoryBean with WebLogic’s MBean Servers:

<!-- expose WebLogic Server's runtime mbeanserver connection -->

<bean id="runtimeMbeanServerConnection"

  class="org.springframework.jmx.support.MBeanServerConnectionFactoryBean">

   <property name="serviceUrl"      value="service:jmx:t3://${WS_HOST}:${WS_PORT}/jndi/weblogic.management.mbeanservers.runtime"/>

   <property name="environment">

      <props>

         <prop key="java.naming.security.principal">

            ${WS_USERNAME}</prop>

         <prop key="java.naming.security.credentials">

            ${WS_PASSWORD}</prop>

         <prop key="jmx.remote.protocol.provider.pkgs">

            weblogic.management.remote</prop>

      </props>

   </property>

</bean>

For more information, see Understanding WebLogic Server MBeans and Spring’s JMX Support.

Support

Starting with WebLogic Server 9.0 and Spring 1.2.5, BEA is making available support and certification of the Spring Framework on WebLogic Server. This support is no mere sanity testing of the Spring libraries on WebLogic Server, but has involved intense effort and collaboration between BEA and Interface 21—the creators and maintainers of the Spring Framework. Not only have we tested all the features and configurations that we described above with Spring 2.0, but some of the new features were introduced in Spring 2.0 directly as a result of the BEA and Interface 21 collaboration.

Download

The Spring Open Source Framework Support 2.0 download includes Spring 2.0—certified on WebLogic Server 9.2—the Spring-JMX console extension and the WebLogic Medical Records sample application rewritten using the Spring 2.0 Framework.

Future Work

In the future we plan to provide deeper integration between WebLogic Server and the Spring Framework. Although we have several ideas, some of the most interesting are:

  • Spring Deployment Unit: Spring applications are normally deployed as webapps, but it would be possible to provide a dedicated deployment unit for Spring applications.

  • Spring Security and WebLogic Server Security Integration: Spring Security is Spring's security framework, and we plan to integrate this with WebLogic Server's enterprise-class security framework.

Summary

We have spent some time looking at Spring, WebLogic Server, and the integration of the two technologies. As we have shown, Spring enables enhanced developer productivity while WebLogic Server enables enhanced application quality of service. Both technologies are highly non-invasive, allowing you to concentrate on developing the business functionality of your application rather than the intricacies of technology specific APIs.

References

Andy Piper is a Senior Staff Engineer in the WebLogic Server advanced development group. Andy has worked on WebLogic Server for the past 6 years and is responsible for many features and innovations.