assuming you are interested in seam, i recommend to read the excellent online documentation. specially that - really fundamental - topic is covered in much broader depth than any forum post could provide.
I 'need to read either the Seam reference documentation or Seam in Action.
The conversation is a slice of the HTTP Session dedicated to a single browser viewport (tab or window). It maps one-to-one with a use case involving a single user, where the boundaries are something you decide based on the business logic. Those boundaries can be set various ways, either declaratively (XML) or programmatically (Java/Groovy/EL). The main purpose of the conversation is to extend the persistence context across more than one request to avoid detached entities. You also have the option of binding the conversation to a stateful pageflow, which makes the boundaries more well defined and constrains the user on a predetermined navigation path.
The business process is a persistent context (i.e., stored in a database) and therefore can stretch across any number of requests, sessions, or even application restarts. It maps one-to-one with a use case involving one or more users. The boundaries are controlled by a business execution language. Seam relies on jBPM to drive the business process described in jPDL. In some regards the business process is a multi-user conversation, though each task in the business process can itself be a single-user conversation. You can start to see how these two contexts build on one another.
If you want to learn about the business process in depth, and see more references to its relationship to the conversation, you can read the Business processes chapter of Seam in Action for free online.
I understand that the business process can span multiple sessions and even multiple application restarts and this is done by persisting the business process state.
However I haven't been able to find anything in the online docs or even the the jBPDL example distributed with seam 2.0.2GA which demonstrates this functionality or how it works. There is the dvd store example but I couldn't work out how the BP state was maintained wrt to persisting to the DB.
I am very interested to know exactly how this works as I've been working on an application that manually deals with persisting state to maintain a business process, it has caused us many problems and continues to be a complex and hard to maintain part of our application. [ October 08, 2008: Message edited by: dan oxlade ]
Joined: Mar 05, 2003
I am very interested to know exactly how this works as I've been working on an application that manually deals with persisting state to maintain a business process, it has caused us many problems and continues to be a complex and hard to maintain part of our application.
I address this exact point in the business process chapter in Seam, chapter 14. I say that most companies are using a business process, they just don't know it (or they know it and they use the database directly anyway). Most people end up using an embedded database to store the business process state, such as HSQLDB or H2, though you can certainly use any database supported by Hibernate.
I encourage you to read chapter 14, which really does give you the answers you are looking for. I don't even have to sell you on the book since the chapter is available for free. The only disclaimer is that if you wait for the PDF (hopefully out in the next week), it's of better quality (both visually and technically) than the current Word document.