Spring in WebSphere

[bdrhoa]

I'm trying to understand what the connection between Spring and WebSphere could/should be. I'm new to both and a bit confused...

I love the base ideas in Spring. And when I've done Java in the past (cerc. Struts 1.0), I ended up with 1 directory (or .war) that I could easily move from server to server. Back then it was all Tomcat and the only thing I used the container for was to protect a directory. So I'm hoping to use Spring for everything if I can. But I need to understand things better to make my case.

On this project I have to use WebSphere. It looks like there is a sort of framework built into WebSphere itself.

So, does it make sense to use Spring in a WebSphere environment? Should I use just Spring (if the powers at be will let me) or should (can) I use the pieces of Spring that WebSphere doesn't have?

My questions here releate to two separate subprojects. I'm writing a web service to update an LDAP direcotory.

The other project is a client that will consume the service; I will most likely be forced to use a WebSphere portlet for the front end. Can (and again should) Spring portlets be used in the WebSphere portal server? Or can a WebSphere portlet just be the front end to a Spring middle layer?

Thanks for the help!

[JimScarver]

I would expect the Spring MVC framework to be redundant in the portal environment. You may want to see this article on deployiong a struts application on websphere.
http://www-128.ibm.com/developerwork...nis/hanis.html

I am more interested in using other aspects of Spring on WebSphere.

I am investigating avoiding the use of EJBs by using Spring for distributed objects and services on Websphere.

Or, using spring to allow transparent migration to EJB3.0 when it is available.

Any pointers would be moost welcome.

[JimScarver]

this link may help:
Configuring Hibernate, Spring, Portlets, and OpenInSessionViewFilter with IBM WebSphere Portal Server

http://www.thearcmind.com/confluence...ortal +Server

[Rod Johnson]

So, does it make sense to use Spring in a WebSphere environment? Should I use just Spring (if the powers at be will let me) or should (can) I use the pieces of Spring that WebSphere doesn't have?

There is no conflict in using Spring in an application running on a J2EE application server. You can still access WebSphere's distributed transaction management regardless of whether you use the Spring or EJB programming model. And, if you want, you can use Spring even to simplify the implementation of EJBs.

All the same benefits apply as in other environments: greater productivity, greater ease of testing etc.

Assuming that you have any JSR-168 compliant portal server, you can use Spring Portlet MVC.

Regarding the powers that be, if they have any misgivings about Spring being enterprise ready you could tell them that all French online tax submissions are handled by a Spring-based application, and that soon all 70 million per day UK interbank transfers (including 90% of all salaries in the UK) will be handled by a Spring-based application.

[mchellia]

Can somebody point me to a crisp document which highlights how J2EE servers (Geronimo, Jboss, etc.) complement Spring framework? In other words, I am assuming that Spring + Tomcat cannot replace a full-fledged J2EE app. server for enterprise customers. On the other hand, I do believe that J2EE app. server + Spring - EJB is a huge value-add. However most of the pitches on Spring that I am exposed to gloss over the gaps it has which only a J2EE app. server can plug. Any help here would be greatly appreciated.

[wpoitras]

I found Rod Johnson's Expert One-on-One J2EE Development without EJB explains how Spring helps you replace EJBs pretty well.

It is possible for Spring to obviate the need for a J2EE server. It really depends on what services you require. Spring + Tomcat can provide declarative transaction management, stateless services similar to local EJBs, various forms of remoting/web services. If you need JMS ActiveQ can be added to mix pretty easily. For simple Web and Spring clustering Terracotta provides focused products to meet those needs without having to upgrade to a full blown server.

But J2EE servers do have their place. They offer more advance logging, monitoring, clustering services. Their implemenations of JTA, JMS maybe more mature, or at least more integrated. BEA accepts the reality that simple J2EE applications don't need a full blown app server. Of course when you DO need an app server, they fully support Spring so you can migrate to their application server

The thing I have found that Interface21 and Spring reinforce is using the right tool for the job. And with Spring you can get capabilities you could only get before with a full app server. So now there is a range of choice.

[mchellia]

Thanks for the response. Actually, you hit right on the point for more integrated support for JTA in an app. server as an advantage over Spring+Tomcat+ stand-alone JTA implementation (e.g., JOTM). Even though I have not understood this completely, a look at JBoss source code as well as JTA spec.s from Sun indicate that J2EE app. server clearly has a role to play in global transaction management (i.e., as an intermediary between transaction manager and resource manager to coordinate connection pooling and ensure application transparency in this regard) which in my understanding Spring is not trying to obviate.

I was also curious about Rod Johnson's quote also in this regard something like as follows: "Spring's goal is no to be as an alternative for full-blown global transaction management by an application server". My quest is really for a devil's advocate perspective on Spring to the effect that it is not a cure-all but a much better facade to a robust J2EE application server than an EJB container can be. Otherwise, I canno tunderstand why there are attempts to integrate Spring with the likes of Geronimo rather than making a claim that Spring is all that J2EE enterprise customers need.

[wpoitras]

Thanks for the response. Actually, you hit right on the point for more integrated support for JTA in an app. server as an advantage over Spring+Tomcat+ stand-alone JTA implementation (e.g., JOTM). Even though I have not understood this completely, a look at JBoss source code as well as JTA spec.s from Sun indicate that J2EE app. server clearly has a role to play in global transaction management (i.e., as an intermediary between transaction manager and resource manager to coordinate connection pooling and ensure application transparency in this regard) which in my understanding Spring is not trying to obviate.

Actually this is one area Spring can actually replace as long as you have a robust enough JTA implementation. Unfortunately, I don't think JOTM is quite there because it is still working on XA recovery. But because of the data access abstraction Spring has, it can do the right thing with reguard to coordinating connection pooling. Even better you can switch between JTA and non-JTA transaction strategy (like the Hibernate or JDBC native) without having to change your underlying code.


[/QUOTE]I was also curious about Rod Johnson's quote also in this regard something like as follows: "Spring's goal is no to be as an alternative for full-blown global transaction management by an application server". My quest is really for a devil's advocate perspective on Spring to the effect that it is not a cure-all but a much better facade to a robust J2EE application server than an EJB container can be. Otherwise, I canno tunderstand why there are attempts to integrate Spring with the likes of Geronimo rather than making a claim that Spring is all that J2EE enterprise customers need.[/QUOTE]

Spring is definitely not a cure-all. But it is designed to help you architect your application one way, and as your requirements get more intense be able to migrate your code to a more robust environment and not really have to change your code.

Spring is more about integration than about actual J2EE technology. It mostly provides consistant abstractions on top of existing technologies that you must provide: Hibernate, iBatis, JDBC, Toplink, JTA, JMS, JMX, EJB, Hessian, Burlap, RMI, JCA, Quartz, Web services.

I say mostly because it does provide a few things that are replacement technologies:
- Spring MVC web framework
- Because of the data access and transaction abstractions, can provide local and remote stateless services without an application server.
- IoC container that replaces (at a higher level of functionality) custom factories and JNDI (although it can still utilize JNDI if needed)

[simbo1905]

Can somebody point me to a crisp document which highlights how J2EE servers (Geronimo, Jboss, etc.) complement Spring framework?

POJOs In Action by Chris Richardson has a chapter on spring+ejb in it's "alternatives" section. most of the book is spring with JDO or Hibernate side by side examples.

[bsdwork]

simbo1905 can you help us with a link or something?
Thanks,
Daniel
__________________
Wisdom is knowing what to do next; virtue is doing it.David Starr Jordan
low-fat diet