Using Spring to run an enterprise messaging application vs WebLogic

Hi-

I'm new to Spring and a novice at understanding the concepts of application servers and j2ee, so please bear with me if i screw up some concepts.

A little background:

My company currently uses WebLogic to run a messaging interface/app that acts as the middleware between an in-house thick client and a vendor busienss engine. The app also has data source connections to an oracle db.

[thick client] <--jms--> [ Our WebLogic app ] <--jms--> [vendor engine]
[oracle DB] <-WL DB SOURCE->
-Our Weblogic app runs on 2 sun servers as a single cluster for failover support and load balancing.
-The application provides asynchronous service to the thick client (stateless is the term i think).
-The only ejb we use are message driven beans, nothing else.
- We use tangosol caching to lookup data quickly for optimization purposes
- we don't use servlets or other stuff related to web dev

Our app does things like translate the data that the thick client sends into comprehensible data for the vendor engine and also does certain business logic that's customized for our needs to feed into the engine.

We use a custom proprietary framework written in java, which uses XML to configure objects, like how certain requests/replies are handled.

Question:

We are evaluating ways to save money on licensing by going away from Weblogic. I understand this would involve rewriting our code to fit with the new framework/app server.

1) Do you think using Spring framework only with no enterprise app server can serve well to fit our needs? (failover, clusters, load balancing, messaging, scalability, etc). The core question for me is, can I use Spring framework to suit my needs or do I also need some type of app server to go along with Spring for my needs? A developer on the team said he used spring 2.5.6 and activemq to simulate load balancing on a single machine (by running two "server" processes and running a client to send multiple requests to the two servers.). I think the concept was called "message driven pojo (http://blog.springsource.com/2006/08/11/message-driven-pojos/)"

2) (stupid question) What's the fundamental difference between Spring and WebLogic? Is it the fact that WebLogic is just a j2ee container and spring isn't? If I understand correctly from what I've read, an application built on the Spring framework can adhere to J2EE standards still, so I'm having difficulty understanding why people just not move away from app servers and go to spring, which is a lot cheaper and can do more I assume.

3) Any other suggestions on alternatives to WebLogic? Perhaps using Spring with another app server, or using a different app server by itself, etc?

4) Please feel free to provide some buzz words I should research on my own and I'll try to do my own DD if you show me the right door :).

Thanks

ps. i did use search and read for bit... the closest relevant topic i could find was this but it wasn't fully answered.

FB

Quote:

---

Originally Posted by firstblud

1) Do you think using Spring framework only with no enterprise app server can serve well to fit our needs? (failover, clusters, load balancing, messaging, scalability, etc). The core question for me is, can I use Spring framework to suit my needs or do I also need some type of app server to go along with Spring for my needs? A developer on the team said he used spring 2.5.6 and activemq to simulate load balancing on a single machine (by running two "server" processes and running a client to send multiple requests to the two servers.). I think the concept was called "message driven pojo (http://blog.springsource.com/2006/08/11/message-driven-pojos/)"

---

Since it appears that you are basically using weblogic as a messaging hub, you can surely move away from weblogic.

You could replace your weblogic cluster with a jboss cluster and it would provide almost all of the functionality that weblogic is providing: JMS provider, ejb container, datasource connector.

Since I don't use it, I'm not sure what current support Jboss has for clustered and highly available JMS but I'm pretty sure they have it.

I'd look here for a start:

http://www.jboss.org/community/docs/DOC-10526

If you decide not to go with jboss (e.g. you want to move away from enterprise containers altogether), you'd need a standalone JMS provider and a lightweight container to run your spring application (e.g. tomcat, jetty). You can replace your MDB's with MDP's in the spring container and connect to your standalone JMS provider.

The biggest issue you are going to have to deal with is failover. Your primary point of failure is the JMS server since it has to be highly available to your thick clients. It isn't clear if the outbound JMS is owned by the vendor (to which you send messages) or you (to which they connect and retrieve messages you've queued for them).

There are several free standalone JMS providers, including openjms and activemq. You'd have to investigate the failover/clustering support these offer to see if they'll meet your needs. Currently we use Tibco EMS as a JMS provider and it supports failover but it is not free (and frankly is overkill for our needs but I didn't make that decision).

Scaling in your case can be handled mostly by deploying horizontally at the message consumer tier (i.e. just add additional deployments of your application in a tomcat container, either on separate VM's or on separate physical servers).

Quote:

---

Originally Posted by firstblud

2) (stupid question) What's the fundamental difference between Spring and WebLogic? Is it the fact that WebLogic is just a j2ee container and spring isn't? If I understand correctly from what I've read, an application built on the Spring framework can adhere to J2EE standards still, so I'm having difficulty understanding why people just not move away from app servers and go to spring, which is a lot cheaper and can do more I assume.

---

Weblogic is an application server. It provides common services that most applications need: transaction management, threading, datasource/connection pooling, servlet container, security infrastructure. These are things that most applications need and using a container means that you don't have to build all this infrastructure yourself, you just leverage the services of the container.

Spring is basically just an application development framework and microcontainer. It allows you to DO many of the things that would be offered by the container, in conjunction with other libraries. For instance, you can create a datasource bean in your spring context and wire it up to commons-dbcp or c3po to provide the pooling support. In weblogic, you'd create a weblogic datasource and use JNDI to connect to it. In spring, you COULD connect to your spring datasource using JNDI or you could just wire up the users of that datasource (e.g. hibernate or spring jdbc) directly to the datasource.

However, one major thing that you lose when moving away from jboss or weblogic is a transaction manager; something which is very critical for your messaging application. We've migrated to using an atomikos TM that is configured with spring but let me tell you it was no picnic to get setup from scratch. I had alot of sleepless nights as we were untangling our reliance on jboss jms, datasources and transaction management. Atomikos is great once you get it configured but you have to configure it. It's not like an enterprise container where you just wire up to the existing TM via JNDI.

Moving away from an app server can be a good thing but frankly, it's trading one poison for another. Frequently your applications become just as highly dependent on and integrated with the spring framework as they were with the application server. In most cases this isn't such a bad thing since a spring app is still highly portable and can be dropped in weblogic, jboss or tomcat with little or no modification and it will still run. However, you are binding yourself rather tightly to a technology, much as when you make the decision to use struts or any other framework.

Quote:

---

Originally Posted by firstblud

3) Any other suggestions on alternatives to WebLogic? Perhaps using Spring with another app server, or using a different app server by itself, etc?

---

We run our spring apps on jboss with Tibco EMS as our messaging provider. We have messaging apps as well as web apps. Our webapps don't need to provide failover so we don't use HTTP session clustering (e.g. if the app server you are talking to dies another server can pick up the conversation). What this means is that if a server dies, you'd have to log back in and any work in flight would be lost. OTOH, our apps are mainly for internal, not external customers so this isn't a requirement. We provide load balancing using a dedicated load balancer/SSL terminator (e.g. BigIP F5). This provides stickly sessions so that a user is pinned to the same server for the duration of their HTTP session.

We could pretty painlessly migrate away from jboss and use tomcat but our IT staff is familiar with Jboss and we don't see much need. However, we really aren't using any of the jboss enterprise container services at this point, other than things like the application deployer (which automatically finds your WAR/RAR files and deploys them and the servlet container.

Hi,

If you are doing messaging then you don't need an application server nor even Tomcat. Atomikos supports message-driven POJOs (it is a core component of the platform).

Have a look at these:

http://www.atomikos.com/Publications...licationServer

http://www.atomikos.com/Publications...ionsWithSpring

http://blog.atomikos.com/?p=36

http://blog.atomikos.com/?p=29

Best
Guy

appreciate the lengthy feedback. will look more into your ideas.

Another question... in the context of my original post, how do i decide when i should

a) run a spring application as standalone (i.e. simply call the class with a "main" method in it)

or

b) run the spring application within some type of container like (tomcat, jboss, weblogic, etc)?

The reason I ask this is because I've read a lot of spring tutorials (all of them only web related examples) and some ran spring as standalone to run a basic web app while most seemed to use tomcat. I failed to find an explanation as to why tomcat was or was not used, so I'm a bit confused. Could I please get a description of when to use or not use it? My understanding was I thought tomcat was only useful if you want to use JSP and servlets. However, there seems to be cases where people just want to use tomcat just because...

my question inspired by my thread and (http://forum.springsource.org/showthread.php?t=48197)

thanks!

The biggest disadvantages to running an application as a standalone app (main method) versus a container is the lack of manageability and portability.

While newer jdk's and the management api (JMX) make this somewhat easier, without a container you'd have to build managed components in your application to support much of what you already get in a container.

How would you gracefully shutdown your application? If you ctrl-c your app you could nuke in flight work. While this can be mitigated with transactionally bound work using a transaction manager that supports recovery, if you are doing other things such as reading/writing files or other things that are outside a transaction you are left with inconsistent state.

When you hit ctrl-c in a jboss container, the shutdown hook that jboss registers on startup gracefully brings down the container (including your spring application). When you hit crtl-c in a (main) application, it just terminates.

Jboss provides several management views of your application that allow you to monitor threads, memory and cpu usage as well as the applications that are deployed. This is all available via the web browser. Tomcat provides a similar admin interface. With a (main) application your options are more limited. You can use something like jconsole to connect to a running VM but you won't get any insight into your application unless you've added your own JMX managed components.

WRT portability, if your app is packaged as a runnable application it has to be in a jar. This means that you CANNOT deploy it to a container unless you repackage it into something that meets the J2EE specification (e.g. WAR/RAR/EAR) for application deployment. This effectively means that once you've made your bed, you'll have to lie in it or suffer the pain of migrating it back to support a container if the need arises.

Obviously I've simplified quite a bit of the above but the general idea is this: while the idea of avoiding an application server/container seems good in theory, in practice, there are several free solutions to choose from (depending on what you need) and it really makes alot of sense to just use one as it makes your application more portable. If you avoid binding to any of the J2EE container pieces (i.e. JNDI) in your application and you aren't using the servlet container, you can easily drop the same artifact into any of these containers and it should still run.

great post. thanks for going into detail for a dummy like me. makes perfect sense and I'm sold on picking a container now :)

Hi

I am working on a similar problem and would seek suggestions. As pointed out by chudak, we need an app server for manageability and portability. My messaging application does not have a front-end. So I do not want to go for Tomcat etc. Also since I am not wanting to use EJB-MDB's so I do not want an app server as well. Do I have any other choice in this case to deploy my application?

Sorry for repeating myself:

http://www.atomikos.com/Publications...licationServer

HTH

Quote:

---

Originally Posted by chudak

The biggest disadvantages to running an application as a standalone app (main method) versus a container is the lack of manageability and portability.

---

Portability is assured by the VM and no longer by the appserver dinosaur:-)

Quote:

---

Originally Posted by chudak

While newer jdk's and the management api (JMX) make this somewhat easier, without a container you'd have to build managed components in your application to support much of what you already get in a container.

---

Right, just like any appserver requires; this is not really an argument IMHO.

Quote:

---

Originally Posted by chudak

When you hit ctrl-c in a jboss container, the shutdown hook that jboss registers on startup gracefully brings down the container (including your spring application). When you hit crtl-c in a (main) application, it just terminates.

---

You have a point here, although this does not really sound like a killer feature to me. I guess it's not that hard to add utilities that intercept ctrl-c... Most managed UNIX environments will prevent you from doing that anyway?

Quote:

---

Originally Posted by chudak

Jboss provides several management views of your application that allow you to monitor threads, memory and cpu usage as well as the applications that are deployed.

---

So does the JMX console of any JDK 5 or higher... And you're not restricted to a web interface either.

Cheers
Guy