WebLogic Server 10 Update: Java EE 5, Spring Pitchfork, WS-*

Posted by Floyd Marinescu on Feb 09, 2007 02:23 PM

Community

Java,

SOA

Topics

WS Standards ,

Application Servers

Tags

JPA ,

Spring ,

WebLogic ,

BEA

BEA has released a new tech preview of WebLogic Server 10 that has passed the Java EE 5 CTS (compatibility test suite), making WebLogic the first of the big 3 to feature a release that passes the tests. WebLogic Server 10 uses the Kodo JPA container (based on Apache OpenJPA) for JPA and also Spring's Pitchfork project to provide EJB and Java EE 5 features. In addition to Java EE 5 support, WebLogic Server 10 also adds side-by-side deployment of multi-version apps, JMS automatic failover, tools & standards for document-centric web services development, filtering class loader, clusterwide-singleton EJB timer etc. The tech preview also includes the BEA Workshop for WebLogic, which provides Eclipse 3.2-based tooling support for WebLogic.

InfoQ spoke to BEA's Patrick Linksey to learn more about what's cool  about WebLogic 10, including the Spring integration (discussed later in this article).   Some of the key new things according to Patrick are:

The primary focus of WebLogic Server 10 is Java EE 5. This translates into a lot of specification updates and new specification support, including the new Web Services specifications and the EJB 3 / Java Persistence API specifications.

The filtering classloader functionality will be another welcome addition - this allows developers to use different versions of the same libraries that WebLogic Server depends upon, by configuring the application's classloader to exclude classes and packages found in the server classpath.

We've also done some interesting work in the deployment arena. Most notably, we've fleshed out the side-by-side production deployment functionality that was introduced in the WebLogic Server 9 release cycle, and we've implemented an option to record console activity and store it as WLST (WebLogic Scripting Tool) admin scripts for later execution.

One neat new feature in WebLogic Server 10 is our support for clusterwide-singleton EJB timers. We've had this functionality in previous versions via proprietary APIs, but now it's possible to designate that an EJB timer should be unique in the cluster. This is useful when you want a timer to kick off to run an application-level operation that should only happen at one location in the cluster, such as database cleanup, bulk imports of data, or periodic system status emails.

A key focus for WebLogic 10 was interoperability with other vendors in the Java space, older versions of BEA Web Services stacks, and with Microsoft / Indigo. "Another major focus was better support for document-centric web services such as the JAX-WS 2.0 spec in JEE5, while continuing to support existing RPC-based web services via retention and enhancement  of our JAX-RPC stack," Patrick said. The most notable new specifications are:

• WS-SecureConversation (2005/02)
• WS-Security 1.1
• WS-SecurityPolicy 1.1/1.2
• WS-Trust (2005/02)
• WS-MTOM
• .NET WCF/Indigo interoperability
• Standalone WS client
• Improved XMLBeans support
• Asynch callback support from Workshop 8.1-based Web Services

WS-MTOM is a standard for high-performance non-XML-in-XML processing (Message Transmission Optimization Mechanism). It is designed for optimizing SOAP with non-XML attachments. The really useful thing about it (versus its predecessors, like SOAP With Attachments and Microsoft's Direct Internet Message Encapsulation) is that it is supported broadly by the SOAP vendor community, including vendors in the Java space and Microsoft.

Another new feature in WebLogic 10 is automatic JMS failover. Patrick explained:

Automatic JMS failover kicks in when a JMS client is unable to reach the server, either because the server went down or because of network problems. For JMS producers, this is pretty transparent: by default, if a producer fails to reach a server, it will transparently attempt to fail over to another available server instance. Things are a bit more tricky for JMS consumers: since consumers are often stateful, the default behavior is to not automatically reconnect in case of failure. If you are sure that your consumer logic can tolerate reconnects gracefully, then you can write some code (or do some admin configuration) to enable consumer reconnects. http://edocs.bea.com/wls/docs100/jms/recover.html goes into the various options and considerations in more complete detail. Internally, this is implemented with the same facilities we use for service migration in general, including cluster-singleton service migration.

WebLogic Server allows multiple versions of the same application to be deployed to the same server (or server cluster) at the same time:

So, if you have version 1 of your stock trading application on-line and in use, you can then deploy version 2 into a staging mode, test it out with internal folks or a few eager customers, and then bring it online to replace version 1.  You even get to choose how to bring down version 1 of the application: gracefully (meaning that clients currently using version 1 keep on using them indefinitely, until they disconnect and reconnect), graceful with a timeout, or immediate shutdown of the old version.

BEA and Interface21 (providers of Spring) collaborated on a project called Pitchfork to deliver Java EE 5 bindings for Spring 2 in WebLogic 10; the EJB3 and web container implementations make use of Spring via Pitchfork to provide some of the new dependency injection and interceptor capabilities:

This architecture also provides us with some opportunities down the road to expose Spring artifacts to WebLogic Server developers at a more integrated level. Meanwhile, our EJB 2 code paths remain virtually unchanged from WebLogic Server 9.2. This helps ensure that customers upgrading from the WebLogic Server 9 family will have a very smooth experience. We expect that upgrades from the WebLogic Server 9 family will be trivial.

A frequent question about the Spring WebLogic integration is if there will be any externally facing Spring features that WebLogic users can benefit from. Patrick named a few:

...deployment of Spring beans in a WebLogic Server cluster; Spring session replication (piggybacking on WebLogic HTTP session replication); WebLogic security integration with Spring beans; WebLogic-based clustered remoting of Spring beans; and management of  Spring beans in the WebLogic Server administration console. Additionally, we've laid the groundwork internally for some compelling new externally-facing Spring integration capabilities, but we aren't exposing these just yet in WebLogic Server 10.

See more news about BEA at http://infoq.com/bea.  Patrick Linksey & Spring's Rod Johnson and Rob Harrop are all speaking at the QCon London event, this March 12-16.

1. Back to top

   Very nice. It would be even better if...

   Feb 9, 2007 4:27 PM by Martin Perez

   ... libraries could be defined also at server level, so sitting at a higher stake in the ClassLoader hierarchy. ... there was some cluster-wide URL Resource Provider and registry. ... there was some way to plug classloader plug-ins or extensions. ... the JMS system were more reliable under heavy load conditions. Ok, this is something that happens with all the three competitors.

   Reply

2. Back to top

   Re: Very nice. It would be even better if...

   Feb 9, 2007 11:46 PM by Patrick Linskey

   ... libraries could be defined also at server level, so sitting at a higher stake in the ClassLoader hierarchy.

   The way that libraries work in WebLogic Server, every EAR (or other top-level module) always gets its own copy of the classes in the library. This to provide strong isolation between different enterprise archives.

   ... the JMS system were more reliable under heavy load conditions. Ok, this is something that happens with all the three competitors.

   What do you mean by "heavy load conditions"? -Patrick -- Patrick Linskey http://bea.com

   Reply

3. Back to top

   Re: Very nice. It would be even better if...

   Feb 10, 2007 6:32 AM by Martin Perez

   Hi Patrick. Yes, I know how libraries work in WebLogic. What I say is that in other application server(s) in addition to this library-tied-to-application model you can deploy a library tied to the server. So you can share the classes and still leverage the library version/packaging advantages. The drawback is what you said, breaks isolation. But the choice will always up to the developer. heavy load conditions. I suppose I mean thousands of users,hundreds of thousands of messages going around, etc. I found that it´s not strange to see some sporadic thread lock, some message lost, etc. But as I said, happens with everyone, and I don´t consider it a capital sin. Finally, BEA support is quite good and always does the best efforts to solve this very concrete failures.

   Reply

4. Back to top

   Re: Very nice. It would be even better if...

   Feb 14, 2007 3:34 PM by Nagesh Susarla

   Hi Martin,

   Yes, I know how libraries work in WebLogic. What I say is that in other application server(s) in addition to this library-tied-to-application model you can deploy a library tied to the server. So you can share the classes and still leverage the library version/packaging advantages. The drawback is what you said, breaks isolation. But the choice will always up to the developer.

   Nice point. I'd like to mention that we did investigate this option before deciding not to go for it. I presume you are saying that a single classloader would host each library version, it being a child of the system-classloader/app server classlaoder? (Otherwise adding it to the system classpath would allow only that particular version to be visible) In this model, all application classloaders would be children of the system classloader but would also "import" the specific library version they intend to use. This is similar to saying that the app classloader now has multiple parents. The problem with multi-parent classloaders, when you allow excluding/filtering packages in one classloader is that you always end up with another path to the system-classloader/parent breaking the exclusion/filtering guarantees required by the child classloader. Although a good model, this would have lead us to have an either exclusion OR server-wide library model so we decided to keep it simple. That said, we're doing some research into classloading architectures that can support both limited class pollution and multi-parent classloaders. If those projects make it into the WebLogic Server, we will be able to revisit that decision.

   Reply

5. Back to top

   Re: Very nice. It would be even better if...

   Feb 22, 2007 3:54 PM by Ramdas Hegde

   Since there is a discussion on how libraries work within WLS 9.2 , i had a question since i have not got a convincing answer or explaination on this from other sources. If i have a single application domain, is it preferable to package libraries(JARs) as part of the EAR or drop it into the /lib folder? I am not sure if there is a memory footprint difference at runtime since including libraries as part of the EAR increases the size of the EAR. Thanks Ramdas

   Reply

6. Back to top

   Re: Very nice. It would be even better if...

   Feb 24, 2007 12:17 PM by Nagesh Susarla

   Hi Ramdas,

   If i have a single application domain, is it preferable to package libraries(JARs) as part of the EAR or drop it into the <domain>/lib folder? I am not sure if there is a memory footprint difference at runtime since including libraries as part of the EAR increases the size of the EAR.

   As you've already mentioned there are two options 1) Add them to the domain/lib directory 2) Package them into the physical EAR OR you could use the shared application libraries detailed here Before you choose an option, we have to consider the following 1) Do these jars ever change? 2) Is it possible that in future an application would need a different version of the jar? If you answered "yes" to any of the above then using the Shared Application Libraries is ideal. Also note that for domain/lib directory, you must either share the lib directory between the admin and managed servers OR distribute the files yourself. (this requires additional steps on your side) The distribution of libraries is handled by the deployment subsystem which implies that you do not have to worry about distributing the jars yourself to multiple servers. Lastly I should point you to a great blog by Rob Woollen on Application Libraries here -- Nagesh

   Reply

• Older >