Announcement Announcement Module
Collapse
No announcement yet.
Decision to use the Spring Framework Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Decision to use the Spring Framework

    Hi!

    We are planning a reservation service wich should interact with our hospitality retail system.

    The communication between these two systems is well defindend and not in the scope of this post.

    One main goal is to build a solid base for our own reservation module and another goal is to connect the reservation service with many different online reservation systems build by other vendors. We have to sync the reservations over all involved reservation systems.

    I dont know wich vendor specific interfaces all the possible online reservation systems will provide. I know one wich provides a webservice and i know another wich try push his reservations via HTTP-GET to the retail system.

    My architectural approach for now is to use Hibernate and Spring for our reservation service. This service will provide the reservation functionality and will be instrumented by one adapter for every vendor.

    The service could expose his functionality as a webservice wich will be used by the adapters. So the adapters have not to reside on the same machine like our reservation service wich is a prerequisite for our future reservation module wich could be now a remote swing gui or an ajax app too. All adapters have to register by our service and can then communicate in their own manner with the external reservation systems.

    For what to use hibernate is clear. the model of up to 20 classes will be mapped to our database.

    But i have some questions.

    Make it sense to use Spring?

    The IoC pattern is not the main reason for me to use Spring. The implementation of our business layer will not change often, so i could hardwire the dependencies.

    For me Spring ORM could help to integrate easily the business layer with Hibernate. For me Spring WS could help to build the webservice. For me Sring AOP could help to build transcational code more easy.

    And at least the integrated scheduling support and the simpler testing let me make the architectural decision to use the Spring Framework.

    I would very happy about some advices from Senior Members

    Regards,
    Thomas Chille!

  • #2
    I think Spring would be a great fit, for several reasons:
    - Even though IoC isn't a primary reason I think writing your applications to use IoC makes them more unit testable and more flexible. It makes adding in additional infrastructure functionality to your system just by editing config files.
    - Spring encourages writing your business services agnostic of how you connect to them. This allows you to expose a single service with a number of remoting APIs (RMI, EJB, Axis, XFire, Hessian, Burlap, Spring HTTP Invoker, JMX) mostly adding configuration (a few of them like EJB requires some sort of wrapper class). You could if you wanted expose ALL of these. And the beauty of it is, you don't need to make your service aware that its being exposed by any of these.
    - As you noted it would be good for transaction and data access support. Especially if you need to mix straight JDBC with Hibernate in the same transaction.

    If you need more functionality for exposing your services using more interfaces with more functionality (like routing, message transformation, etc) you should consider looking at an enterprise service bus (ESB) like ServiceMix or Mule. I believe both of these integrate with Spring in case that makes sense.

    You should first architect your code to implement your business logic, and then using Spring or an ESB decide how to export that functionality to a particular infrastructure. If I think about both things at the same time, I tend to mix my business concerns with my infrastructure concerns

    Comment


    • #3
      Originally posted by thochi
      Make it sense to use Spring?

      The IoC pattern is not the main reason for me to use Spring. The implementation of our business layer will not change often, so i could hardwire the dependencies.

      For me Spring ORM could help to integrate easily the business layer with Hibernate. For me Spring WS could help to build the webservice. For me Sring AOP could help to build transcational code more easy.
      Just to add to what Bill has so nicely articulated.
      The biggest advantage of using Spring is its non-invasiveness. It is possible to use Spring in ur application without a single import of Spring classes. Make sure u have a rich domain model and wire up the dependencies using Spring IoC. That's a great way to make ur application unit-testable (through using mocks). I recently passed through this phase and it works like a charm.

      Thanks.

      Comment


      • #4
        Originally posted by wpoitras
        I think Spring would be a great fit, for several reasons:
        - Even though IoC isn't a primary reason I think writing your applications to use IoC makes them more unit testable and more flexible.
        Lets assume I am just a dumb a$$. I wonder just because it can make my code more unit testable should I really do it? I mean If i do, when one of my developer is leaving I have to make sure the next one have the knowledge of the product and not just java/J2EE or GoF patterns for that matter. I also have to make sure the next person is not a webwork or struts or pico fan and keep reminding me how terrible mistake I made by choosing springframework. Unit testing is all about faking your results anyways. 5 years of writing JUnit tests and I still am not sure how much value has it added to my work. Never helped me estimating hours nor it helped me in enhancements and maintenance. The only thing it has helped me with is make me realize what unseen scenarios can come up and can make my system to fail which may or may not make you access database manually and make you monkey with data(This can be hashed out during development or qa testing). Apart from that nada, zero, zip, zilch so far.
        It makes adding in additional infrastructure functionality to your system just by editing config files.
        May be some day we will move business logic in config files altogether. Just like client/server applications (Remember data driven programming?) so that applications can run on meta objects. It will be called configuration driven programming someday.

        - Spring encourages writing your business services agnostic of how you connect to them. This allows you to expose a single service with a number of remoting APIs (RMI, EJB, Axis, XFire, Hessian, Burlap, Spring HTTP Invoker, JMX) mostly adding configuration (a few of them like EJB requires some sort of wrapper class). You could if you wanted expose ALL of these. And the beauty of it is, you don't need to make your service aware that its being exposed by any of these.
        - As you noted it would be good for transaction and data access support. Especially if you need to mix straight JDBC with Hibernate in the same transaction.

        If you need more functionality for exposing your services using more interfaces with more functionality (like routing, message transformation, etc) you should consider looking at an enterprise service bus (ESB) like ServiceMix or Mule. I believe both of these integrate with Spring in case that makes sense.

        You should first architect your code to implement your business logic, and then using Spring or an ESB decide how to export that functionality to a particular infrastructure. If I think about both things at the same time, I tend to mix my business concerns with my infrastructure concerns
        I could go on these too...... Nothing against spring framework just that I kinda feel that Every few months there is a new framework in the market, just like VB days. Well you are free to think I desperately need to get laid and I will be happy thinking who cares at the end of the day I have a job and keeps my family running.

        Comment


        • #5
          Lets assume I am just a dumb a$$.
          If you insist

          I wonder just because it can make my code more unit testable should I really do it?
          In my opinion yes. Because when your code is more unit testable, it also becomes more flexible and easier to reuse. Of course most code only has a single purpose... until it doesn't.

          May be some day we will move business logic in config files altogether. Just like client/server applications (Remember data driven programming?) so that applications can run on meta objects. It will be called configuration driven programming someday.
          I'm not saying that all infrastructure can be specified just using config files. But I had a situation just recently when I implemented a project using the principles I've learned from Spring and I found I had a performance issue. Adding declarative caching from Spring modules was just a little configuration. I didn't need to change my underlying code to know that I was adding caching. And I could change the cache implementation without really affecting my code, or eliminate it all together. And I could easily integration test the code because I had developed a test during the development of the module.

          I could go on these too...... Nothing against spring framework just that I kinda feel that Every few months there is a new framework in the market, just like VB days. Well you are free to think I desperately need to get laid and I will be happy thinking who cares at the end of the day I have a job and keeps my family running.
          As far as I know there is not another framework out there like Spring. Its a full-stack J2EE framework. In my opinion it does a good job of making J2EE development easier and for simple jobs can do it on top of a servlet container instead of requiring full-blown app server, where before Spring you often would.

          Web frameworks do indeed come every few months. But Spring it not just a web framework. It helps in other areas of J2EE development. And many other web frameworks work well with Spring.

          And Spring has been around for a few years. Major J2EE software vendors (like BEA, Oracle, IBM) have written articles about how to integrate their technologies with Spring. BEA supports Spring on Weblogic Server themselves. There are numerous books, training courses and online resources for Spring. Its pretty safe to say its not going anywhere soon. And even if it is, if your code is independent enough from Spring you would be able to replace most of it (which goes back to my original point about making your code unit testable)

          Should you take my (or anyone else's) word for it that Spring will make your development easier? No. Partially because its possible it won't. I've seen experienced J2EE programmers have the same reaction you have even after using Spring. If you aren't writing decoupled code or are migrating from a standard J2EE EJB-centric application where configuration is done by each EJB and using service locator's, private XML or static singletons you are likely to be extremely frustrated with Spring.

          Use the right tool for the job. If you don't need Spring don't use it. The only thing worse than people who don't use the right tool for the job, is those who use the wrong tool for the job. The former tends to be blissfully ignorant (until you force the tool down their throat). The latter tend to be miserable and resentful that anyone made them use the stupid tool in the first place.

          Comment


          • #6
            Originally posted by wpoitras

            As far as I know there is not another framework out there like Spring. Its a full-stack J2EE framework. In my opinion it does a good job of making J2EE development easier and for simple jobs can do it on top of a servlet container instead of requiring full-blown app server, where before Spring you often would.
            PICO from thoughtworks!

            Web frameworks do indeed come every few months. But Spring it not just a web framework. It helps in other areas of J2EE development. And many other web frameworks work well with Spring.
            Oh i Know that!
            And Spring has been around for a few years. Major J2EE software vendors (like BEA, Oracle, IBM) have written articles about how to integrate their technologies with Spring. BEA supports Spring on Weblogic Server themselves. There are numerous books, training courses and online resources for Spring. Its pretty safe to say its not going anywhere soon. And even if it is, if your code is independent enough from Spring you would be able to replace most of it (which goes back to my original point about making your code unit testable)
            integrate spring with websphere and weblogic? comeon, you know better than that. its not them, it spring framework that does most of the work. Virtually runs under any given container.
            Should you take my (or anyone else's) word for it that Spring will make your development easier? No. Partially because its possible it won't. I've seen experienced J2EE programmers have the same reaction you have even after using Spring.
            I am not sure what are you trying to imply here by saying "having a reaction". What I said was not a reaction. Man I sure need some classes in communication. What I said was, every framework implements GoF patterns in a different way that even people knowing these patterns by heart will be confused as to what the hell is going on. therefore raises a need for experienced developer in product and not technology.
            If you aren't writing decoupled code or are migrating from a standard J2EE EJB-centric application where configuration is done by each EJB and using service locator's, private XML or static singletons you are likely to be extremely frustrated with Spring.
            First thing first the only product I have ever been frustrated with was entity beans. As I said nothing against spring framework. Secondly If I am not writing decoupled code, java/j2ee or any other object oriented language will not be my choice of technology to do the job.
            Use the right tool for the job. If you don't need Spring don't use it. The only thing worse than people who don't use the right tool for the job, is those who use the wrong tool for the job. The former tends to be blissfully ignorant (until you force the tool down their throat). The latter tend to be miserable and resentful that anyone made them use the stupid tool in the first place.
            Goody! How many times in your career have you seen people use right tool for right job? Its always whats hot in the market. see my last comments. I suppose I should get a life.
            Last edited by tatvamasi; Sep 11th, 2006, 11:56 AM.

            Comment


            • #7
              Originally posted by tatvamasi
              PICO from thoughtworks!
              Pico is only an IoC container and not a full featured application framework. A closer comparaison would be Nano, although Spring offers a lot more features IMO.

              Comment


              • #8
                Originally posted by tatvamasi
                Lets assume I am just a dumb a$$. I wonder just because it can make my code more unit testable should I really do it? I mean If i do, when one of my developer is leaving I have to make sure the next one have the knowledge of the product and not just java/J2EE or GoF patterns for that matter. I also have to make sure the next person is not a webwork or struts or pico fan and keep reminding me how terrible mistake I made by choosing springframework. Unit testing is all about faking your results anyways. 5 years of writing JUnit tests and I still am not sure how much value has it added to my work. Never helped me estimating hours nor it helped me in enhancements and maintenance. The only thing it has helped me with is make me realize what unseen scenarios can come up and can make my system to fail which may or may not make you access database manually and make you monkey with data(This can be hashed out during development or qa testing). Apart from that nada, zero, zip, zilch so far.

                May be some day we will move business logic in config files altogether. Just like client/server applications (Remember data driven programming?) so that applications can run on meta objects. It will be called configuration driven programming someday.


                I could go on these too...... Nothing against spring framework just that I kinda feel that Every few months there is a new framework in the market, just like VB days. Well you are free to think I desperately need to get laid and I will be happy thinking who cares at the end of the day I have a job and keeps my family running.
                The members who responded to you made some sense, but what you say makes sense to me also. Without trying to "sell" you on Spring the way you were probably "sold" on J2EE, JUnit, VB, and on and on, here's what I've personally found useful and useless so far with Spring:

                ( ) Spring Web Services - useful in that it has a better, simpler, cleaner model, with fewer moving parts than Axis, so it worked better out of the box than axis. Only downside is that it is brand new.

                ( ) Spring MVC - useful in that it is easier to use and understand than Struts.

                ( ) Spring JDBC - useful in that it eliminate significant "grunt" boilerplate coding.

                ( ) DI/IoC - useless to me, so far. Your point about data-driven programming is well-taken. IoC has POTENTIAL, but it doesn't seem to have been fully thought out yet. (See my posts about bean scope and per-thread Singletons and such.) "Flexibility" is SO overhyped these days, that I sense it's more about job security than a true business need. Yes, you CAN swap this out with that, but in reality, that seldom happens, in day-to-day app maintenance, in my long experience at least. And you can do about 90% of it with simple properties files anyway. I don't yet see much "magic" in IoC, but I'm keeping an open mind, coz so many others appear to be seeing it. Besides, when something gets "swapped" out, it's more often the entire app, and usually because no one wants to (or can?) maintain the previous "framework". Remember that framework? The framework that was supposed to make our lives so much easier? Programmers who were not around in the 80's may not realize that in some ways we have gone backwards as far as getting real, functioning app work delivered and efficiently maintained. You are now being asked to buy in to YAFF (Yet Another F* Framework). You have the right to be skeptical until it has proven itself to be a winner...until it has shown YOU some clear, unequivocable value.

                That being said, I'm betting that Spring is going to be a winner, because (a) the useful things it does above that are probably going to be useful to many other programmers and (b) it's actively maintained by some very good programmers, many of whom work for Interface21. For whatever reason, Interface21 appears to be heavily invested in Spring, beyond what I've come to expect in an open-source product. I think it's a great business model they have come up with (or appear to me to have come up with), and I hope they make a LOT of money with it, so as to preserve my time and code investment in Spring, i.e. so that they can afford to keep maintaining it and continue giving me the great support they've given me so far.

                Ben

                Comment


                • #9
                  Spring DI vs Dependency Pull

                  Hi Ben,

                  I agree on some of your points. I guess it is true that some people go crazy coding to interfaces and using dependency injection, but then don't take advantage of it because 1) they don't write mocks of the implementations for unit tests and 2) they don't every end up swapping in different implementations during the application lifecycle (or if they do, it's part of a major overhaul and preserving the code dependent on the interface doesn't happen).

                  However, I disagree with your following quote in reference to situations in which you do want to use some form of IoC:
                  Originally posted by benethridge
                  And you can do about 90% of it with simple properties files anyway.
                  That is one thing I have found great about Spring. Once you learn the Spring dependency injection way of doing things, coding to interfaces become so easy. I can honestly say that as a coder, I am too impatient to write a factory and read some properties file to serve this purpose. With Spring, I code to interfaces without even thinking about it, because it doesn't require much additional work.

                  So if you don't take advantage of the benefits of using dependency injection, I can understand feeling lukewarm about Spring's IoC services. But if I were to choose between Spring's dependency injection model versus a manually coded dependency pull model, I would choose Spring any day.

                  -Arthur Loder

                  Comment


                  • #10
                    Spring MVC vs Struts

                    Actually, I have an opinion regarding Spring MVC and wanted to know if anyone else feels the same.
                    Originally posted by benethridge
                    ( ) Spring MVC - useful in that it is easier to use and understand than Struts.
                    I personally like the Spring MVC framework. When I read about it, everything seems so elegant, extensible, and well thought-out. However, I personally don't think it is easier to use than Struts. There are many things I like better about Spring MVC, and that is why I spent some time learning it. But I personally think Struts is a simpler framework to learn.

                    Has anyone else found this to be true? Again, I think it is worth mastering the Spring MVC (out-of-the-box non-JSP view support, interfaces rather than concrete class inheritance, extension points, etc), but I do think that it is so flexible and there are so many options that it has a higher learning curve than the simpler Struts framework.

                    -Arthur Loder

                    Comment


                    • #11
                      Hi, Arthur.

                      Yeah, 90% is probably too high. It's just that most things I've personally seen done with FILE-BASED DI/Ioc are not all that profound, and down-side to the file-based (xml-based) is, kind of to tatvamasi's point, it's "data-driven", which is to say, you lose the protection of the compiler, a protection which is vastly under-rated in my opinion.

                      However, I'm relatively new to Spring, so I'm keeping an open mind about file-based DI/Ioc. I'm fully on-board now with what I'll call "code-based" DI/Ioc. I discussed this a while back under this thread:

                      http://forum.springframework.org/showthread.php?t=24569

                      ...but it all really boils down to a few ancient fundamentals of programming:

                      (1) Encapsulate and hide the details from the caller, so that the called functionality is an "abstraction" to you, i.e. you can use the functionality as a black-box...at least until it breaks on you ...and then heaven help you if you can't reasonably debug into it or find someone who can (like, say, the Interface21 folks ...and...

                      (2) Never write the same chunk of code in more than one place, and

                      (3) Separate the things that change from the things that stay the same.

                      Note that (3) often involves predicting what you think MIGHT change, and every time you are wrong, there is a price to be paid for your unnecessary "code flexibility".

                      By the way, high-level, (1) and (2) are why I say that in some ways, we've gone backwards from the 80's. Neither our "modern" languages (C#, Java, VB) nor our operating systems allow us to reasonably do either.

                      Open-source, such as Spring, is, however, a step in the right direction, given the limitations of the language it's written in. At least, it's giving us a framework in which to do (1), (2) and (3).

                      Ben

                      Comment


                      • #12
                        Originally posted by Arthur Loder
                        Hi Ben,

                        I agree on some of your points. I guess it is true that some people go crazy coding to interfaces and using dependency injection, but then don't take advantage of it because 1) they don't write mocks of the implementations for unit tests and 2) they don't every end up swapping in different implementations during the application lifecycle (or if they do, it's part of a major overhaul and preserving the code dependent on the interface doesn't happen).
                        The problem is not of coding DI, the problem is people misunderstanding DI, thinking DI is all about which component depends on which component instead of thinking which component depends on which "service" (be it J2EE resource or propritory service). Don't you think people pushed spring DI little too much and started using it as instantiation framework?
                        However, I disagree with your following quote in reference to situations in which you do want to use some form of IoC:That is one thing I have found great about Spring. Once you learn the Spring dependency injection way of doing things, coding to interfaces become so easy.
                        "coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.
                        I can honestly say that as a coder, I am too impatient to write a factory and read some properties file to serve this purpose. With Spring, I code to interfaces without even thinking about it, because it doesn't require much additional work.
                        sure it doesn't require much of additional work but it does require hell LOT OF work to train a new hire (given new hire doesn't have knoledge of THE Framework). However I do feel, having a factory in my codebase would allow anyone to read code more easily and effectively. Even people without proper knowledge of design patterns would be able to go through code easily(provided they have to good knowledge of java/j2ee and/or OO fundamentals).

                        Comment


                        • #13
                          Hi tatvamasi,

                          Originally posted by tatvamasi
                          "coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.
                          I agree that coding to interfaces isn't done solely for unit testing purposes. I guess what I was saying was that I agree with Ben in that using Spring's IoC support blindly and without taking advantage of some of the perks that come with using it (e.g. ease in unit testing, which is only one example) can result in a lot of time spent for an inexperienced team, without reaping the benefits. Ben was correct: a different strategy implementation may never be swapped in during the application's lifetime.

                          My real point was that personally, if the decision to use some form of IoC was already decided, I would prefer to use Spring's dependency injection mechanism rather than write my own dependency pull via factory classes. I agree with you on one point: even though there is more code to write with the dependency pull way, it can be easier to understand for a developer new to Spring; I just think it is worth the effort of teaching him/her Spring.

                          -Arthur Loder

                          Comment


                          • #14
                            I have used spring framework for my persistence in past. I think its hot in market why not use it, doesn't hurt to bump up my price by having that on my resume anyways(seriously).

                            Comment


                            • #15
                              Originally posted by tatvamasi
                              The problem is not of coding DI, the problem is people misunderstanding DI, thinking DI is all about which component depends on which component instead of thinking which component depends on which "service" (be it J2EE resource or propritory service). Don't you think people pushed spring DI little too much and started using it as instantiation framework?

                              "coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.
                              sure it doesn't require much of additional work but it does require hell LOT OF work to train a new hire (given new hire doesn't have knoledge of THE Framework). However I do feel, having a factory in my codebase would allow anyone to read code more easily and effectively. Even people without proper knowledge of design patterns would be able to go through code easily(provided they have to good knowledge of java/j2ee and/or OO fundamentals).
                              First of all, programming to interfaces is really important because it is how you can achieve polymorphism in a statically typed language, which is one of the main tenet of OO. If you don't use polymorphism, you might consider using a procedural language instead of Java.

                              The problem when you program to interfaces, is how do you get the correct interface implementation without getting your code coupled to it. Not to mention the complexity involved in creating objects (initialization of his dependencies, state management, cache, ...). This is usually where factories come in. In fact, factories are so important that acccording to the very popular "Domain Driven Design" book, they are an integral part of any domain model and any applications will have several of them (I know it used to be my case). The problem is that writting factories is most of the time a time consuming redudant and somehow complex task. This is where DI comes to help you.

                              DI allows you to code to interfaces at basically no cost. You just need to add a little snippet of xml and tada you get the implementation injected for you. No need to code anymore lot of ad hoc factories (or evil singletons) using proprietary config files. Plus you don't need to think about how to store the objects instances, to manage their states, ... The creation code which can be quite complex ends up totally separated from your core business logic. The DI container take care of those details for you. DI is in fact a very nice creational design pattern removing most of the need for custom factories and promoting a very neat separation of concerns (separating objet creation logic from business logic).

                              Also don't overlook the fact that a componenent model la Spring or EJB gives you the possibility to make your objects available easily to almost any protocol (rmi, web services, jmx, you name them, ...). It also allows you to decorate them transparently with infrastructural services (it can also be achieved using an AOP compiler).
                              Last edited by madtree; Sep 12th, 2006, 11:05 PM.

                              Comment

                              Working...
                              X