Choosing right technology for messaging system

Question

I'm working on a messaging system for two years now, the system was written by a long ago gone team and involves emails and document processing. The basic process is:

1. Receive an email, parse it, save attachments to samba share. Notify message processor. We have a robust Java application doing this very well.

2. Process the message, this involves getting user data from LDAP, calling file processing web-services on different platforms. The system has a sort of re-delivery service that polls database for failed or timed out messages in different states and resends them.

The file processing parts are EJB web-services that basically run command line utilities. The problem lies in our orchestration solution which is based on OpenESB (almost dead now), it has a bunch of BPELs calling each other and calling remote EJBs (EJB3.0 on glassfish v2).

The biggest problem is that too much logic is done in BPELs (say, all database updates are done in BPELs, there's no persistance layer), they look like the most horrifying spaghetti I've ever seen. Not to mention they make NetBeans which we're using to edit them run really slow, to the point that some files are only editable in a simple text editor as XML. Moreover the system has a number of nasty bugs that would require major refactoring to fix and I'm dreaded to even think about it. These messages are handled manually by our support stuff so there's almost no client-impact but I would like to have a real transactional system anyway.

Now, for the question itself. I'm willing to spend a lot of my own free time trying to reach two goals: build a replacement for ESB and BPELs, learn new and preferably trendy technologies. I would like to keep the code in file processing EJBs since they run just fine, although I'm thinking of getting rid of SOAP as their remote interface. So I'm asking for any insight of which technology(-ies) would let me create a robust messaging solution that would:

1. Have a friendly persistence layer, there won't be anything really complex in dbs, just message meta-data.
2. Take care of balancing and polling calls to file processing web-services.
3. Wouldn't require dealing with tons of XML in different places in order to add a new interface method.
4. Would be scalable - run on a number of machines.
5. Would allow realtime monitoring, like viewing message queues, current load, statuses etc.
6. Hopefully will let me learn something new, meaning not J2EE stack. Basically I'm open to anything except BPEL and OpenESB.