8 Replies Latest reply on Sep 28, 2005 7:08 PM by andyd

    Layered architectures and Seam

    jajansen

      Very impressed after my first dive into Seam. I have some questions though...
      It seems that Seam is typically a two layered approach, where transactions and entity beans live in the web context.

      What about multi-layered architectures? For example, can I have a SessionFacade (implemented as a stateless session bean or maybe a Seam statfull session bean) that is used by Seam and a JMS MDB or a Java Swing client?

      Another thing I noticed is that Entity beans have a context applied to them. This seams (no pun intended!) to be a bit restrictive. How would I code a User class that is both the 'loggedInUser' instance in sessionScope and a 'newUser' instance in a accountmanagement screen (Conversational context)?

        • 1. Re: Layered architectures and Seam
          lavoir

           

          "jajansen" wrote:


          Another thing I noticed is that Entity beans have a context applied to them. This seams (no pun intended!) to be a bit restrictive. How would I code a User class that is both the 'loggedInUser' instance in sessionScope and a 'newUser' instance in a accountmanagement screen (Conversational context)?


          I was wondering the same thing last night actually.

          • 2. Re: Layered architectures and Seam

             

            "lavoir" wrote:
            "jajansen" wrote:


            Another thing I noticed is that Entity beans have a context applied to them. This seams (no pun intended!) to be a bit restrictive. How would I code a User class that is both the 'loggedInUser' instance in sessionScope and a 'newUser' instance in a accountmanagement screen (Conversational context)?


            I was wondering the same thing last night actually.


            You can still always rely on composites (has a) relationship with an SFSB as your action. So your parent action could coordinate the injection of entities into whatever scope you want, without relying on it being declared explicitly on the entity class itself.

            The above solution would force some layering, while there's another thread on the post that is a proposal for @Role, which would allow you to provide multiple [name/scope] pairs on a single instance available to Seam.

            -- Jacob

            • 3. Re: Layered architectures and Seam
              yeroc

              I'm also interested in whether Seam supports an architecture where the web container and EJB container are running on separate machines?

              • 4. Re: Layered architectures and Seam
                jajansen

                Jacob,

                Thank you for the reply. I will experiment a litte more with your suggestions.

                Maybe it is a good idea (in time) to have a wiki section devoted to this? We could have serveral typical architectural patterns described, just like on the hibernate wiki (which helped me a lot).

                • 5. Re: Layered architectures and Seam
                  andyd

                  Remote invocation of session beans directly from a facelet page via seam certainly interests me. It would be interesting to see a seam app running on a web teir cluster and working with an app server cluster. Obviously there is a name resolving issue. Seam currently uses the @Name annotation to resolve the EJB Session bean name within the container, which would then not be local.

                  Maybe a web.xml <context-param> for seam could point to the app server cluster (jndi stuff)?

                  Alternatively an additional parameter to the @Name annotation could supply jndi info for the app server(s), but I'm not sure this stuff should go into the code.

                  Actually, how about this.
                  Install seam on both app and web tier.
                  On init seam will go find all references using annotations as now.
                  If there is a remote teir reference as a context-param in web.xml, the web tier calls a remote method on seam on the remote tier to get a list of names that resolve on that tier.

                  Just thinking aloud.

                  Andy.


                  • 6. Re: Layered architectures and Seam
                    gavin.king

                     

                    "jajansen" wrote:
                    It seems that Seam is typically a two layered approach, where transactions and entity beans live in the web context.


                    Right, that is the idea.

                    "jajansen" wrote:
                    What about multi-layered architectures? For example, can I have a SessionFacade (implemented as a stateless session bean or maybe a Seam statfull session bean) that is used by Seam and a JMS MDB or a Java Swing client?


                    I need to think this through.

                    "jajansen" wrote:
                    Another thing I noticed is that Entity beans have a context applied to them. This seams (no pun intended!) to be a bit restrictive. How would I code a User class that is both the 'loggedInUser' instance in sessionScope and a 'newUser' instance in a accountmanagement screen (Conversational context)?


                    Jacob basically answered this one, you really have a choice in Seam, either:

                    (1) treat your entities as components, and refer to the entity by name directly #{user.name} (and @Role will let you have multiple names/scopes)
                    (2) don't treat your entities as components, just hang them off the SFSB and refer to them like #{userEditor.user.name}

                    So this is really quite flexible.

                    • 7. Re: Layered architectures and Seam
                      gavin.king

                       

                      "andyd" wrote:
                      Remote invocation of session beans directly from a facelet page via seam certainly interests me. It would be interesting to see a seam app running on a web teir cluster and working with an app server cluster.


                      I don't think it can perform acceptably, because each text field you render in the JSF page is going to come out as a remote call.

                      • 8. Re: Layered architectures and Seam
                        andyd

                        Hi Gavin,
                        Agreed, after thinking this through a bit more.
                        I guess the alternative architecture would be to collect all the references to EL variables and marshal them across as one call to the app servers.
                        then pick up all the responses and do the same back to the web servers. However, you just aswell use apache/mod_jk or equivelent on the front end and get a similar solution without all the hard work ;-)

                        Alternatively stick with the javabean classes calling session beens on the app servers, of course.
                        Andy.