9 Replies Latest reply on Jan 21, 2008 5:27 AM by pmuir

    Component Architecture instead of traditional Layers

    ruettimac

      Hi,

      I have searched this forum but did not found answers to my questions regarding architectural patterns (pro/cons). The examples are to simple for my taste.

      Coming from the traditional J2EE pattern oriented software development with Session Facades, DTO's, DAO's, ServiceLocator I dream a bit from a simplified architecture and I hope this becomes true.

      What I want to do:

      I have a dozen of losely coupled seam components (session beans) which are the foundation of my application besides the entity beans. For example, I have a customer component which provides services for customers like load current logged in customer, change the customers personal data. Then I have another computer component which manages the computer infrastructure of a customer like adding a computer, add RAM to the computer. But this computer needs a customer to manage its computer items. I like to inject into the computer component the customer component. I hope this is enough to describe my architecture - SOA like.

      Are there problems to expect with this architecture like


      a) Injecting stateful session beans into other stateful session beans?

      b) Are there any problems regarding the different seam scopes like CONVERSATION and long running CONVERSTAION scopes beans?

      c) Any patterns to avoid or seam annotations like @Create or @Factory?


      If you can share any insights into your experience whould be very helpful. I am breaking my head philosophize about component architectures with seam or using seam components with a DAO-Layer and Entity Beans. In the near future, there is probably another client (Netbeans RCP) than JSF/Facelets.


      Regards,

      Cyrill

        • 1. Re: Component Architecture instead of traditional Layers
          brachie

          @Cyrill: Interesting questions! I would also be very interested in an answer, since we are currently using Seam in our project and having a proper architecture is essential. I agree, that the seam examples are a bit too simple as template for real-world application architecture.

          In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong.. It would be great if someone with real-world seam experience could give some architectural advises.

          The following questions are in my mind:

          Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?

          Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?

          Or would it be good to have one SFSB per use case of your application?

          What would be the correct approach? Please share your opinions!

          Greetings,

          Alexander

          • 2. Re: Component Architecture instead of traditional Layers
            pmuir

             

            "ruettimac" wrote:
            a) Injecting stateful session beans into other stateful session beans?


            No problem here, just use @In

            b) Are there any problems regarding the different seam scopes like CONVERSATION and long running CONVERSTAION scopes beans?


            Like what?

            c) Any patterns to avoid or seam annotations like @Create or @Factory?


            I find @Create is less useful in writing apps (it's great for build infrastructure components, like those in Seam). @Factory is great. I'm a fan of using a Seam component and a factory to manage your entites (a la EntityHome/seam-gen) rather than explicitly outjecting objects (but outjection has performance benefits).

            • 3. Re: Component Architecture instead of traditional Layers
              pmuir

               

              "brachie" wrote:
              In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong..


              Why?


              The following questions are in my mind:

              Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?


              This seems reasonable, and is the approach we take with seam-gen (using EntityHome for scaffolding).

              Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?


              This strikes me as a bad idea and hangover from older design patterns.

              Or would it be good to have one SFSB per use case of your application?


              This is, IMO, another very valid approach. It could easily be combined with your first suggestion (an EntityHome for each entity, a component for a use case can call the EntityHome as necessary).

              • 4. Re: Component Architecture instead of traditional Layers
                ruettimac

                Hi,

                I tried a small example today (with glassfish) and failed to create it. There is a thread and a JIRA-Issue failed against this problem:


                http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123592

                and

                http://jira.jboss.org/jira/browse/JBSEAM-2430

                What's happening here is, that the beans are not found in JNDI:


                
                
                Caused by: javax.naming.NameNotFoundException: No object bound to name java:comp/env/trainingplatform/CustomerPreferencesAction/local
                 at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:834)
                 at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:173)
                 at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:396)
                 at javax.naming.InitialContext.lookup(InitialContext.java:392)
                 at org.jboss.seam.Component.instantiateSessionBean(Component.java:1287)
                
                


                But If you look at the startup debug lines, you see that the component is bound to this JNDI-Entry:


                Component: customerPreferences, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: ch.hcrtraining.trainingplatform.customer.facade.CustomerPreferencesAction, JNDI: java:comp/env/trainingplatform/CustomerPreferencesAction/local


                Something strange goes on here. Since I have not Scope.Session, even the proposed @Startup does not work.


                b) Are there any problems regarding the different seam scopes like CONVERSATION and long running CONVERSTAION scopes beans?


                My concerns are regarding the transaction handling of the wired components. Is the transaction management of the caller master? Otherwise, the called component can open and flush the transaction ...


                Regards,

                Cyrill

                • 5. Re: Component Architecture instead of traditional Layers
                  brachie

                  @Pete: thanks for the answer! :-)

                  "pete.muir@jboss.org" wrote:
                  "brachie" wrote:
                  In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong..



                  Why?



                  I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.




                  The following questions are in my mind:

                  Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?


                  This seems reasonable, and is the approach we take with seam-gen (using EntityHome for scaffolding).

                  Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?


                  This strikes me as a bad idea and hangover from older design patterns.

                  Or would it be good to have one SFSB per use case of your application?


                  This is, IMO, another very valid approach. It could easily be combined with your first suggestion (an EntityHome for each entity, a component for a use case can call the EntityHome as necessary).


                  Ok, so I would have to inject the EntityHome into my SFSB implementing the use case?

                  Regards,

                  Alexander

                  • 6. Re: Component Architecture instead of traditional Layers
                    ruettimac

                     

                    I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.


                    If you look at service oriented architectures (like SOA) - that's the way your software components work together. In seam, you inject the components to each other and in a SOA architecture you have some more intelligent components like the ESB which routes the service calls to the right component (maybe version of a component's interface). But if you break/modify a service, the others have to know that. The same as in the old days of CORBA :-)

                    Regards,

                    Cyrill

                    • 7. Re: Component Architecture instead of traditional Layers
                      mirko27

                      About the NameNotFoundException you got.
                      Search for my posts on the forum and you will find the solution.
                      You`ll have to declare ejb-reference in ejb-jar.xml when injection EJB.

                      • 8. Re: Component Architecture instead of traditional Layers
                        ruettimac

                        mirko27,

                        Thanks, you saved my day (frustrations). I saw your post today but did not realise the impact - thought is was about web.xml bindings. Now it works :-)

                        Regards,

                        Cyrill

                        • 9. Re: Component Architecture instead of traditional Layers
                          pmuir

                           

                          "brachie" wrote:
                          I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.


                          Umm. This is why you define an API? I think coupling that loosely is impossible (your components need to interact!).

                          Ok, so I would have to inject the EntityHome into my SFSB implementing the use case?


                          Yup.