1) Not quite: Seam makes simpler architectures *possible*, and essentially lets you layer your application however *you* like. You can certainly follow whatever architectural patterns you prefer, and in particular you can certainly have your entity beans have no Seam dependency. Up to you to weigh the costs and benefits.
2) Should be. I've certainly used multiple ejb jars. Have not specifically tried multiple wars, if you do that you will need to be careful about classloader issues, the wars will need their own classloading scope, I suppose.
3) The design patterns are your own design patterns, that's the whole point: to give you flexibility. My example apps mostly concentrate on simplicity at the cost of all else.
This is a topic I have been thinking of opening as well.
It is still unclear to me to which extent using Seam pays off when you have to deal with multiple presentations for example.
I would like to see something like sun's blueprints for scoping and injecting Seam into a layered application.
For example from one side it is appealing to annotate a data model to use it directly in the presentation, but conceptually the data model should remain
independent from higher level layers. I agree, annotations are not as intrusive as interfaces but they still create dependencies.
Personally I find diffucult to estimate costs and benefits for technologies like Seam for anything more than really simple contexts
gavin, thx for the quick answer, this sounds really good ..
being free to choose and design the overall architecture and not being inforced by a particular framework is a basic requirement in my opinion.
however, i fully agree to drVillo, it would be great if you could provide some more documentation or examples, how to build a seam based application using a multi layer architecture. I think of the dvd application example of being a good candidate for such a purpose. actually, there is only one org.jboss.dvd.seam package with "everything" inside..
this might be good for simplicity purposes, but acceptance would greatly increase in my opinion, if you would also provide more architectural blueprints. in real live applications you wouldn't have only one package (or one layer).
since seam is a brand new framework and also introduces some new paradigms, it's very easy to run into traps while dealing with complex situations.
drVillo, I think once you are really familiar with Seam, extending it to cover complex situations is a more or less straight point.
Seam manages pretty well to solve most of the dependencies.
I would agree with you if you were talking about advanced application configuration, but again that's a matter of design. Every architect has his / her own design patterns.
I view things from a different perspective, if you have complex situations then your design is complex and no matter what framework you use the outcome will always be complex.
In any cases, I have been working on implementating a framework that resembles to Seam to a large extent, however I used WebWork and other frameworks and different patterns for source code generation. the stuff generated by Seam is really huge, it's a boost of at least 40% of your time and your developers time once they're familiar with the new concepts (not really new, except for the conversations)
To make this discussion a short one I believe that Seam is on its way, a lot is still pending but the architecture, the vision and hopefuly the resources are there. This project is worth a remarkable success that will show off in a while.