1 2 Previous Next 20 Replies Latest reply on Mar 11, 2007 10:34 PM by Hari Cahyadi

    Seam and Portal Future

    Hari Cahyadi Newbie

      Hi JBoss Seam Team,

      I just want to ask simple question, how about future integration of seam and portal, becaus like in my previous post, there is some problem about seam and portal, hopefully that seam and portal will be a good match in the future :)

      Regards,

      -haric-

        • 1. Re: Seam and Portal Future
          Bradley Smith Master

          Here's another slant on this topic and your statement:

          hopefully that seam and portal will be a good match in the future


          I did a fair amount of work with JBoss Portal about a year and a half ago. This last year, I've mainly worked with Seam + Facelets and JSF. I've recently spent some time reevaluating JBoss Portal. I've found that with each point release of the portal, the chief integration points between your application (i.e. the various deployment descriptors, and the security API's) tends to change in a non-backwards compatible manner. Thus, if you were to pick a released version of the portal today (say 2.4.X), and develop a completely customized portal application that featured your look and feel for the pages, and integration with your company's security system - you could expect to redo all this if you wanted to go to version 2.6. My point in saying this is that's a lot of PAIN just to build an application that is primarily based on the JSR 168 (Portlet) API's.

          Also, you should be aware that figuring out the best mix of JSF-Portlet bridge and JSF component sets and coming up with a working configuration that includes all of this plus Seam is a major research project.

          Let me contrast the work described above with just using Seam + Facelets (+ whatever my current favorite JSF Component library is).... Basically, Facelets makes it darn easy to build view components and page templates; furthermore, with JSF EL and Seam, I simply 'declare' in an expression what component or component property, or data collection (model) my system should supply for a view component - it's ridiculously simple. So I can (and do) make use of this combo of Seam and Facelets to build much richer apps than I could with the Portal. I can use techniques such as AJAX and/or remoting to make anyone of my view components behave much like a portlet.

          Basically, I am saying I think there is no great value in using a piece of technology as complicated as a portal simply to get little boxed pieces of content onto a page with 'questionable decorations' (edit, minimize, maximize, close, etc...). It's much easier, faster, maintainable, etc... to simply build up a webapp that has similar characteristics using Seam (and, say, AJAX) + Facelets directly.

          So you should think carefully about whether you really do need to use the JSR 168 API's as part of building your web application(s). Simply using Seam + Facelets / JSF and a good component lib (like ICEFaces) will probably yield a better user experience and a better development experience than trying to bridge all this stuff into the JSR 168 request-response lifecycle.


          • 2. Re: Seam and Portal Future
            Norman Richards Master

            Portal does solve some big issues. jboss.org runs on portal, and I couldn't imagine trying to do something with that scope by building up all the components in Seam. There are too many moving pieces, developed by different teams that need to come together. Things like that really need advanced infrastructure, and I really don't think *I* would want to write that.

            When writing the dvd store, I tried to simulate the effect of a portal. There are clearly defined regions with clearly defined content boxes on the side. It is all done using faces templates. It works really well, but it wasn't trivial to get all the pages to look (and work) consistently. I think there are maybe 4 or 5 distinct pages in the app, divided into two sections (user and admin). I don't know how far the techniques could scale, but I'm sure it isn't that far. It was MUCH easier than doing the equivalent work in other technologies, but it left me longing for something more.

            Portal is clearly too heavy a tool, but I don't know of a lightweight portal solution for these types of things. I'm very curious to see how other people approach these types of issues and whether or not someone can come up with something to sit on top of seam to simply create a portal-lite environment.



            • 3. Re: Seam and Portal Future
              Ian White Newbie

              I agree with Smithy. Right now it is proving to be just too difficult to work out the right combinations of artifacts to get Seam and Portal and jBPM and Facelets and AJAX etc working together.

              Even the JBoss guys have not yet been able to do it !

              I also agree with Norman, that Portal does make our life easier, because we can let non-developers get on with building the page structure and adding content items using the Admin and CMS Admin portlets resp. while we concentrate on building the important self-service processes of our web app.

              So I have this cunning idea ...

              - use Portal's various admin portlets to build your page structure and content

              - use Seam + Facelets + jBPM + AJAX to render your web pages and dialogues, extracting the page structure and content items from Portal's DB using the Portal (and JCR) APIs. So, in effect, our web app will be driven by the Portal DB.

              - some time later, when a future version of Portal becomes available that fixes our problems, we can move our Seam app towards pure portlets.

              So JBoss guys: will v3 of Portal be resolving the above ?

              • 4. Re: Seam and Portal Future
                Norman Richards Master

                I wish I could help. I haven't figured out portal yet. :)

                • 5. Re: Seam and Portal Future
                  Hari Cahyadi Newbie


                  "jboss@biancashouse.com" wrote :


                  some time later, when a future version of Portal becomes available that fixes our problems, we can move our Seam app towards pure portlets.


                  Is this mean that at this time, it would be a huge PAIN if I am trying to combine seam+portlet+jsf+facelets? may be roy russo or some jboss guy from jboss portal can join this thread, because I have already combine use the combination of technology I mention above, and it would be a great PAIN if I try to start from scratch again :(

                  Best Regards,

                  -haric-

                  • 6. Re: Seam and Portal Future
                    Bradley Smith Master

                    Just a bit more on this discussion - mainly in response to the following:

                    "norman.richards@jboss.com" wrote:
                    Portal does solve some big issues. jboss.org runs on portal, and I couldn't imagine trying to do something with that scope by building up all the components in Seam. There are too many moving pieces, developed by different teams that need to come together. Things like that really need advanced infrastructure, and I really don't think *I* would want to write that.


                    Big issues - what big issues does the Portal solve? There are many technologies suitable for building up large web sites - using a system that's primary feature is support for JSR 168 API's wouldn't be my first choice for building a 'large site' - I don't really count the CMS component of the portal as a serious component (partly because the API's, behavior, and schema seem to be a moving target between point releases). It doesn't bother me, because I think the 'Seam way' is much better than trying to map my features onto portlet API's, however, I should point out that your statement about Seam can be interpreted to mean that Seam can't cut it for the 'real stuff' ;-).

                    When writing the dvd store, I tried to simulate the effect of a portal...


                    Did you really simulate the effect of a portal or did you make an effort to factor the view into logical components?

                    Portal is clearly too heavy a tool, but I don't know of a lightweight portal solution for these types of things. I'm very curious to see how other people approach these types of issues and whether or not someone can come up with something to sit on top of seam to simply create a portal-lite environment.


                    I think you can already achieve a lot of this kind of portalizing effect using Facelets templates / components. Probably the least portable part of building a portal is the page layout and portlet-page embedding aspects. Having 'done' both with JBPortal and Seam - I sincerely think the Facelets way gets easier the more pages and components you have - and thus seems more 'scalable' to me from a development-process perspective.

                    good discussion!

                    Brad Smith

                    • 7. Re: Seam and Portal Future
                      Christian Bauer Master

                      I personally also wouldn't use a portal system to build a plain old interactive website (now matter how large it is). A templating solution should be able to solve all the modularization problems within a single applicaton, from a UI perspective.

                      I think that the value of a portal is mostly as an integration technology, ie. aggregation of portlets from different applications.

                      • 8. Re: Seam and Portal Future
                        Stephen Westbom Newbie

                        What is missing from seam applications is independent state maintenance for the various portlets on the page. We have many applications that we want to bring together under one site. These sites are all intranet based so the weight isn't as much of an issue (this can be ameliorated to a considerable degree).

                        Also, where appropriate, we use traditional MVC (Sorry, not yours Gavin) and AJAX within portlets to deal with weight and avoid having to rebuild the whole page when an action is called within a portlet, so it is a hybrid.

                        I really don't think that portlets are a big pain because I am not using seam to build them, I use that XML crazy other framework that Gavin King loves to take cracks at.

                        • 9. Re: Seam and Portal Future
                          Norman Richards Master

                          Sorry - I hope nobody took me to be promoting portal usage. Portals are a great idea, but I don't have any significant experience with JSR 168 or JBoss Portal to know when/where they should be used. I like the idea, but my knowledge of them begins and ends with my conversations with the guys running jboss.org. I would certainly not try and implement something like that without something (portal, whatever) providing some support. But that's just me. :)

                          On the dvd store - when I said "simulate" a portal, I just meant I tried to create distinct portal-like regions serviced by Seam components. Templating worked great, but I think I would have liked addtional jsf components to manage content-areas better. I could have built them myself, but I'm lazy. Portal-like content areas are not what the dvd store is about and I should have to spend time developing that kind of infrastructure when I'm trying to write a storefront app.

                          • 10. Re: Seam and Portal Future
                            Norman Richards Master

                            On the other hand, maybe I just wasn't very clever with the way I did the application. If someone has a suggestion for a simpler way to go about it, I'm all ears. :)

                            • 11. Re: Seam and Portal Future
                              Bradley Smith Master

                               

                              "swestbom" wrote:
                              What is missing from seam applications is independent state maintenance for the various portlets on the page. We have many applications that we want to bring together under one site. These sites are all intranet based so the weight isn't as much of an issue (this can be ameliorated to a considerable degree).

                              Also, where appropriate, we use traditional MVC (Sorry, not yours Gavin) and AJAX within portlets to deal with weight and avoid having to rebuild the whole page when an action is called within a portlet, so it is a hybrid.

                              I really don't think that portlets are a big pain because I am not using seam to build them, I use that XML crazy other framework that Gavin King loves to take cracks at.


                              On state maintenance - your statement is flat out wrong - I'm going to sound like a Seam salesman, but Seam has one of the best state mgmt. capabilities available in Java-web frameworks. Your problem of tying state to individual regions on a page can be realized in a Seam architecture by using Stateful Session Beans (EJB3) that are associated to a particular conversation for a user-page interaction. In Seam, every component associated with a conversation exists as long as the conversation it's tied to exists. Having experience with both Portals and Seam, I'm going to say that my impression is that Seam's state-mgmt. is better; it's there working for you in an unobtrusive way, but it has hooks that allow you to perform sophisticated state mgmt. when necessary.

                              JSF apps are much easier to 'do Ajax with' than portlet apps - plain and simple. You have the options of letting a JSF component set (like ICEFaces) do the Ajax for you, use something like Seam remoting, do your own Ajax requests, etc...

                              By 'XML crazy other framework' do you mean Spring? --- IMHO - if we were still stuck with EJB 2.X/1.X and Java 1.4 or earlier, then Spring is a great way to build up your application infrastructure. Now that we have Java 5 annotations and JEE - EJB3 with JPA, a lot of the infrastructure difficulty that Spring was created to simplify is gone. Thus, if you can use Java 5 and the EJB3/JPA stuff for your apps, the value of using Spring goes way down. The Seam bijection annotations and annotations like @Resource in EJB3 make life so much easier and saner as a JEE developer.

                              Regards,
                              Brad Smith



                              • 12. Re: Seam and Portal Future
                                Norman Richards Master

                                On your last point, my standard Spring bash is "Spring - a much simpler way to write broken J2EE applications." :)



                                • 13. Re: Seam and Portal Future
                                  Per Wiklander Newbie

                                  I've followed the development of Seam for about a year now, but it's only recently that I've started to build something with it. I see a need for splitting my project into modules (call them portlets if you like).

                                  The problem with these modules is that, as far as I understand, if I want to deploy a new version of a module to my site (let's say I've added some features to the forum part of the site) I'd have to redeploy the whole .ear and reload everything (this could be 10 different modules with any number of entities and SFSBs etc.) and by doing that the whole site would be down, if only for a minute or two. Is there something I've missed here? From what I've seen, this kind of dynamic loading is something you'd get with JBoss Portal.

                                  • 14. Re: Seam and Portal Future
                                    Bradley Smith Master

                                     

                                    "perwik" wrote:
                                    I've followed the development of Seam for about a year now, but it's only recently that I've started to build something with it. I see a need for splitting my project into modules (call them portlets if you like).

                                    The problem with these modules is that, as far as I understand, if I want to deploy a new version of a module to my site (let's say I've added some features to the forum part of the site) I'd have to redeploy the whole .ear and reload everything (this could be 10 different modules with any number of entities and SFSBs etc.) and by doing that the whole site would be down, if only for a minute or two. Is there something I've missed here? From what I've seen, this kind of dynamic loading is something you'd get with JBoss Portal.


                                    I can't imagine how the portal makes this problem of managing different modules any better than just dropping new .ears, .wars, .sars, .hars, etc. into JBoss AS directly. In the scenario you describe above, I would think your 'forum part' is in its own .war or .ear, and thus, you can redeploy as often as you like (caveat: JBoss AS tends to run out of memory after a few hot deploys - the bigger the .ears, .wars, .sars, whatever, the faster it runs out of memory). If you have multiple components share a core dependency, and you change the core dependency in some way, you're simply going to have to redeploy, retest all dependent components - no way around that.

                                    The portal can also add a different type of development process to your system - let's say you take the default portal .sar and completely customize it for your business / web site - quite common in a 'real' deployment. Then you're total deployment package is the .sar and any other artifacts that make up your portal site - and that means it's going to be more complicated to make fundamental changes to your site anyway using the portal.

                                    All in all, a set of Seam .ears / .wars are probably a bit easier to manage over the lifetime of a real system than the combination of a portal .sar and any other .ears / .wars that make up your system.

                                    Happy coding!

                                    1 2 Previous Next