SEAM without ejb

[Marinescu Violeta]

I read some stuff on seam which stated that seam implements the concept of web components and by this provides an unified view of ejb and jsf beans (also jpa). My question is , if don't use ejbs in a project doesn't make sense to use seam? For example if you have a project which handles mainly the view of an plication and delegates all the busssines logic to some webservices. Seam may still be a solution for this kind of project?

[Jason Porter]

Yes, Seam would still work. EJBs right now as Seam components really aren't that great (at least not until 3.1 when we really start to see some power and usefulness for the regular project from them). POJO components work great in Seam and are very easy it use.

In your example saying it's mostly done with web services I would ask why so stateless? If you app needs to be stateless then maybe Seam isn't the best solution as state is a very big thing in Seam (though you can get some very good results with Seam's RESTeasy integration). If you could make the app better or more user friendly by keeping some state around then by all means take a look at Seam.

[Marinescu Violeta]

The view is a stateful application, but the webservice is kept stateless (because there are some other applications using the same ws and we don't want to introduce any dependency on client state to the ws). One of the reasons seam is considered as a solution is conversational scope as there are some wizard like features that need to be implemented .
I know that seam works without ejb or jpa , the question is if in this situation i will be using all the power behind seam, or i will use seam just for the sake of using seam.

[Marinescu Violeta]

i have soap ws. It think that using rest services requires a change into the way the application was design - you have to think in a ,,state " world, and this seems like another topic - changing the application philosophy etc .

[Jason Porter]

As you stated you may be able use the conversation state (outject result from the web service or something). You most certainly get some of the niceties that Seam brings to JSF (or you could use a different view layer) and if you end up having to generate emails, RTF, PDF, or Excel files there's not much that's easier than what Seam does. Seam may very well make sense for the application, but it really depends on the requirements. If you're using JSF it's almost worth it just for what Seam brings to JSF. If conversations are possible (I find myself saying now, when would I not use them) or you need to do any of the above mentioned things, or even JMS and don't want to use MDBs Seam works very well.