Announcement Announcement Module
Collapse
No announcement yet.
Designing J2EE Application Using Spring, Hibernate & RUP Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Designing J2EE Application Using Spring, Hibernate & RUP

    Hello Spring Gurus
    We are developing Next Generation product . The project is in design phase as we plan on to use Spring Framework inc. Spring MVC & Hibernate, i am wondering how to go about representing Framework Components in Design phase for example Session & Entity Beans in EJBs

    We are designing the application based on Rational Unified Process (RUP) approach in terms of Layers. So i need to represent decoupling of layers thru usage of design patterns like Controllers, Business Delegate, Service Locator, Session Facade & Value/Transfer objects.

    Any pointers/suggestions on designing Presentation, Business & Integration Layers using Spring Components would be highly appreciated

    Regards
    Bansi

  • #2
    Just a word of warning; I would be careful about adopting any process, or any prescribed methodology wholesale without question

    What type of application are you developing, how large, what is the expected load etc.

    Do you really need to use Enterprise beans, or can you just use POJOs etc. Do you really have to create VO/DTOs?

    As I am sure you are aware design patterns are simply solutions to a specific problem; they are not in, and of themselves so called "best practice"s. In otherwords, if you do not have that particular problem, using the design pattern will just introduce bloat.

    Please don't think this is patronising, I would just think carefully before adding all these layers
    Last edited by Colin Yates; May 5th, 2006, 04:10 AM.

    Comment


    • #3
      Originally posted by mail2bansi
      Any pointers/suggestions on designing Presentation, Business & Integration Layers using Spring Components would be highly appreciated
      I'd recommend starting with "J2EE without EJB" by Rod Johnson and Juergen Hoeller.

      Comment


      • #4
        Thanks for quick responses. Few things
        -> I am not using EJBs. In fact we plan to use Spring i.e. POJOs & Hibernate

        -> Not sure how to represent Spring components in Design phase

        -> For e.g how do you represent a call from Presentation Layer to Business Layer in Design phase . Is there any Facade in Spring to rep business layer

        -> I understand applicationcontext.xml & Beanfactory acts as ServiceLocator so how do i represent them in Sequence or Class diagrams

        What exactly i am looking for is representation of components in design phase i.e. Class & Sequence diagrams

        It is medium size applic & as part of architecture we decided to go for Layering

        Comment


        • #5
          based on Rational Unified Process (RUP)
          You'll fail with RUP. RUP is overweight. This alone will weigh you down and send you to the bottom of the ocean where you will subsequently be eaten alive by a giant squid.

          Use something workable and practical like "Writing Effective Use Cases" to gather requirements.

          Use some of the Spring books for technical guidance.

          We use Spring MVC, Hibernate, some JDBC + stored procs, and Quartz. Its a very good combination.

          In terms of layers
          - DAO - contains hibernate, jdbc, + stored proc code.
          - Business-> references DAO layer
          - Web -> contains controllers. References Business and/or Service layers.
          - Service -> contains chunks of business logic specific to some use cases. References Business layer.

          Sounds like you also need to write some throwaway code first to understand how Hibernate, Spring MVC, Spring (core), and other components fit together before you can create sequence diagrams of any meaning.

          ...and another thing, you should also be familiar with Spring AOP, so that you can at least consider if it is suitable for your project. Spring AOP can drastically affect (simplify) how you might otherwise approach a project.

          Hope this gives you some things to think about,

          Good luck.

          Comment


          • #6
            Giant squids

            I definitely can't disagree with the giant squids comment. =)

            We've been using RUP SE (where "SE" is an abbreviation for "We at Rational need to make some more money, so we're going to slap a suffix onto our process and produce new training courses, and we know most project managers and non-technical architects will buy whatever we sell"). I've had to do a lot of sequence diagrams to realize service interfaces and such. You shouldn't even think about Spring when doing this. Doing that design work is all about realizing operations and what the inputs and outputs should be. Spring has nothing to do with that.

            My opinion is that Spring doesn't come into play until the implementation begins (and I'm talking solely about the Spring container; for things like Spring MVC or Spring's JDBC framework, you'll want to talk about those things at the design level). Spring will be your way of resolving dependencies instead of writing stupid ServiceLocator classes. So really, using Spring should thin down your design because you won't have to spend time designing ServiceLocator classes or PropertyManager classes or any other ugly things like that.

            Comment


            • #7
              One point I find worth noting is that, during design, whenever I find myself spending most of the time on drawing sequence diagrams depicting how the tiers are calling each other, I would remind myself that I wasn't really designing. IMO, for each application, its uniqueness(as far as design is concerned) lies in the domain model, not the tiers. How the tiered architecture works should not be the focal point during design. Spending a lot of time drawing 31 various instances of "web controller calls service facade which in turn calls the DAO" sequence diagram doesn't really help understanding, let alone modeling, a particular system. Unfortunately, I have seen many projects whose designers grew a complacency out of the sequence diagrams, and totally neglected the domain model, which therefore almost always turned out to be anemic at best, or worse, a bunch of C structs.

              Comment


              • #8
                Originally posted by manifoldronin
                One point I find worth noting is that, during design, whenever I find myself spending most of the time on drawing sequence diagrams depicting how the tiers are calling each other, I would remind myself that I wasn't really designing. IMO, for each application, its uniqueness(as far as design is concerned) lies in the domain model, not the tiers. How the tiered architecture works should not be the focal point during design. Spending a lot of time drawing 31 various instances of "web controller calls service facade which in turn calls the DAO" sequence diagram doesn't really help understanding, let alone modeling, a particular system. Unfortunately, I have seen many projects whose designers grew a complacency out of the sequence diagrams, and totally neglected the domain model, which therefore almost always turned out to be anemic at best, or worse, a bunch of C structs.
                Excellent excellent, well made point.

                Cannot agree more.

                I once worked for a company that had 4 *programmers* twiddling their thumbs whilst the *designer* had to miss their Christmas holiday to draw up the afore mentioned sequence diagrams. The only difference between them was the names of the tier artifacts that were called.

                Obviously the programmers couldn't do any programming until they had a sequence diagram to use...and of course the humble programmers couldn't be involved in the "design process"....

                Really. What a waste.

                Comment


                • #9
                  Originally posted by yatesco
                  Excellent excellent, well made point.

                  Cannot agree more.

                  I once worked for a company that had 4 *programmers* twiddling their thumbs whilst the *designer* had to miss their Christmas holiday to draw up the afore mentioned sequence diagrams. The only difference between them was the names of the tier artifacts that were called.

                  Obviously the programmers couldn't do any programming until they had a sequence diagram to use...and of course the humble programmers couldn't be involved in the "design process"....

                  Really. What a waste.
                  I agree with both of you to 100(+10)%! :-)

                  In our projects, we always try to have "programmers" with so much experience that they can be involved in the design (and, to some point, architecture) process. If we have "programmers" like that, we don't need that many sequence diagrams. We only draw them for very complicated things or when we want to show something that is important for the architecture.

                  Cheers

                  Comment


                  • #10
                    I just wanted to mention that I've been involved in one project where we used RUP and it was actually useful. But, as others have said, you can't use the entire process. You have to look at what parts of RUP are valuable in your organization and your project.

                    For us, RUP gave us some good guidelines for how to organize our regular (but short) project meetings. A manager would take us through progress status reports, risk assessments etc. and would confirm or update work priorities for the next week.

                    -Magnus

                    Comment


                    • #11
                      AndroMDA

                      Originally posted by mail2bansi
                      We are designing the application based on Rational Unified Process (RUP) approach in terms of Layers. So i need to represent decoupling of layers thru usage of design patterns like Controllers, Business Delegate, Service Locator, Session Facade & Value/Transfer objects.
                      I would take a look at AndroMDA:

                      Here is an intro article (all about layers, very easy to understand):
                      http://galaxy.andromda.org/docs/gett...ava/index.html

                      Also (more about layers, also very easy to understand):
                      http://www.jaxmagazine.com/itr/news/...odeid,146.html

                      Using AndroMDA with Spring and Hibernate (step by step tutorial):
                      http://galaxy.andromda.org/docs/andr...ge/howto1.html

                      If you don't work alone in your project, using AndroMDA will help you a lot by defining a clean architecture of your application, which can be followed by all developers rigorously. Another positive impact is that you won't care anymore of creating those XML (hbm, Spring XML, etc.). AndroMDA creates them for you :-)

                      Hope this helps!
                      Lofi.

                      Comment


                      • #12
                        Tapestry is the presentation layer, which interacts with domain business interfaces. These domain interfaces obtain the implementation classes via Spring configuration and calls the persistant layer which is implemented in Hibernate.
                        The advantage of this architecture is that domain interface implementation can be changed via Spring configuration. Also database persistence layer can be switched without any code change. Another advantage of this architecture is that the domain implementation classes can be tested outside a Web application context. This architecture also supports declarative transaction management and web security model without the need for a EJB container. Overall, this architecture reduces the overall cost of developing enterprise application by reducing the cost of maintenance, cost application server licences and support cost. All the frameworks used in this application is open source and therefore it can be modified by in-house developers to support specific needs of an organisation

                        Ilango Djearamane

                        Comment

                        Working...
                        X