Spring 1.2.x Integration with WebLogic Server

Abstract

BEA WebLogic Server 9.0 is the leading implementation of Sun Microsystems' J2EE 1.4 platform. However, WebLogic Server's core value proposition is in areas not covered by the J2EE specification—enhanced management, ease-of-use, high availability, scalability, reliability, and performance. Indeed, WebLogic Server's value is not tied to any particular programming model, so it is therefore a natural fit with the new breed of non-J2EE programming models. The most exciting of these to emerge in recent years are models based on Inversion of Control (IoC)—of which the Spring Framework is the leading implementation. This article introduces features of the Spring Framework, WebLogic Server, and the integration of the two. As we shall see, the whole is greater than the sum of its parts.

Article Structure

In the first two sections, we give an overview of Spring and WebLogic Server and their respective features. If you are familiar with the Spring Framework, then you should skip over the first section, and if you are familiar with WebLogic Server, then you should skip over the second section. Since this article is primarily about the integration of the two technologies, we devote the rest of the article to this topic. To give it some context we first examine MedRec—a sample application shipped with WebLogic Server—both in its original J2EE form and then recast using the Spring Framework. After this we dive into some detail around specific integration points. If you are trying to develop Spring applications on top of WebLogic Server, then you will almost certainly find the level of detail helpful. If you just want an idea of what is possible, then read the titles and save the substance for later. Finally, we summarize and look at some of the future developments we are thinking about.

An Introduction to Spring

In this section, we briefly summarize the features of the Spring Framework.

Spring is a layered Java/J2EE application framework, based on code published in Expert One-on-One J2EE Design and Development by Rod Johnson (Wrox, 2002). Spring exists because we believe that J2EE should be easier to use and that it's possible to enable a simpler approach to J2EE development without sacrificing the power of the platform.

Spring enables agile J2EE development, and allows J2EE applications to be developed using POJOs.

Enhanced development experience with Spring

At its core Spring provides an easy-to-configure, XML-driven, Inversion of Control (IoC) container. IoC is based on the so-called "Hollywood" principle—"don't call us—we'll call you." In this scheme relationships between Java objects in your application are injected by the container rather than programmed by you directly. This injection comes in two forms—constructor injection and setter injection—depending on whether the container injects information into a created Java object via its constructor or its mutator methods.

In Spring, injected properties—or references to other beans—are configured via an XML file, making configuration almost entirely trivial. This, coupled with an AOP framework that allows attributes such as transactions and security to be added non-invasively, means that developers can concentrate on creating a solution for your business problem rather than getting tied up in the complexity of J2EE development or configuration. Since the container is non-invasive you can also relax knowing that your business code is not polluted with vendor-specific (and we include Spring here) artifacts.

Components of a Spring application

As we have mentioned, Spring provides a lightweight container offering centralized, automated configuration and wiring of your application objects. The container is non-invasive, capable of assembling a complex system from a set of loosely coupled components (POJOs) via IoC in a consistent and transparent fashion. The container brings agility and leverageability, and improves application testability and scalability by allowing software components to be first developed and tested in isolation, then scaled up for deployment in any environment (J2SE or J2EE). Additionally, Spring provides a number of other developer-friendly features that we enumerate below:

• A common abstraction layer for transaction management, allowing for pluggable transaction managers, and making it easy to demarcate transactions without the need to deal with low-level issues. Generic strategies for JTA and a single JDBC DataSource are included. In contrast to plain JTA or EJB CMT, Spring's transaction support is not tied to J2EE environments.

• A JDBC abstraction layer that offers a meaningful exception hierarchy (no more pulling vendor codes out of SQLException), simplifies error handling, and greatly reduces the amount of code you have to write. You'll never need to write another finally block to use JDBC again. The JDBC-oriented exceptions comply with Spring's generic DAO exception hierarchy.

• Integration with  industry-leading, object-relational  mapping solutions, in terms of resource holders, DAO implementation support, and transaction strategies. First-class support with lots of IoC convenience features, addressing many typical O-R mapping integration issues. All of these comply with Spring's generic transaction and DAO exception hierarchies.

• AOP functionality, fully integrated into Spring configuration management. You can AOP-enable any object managed by Spring, adding aspects such as declarative transaction management. With Spring, you can have declarative transaction management without EJB—even without JTA.

• A flexible MVC Web application framework, built on core Spring functionality. This framework is highly configurable via strategy interfaces, and accommodates multiple view technologies like JSP, Velocity, Tiles, iText, and POI. Note that a Spring middle tier can easily be combined with a Web tier based on any other Web MVC framework, like Struts, WebWork, or Tapestry.

You can use all of Spring's functionality in any J2EE server, and most of it in non-managed environments too. A central focus of Spring is to allow for reusable business and data access objects that are not tied to specific J2EE services. Such objects can be reused across J2EE environments (Web or EJB), standalone applications, and test environments without any hassle.

Spring's layered architecture gives you a lot of flexibility. All its functionality builds on lower levels. So you can, for example, use the JavaBeans configuration management without using the MVC framework or AOP support. But if you use the Web MVC framework or AOP support, you'll find they build on the configuration framework, so you can apply your knowledge about it immediately.

An Introduction to BEA WebLogic Server

In this section, we briefly summarize the features of BEA WebLogic Server, with an emphasis on the underlying infrastructure—rather than on programming models—that it provides.

WebLogic Server is a scalable, enterprise-ready J2EE application server. The WebLogic Server infrastructure supports the deployment of many types of distributed applications and is an ideal foundation for building any kind of application.

The WebLogic Server implementation of the Sun Microsystems J2EE 1.4 specification provides a standard set of APIs for creating distributed Java applications that can access a wide variety of services, such as databases, messaging services, and connections to external enterprise systems. End-user clients access these applications using Web browser clients or Java clients. Since J2EE is so widely known we will not discuss it in any more detail here. See the WebLogic Server documentation on  programming models for more information.

In addition to the J2EE implementation, WebLogic Server enables enterprises to deploy mission-critical applications in a robust, secure, highly available and scalable environment. These features allow enterprises to configure clusters of WebLogic Server instances to distribute load, and provide extra capacity in case of hardware or other failures. New diagnostic tools allow system administrators to monitor and tune the performance of deployed applications and the WebLogic Server environment itself. You can also configure WebLogic Server to monitor and tune application throughput automatically without human intervention. Extensive security features protect access to services, keep enterprise data secure, and prevent malicious attacks.

Enhanced quality of service with WebLogic Server

Like many other BEA products—and icebergs—WebLogic Server has more below the water line than above it. In particular, WebLogic Server provides a number of features and tools that support the deployment of highly available and scalable applications:

• WebLogic Server clusters provide scalability and reliability for your applications by distributing the workload among multiple instances of WebLogic Server. Incoming requests can be routed to a WebLogic Server instance in the cluster based on the volume of work being processed. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node. In addition, you can implement clusters so that services may be hosted on a single machine with options to migrate the service to another node in the event of failure.

• In addition to replicating HTTP session state across servers within a cluster, WebLogic Server can also replicate HTTP session state across multiple clusters, thereby expanding availability and fault tolerance in multiple geographic regions, power grids, and Internet service providers.

• Work Managers prioritize work based on rules you define and monitor actual runtime performance statistics. This information is then used to optimize the performance of your application. Work Managers may be applied globally to a WebLogic Server domain or to a specific application component.

• Overload protection gives WebLogic Server the ability to detect, avoid, and recover from overload conditions.

• Network channels facilitates the effective use of network resources by segregating network traffic into channels based on the type of traffic.

• WebLogic Server persistent store is a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. For example, it can store persistent JMS messages or temporarily store messages sent using the store-and-forward feature. The persistent store supports persistence to a file-based store or to a JDBC-enabled database.

• Store-and-forward services enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. If the message destination is not available at the moment the messages are sent, either because of network problems or system failures, then the messages are saved on a local server instance and are forwarded to the remote destination once it becomes available.

• Enterprise-ready deployment tools facilitate deployment and migration of applications from the development phase to a production environment.

• Production redeployment enables enterprises to deploy a new version of their application without interrupting work in progress on the older version.

Let's now look at the synergy between these two systems.

Developing Applications in J2EE and Spring

To compare and contrast the different development approaches between J2EE and Spring, we took the MedRec sample application and rewrote it using the Spring Framework. In the next section, we give a brief overview of MedRec's general architecture and then look at it in its J2EE form followed by its Spring form.

The Medical Records application

Avitek Medical Records (or MedRec) is a WebLogic Server sample application suite that concisely demonstrates all aspects of the J2EE platform. MedRec is designed as an educational tool for all levels of J2EE developers. It showcases the use of each J2EE component and illustrates design patterns for component interaction and client development. MedRec also illustrates best practices for developing and deploying applications with WebLogic Server.

The real-world concept behind MedRec is a framework for patients, doctors, and administrators to manage patient data using a variety of different clients. For patients, MedRec provides a Web-based application for users to view their medical record history and maintain a profile. For administrators, MedRec provides a Web-based application to manage incoming registrations, medical record uploads, and general application monitoring. MedRec also has resources for interfacing with independent medical institutions. To demonstrate this communication, MedRec consists of a physician application to request and provide data to MedRec’s system.

MedRec in J2EE—architectural overview

The J2EE and WebLogic Server version of MedRec is designed and implemented following the traditional three-tier architecture model in which the client, server, and data store are independent of one another:

• Presentation Tier: This tier is responsible for all user interaction; it is sometimes referred to as the Client Tier.

• Service Tier: This tier is the middle tier that encapsulates the application’s business logic. The Service Tier processes requests from heterogeneous clients while interfacing with various backend systems including data stores. This tier is sometimes referred to as the Server Tier.

• Enterprise Information System (EIS) Tier: This tier represents those systems that provide and/or store data such as legacy applications and databases. The EIS Tier is sometimes referred to as the data store.

For the patient and administration applications of MedRec, we developed Web applications (webapps) to expose services to their respective users. The webapps follow the Model-View-Controller pattern where Java Server Pages render the View to the user, the Model encapsulates the data presented to and captured from the user, and the Controller is the mechanism that manages the interaction of these components in addition to interfacing with the Service Tier. MedRec employs Jakarta Struts to accomplish this pattern.

The Service Tier provides services to requesting clients and manages interactions with backend applications and resources. MedRec’s Service Tier employs the Session Facade pattern to encapsulate business logic and business data. Session Facades simplify the complexity of an application by offering an interface into distributed services. In MedRec, the primary responsibility of Session Facades is to provide data throughput. In the J2EE and WebLogic Server version of MedRec, Sessions Facades are developed as stateless session Enterprise JavaBeans, and data is managed by entity Enterprise JavaBeans.

To interface with external entities, MedRec exposes application functionality through Web services, which allow for dynamic interaction between disparate systems using a series of open standards. By exposing services via Web services, MedRec can provide and accept data to and from independent parties, therefore achieving the primary goal of centralized medical record management.

Figure 1 illustrates the high-level architecture diagram of the J2EE and WebLogic Server version of MedRec.

Figure 1: Architecture diagram of the J2EE version of MedRec

Spring in action—Medrec reformulated

To establish that Spring can take advantage of the enterprise features of WebLogic Server, MedRec was rearchitected to replace core J2EE components with their Spring counterparts. We replicated the same functionality as the original version of MedRec with the Spring-based version of MedRec (MedRec-Spring).

The introduction of Spring’s IoC is the most prominent addition to MedRec-Spring. IoC is a powerful principle applied via a container that injects dependencies into configured components. IoC decouples application code from its configuration. For instance, objects are not concerned with their dependencies, so they may focus on their responsibilities. In MedRec-Spring’s case, enterprise resources such as DataSources, JMS services, MBean connections, and peer services are provided to MedRec-Spring’s objects during runtime. Additionally, by migrating resource configuration and referencing outside of compiled code, the application is more manageable to shifts from development-specific resources to production resources and environments that are in between.

To properly employ IoC, we found that an application’s code needs to follow stricter Java programming principles—specifically coding to interfaces. Interfaces, among other things, promote better collaboration because dependencies are lightened and implementation changes are isolated. From an IoC perspective, interfaces allow for the pluggable nature of dependency injection. To take advantage of IoC, MedRec-Spring was refactored so that business objects were coded against interfaces.

In MedRec-Spring, stateless session EJBs were replaced by Plain Old Java Objects (POJO). The strength of stateless session EJBs is their remoting capabilities and transaction management. MedRec-Spring satisfied the remoting requirement by exposing service beans via Spring’s HTTP Invoker architecture. Transaction management was provided by Spring’s transaction abstraction layer. Transaction management exactly mirrors that of the original MedRec because the Spring transaction manager was configured to delegate responsibility to WebLogic Server’s JTA transaction manager.

MedRec-Spring contains most of the original MedRec’s messaging functionality. We employed Spring’s JMS package to simplify some of the mundane tasks such as connection factory and destination lookups. Instead of programmatically obtaining a handle on a queue, Spring provides an object that represents a messaging destination. Like all Spring beans, these object representations—JNDI names, connection factory association, and so on—are configured outside of compiled code.

MedRec-Spring contains application management features. These features interact with WebLogic Server’s domain configuration as well as its runtime domain. MedRec-Spring must act upon WebLogic Server’s MBean Servers, and Spring offers connection management that simplifies the accessibility of MBean Server.

Finally, MedRec-Spring exports its services using Web services. Spring offers a JAX-RPC factory that produces a proxy for a Web service. Similar to other Spring beans, the factory bean is configured outside compiled code, making the application more flexible.

Figure 2 shows a high-level architecture diagram of the Spring-based version of MedRec.

Figure 2: Architecture diagram of the Spring-based version of MedRec

Spring Best Practice with WebLogic Server

Having compared the architecture of MedRec in both J2EE and Spring environments, we now describe some gems that we gleaned when implementing the MedRec-Spring application:

• Use lazy initialization. To implement its IoC container, Spring loads an application context file and creates and caches instances of each configured bean. It’s important to understand that each resource referenced by a Spring bean must be available for instantiation or lookup. For example, Spring’s JMX support provides connections to WebLogic Server’s MBean servers. Since not all MBean servers are activated during deployment, users should use Spring’s lazy initialization and look up services on start-up when deploying resources.

• Separate out Spring configuration based on functionality. This allows the application components to load only those contexts that are pertinent to their work responsibilities. The practice also allows testers to change the behavior of the application by replacing one application context—DataSource configuration, for example—with a context that is specific to the test environment.

• Encapsulate JDBC DataSource connection pooling via JndiObjectFactoryBean . Beans that require database interaction may then reference this bean in order to take advantage of WebLogic Server’s DataSource pooling capabilities.

• Use Spring’s org.springframework.ejb.support for Session and Message-Driven Enterprise JavaBeans . Spring’s org.springframework.ejb.support provides abstract classes that Enterprise JavaBeans (EJB) may extend. These abstract EJB classes assist development by including standard implementations for EJB lifecycle methods. More importantly, these classes provide mechanisms for loading Spring’s application context, including sharing the context across multiple EJBs and clients and therefore reducing duplication and overhead during EJB initialization.

• Leverage hot deployment and WebLogic Server’s split development directory environment. This vastly improves the Spring development experience during integration testing. Hot deployment allows your application to be reloaded without restarting the server. The split development directory environment enables faster development and deployment by minimizing unnecessary file copying. The split development directory Ant tasks help you recompile and redeploy applications quickly without first generating a deployable archive file or exploded archive directory.

• Package Spring libraries as application libraries, optional extensions, or server extensions. This allows several Spring applications to share the Spring Framework and reduces the footprint of your application. Not only does this decrease memory usage, but it improves deployment times too.

The Spring on WebLogic Server kit

To help you get the most from your Spring applications deployed on WebLogic Server, we have put together a certified BEA distribution that includes Spring 1.2.5, the MedRec on Spring application, and a host of other goodies. The kit can be downloaded from BEA's distribution Web site free of charge.