[wschwendt]

Gavin King wrote on May 17, 2009 08:13:


I expect that we will port the pageflow support in Seam to 299 quite soon. But that stuff isn't actually using nested conversations at present.

And that's a pity!  Nested conversations would be incredibly important when pageflows are used.

Think of an activity or use case modeled as a pageflow. A complex activity (of a stateful application) could be decomposed into less complex sub-activites which are modeled as sub-pageflows.  Spring Web Flow demonstrates this.

When using a conversation-scoped persistence context, which Seam encourages, one problem the programmer needs to be aware of is that the persistence context caches every object that is in managed state. So if the conversation is kept alive for a long time, the conversation-scoped  persistence context grows endlessly until (in the worst case) you  get an OutOfMemoryException.

So what is the natural solution to this problem?  Simply decompose a complex pageflow into sub-pageflows and execute each sub-pageflow as a nested conversation. The nice effect is that all conversation scoped data structures and components of the sub-pageflow get automatically cleaned up when the nested conversation ends. A sub-pageflow could therefore also use an own persistence context the lifetime of which is limited to the nested conversation.

I was already thinking about getting more involved in the improvement of Seam's  pageflow support, which is so far still limited. But, as mentioned, the ability to execute sub-pageflows as nested conversations depends on how usuable the nested conversation support by the framework really is. And right now it's totally unclear how this will evolve, given that Seam 3.x will be based on Web Beans.

[gavin.king]

Think of an activity or use case modeled as a pageflow. A complex activity (of a stateful application) could be decomposed into less complex sub-activites which are modeled as sub-pageflows. Spring Web Flow demonstrates this.

Sorry, I don't need to look at Spring Web Flow to understand how this works. I coded Seam's support nested conversations and for jBPM substates into the Seam pageflow module before anyone had ever heard of Spring Web Flow.

And subflows have very little to do with nested conversations. You can do them as orthogonal features. You don't need nested conversations to implement subflows. You don't need subflows to implement nested conversations.

In Seam, each nested conversation can have its own pageflow. Or, a pageflow can be decomposed into jBPM substates which all run in the same conversation. That's your choice.

It is actually a shitty limitation of Spring Web Flow that it forces you to use a pageflow if you want a conversation. That's just crazy.

I was already thinking about getting more involved in the improvement of Seam's pageflow support, which is so far still limited.

Limited how? The feature you just mentioned is already supported by Seam.

But, as mentioned, the ability to execute sub-pageflows as nested conversations depends on how usuable the nested conversation support by the framework really is.

Not correct.

This is the problem with Spring. People get into their little Spring is the whole universe world, completely unaware of technology like jBPM or Oracle ADF, or other things that pre-existed Spring by years, and think that the limitations of Spring are somehow logically necessary.

And right now it's totally unclear how this will evolve, given that Seam 3.x will be based on Web Beans.

As described above, it is totally possible to implement nested conversations as a portable extension to 299. It's also possible to implement subflows without nested conversations. In fact, my opinion is that experience has shown that this is the better path to go down.

I also direct your attention to section 11.6 of the 299 spec, which describes how 299 supports Activities for use by orchestration engines.

[wschwendt]

Gavin King wrote on May 25, 2009 01:38:


In Seam, each nested conversation can have its own pageflow. Or, a pageflow can be decomposed into jBPM substates which all run in the same conversation. That's your choice.

I know that Component (org.jboss.seam.pageflow.pageflow) is defined with @PerNestedConversation.

But that's not really useful.

Instead, what would make much more sense is that every subprocess  (sub-process element in jPDL) gets executed as a nested conversation.

And this is not yet supported by Seam.

It is actually a shitty limitation of Spring Web Flow that it forces you to use a pageflow if you want a conversation. That's just crazy.

I'm a Seam user, not a Spring advocate. Nevertheless, in some areas Web Flow is more advanced than Seam's Pageflow concept.

I was already thinking about getting more involved in the improvement of Seam's pageflow support, which is so far still limited.

Limited how? The feature you just mentioned is already supported by Seam.

unfortunately no, see above.

And exception handling is still broken when Pageflows are involved (Seam then goes into an endless loop). But it's easy to fix that. One simple workaround I used more than 1 year ago already  is to simply override the Pageflow component as follows (Seam's  component model nicely allows this)

@Scope(ScopeType.CONVERSATION)
@PerNestedConversation
@Name("org.jboss.seam.pageflow.pageflow")
@BypassInterceptors
@Install(dependencies = "org.jboss.seam.bpm.jbpm", precedence = FRAMEWORK, classDependencies = "javax.faces.context.FacesContext")
public class Pageflow extends org.jboss.seam.pageflow.Pageflow {

    private static final long serialVersionUID = -6827446509537097026L;

    protected boolean isDeactivated = false;

    @Override
    public boolean isInProcess() {
     if (!isDeactivated)
         return super.isInProcess();
     else
         return false;
    }

    @Observer( { "org.jboss.seam.exceptionHandled",
         "org.jboss.seam.exceptionNotHandled" })
    public void deactivatePageflow() {
     isDeactivated = true;
    }

}

I have not filed a JIRA case (and a more detailed analysis) why Seam's exception handling goes into an endless loop, due to lack of time.  But I could.

We have 2:16 local time now here in Germany, so I have to go to sleep and cannot write a lengthy post now.

[gavin.king]

But that's not really useful.

Instead, what would make much more sense is that every subprocess (sub-process element in jPDL) gets executed as a nested conversation.

And this is not yet supported by Seam.

Why, how would it be better?

I have not filed a JIRA case (and a more detailed analysis) why Seam's exception handling goes into an endless loop, due to lack of time. But I could.

Please do. That's a bug, clearly...

[wschwendt]

Gavin King wrote on May 25, 2009 02:39:

Please do. That's a bug, clearly...

yes, I will try to file an issue during the next days, together with some analysis (therefore I cannot promise to file the issue immediately).

Why, how would it be better?

As you know, your invention Seam makes it easier to implement stateful web applications. In simple webapps most navigation is stateless and we execute only a small number of interaction steps in a wizard-like way, e.g. the checkout process in an online shopping application.  But when stateful interactions are more complex, which can be the case in (intranet) enterprise apps,  solutions such as Web flow or Seam's pageflow concept become important. They help the programmer maintain the integrity of the application in light of the back-button problem. In fact, they make it possible to write enterprise webapps as if they were stateful desktop apps.

Referring to the development of enterprise apps, which Red Hat targets with Seam:  When interactions are complex, it makes tremendous sense to model them first before the programming work gets started.  Think of UML use case diagrams, for example. Here relationships between use cases are possible. An include relationship is used to integrate a use case into another use case, thus becoming a logical part of that use case. Alternatively, an extend relationship is used to express that a use case will be extended by another use case in certain circumstances, and at a certain point referred to as extension point.  Or think of UML activity diagrams which can be used to model the functional behavior of use cases. The UML allows an activity to call another (sub-)activity. Similarly, jPDL provides the concept of a process-state which can call another pageflow as a subprocess.  This modeling principle of functional composition/decomposition is widely accepted as very useful, so I think we do not need to have a lengthy debate about it here. 

However, as far as Seam is concerned, the following question arises:  If we use Seam (with JSF/Richfaces) as the target platform for our enterprise app, how easily can we map models of the kind described above to the target platform?  And here it is my conviction that it would make things much easier IF we had the ability to execute a jPDL subprocess (sub pageflow) as a nested conversation.  One big advantage would be that when the sub-process ends (and in turn the nested conversation), any state held in the nested conversation context is automatically cleaned up.  Further, if a subprocess is executed as a nested conversation, we can also avoid namespace clashes (with the parent activity/parent jPDL process) when using the conversation context.   Web Flow may have weaknesses, but with regard to the described problem, it at least provides a good and clean solution with the flow scope.  And I see no reason at all why Seam's pageflow functionality shouldn't be improved a little bit in this regard.    For example, I could imagine the addition of an attribute named nested-conv to the jPDL sub-process element, so that we could write:

<process-state name="subactivityInvocation">
    <sub-process name="subactivityName" nested-conv="true"/>
    <transition to="end"/>
</process-state>

Btw, last year I devised a scheme to map use cases modeled as activity diagrams to Seam-based design class diagrams and jPDL process descriptions. It worked very well, but the weakness was the mentioned execution of subactivities (jPDL subprocesses) in the conversation scope of the parent jPDL process rather than as a nested conversation.   I don't know if an alternative mapping had been possible which would execute the subactivities  as a nested conversation, given that the pageflow component is defined with @PerNestedConversation.  But when devising a mapping scheme, other questions need to be solved such as how parameters are (systematically) passed from the calling activity to the subactivity and back once the subactivity ends.

And last year I thought that Seam's handling of nested conversations would be too limited to allow my idea described above (the nested-conv attribute).  The reason why I thought this is that Seam's conversation manager is actually only managing a stack of conversation ids, not a stack of conversation contexts. Hence I thought that Seam is only able to write to (at most) one conversation context per request. But Dan Allen's fix for JBSEAM-2209 (ManagedEntityIdentityInterceptor) demonstrates that it is in fact  possible to switch from a parent conversation to a nested conversation and back during a single request. He explicitly flushes the conversation context before conducting the switch.  And with such an approach it would be no problem at all to execute a jPDL subprocess as nested conversation and switch immediately back to the parent conversation when the subprocess ends.   In terms of implementing the conversation switching I had the same idea as Dan already last year, but wasn't sure whether this would be a legal use of Seam.