Message contexts and Spring Webflow conversation scope

[Brent Putman]

I've been getting up to speed on Webflow and in my reading I was
reminded of an important issue that I broached with Chad a couple of
years (!?) ago.  Wanted to make sure it is on (especially) Tom's and
everyone else's radar.

Our whole message processing design for the IdP v3 is based on the
notion of storing our message context tree in Spring Webflow's
'conversation' scope.  For reference, this is currently implemented in
the WebflowRequestContextProfileRequestContextLookup strategy.

The issue is that, by default, anything you store in conversation scope
must be serializable (as in implements java.io.Serializable), because
their default impl simply stores the conversation container object in
the HttpSession as a session attribute.  We absolutely can't
realistically meet this requirement, as we've discussed ad naseum re:
the proposed and abandoned use of Infinispan and other notions of
clustering support that would require all our domain objects to be
serialized and persisted (one way or another).

When I brought up to Chad, his answer was that we can change Webflow's
conversation scope implementation to do something different.  In
particular, re: clustering we assume the use of load balancer stickiness
that lasts at least the lifetime of a conversation, so conversational
scope does not need to be distributed beyond the original node the user
hits.  So something like a simple in-memory Map-based conversation scope
impl *should* work.

However, AFAIK we've never really done any work to validate these
assumptions. (Correct me if I'm wrong).  Since our whole v3 design
depends on us being able to do this, IMHO we should probably do this
work sooner rather than later, in order to know whether we've got a
serious roadblock here.

As far as I can tell, the Webflow components that will need custom impls
to accomplish what we need are (at least) the ConversationManager and
Conversation interfaces.  It looks like doing what we need should be
do-able, and seemingly easily.  But we need to find out for sure, me thinks.

I propose that we get these impls done and actually tested in a running
Webflow environment as soon as possible.  I suppose it's probably a Tom
thing, since it's in the IdP, but it's also a critical part of the
message processing design, so I can also take it on if Tom doesn't have
the time or interest.  Would also give me an opportunity to get some
hands-on experience with Webflow.

Thoughts?

--Brent