Conversations only really take place within the web context as a way to provide stateful interactions on an otherwise stateless infrastructure.

A conversation is an object that is used to hold named objects between requests. In the JSF case, these objects are provided based on the name matching EL expressions using a JSF variable resolver.

I could be wrong, but if you use standalone java clients interacting with remote ejbs, no conversation is needed because the client keeps hold of the conversational objects. One other problem you might face is not having Seam Transaction Management for non-JSF/Web Service bean access.

I believe both JSF and Web services can use conversations as long as the Id is passed back and forth.

Personally, I only use conversations in pages.xml since it decouples conversation management from my beans.

In your case, since you have such varied uses for your beans, you may need to really consider the structure of your application carefully regarding conversations and also transactions. One other aspect of this is whether you clutter your beans with JSF backing bean code. You don't need your desktop clients calling your button click backing bean code in the same bean.

Cheers,

Andy Gibson