Web Logic

WebLogic Server (WLS, for short), an EJB Server (among other things) originally created by BEA Systems (http://www.beasys.com/products/weblogic/), now owned by Oracle.

A Review from TheServerSide.Com

BEA WebLogic Server 6.0

The Main Points

No more evil properties files :) [Enter the console] (Though BEA employees generally seem to edit the XML files)
No more classloader issues (well not the same ones)
Central Admin Server -> Managed Server
EJB 2.0 [almost]
Database Multipools
Solid transaction support (Two Phase Commit)
Enhanced JMS
Enhanced web server
JMX system management
Stateful Session In-memory replication
Deployment tool? where? :)

Admin Console

If you have used WLS 5.1 or below, you will be pleased to see that the weblogic.properties files are gone! You used to configure WLS via a text file, that would allow you to screw up the entire server by not putting a '\' in the right place. WLS 6.0 now holds its configuration in a config.xml file, that you are not supposed to directly edit. You configure the server via a console web application that has an explorer look and feel (left hand tree, right hand pane to edit config).

The console is a big improvement to the properties files, but it is still a little buggy, and you find yourself touching that config.xml manually from time to time. In the future your config could live in a database, LDAP, etc.

weblogic.class.path no more

Again, if you are used to WLS 5.1 and below you will have run into problems when you didn't setup your weblogic.class.path, CLASSPATH, and/or servlet.class.path correctly. The nasty "ClassCastException" can glare at you if you are not careful. Now JDK1.3 is out, it allows WLS to disgard it's hack with multiple classloaders, and we are left with one CLASSPATH. WLS *forces* you to use 1.3 and above for the server, which I am fine with :) It may seem like a small thing, but I have seen more problems with the classpaths than I have had hot dinners.

Central Admin Server -> Managed Server

WLS 6.0 has changed its configuration architecture to come closer to BEA Tuxedo. You have an admin server that holds the configuration for all servers in a given "domain". When you start up the managed servers, they point to the admin and get their config, and code sent over to them. This allows you to centralize your configuration, instead of having properties files all over the network.

EJB 2.0 [almost]

WLS 6.0 has a 2.0 container, that has everything bar dependant objects, which are going to change a lot in the final release of 2.0 anyway. You can write Message Beans, enhanced CMP with relationships, etc.

Database Multipools r

You have always been able to setup jdbc connection pools in WLS, but in 6.0 they allow you to setup a meta pool. You would normally setup your architecture so that you have replicated database servers, and then the pool points to both servers (e.g. Oracle replication). Then if the main oracle instance dies, the multipool will failover to the backup instance.

Solid transaction support (Two Phase Commit)

BEA got the transaction gurus from Tuxedo, and built full XA compliant 2PC transactional support into WLS 6.0.

Enhanced JMS

The JMS architecture has been solidified, and is now enterprise ready, so you could use it instead of an IBM MQSeries, SonicMQ, etc.

Enhanced web server

The web server in 5.1 and below has always been a little "bare bones", and its performance has been a little weak. The updated web server allows you NOT to have to sit behind apache (or netscape, iis, ...). You get virtual hosting support, extended logging, and more... but it still isn't as feature rich as a *real* web server.

JMX system management

BEA opened up the server management to use the JMX API, so you have a standard way to manage the server. The console, command line tools, all use this API. You can use the MBeans in the server to tie your code into the management infrastructure! Yay standards :)

Stateful Session In-memory replication

WebLogic clustering has been improved in 6.0. You can now cluster stateful session beans using in-memory replication. The server that holds the state will replicate it to a backup server. If the primary goes down you will be routed across to the backup. Then the backup will become the primary and choose another server as its backup.

You also have a say on choosing the backup via replication groups, and by tying servers to "machines". This is needed because you do not want to replicate your state to another server on the same box... as what if the box goes down!

Deployment tool? where? :)

So it comes to deployment time. You want to package an EJB. Surely you don't have to hand edit the XML descriptors? Well, kinda!

Your options are:

Use the WLSBuilder that you can download from the develop.bea.com website. This is a web based app that can package beans... but it is VERY buggy. In fact it has never gotten out of beta, and they have stopped developing it
Use a third party tool (e.g. in your IDE: Together, Cafe, JBuilder, etc). I think a lot of tools are catching up for WLS 6.0/EJB 2.0
Write the xml yourself, and write helper tools yourself :)

I wish there was a really nice tool given to us!

Conclusion

There are a lot of good additions to WLS 6.0, however it looks like some bugs need to be ironed out (Service Pack 1 seems to fix a lot). I like the fact that you can shove a .jar file into a directory and have it auto-deploy (JBoss has had that for a long time), and in general I have been impressed with the product.

BEA continues to be a server to beat

...your head against a wall with (see WebLogicGripes).

I'm playing with WebLogic 6.0 at the moment, and I've started a WebLogicGripes page to allow me to vent. WebLogic is a nice product, but damn, there's some annoying problems with it. -- RobertWatkins

CategoryEjb