Podcast: Gavin King on Seam

Discussions

News: Podcast: Gavin King on Seam

  1. Podcast: Gavin King on Seam (34 messages)

    In this presentation, given at TheServerSide Java Symposium Barcelona in June, Hibernate founder Gavin King looks at how Seam, a new application framework that integrates the EJB 3.0 component model with JSF as a presentation tier, builds upon the standard extension points provided by both specifications. The discussion includes coverage of Seam's managed conversations, declarative and contextual application state management, and bijection. King also describes how Seam addresses state-related problems that existed with J2EE by providing a uniform model for stateful components in Java EE 5. Download and listen to Gavin King on Seam. (8.26 MB) View the slides for this presentation. What do you think of Seam? Has it chosen the right technologies to provide features such as persistence, workflow and presentation?

    Threaded Messages (34)

  2. I have been following Seam ever since it first came out in beta... I can't believe how many (if not all) it's features have NOT managed to be implemented in JEE 5.0. I think the JCP really missed the boat by not including extremely useful (if not mandatory) features found in Seam such as: the new "conversation" context that cuts accross requests/pages and bijection. Honestly, the lack of these features are what I detest the most about JEE 5.0 (JSF in particular). These are things that we constantly have to reinvent or add in via third-party solutions such as Seam, yet, IMO, are an essential part/requirement of any web application! Congrats on all the great work being done at JBoss/Seam... Hopefully, like Hibernate, Seam's features will make their way into JEE 6.0 via the JCP and we will finally have a standard framework that covers pretty much all of an application's architecture's bases.
  3. Re: Podcast: Gavin King on Seam[ Go to top ]

    Honestly, the lack of these features are what I detest the most about JEE 5.0 (JSF in particular). These are things that we constantly have to reinvent or add in via third-party solutions such as Seam, yet, IMO, are an essential part/requirement of any web application!
    One of the main features of JSF was that it should be easily be extended and allow add-ins. It was designed to allow frameworks such Seam, facelets, Shale and so on. These solutions are not so much overcoming failings of JSF, they are making use of one of its strengths. JSF seems to be much mistunderstood.
  4. Re: Podcast: Gavin King on Seam[ Go to top ]

    Yay! I just did a quick search for Seam-like features in the JCP and look at what I found! JSR 299: Web Beans http://jcp.org/en/jsr/detail?id=299 There is hope!
  5. Web Beans JSR[ Go to top ]

    If you followed the project closely, you would've seen that announcement on the JBoss SEAM Home Page under News. "16.05.2006: JBoss has proposed the Web Beans JSR"
  6. Is it App Server Independent?[ Go to top ]

    Gavin, Looks like the Framework is JBoss-Specific?
  7. Gavin,
    Looks like the Framework is JBoss-Specific?
    If you look at the FAQ at the SEAM home page, they explicitly state that you can use it with any application server...
  8. Arun Patel is that you ?
  9. Re: Podcast: Gavin King on Seam[ Go to top ]

    What do you think of Seam? Has it chosen the right technologies to provide features such as persistence, workflow and presentation?
    I think the components used by Seam are just right (JSF, EJB3, JPA, etc.) But the implementation got some serious problems. Maybe it's because Seam is young, but I have a feeling that something is seriously broken. We evaluated Seam in May-June 2006 for an enterprise CRM application, but we gave up late June. Seam works well for the easy straight forward examples like Hotel Booking and DVD Store. But for complex enterprise systems, the Seam concept is starting to hit you hard. The conversation implementation is the major problem. We constantly faced problems with conversations not started, conversations not available when expected, etc. Back button problems and lots of other small issuses that summed up to the decision to not go the Seam route... yet. But I will be happy to try Seam a second time, once it has matured more. Fact is, that we are still searching for a stateful web framwork that fulfil our (rather complex) needs.
  10. Re: Podcast: Gavin King on Seam[ Go to top ]

    Fact is, that we are still searching for a stateful web framwork that fulfil our (rather complex) needs.
    Hi Goran, out of interest, what are those needs? Can you summarize them? Best regards, Geert
  11. Re: Podcast: Gavin King on Seam[ Go to top ]

    out of interest, what are those needs? Can you summarize them?
    Ok, this is from my head. I don't have the spec lying around here at home. And I can't tell everything in it. * Reusable detail screens (i.e View Account, View Contract, ...). Same screen can be called from many places in the application. Going back (with browser button or HTML link should resume the calling flow. * Multiple workspaces/flows. Open same screen multiple times but with different data. (same browser window, not opening multiple windows). * Switching from list view to detail view and back should keep data, sorting and selection in the list view. * 1-5 step wizards with back/forward buttons * Save state of "desktop", logout, continue next day or after lunch. * Start a report generation (PDF) from most of the screens. * Container Managed Security * List of "Recent views", and fast jump to a recent view ("flexible" history management) * Bookmarking * Integration with computer telephony: incoming call should start a new workspace/flow. After completion, the previous workspace should be resumed. * Integrate with external web applications. Exchange data with GET and POST. I probably forgot some important stuff. These requirements are not crazy, it's normal functionality in serious enterprise applications. This is what we had in rich clients 10 years ago, before everything was webified. ;-) I think multiple workspaces and flexible history management are the most important. Seams workspaces looked promising but did not work well for us in CR2, CR3 and 1.0 Hopefully the code in CVS today are much better. Reading the Seam forum I can see there have been some improvements to conversations after 1.0 The last version we used was 1.0.1 back in June. /Goran
  12. Try Spring and Spring web flow[ Go to top ]

    Try out Spring MVC and Spring Web Flow. Web Flow http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home Spring and Spring MVC http://www.springframework.org/ Plus you get to use the awesome spring framework too.
  13. Try out Spring MVC and Spring Web Flow. Web Flow http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home Spring and Spring MVC http://www.springframework.org/ Plus you get to use the awesome spring framework too.
  14. Correct me if I am wrong, but Spring MVC is not a component framework. Praising it is a bit like trying to advertise Basic to Java developers. The webflow technology is somewhat independent from the underlying web framework, however, and can often be used regardless of the selected underlying technology (with some additional work). As such the Spring Web Flow is an interesting alternative to the Web Flow used in Seam. Unfortunately the Web Flow field is still young and even what Seam and Spring Web Flow provide is far from what many people want. But competition is always good...
  15. I was reading the slides and I couldn't find something new. I use to work with Spring, Hibernate, JSF and Acegi. I reached the same features and functionality with that frameworks, I think I don't need Seam. Please, correct me if I am wrong.
  16. I use to work with Spring, Hibernate, JSF and Acegi. I reached the same features and functionality with that frameworks, I think I don't need Seam.
    You need conversational and process state to build fully rich web UIs (with the requirements like described by Goran Ehrsson). Stateful components are only one part in managing state in rich web UIs.
  17. I use to work with Spring, Hibernate, JSF and Acegi. I reached the same features and functionality with that frameworks, I think I don't need Seam.


    You need conversational and process state to build fully rich web UIs (with the requirements like described by Goran Ehrsson). Stateful components are only one part in managing state in rich web UIs.
    Spring 2.0 scoped beans and Spring Web flow allow you to manage state quite easily.
  18. Spring 2.0 scoped beans and Spring Web flow allow you to manage state quite easily.
    Correct me if I'm wrong, but Spring still does not support stateful remoting (a la SFSB)?
  19. Spring 2.0 scoped beans and Spring Web flow allow you to manage state quite easily.


    Correct me if I'm wrong, but Spring still does not support stateful remoting (a la SFSB)?
    No but Rod Johnson (according to his book) doesn't believe that stateful services are useful in most cases. I agree with him. Scope is a network protocol dependant-concept and I think is best handled is the corresponding tier, the web tier in most case. The only case where I see stateful services as useful is when you have to support both web and rich client but this is kind of rare in my experience. I could be wrong, Seam really seems like an interesting product to me and I'll probably give it a try in the near future but it's not true to say that Spring doesn't offers an alternative .
  20. Spring 2.0 scoped beans and Spring Web flow allow you to manage state quite easily.


    Correct me if I'm wrong, but Spring still does not support stateful remoting (a la SFSB)?


    No but Rod Johnson (according to his book) doesn't believe that stateful services are useful in most cases. I agree with him. Scope is a network protocol dependant-concept and I think is best handled is the corresponding tier, the web tier in most case. The only case where I see stateful services as useful is when you have to support both web and rich client but this is kind of rare in my experience.
    Yes, I'm aware that Spring folks consider SFSB functionality a rare case. It's just so happens that I disagree. That functionality is a common need in financial applications, and I do not believe that financial software is that uncommon.
  21. Spring 2.0 scoped beans and Spring Web flow allow you to manage state quite easily.
    Does Spring 2.0 scoped beans and Spring Web flow allow me to have multiple entry conversations (with back button working correclty when exiting conversation)? Does they have support for multiple browser windows opening the same page, but having different conversational and process state? These are minimal requirements for stateful rich web UI.
  22. I believe those are the main features of Spring Webflow although I have never tried it myself but I plan to give it a try in a future. According to the introduction in this chapter, I don't seem wrong : project.http://static.springframework.org/spring-webflow/docs/1.0-ea/reference/flow-execution-repository.html Anyway, I don't want to hijack this thread about Seam or say Spring Webflow is better. I just want to get the facts right.
  23. Correct me if I am wrong, but Spring MVC is not a component framework. Praising it is a bit like trying to advertise Basic to Java developers.
    More like advertising Java to VB programmers...
  24. More like advertising Java to VB programmers...
    Web Components are like objects -- they allow you to encapsulate what you are doing into well-defined small packages and then reuse those packages throughout your work. It took a long time for people to accept OOP, but nowadays you will not be taken seriously if you write big applications in a non-OOP language. The very same will happen in the web-framework space -- a web framework will eventually not be taken seriously if it does not support components. (a similar reasoning can be applied to Page Flows and conversations, but this another topic) I have no doubt that Spring MVC will eventually include component support, perhaps under the pressure of its users who would realize that the development of large-scale web applications _requires_ components to make it efficient. In a few years web components will become what objects in programming languages are today. Unfortunately the parallels are not easy to see for some, and until then one would have to deal with many posts that deny this fact.
  25. Why Web?[ Go to top ]

    Hi Goran, I don't understand why everybody must target a web application this days. Some of your requirements would work much better in a desktop application. I'm working on an Eclipse RCP application and I'm happy with the framework. If deployment is a concern, there are good options, like Webstart or the Eclipse update manager. Best regards, Danilo
  26. Re: Why Web?[ Go to top ]

    I don't understand why everybody must target a web application this days. Some of your requirements would work much better in a desktop application.
    THANK YOU! Can you please tell that to all those people pushing AJAX desktop replacements? ;oP
  27. Re: Why Web?[ Go to top ]

    I don't understand why everybody must target a web application this days. Some of your requirements would work much better in a desktop application.
    Well, don't ask me. I agree with you. We have a fully functional, feature rich, thin desktop client with all these features (and more) today. But with zero sales the last three years! Customers buy our feature limited browser app that pushes functionality back to 1996 instead.
  28. Re: Why Web?[ Go to top ]

    I don't understand why everybody must target a web application this days. Some of your requirements would work much better in a desktop application.
    I agree on that too. Today everybody thinks first about HTML/JS web app UI when developing enterprise apps, but in most cases, classic windowing UI with adequate remoting technology would be much better choice. Swing applets or Swing/SWT JavaWebStart with WebServices/RMI/CORBA for service-oriented remoting is definitely a good choice for many enterprise app UIs.
  29. Just what I needed!!![ Go to top ]

    Another component framework!
  30. Re: Podcast: Gavin King on Seam[ Go to top ]

    What do you think of Seam?
    Good: addressing conversational and process state. Bad: tied to JPA (please correct me if I am worng, I mean if conversational and process state management is not tied to JPA)
  31. Stateful Framework Comparison[ Go to top ]

    I have been evaluating JBoss Seam, Spring Webflow and Apache Shale as a result of Oracle's de-support notice for UIX. In terms on conversational state they all look to be addressing the same issues, but using different concepts. However, which ever way you turn, it is looks like you will have to absorbe quite significant framework. Bearing in mind all these frameworks are still quite yonug, it does give you an uneasy feeling. Protecting our existing investment in one framework and moving to a JSF + framework alternaltive is a huge step. If anyone out there has actually made this step, I would love to here about your experiences. We are still evaluating. Thanks Pat
  32. Hi Pat, Out of curiosity, did you consider Oracle's component framework ADF with binding to JSP on the UI layer as an option and did you have any experiences with that?
  33. We are looking at ADF/JSF, but I've been advised that we will have to wait for 11g before there is a proper page flow framework. We had already extended UIX by introducing the concept of a Dialogue Manager, i.e. a Flow in WebFlows terms, or a Dialogue in Shales terms. Because we have similar concepts to these frameworks, but have no migration path available to us via Oracle's ADF framework, we are looking for the best fit instead. Either way its going to be expensive. We have of 500 page, 230 templates and 230 dialogues. ADF 11g is currently be pre-viewed, but I dont have anough information to determine if it is going to add any value. I understand that they are working on conversation state concepts. But without any concrete information its hard to speculate. IF you have any information about ADF 11g, it would be welcome. Thanks Pat
  34. Re: Podcast: Gavin King on Seam[ Go to top ]

    We're in the process of integrating Seam with ICEfaces and we find the Conversation scope to be a perfect fit for multi-window Ajax applications. ICEfaces and Seam work naturally together: ICEfaces already supports Facelets, so it will be possible to transform a Seam application into an Ajax application just by adding the ICEfaces libraries (in many cases). "Session" and "Request" scope simply aren't enough to represent the user's context in a web application (especially when multiple windows are concerned). For instance, if two windows are opened into our auction monitor demo, it's natural to expect that bidding should take place between the two windows (it's certainly useful from a demo perspective, even if most users aren't interested in bidding against themselves), but session scope leaves you with the same application state in both windows. With asynchronous updates from the server, this would cause one window to directly control the other. With ICEfaces we have adjusted the definition of "request scope" slightly so that it endures from one full page request to another (request scope is not marked by events sent over Ajax) thereby allowing the developer to distinguish between different "conversations" in different windows by their distinct requests. It's a defensible adjustment, but it's far better to make it explicit as has been done with Seam. Ted. http://www.jroller.com/page/tedgoddard
  35. Podcast: Gavin King on Seam[ Go to top ]

    i have had the same problems as Goran. The ideas are greate but implementation is not ready yet. I tried to create CRUD component with parent-child relation without success.... We'll see who winns seam, spring WF or shale. I see it as advantage that seam uses SFSB to store state and not persist it as spring WF.