Announcement Announcement Module
Collapse
No announcement yet.
Spring in WebSphere Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring in WebSphere

    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!
    Last edited by Rod Johnson; Jun 19th, 2006, 11:54 AM.

  • #2
    distributed objects and services with websphere/spring

    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.

    Comment


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

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

      Comment


      • #4
        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.

        Comment


        • #5
          Spring and J2EE application server

          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.

          Comment


          • #6
            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.

            Comment


            • #7
              integrated JMS/JTA/security support in J2EE app. servers

              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.

              Comment


              • #8
                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)

                Comment


                • #9
                  spring+ejb

                  Originally posted by mchellia
                  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.

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      more 2c, make it $2

                      bsdwork: POJOs In Action is at http://www.manning.com/crichardson/ and you can download the source code from that page. If you open the zip file of source code at the link you can see the chapter 10 source code for ejb3.

                      Commercially in my day job I work with Spring run inside of websphere6 stateless session beans and Spring run in the webapplication running in websphere6. Make a pojo facade managed by Spring as per the POJOs In Action book then make an EJB stateless session bean that implements the interface. Then in the implementation of the EJB just programmatically start up a spring bean factory and get the bean that is the pojo facade and invoke its methods. The EJB is then just a very thin wrapper. Use the spring websphere transaction manager support to enlist in any ongoing container managed transactions (e.g. JMS messages might be sent under the same distributed transaction). The advantage of using spring to manage the transactions is that you can write junit tests that test database rollbacks that you can run in your IDE or on cruise control without having to start up a websphere container (which is just too slow for a JUnit test). Waiting to cycle websphere 6 in RAD slows you down to the point where you just cannot be productive. Last month I had to refactor another teams code that could not run outside of Websphere/RAD and my productivity dropped to about half as I spent hours during the day waiting for Websphere to restart. My teams code runs in either Websphere/RAD or Jetty due to the magic of Spring or in JUnit and we are massively more productive as we watch unit tests run in seconds so we run them constantly and we watch our webapp come up in tens of seconds not tens of minutes.

                      Do you need a EJB between your webapp and your data access code as recommended at the turn of the century? No not really. We did that and are now refactoring to just go from the webapp to the data access code. As we wired it all together with Spring the refactor is fairly easy. Spring encourages clear seperation of concerns, coding to interfaces, and wiring things together by external configuration such that one component knows nothing about another component other than its interface. No brittle or rigid code to glue it all together. It embodies best practice and supports best practice. Leave in EJBs to do messaging and other "talk to another server" work but use Spring simple session bean extractor to inject them into your normal POJO service classes.

                      Entity beans are another matter. The book makes a very good justification for not using them and to stick with either Hibernate or JDO. Commercially with Websphere+Spring I have seen Spring HibernateTemplate support used for persistence and Springs JDBCTemplates calling oracle procs (the 'transaction script pattern'). Both of them are well covered in the book POJOs In Action. I have not worked anywhere that was particularly keen to try EJB2 entity beans more than once. I have never interviewed a good candidate who would ever want to use them again or had not been told to avoid them by someone who's opinion they trusted. The domain model pattern with a good ORM framework as recommended in the book is simply easer to use and get a result that you can maintain and refactor as your application evolves.

                      A full J2EE container is useful because of JMS and its industrial strength transaction manager but it's just easier to wire things all together with Spring and have it manage the transactions using Spring's proxy interceptors such that you can JUnit test out of the heavy container (e.g. on a linux workstation acting as a build box). Spring forces you to code to interfaces which makes you actually do layering, encapsulation and seperation of concerns. Occasionally EJB-RMI and JMS are the right tool for the job so it is good to know how to run Spring within a full J2EE container that provides them. Big financial firms don't let you pick any old container for a given project - they have engineering support teams and support contracts for one particular leading container. It is a good idea to use Spring to keep your skills portable between those containers as Spring has great glue utilities for all of the main containers.

                      J2EE has a load of good tools but for most jobs it is just better to focus on your domain model and try to avoid throwing too much "heavy API" at the problem. I once interviewed a guy who said "yes we used webservices but I think it was just because the architect wanted to put it on his CV" - I truly think that there is a lot of that going around - guys writing articles about using X or Y API in order to bump their day rates rather than to tell the world about something that is really a good idea to use. Spring is worth telling the world about as it really is a good idea to use it.

                      Comment


                      • #12
                        Thank you simbo1905.

                        Comment


                        • #13
                          Another perspective on RAD7 and Websphere

                          I use Rational Application Developer 7 ("RAD7") and Websphere 6.1 every working day.

                          I also use Spring in all my work, both batch work and web work.

                          My frustration with using RAD/WebSphere and Spring is that the cheapest version of RAD7 is $2,200 per year. For that reason, no one is using it except developers inside of corporations. So when I have a problem with Spring and using it in RAD7/WS I am pretty much on my own.

                          For example, I would very much like to add the "Spring IDE" support to my corporate copy of RAD7. But it takes about three hours to install RAD7 from the 10 CDs it comes on, and I don't have those CDs in my possession-- I have to borrow them from someone in my department and then use the corporate license registration key. I can't afford to ruin my RAD7 by messing up an installation of Spring IDE into it. I would have to waste 3 hours doing a reinstall of RAD7 plus hours of configuration work to get it back to where it was in the first place.

                          At http://springide.org/project/wiki/SpringideInstall the instructions for installing Spring IDE are too general for me to rely on to do an install into RAD7. For example, the instructions there say, "Click on the mark next to "Eclipse.org updatesite" and check the version of GEF which is sufficient for your version of Eclipse." That is fine when I am at home playing with free downloads of Eclipse, but totally unacceptable as instructions for installing it into RAD7 at work where failure can be job threatening-- my job.

                          So what I end up doing at work is paying $40 of my own money to buy a copy of MyEclipse and using that on the side and then ocassionally exporting/importing from it into RAD7 (MyEclipse has Spring IDE support "out of the box"). And I have another copy of Eclipse, this time a free one, into which I install iBatis/Abator support so that I can generate iBatis "CRUD" which I then manually copy into my RAD7.

                          In RAD7 I manually copy the Spring jar files I need, and I tailor the Spring XML configuration files manually. I write the various Spring related java classes (mostly controllers and service methods) without RAD7 being aware that Spring is even there, other than there being Spring jar files containing classes I import and subclass.

                          I don't know if this is a problem or the wrong way to do things. I am simply explaining how it is out here "in the wild".

                          I remember when all the hoopla occurred about IBM having certified that Spring works with Websphere. That is great news mostly because I can tell my managers and project leaders this and they feel better about my using Spring. But realistically, I think there is some room for improvement. For example there is a problem in RAD7's internal Websphere concerning compiling very large JSPs that have Spring tags. There is an occasional post about it in a Spring forum, but it's not being fixed with the speed that one might naively expect given all the hoopla about IBM certification of Spring for Websphere. ( I'm referring to the subject of this set of posts: http://forum.springframework.org/sho...hlight=6.1.0.7 )
                          Last edited by RobertGloverJr; Dec 5th, 2007, 04:47 PM.

                          Comment


                          • #14
                            2008 update on spring and websphere

                            We started off with mandated EJB2 session beans back in 2006 along with struts. We had a spring+struts configuration one the webapp classpath that used Springs EJB2 support to lookup the stateless session beans to inject into the struts action classes. That meant that the container was doing the transaction management but we had a good 'inversion of control' pattern in the web layer where we coded to interfaces and didn't need a 'business delegate' that would have only hidden the EJB Home lookups which spring was handling through its support classes.

                            Then in the EJB layer we wanted to junit test components without the container. So we had a separate spring configuration on the classpath of the EJB beans that defined DAOs (using spring template classes) wired to stateless singleton service beans. The EJBs that we created just resolved the application context and made calls to the service POJOs. In the spring configuration we used spring's websphere helper classes to lookup the datasource from JNDI and to get a handle to the container TransactionManager. We used classic spring AOP transaction interceptors to define through spring the transactional semantics using the containers JTA TransactionManager. So the global transaction started with the web call to the EJB session bean that immediately got a POJO session bean from spring with spring enlisting within the contains global transaction.

                            After a while we wanted to move away from EJB session facades. We wanted to only expose some search methods of the app via EJB remote calls to remote clients but our own webapp could go directly to the spring beans and bypass EJBs. What proved the power of inversion of control with spring is that it was then a trivial reconfiguration to have the webapp spring configuration file not use springs EJB support to grab an EJB to inject into the struts action, but instead we merged the EJB layer spring configuration and injected the POJO session beans straight into the struts actions. As we had no delegates doing EJB Home lookups the only code we threw away was the generated EJB code and the very trivial code that was in the EJB beans that only did the spring application context lookup of the POJO service beans to invoke the method on the spring bean.

                            That was early 2007. In late 2008 we have no EJB session facades on the current project as we have no remote interfaces on this project and if I did I would expose them using spring's webservices support. Up to very recently I would have said "well, if we need Message Driven Beans then I might use EJBs doing a spring application context lookup and delegated call to a spring bean". However since I now know how to use Spring Message Driven Pojos as shown here http://forum.springframework.org/sho...oto=nextnewest then I know alternative to every EJB technology that I can run outside of a container. When deploying to the container I can chose to use the spring support for that container to lookup XA Aware resources from JDNI and the container Transaction Manager. When running in Junit I can go much faster with a spring config on my junit test classpath that sets up standalone resources directly (such as use a commons jdbc pool rather when running Junit test but do a JNDI lookup of the websphere defined jdbc pool when packaged for deployment to websphere).

                            Back in 2006 we used springs JDBC templates injected into my DAOs. These days we use springs support for JPA to inject and entity manager into the DAOs. Through those evolutions and others we always used spring as it in courages coding to interfaces and writing implementations that you can setup rigorous junit tests for.

                            On the IDE side we started off using RAD but quickly moved to pure Eclipse remote debugging Websphere. We moved onto maven and found that the maven jetty plugin meant that we could debug our web ui in a container that restarts in seconds (after all spring fully insulates us from the container). So now I only deploy into websphere as a final sanity test and develop and debug mostly well away from websphere mostly because its slow to start but partially because I want to know that my code is truly portable to other containers.

                            On the presentation side we don't use spring any more as we go much faster using ZK as the presentation technology. Twice as fast, I used to have two UI developers writing struts for one back-end developer writing business logic. Now the ratio is one-to-one halving the cost of writing the presentation layer. ZK has great spring support and it's pure MVC autowiring is very powerful to inject prototype and session scoped spring beans into your UI layer. If I was not using that I would be using Springmvc and springwebflow.

                            Having used spring for years I still greatly benefited from sitting down and reading the Spring Recipes book by Gary Mak http://www.apress.com/book/view/1590599799 as it taught me a couple of new tricks.

                            The only basic trick that I have not seen documented anywhere is to have beans that may lookup resources in a seperate file from your main business logic beans. For example a resources-context.xml file that looks up your transaction manager and jndi resources and an application-context.xml that has your DAOs and services etc. Then define a test-resources-context.xml that setups standalone resources such as bitronix transaction manager and xa datasource with the same names as the beans in the resource-xml. Then in your app load a context that uses application-context.xml and resources-xml but in your Junit tests tell you AbstractDependencyInjectionSpringContextTests subclass use application-context.xml and test-resources.xml. Then your junit tests run outside of a container and start much faster. You can then build the whole back-end very fast as independently tested components (using EasyMock as per the Gary Mak book to make mock beans for the beans other than what you are testing) including testing all actual the database calls.

                            Of course as we are using spring the choice of websphere is purely because that is what the company has traditionally invested in. With newer smaller projects we are considering deploying to websphere community edition which is tomcat and geronimo.
                            Last edited by simbo1905; Dec 10th, 2008, 04:27 AM.

                            Comment


                            • #15
                              hi
                              i am katy. Shine framework is like an atom & the other frameworks & technologies act as its nucleus. Shine has gathered them together & dissolved their disadvantages by themselves and made a powerful nucleus then added its excellent architecture, (JWMS or Java Web Model Service) to it. Therefore, a powerful Java framework had born which named Shine! I really congratulate this birth to you!

                              Comment

                              Working...
                              X