I'm no expert, but I'll give me two cents.
) Looking through the SOA lens, can the action beans be thought of as services? For example, would it be ok to think of HotelBookingAction as HotelBookingService?
Sure. HotelBookingAction is an Seam implementation of HotelBooking, where it outlines the business operations as part of booking a hotel.
2) From a layered architecture perspective, do you think of the action beans as presentation-tier or middle-tier? I ask this because action beans seem to have presentation logic, e.g. the actions return navigation outcomes. Where is the boundary between the two layers?
At least in the booking example, I don't see the Action classes rely on navigation outcomes. They are part of the middle-tier. Page actions as those defined in pages.xml bridges the presentation and the middile-tier. This is what really nice about Seam.
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. :)
Thanks hstang and Norman for your opinions - very informative and useful.
And yeah, Norman, I will "feel free to join in" as soon as I can :-), currently very busy with two other open source projects. BTW, I totally agree with your comment about over-architecting applications when there is absolutely no need to do so - this is so true for web applications. Fortunately or unfortunately, in my line of work there is 50-50 mix of web apps and enterprise apps (with Swing and other thick front-ends). So at least for me I cannot ignore entrprise apps and SOA. I would love to hear Gavin's comments and direction on this - at least before I jump in with both my feet :-).
+1 to all that Norman says.
But I just want to re-emphasize two points:
(1) If you are building a loosely-coupled (SOA) application, absolutely nothing stops you using a more traditional layering. There is no problem having two layers of Seam components.
(2) Especially with some of the new stuff in Seam 1.1 and 1.1.1, we are working towards the ability to be able to have a single component that can be called from a web page, or from a WS invocation.
(3) Most importantly, Seam 1.2 will provide the integration of the Seam context model with invocation via the WS stack.
Thanks Gavin. I will start by creating a loosely-coupled (SOA) application and see how far I can take it. I will post on the forums in case I have questions or need clarifications.