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
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? :)
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.
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
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!
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