Gavin King Goes Deep with Seam 1.0 at TSSJS Europe

Discussions

News: Gavin King Goes Deep with Seam 1.0 at TSSJS Europe

  1. Gavin King, author of Hibernate and originator for JBoss Seam, spoke with Integration Developer on the eve of the Seam 1.0 release to discuss how Seam came into being, how it will help enterprise Java devs and the status of the Seam project. Gavin will be speaking on Seam at TSSJS-Barcelona on the topic as well.
    IDN: What is the biggest near-term problem you see for Seam? King: Today, one of the biggest things that Seam emphasizes for UI is conversations. This is a critical thing that is missing today. So many apps are broken as soon as I try to work in multiple windows, and that is because of conversations. State management is an absolute disaster. People building desktop applications used to be able to attach state to the screen and the UI and when we went to the web we lost the ability to do that.. Seam looks to bring that back with something we call 'contextual components' which make it possible to manage different states in a single application. IDN: So, my state management for the UI and my state management for a transaction could both be created and managed in Seam? King: State management is such a deep part of what apps do that devs need strong semantics, as well as very strong constructs and modeling. Seam offers 'strong' constructs for conversations, business process, web services conversations. And, yes, all these things require different handling in implementation. IDN: Where else do you see the need for 'meaningful integration' for these new types of web-based apps or services? King: In the Seam context, when I talk about integration, I mean addressing a problem that has grown up in the JCP [Java Community Process], where individual Expert Groups create specifications and programming models to solve narrowly-defined problems. For example, we have a spec for EJB for writing business components that uses transactional resources. We have another expert group, JSF, that concentrates on writing components that can be bound to a UI. And, we have an ESB group addressing the problem of how different applications and systems interact with each other. Often what happens is that these people build individually strong specs, but the trouble is that the only component model that all can agree on is fairly weak, and that makes it difficult for a developer to do everything he needs for one application -- access transactional resources, bind to a UI and interact with other services connected to the ESB.
    What do you think? Message was edited by: joeo@enigmastation.com
  2. King: Today, one of the biggest things that Seam emphasizes for UI is conversations. This is a critical thing that is missing today. So many apps are broken as soon as I try to work in multiple windows, and that is because of conversations. State management is an absolute disaster.
    Absolutely agree with Gavin. Managing conversational state across multiple pages and/or windows is very error prone without good framework support. However, I have one conceptual problem with Seam. Using same beans (with all kind of annotations) for persistent domain model and UI model is great feature and simplification for most simple and moderately complex applications. But, there are cases when this is not desirable. Does Seam provide some support for this kind of apps?
  3. However, I have one conceptual problem with Seam. Using same beans (with all kind of annotations) for persistent domain model and UI model is great feature and simplification for most simple and moderately complex applications. But, there are cases when this is not desirable. Does Seam provide some support for this kind of apps?
    With the use of POJOs, everything is described with annotations to the core object model. This is supposed to be a "good thing". Maybe with a more complex application a combination of POJO annotation + XML file(s) (stop the XML hating :) ) would be better..? Personaly I for example sometimes prefer the XML document when describing an ORM instead of the annotation way. When the ORM is straightforward then a annotated POJO will probably work well too... You are right that there is a certain worry about annotation overkill / unreadable annotation, where the amount of annotation exceeds "real code". Tools might help with this, but I think there can be such a thing as "too much metadata". If this happens we would need to "reinvent POJO" as everything in life works/happens in cycles. :) -I
  4. With the use of POJOs, everything is described with annotations to the core object model. This is supposed to be a "good thing". Maybe with a more complex application a combination of POJO annotation + XML file(s) (stop the XML hating :) ) would be better..? Personaly I for example sometimes prefer the XML document when describing an ORM instead of the annotation way. When the ORM is straightforward then a annotated POJO will probably work well too...

    You are right that there is a certain worry about annotation overkill / unreadable annotation, where the amount of annotation exceeds "real code". Tools might help with this, but I think there can be such a thing as "too much metadata". If this happens we would need to "reinvent POJO" as everything in life works/happens in cycles.

    :)

    -I
    What is being promoted is integration and coordination of processes, state, and behavior-- and XML can only convey so much. With the addition of metadata within Java, we can now keep everything cohesively bound in composite Java models. You'll often times find that even with introducing XML, there's still a 1:1 association between Java code written and the supplementing XML metadata, so why not just marry the two?
  5. You'll often times find that even with introducing XML, there's still a 1:1 association between Java code written and the supplementing XML metadata, so why not just marry the two?
    As my object libraries have grown over the years, I have re-used a large number of objects and deployed them on many different schemas. Therefore I no longer have a 1:1 relationship. With XML files, I was able to have a clean object library. Annotations may be better for many if not most of the situations, but I don't want to have an object that contains 30 lines of code, 100 lines of documentation, and 200 lines of annotations.
  6. You'll often times find that even with introducing XML, there's still a 1:1 association between Java code written and the supplementing XML metadata, so why not just marry the two?


    As my object libraries have grown over the years, I have re-used a large number of objects and deployed them on many different schemas. Therefore I no longer have a 1:1 relationship. With XML files, I was able to have a clean object library.

    Annotations may be better for many if not most of the situations, but I don't want to have an object that contains 30 lines of code, 100 lines of documentation, and 200 lines of annotations.
    This is exactly where I was getting at... I would like for there to be a "override/extend annotations" annotation or standard way to link the XML. Something like @LocationOfMyXMLConfigFileToUseInstead(/com/something/xmlconfig.xml). That and maybe somekind of a convention/agreement to describe simple metadata with annotations and complex metadata with XML. -I
  7. You are right that there is a certain worry about annotation overkill / unreadable annotation, where the amount of annotation exceeds "real code". Tools might help with this, but I think there can be such a thing as "too much metadata". If this happens we would need to "reinvent POJO" as everything in life works/happens in cycles.
    Don't worry about "annotation overkill". Annotation is evolution of xdoclets idea, i.e. using annotation is proven by time. E.g. we use xdoclets without pain in a large open source project (RUNA WFE is an open source workflow environment). Xdoclets is used for struts, hibernate, ejb. Before Xdoclets it was hell to modify huge XML documents after each refactoring. With Xdoclets it became a peace of cake. The drawback of Xdoclet is XML generation phase which was removed with annotation. Source code of RUNA WFE project can be found here. Online demo can be found here. Regards, Vitaliy S
  8. However, I have one conceptual problem with Seam. Using same beans (with all kind of annotations) for persistent domain model and UI model is great feature and simplification for most simple and moderately complex applications. But, there are cases when this is not desirable. Does Seam provide some support for this kind of apps?


    With the use of POJOs, everything is described with annotations to the core object model. This is supposed to be a "good thing". Maybe with a more complex application a combination of POJO annotation + XML file(s) (stop the XML hating :) ) would be better..? Personaly I for example sometimes prefer the XML document when describing an ORM instead of the annotation way. When the ORM is straightforward then a annotated POJO will probably work well too...

    You are right that there is a certain worry about annotation overkill / unreadable annotation, where the amount of annotation exceeds "real code". Tools might help with this, but I think there can be such a thing as "too much metadata". If this happens we would need to "reinvent POJO" as everything in life works/happens in cycles.

    :)

    -I
    I think he was more refering to JSF backing beans being replaced by EJB 3 session beans. I also have this concern but my knowledge of Seam at the moment is very limited. From what I know, Seam consider backing beans as 'glue code' and and therefore make them disappear. But my problem is that my backing beans contain usually more than glue code. Any Seam power user here ? I would like to hear your opinions on this topic. But I really like initiaves like Seam because right now JEE is an integration nightmare and it would be great to see some improvement in this area.