Seam will be addressing SOA, WS, etc... more in a later release, in the meantime I'll give you my take on the rest of you message. You should take that as just my opinion, which doesn't necessarily reflect Gavin's view or any of the other Seam contributors. I think one of the biggest mistakes we make creating applications is over-architecting and layering or applications when there is absolutely no reason to do so. One of the revolutionary things about Seam is that it completely breaks down the layering and let's you get to the business of writing an application. If layering suits you, use it. But you aren't forced into over-architecture. That's pretty much the same answer that left you unsatisfied in the docs, but it's worth emphasizing because I really think it's true. An overwhelming number of people go about about designing what should be a relatively simple application but get caught up in "patterns" inflicted on them by their choice of technologies. (EJB, Spring, whatever) I think Seam's greatest contribution right now is simplifying life for the vast majority of application types out there. Ok, let's talk tiers. If you have to pin Seam down, I'd say you should shoot for Seam as being middle-tier components. However, I'd simply say "application" components. You should write components that accomplish the needs of your application is if you were writing simple Java objects. Seam let's you, with annotations, bind to front-end GUI behaviour and back-end concerns. Ideally, you these concerns really shouldn't influence the design of your application, but they can. Seam is trying to eliminate those ugly places. For instance, Seam actions don't have to return a String outcome. You can guide your navigation in other ways. You don't have to use UI components in your objects, you can do databinding to wrap/link your data to UI objects in the view. (datamodel is the example seam provides, but it is an extensible framework) So, on the far end of "layering" Seam tries to let you achieve layering by performing the jobs of all the layers - leaving you with just an application component. Ideally it's just a POJO. So - HotelBookAction or HotelBookingService? Take your pick! You should be able to write it as a generic HotelBookingService if you want, but most of the Seam examples are not trying to be anything more than what they are - simple web applications. The naming reflects this. If you are writing a web application, why do you need a service? You probably don't. Seam let's you simplify - your code and your thinking. Yet, it's trivial to move from a "simple" web app to a complex enterprise app in seam. It all works the same way. I agree that we should have more examples. We are growing them with every release, but we aren't there yet. Quite frankly, we don't have the resources to be able to tackle all the possibilities and still have time to get to all the planned features. It'll only happen with more community involvement. We've had quite a few wonderful contributions recently, but we obviously need more. Feel free to join in. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997720#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...