이번 S생명 차세대에서 실행 아키텍처 구축 및 검증을 수행하면서 웹로직과 스프링간에 관련된 문서를 찾게 되었다.
http://www.oracle.com/technology/pub/articles/dev2arch/2008/07/spring.html
Spring 2.5.x and WebLogic Server 10.3 Integrationby Michael Chen, Andy Piper, Eric Hsiao, Rod Johnson 07/28/2008 AbstractOver two years ago, we started the integration the Springframework 1.2.x with WebLogic Server 9.2. Last year, we updated the integration with Spring frame 2.0.2 and Weblogic Server 10.0. Since then, we have certified further versions of Spring and WebLogic Server culminating in the combination of WebLogic Server 10.3 against Spring 2.5.3. Both these versions represent further enhancements in functionality, useability and performance and we decided it was time to update this article to reflect this. Oracle WebLogic Server 10.3 is the leading implementation of Sun Microsystems' Java EE 5 platform. However, WebLogic Server's core value proposition is in areas not covered by the Java EE 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-Java EE Java 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 de facto implementation. This article introduces new features of the Spring 2.5.x Framework, WebLogic Server, and the integration of the two. As we shall see, the whole is greater than the sum of its parts. Article StructureIn 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. We first introduce the new Spring extension DI and AOP for WLS components feature. Then, to give it some context we examine MedRec—a sample application shipped with WebLogic Server—both in its original Java EE 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. Note: The MedRec sample in Spring was not changed during the WebLogic Server 10.3 release. We intend to update the MedRec sample application in the near future. However, we will mention some of integration enhancements we made this article. An Introduction to SpringIn this section, we briefly summarize the features of the Spring Framework, including some of the features new to 2.5.x Spring is a layered Java/Java EE 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 Java EE should be easier to use and that it's possible to enable a simpler approach to Java EE development without sacrificing the power of the platform. Spring enables agile Java EE development, and allows Java EE applications to be developed using Plain Old Java Objects commonly termed POJOs. Enhanced development experience with SpringAt 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 Java EE 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 applicationAs 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 (Java SE or Java EE). Additionally, Spring provides a number of other developer-friendly features that we enumerate below:
You can use all of Spring's functionality in any Java EE 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 Java EE services. Such objects can be reused across Java EE 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 Oracle WebLogic ServerIn this section, we briefly summarize the features of Oracle WebLogic Server, with an emphasis on the underlying infrastructure—rather than on programming models—that it provides. WebLogic Server is a scalable, enterprise-ready Java EE 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 Java EE 5 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 Java EE 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 Java EE 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 ServerLike many other 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:
Let's now look at the synergy between these two systems. Developing Applications in Java EE and SpringTo compare and contrast the different development approaches between Java EE and Spring, we took the MedRec sample application and rewrote it using the Spring 2.0.x Framework - making use of many of the new and innovative features in Spring 2.0.x. In the next section, we give a brief overview of MedRec's general architecture and then look at it in its Java EE form followed by its Spring form. The Medical Records applicationAvitek Medical Records (or MedRec) is a WebLogic Server sample application suite that concisely demonstrates all aspects of the Java EE platform. MedRec is designed as an educational tool for all levels of Java EE developers. It showcases the use of each Java EE 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 Java EE—architectural overviewThe Java EE 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:
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 Java EE 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 Java EE and WebLogic Server version of MedRec.
Spring in action—MedRec reformulatedTo establish that Spring can take advantage of the enterprise features of WebLogic Server, MedRec was rearchitected to replace core Java EE 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). Inversion of ControlThe 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. POJOsIn 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. MessagingMedRec-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. We also used Spring 2.0.x's Message-Driven POJO (MDP) facility as the target of JMS messages in three areas
AOPMedRec-Spring uses Spring AOP for two main purposes:
JPAMedRec-Spring now uses JPA for accessing and writing patient records. Application ManagementMedRec-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. WebservicesFinally, 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.
Spring Best Practice with WebLogic ServerHaving compared the architecture of MedRec in both Java EE and Spring environments, we now describe some gems that we gleaned when implementing the MedRec-Spring application:
The Spring on WebLogic Server kitTo help you get the most from your Spring applications deployed on WebLogic Server, we have put together a certified Oracle distribution that includes Spring 2.0.2, the MedRec on Spring application, and a host of other goodies. The kit can be downloaded from Oracle's distribution Web site free of charge. Spring extension DI and AOP for WLS componentsJava EE specification added Dependency Injection (DI) to Web and EJB container, and interceptors (a form of AOP) to EJB container. The Spring container is the leader in DI and AOP. WebLogic Server (WLS) is using Pitchfork to bridge with Spring to provide DI and interceptor to the WLS Java EE container. The integration not only satisfies the standard specification requirement, it also creates possibility for extension to the JavaEE5 specification as the Spring framework provides a richer set of features in terms of DI and AOP. WLS takes advantage of these integration features, provided the extension to the standard JavaEE5 DI and AOP. This extension provides DI and AOP to EJB instance and Web components that include the servlet listener and filter. In order to maintain server compliance, the standard out of box WLS installation only provides the standard JavaEE5 DI and AOP. You can see the steps to configure this feature at Spring Integration Enhancements. Enterprise SpringThe non-invasive IoC development model of the Spring Framework relies on, and is designed to complement, the feature set available to a Java EE 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 10.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 deploymentA 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 replicationSpring 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 Clustered Spring remotingSpring 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 applicationContext.xml <bean id="proProxy"
class="org.springframework.remoting.rmi.JndiRmiProxyFactoryBean">
<property name="jndiName" value="t3://${serverName}:${rmiPort}/order"/>
</property>
<property name="jndiEnvironment">
<props>
<prop key="java.naming.factory.url.pkgs">
weblogic.jndi.factories
</prop>
</props>
</property>
<property name="serviceInterface"
value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
</bean>The service exporter will look something like this: applicationContext.xml <bean id="order-pro" class="org.springframework.remoting.rmi.JndiRmiServiceExporter">
<property name="service" ref="petStore"/>
<property name="serviceInterface"
value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
<property name="jndiName" value="order"/>
</bean>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 componentsA new Spring console extension is implemented during the WebLogic Server 10.3 release. The console extension is based on RuntimeMBeans registered using WLS infrastructure; therefore, it provides a cluster view of the Spring applications and more management functionality for Spring Beans. It creates a Spring tab parallel to the Web or EJB applications, and it allows user to view the configuration information of the Spring bean on the WebLogic Console. In order to enable Spring console extension, you need to following the steps in Spring Integration Enhancements to deploy weblogic-spring.jar as a JavaEE optional package. Then, to generate runtime MBeans for your application, the WeblogicSpringApplicationListener from weblogic-spring.jar must be added as a listener to the root Spring context. This can be done in two ways. The first way is preferred. Edit web.xml and change the Spring context loader listener to the WebLogic one. web.xml <listener-class>weblogic.spring.monitoring.WeblogicContextLoaderListener</listener-class>The WeblogicContextLoaderListener extends the Spring ContextLoaderListener and simply adds WeblogicSpringApplicationListener as an ApplicationListener and a BeanFactoryPostProcessor to the web application context. If you already have a customized ContextLoaderListener and can't use the WebLogic one then you can add WeblogicSpringApplicationListener as a bean to the root ApplicationContext. In your web app Spring XML configuration file add the WeblogicSpringApplicationListener as show below. applicationContext.xml <bean class="weblogic.spring.monitoring.WeblogicSpringApplicationListener"/>Web services enablementAnother 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 We found that configuring the Most of the attributes are self-explanatory. A few attributes are of note:
Setting applicationContext-ws.xml <!-- reliable asynchronous Web service for sending new medical records to MedRec -->
<bean id="reliableClientWebServicesPortType"
class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean"
lazy-init="true">
<property name="wsdlDocumentUrl"
value="http://${WS_HOST}:${WS_PORT}/ws_phys/PhysicianWebServices?WSDL"/>
<property name="portName" value="PhysicianWebServicesPort"/>
<property name="jaxRpcService">
<ref bean="generatedReliableService"/>
</property>
<property name="serviceInterface"
value="com.bea.physician.webservices.client.PhysicianWebServicesPortType"/>
<property name="username" value="medrec_webservice_user"/>
<property name="password" value="WebLogic"/>
<property name="customProperties">
<props>
<prop key="weblogic.wsee.complex">true</prop>
</props>
</property>
</bean>
<!-- allows the jaxRpcService class to execute its constructor which loads in type mappings -->
<bean id="generatedReliableService"
class="com.bea.physician.webservices.client.PhysicianWebServices_Impl">
</bean>See WebLogic Server's Overview of Invoking Web Services and Remoting and Web Services Using Spring for further information. SecurityThe 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. The Spring security (acegi) provides security to a Spring application while providing a rich set of security providers.For an application with both JavaEE and Spring components, rather than require authentication with both security frameworks, WLS and Spring security with work together. WLS security handles the authentication, and converts WLS principals to Spring GrantedAuthority through a mapper class. Once authenticated by WLS security, a user is authenticated for Spring security. You can then decide how to secure the objects in the application. One of the common practices is to secure Java EE resource with WebLogic security and secure Spring resource with Spring security. You can see the steps to configure this feature at Spring Integration Enhancements. Distributed transactionsSpring 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
The most powerful feature of 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" read-only="true"/>
<!-- ... -->
</tx:attributes>
</tx:advice>For more information, see Overview of Transactions in WebLogic Server Applications and Implementing Transaction Suspension in Spring. Message-Driven POJOsMessage-Driven POJO's (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: RegistrationMessageListener.java public class RegistrationMessageListener implements MessageListener {
public void onMessage(Message message) {
// Fetch Registration information from ObjectMessage.
// Process new reg by invoking service (DI)
// ...
}
}Configuration of the MDP container is also, as with most things in Spring, naturally simple: 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 MDP's on WebLogic Server take a look here. JPA and AOP configurationWe have definied a web service tier that allow us switch web service implementations between RMI, the Spring HTTP invoker, Hessian/Burlap and JAXPRC easily. If we want to transfer objects via 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 spring aop to help us do that without having to change the application source code: ReturningValuePostProcessorAspect.java @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() {
}
}ReturningValuePostProcessor.java @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);
}
}
}applicationContext-jpa.xml <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 ExtensionsJava 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 The The Additionally, the 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 applicationContext.xml <!-- 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. SupportStarting with WebLogic Server 9.0 and Spring 1.2.5, Oracle 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 Oracle 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.2, but some of the new features were introduced in Spring 2.0.2 directly as a result of Oracle and SpringSource collaboration. DownloadThe Spring Open Source Framework Support 2.0.2 is downloadable from Oracle MetaLink as Patch 8408256. This includes Spring 2.0.2 - certified on WebLogic Server 10.0 - the Spring-JMX console extension and the WebLogic Medical Records sample application re-written using the Spring 2.0.x Framework. Future WorkIn 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. SummaryWe 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. Further Reading
|
j2ee >
Figure 1: Architecture diagram of the Java EE version of MedRec
Figure 2: Architecture diagram of the Spring-based version of MedRec