Spring Web Flow (SWF) 1.0 EA has been released.

Spring Web Flow is a product of the Spring community focused on the definition and execution of page flow within a web application.

SWF allows you to capture logical page flows as self-contained controller modules that are reusable in different situations. The system is ideal for web applications that guide users through controlled interactions that support business processes. These user interactions, or conversations, typically span HTTP requests and may be dynamic and transactional in nature.

As an embeddable page flow and conversational state engine, Spring Web Flow integrates with existing frameworks such as Spring MVC, Spring Portlet MVC, JSF, and Struts. Flow definitions are reusable accross environments without coupling developer application code to SWF APIs.

Spring Web Flow 1.0 EA is a major release for several reasons:

• The 1.0 product roadmap is now complete
• The 1.0 product reference documentation is now complete
• The product has now entered into a four week user evaluation period before the release of 1.0 RC1, which will be the first production-grade release, followed by the release of 1.0 final. The Spring Web Flow team is keen on considering as much feedback from the community as possible during these four weeks with 1.0 EA to further ensure the highest-quality product possible.

The new and noteworthy changes are major and outlined in detail in the announcement. In summary they are:

• Support for binding directly to backing business services from a flow definition (eliminating the need for trivial Action adapter glue code)
• Support for four (4) distinct flow response types out-of-the box (view forward, conversation redirect, flow redirect, external redirect)
• Multiple strategies for launching flows and accessing/refreshing/bookmarking ongoing conversations (parameter-based, path-based [REST-style])
• Simplified support for deploying flow definitions for execution
• Spring Portlet MVC integration, for executing flows in a JSR 168 Portlet environment
JSF integration, for executing flows in a JSF environment
• Improved support for persisting flow executions across requests and tracking (and securing access to) ongoing conversations within a repository.
• Automatic externalized flow definition change detection and "hot reloading"
• Support for global transitions shared by all states of a flow
• Support for importing one or more Spring bean definition files into a flow definition, providing a context for configuring custom flow artifacts such as actions, attribute mappers, exception handlers, view selectors, and transition criteria
• Support for "inline-flows," flow definitions fully local and contained within an outer flow definition
• Support for exception handling at both the flow and state level
• Miscellaneous improvements in many areas including but not limited to Java-based flow building, flow execution testing, flow execution listening, conversation locking, flow execution serialization, attribute and parameter map access support, flow attribute mapping, and piecemeal page-level form validation

Spring Web Flow 1.0 EA runs on JDK 1.3 or newer and requires Spring 1.2.7 (or newer). The Spring Portlet MVC integration requires Spring 2.0 M2 or newer.

The last section of the release announcement points to the reference documentation, available in HTML and PDF form, and notes the SWF sample applications available in this release for getting started in one-step after release download. The sample applications for review include:

1. Phonebook - the central sample demonstrating most features (including subflows).
2. Sellitem - demonstrates a wizard with conditional transitions, conversational scope, and continuations.
3. Flowlauncher - demonstrates all the possible ways to launch and resume flows.
4. Itemlist - demonstrates REST-style URLs, conversational redirects to a refreshable conversation URL, and inline flows.
5. (NEW) Shippingrate - demonstrates Spring Web Flow together with Ajax technology (thanks to Steven Devijver)
6. Birthdate - demonstrates Struts integration.
7. Fileupload - demonstrates multipart file upload.
8. (NEW) Phonebook-Portlet - the phonebook sample in a Portlet environment (notice how the flow definitions do not change)
9. (NEW) Sellitem-JSF - the sellitem sample in a JSF environment (notice how the flow definition does not change)

1.0 final is just on the horizon - we keenly look forward to your feedback on this release at http://forum.springframework.org.

Sincerely,

The Spring Web Flow Team

Keith Donald
Erwin Vervaet
Colin Sampaleanu
Juergen Hoeller
Rob Harrop

Congrats guys, it is a great product.
Any news about when Spring Rich Client will be ready?

Thanks for the kind words.

The Spring Rich Client project (a Swing-based desktop application framework built on Spring) is a separate topic entirely, of course. :-) If you take a peek at the springframework-rcp-dev list you'll see what's happening there. In summary, there is currently a framework modularization and "maven2ization" effort underway by the community to get a base point release out for evaluation. Now is an ideal time for open source developers developing desktop applications with with Swing and Spring to get involved with that effort.

Special note to Spring Web Flow PR5 (SWF Preview 5) users:

As to be expected, Spring Web Flow 1.0 EA is not backwards-compatible with Preview 5 (PR5). To assist with a 1.0 migration, we are working on an official porting guide for those who are in production with the PR5 release. We will announce availability of this guide before the SWF 1.0 RC1 release. With there being over 13K downloads of PR5, this is a high priority for us.

Best regards,

Keith

great

The 1.0 product roadmap is now complete

I thougth tapestry support was on the roadmap.

And WebWork then we got a good cover.

yes please i really need webwork integration or even a pointer on how to do the integration

The best pointer for how to integrate with Spring Web Flow IMO is to study how the other frameworks are integrated. Spring MVC is particularly simple to integrate with because it's a solid foundational framework with a smart set of extension points.

So if you take a look at FlowController, the adapter between Spring MVC and Spring Web Flow, and then perhaps FlowAction, the adapter between Struts and Spring Web Flow, you'll see a general strategy for integration emerge. There are also helpers such as FlowRequestHandler and FlowExecutorArgumentExtractor shared by those controllers as well that could be also in a WW integration piece.

JSF is a different beast, as it's request lifecycle is much more involved, and thus the integration layer is more complex. For WW integration, I would recommend studying FlowController and FlowAction first, and then taking the common ground and taking a stab at implementing a similiar WW adapter. We'll happily support you in this effort on the SWF forums.

We took a stab at Tapestry integration but in the end didn't have the time/resources required to make a quality integration happen in time for 1.0. I'll let Colin Sampaleanu speak more to status there.

Hope this helps!

Keith

Looks promising! I give it a try with JSF. Good work guys!

I like the continuation-style frameworks. This implementation is interesting to me because of the ability to persist long running flows.

Very nice work, Keith.

I like the continuation-style frameworks. This implementation is interesting to me because of the ability to persist long running flows. Very nice work, Keith.

Hey Bruce, I was at your Milwaukee NoFluff talk on Spring 2. Web Flow does seem interesting-worth looking into. Any publicly-available presentation slides for TSS users?

Sorry, no...but I'll be giving the same talk at the TSS symposium later this month, and again at NFJS at around 2o more stops this year.

Hi Bruce,

could you elaborate a bit more on that point? From my skimming of section 4.5 of the documentation of SWF at http://static.springframework.org/spring-webflow/docs/1.0-ea/spring-webflow-reference.pdf I only see "flow execution repository" implementations that either "persist" in the user session (is that the same as HTTP session?) or serialize to the client.

However, that is not what I call to persist something. In my book, to persist comes from persistent and that means that if I persist something it has to be there even after a reboot of the server and it has to be there in a few months also (if needed).

Do you know of a "flow execution repository" implemenation that persists to a db (or at least to the file system)?

Yes. Be glad to.

The continuation-style frameworks work by snapshotting a point in time, usually with native language continuations. So the flow of a continuation server is do work, snapshot state, save state in the session, send web page to client (the URL is stamped with a URL identifying the state), a request is sent to the server, the server restores state, and the cycle repeats.

Since the server saves the state, it's possible to create applications that look from a programming perspective to be stateful, but from a scalability perspective to be stateless. I have an article on developerworks that talks about continuations in Seaside, and another coming out in 2 weeks.

Some Java frameworks implement their own continuations (Rife is the most famous, and webwork uses Rife continuations.) But WebFlow uses a state machine approach instead of a native Java continuation. Since the state that you're storing at the server is just the name of a node in the state machine plus instance variables instead of a partial stack trace, you can persist flows across longer periods of time, safely. It's the biggest advantage of Keith's approach.

I hope this makes sense.

But the WebFlow approach is to implement

Hi Bruce,

I still feel awkward to think about SWF's approach as continuations. If that's the case, actually any web application that persists its state on the client side uses continuations too, since it "is a representation of the execution state of a program at a certain point in time". I think that the real sweet spot of continuations is that they happen in the native language and are available very easily, allowing you to leverage the power of the native language and don't have to wire things together externally.

I would also just like to point out to you that if the state machine approach should be considered continuations too, then RIFE has had that even before it supported native Java continuations. Actually, this was *the* idea that made development on the framework start almost 5 years ago. Our site structure declares logic flows and data flows and the web engine takes care of handling the state transfer, the whole orchestration and 'resuming' the execution after the web request at the correct spot. We offer by default two state storage methods (request and session), but by implementing a simple interface and registering it with the factory, you can implement any kind of persistence. The difference with SWF is that we don't believe that you should write any logic inside the state declaration and create a new language, but that it's better to write Java code that triggers events to make the state machine continue with the appropriate next steps.

Just thought I'd give my view on this.

Take care,

Geert

Geert,

Its an interesting point that you make. Native language continuations are widely useful, not only in a web scenario but for tasks such as async programming (although arguably better models do exist). I think the approach that RIFE is indeed pretty clever but the end result is little different from SWF. As Bruce points out continuations are much more about semantics rather than implementation. As Keith and Erwin will both attest I was pretty negative on this at first, tending to agree with you, but I came to believe that they are right - implementation here is irrelevant, its the user model that rules.

As for Java vs. XML, well I'm a big fan of XML for a number of reasons so I'll probably disagree a little with you, but lets remember that all active code in SWF is written using Java - there is no *programming* in XML. In addition, SWF has a Java-based configuration format, so if you *really* don't like XML then you easily define your flows in Java.

Regards,

Hi Rob,

do you happen to have a quick link to an example that uses the Java-based configuration format?

Thanks,

Geert

Hi Rob,do you happen to have a quick link to an example that uses the Java-based configuration format?Thanks,Geert

Hi Geert.

Take a look at this: http://static.springframework.org/spring-webflow/docs/1.0-ea/api/org/springframework/webflow/builder/AbstractFlowBuilder.html

It might give you an idea.

Regards,
Dmitriy.

Hi Dmitriy, thanks for the link.

This is what I thought, even though you use Java there to structure the flow and provide the elements, you don't use the native Java control syntax express your logic. You abstracted the control structures in a flow definition language expressed in Java classes and objects. There's nothing wrong with that at all, it's however largely just another way of writing exactly what you write with XML.

Best regards,

Geert

PS: I have nothing against XML btw

Regarding the comments made by Geert and Bruse on defining flows using native Java control structures. From my experience this is often harder than you would like it to be since what you really want is a 'goto' statement, not just loops and conditionals.

Erwin

Regarding the comments made by Geert and Bruse on defining flows using native Java control structures. From my experience this is often harder than you would like it to be since what you really want is a 'goto' statement, not just loops and conditionals.Erwin

Sure, we do that with lightweight runtime exceptions that are caught by the state machine. You don't get a goto, but you get a "jump out and interrupt" which can than be handled accordingly depending on the purpose and type.

This seems rather inefficient, and a typical misuse of java exceptions. I'm also not sure what you mean by lightweight? You still get the standard performance overheads when your throw an exception.

Cheers
P.

Regarding the comments made by Geert and Bruse on defining flows using native Java control structures. From my experience this is often harder than you would like it to be since what you really want is a 'goto' statement, not just loops and conditionals.Erwin

Sure, we do that with lightweight runtime exceptions that are caught by the state machine. You don't get a goto, but you get a "jump out and interrupt" which can than be handled accordingly depending on the purpose and type.

This seems rather inefficient, and a typical misuse of java exceptions. I'm also not sure what you mean by lightweight? You still get the standard performance overheads when your throw an exception.CheersP.

You can create lightweight exception classes that don't capture any stack trace, by just overriding some methods:
public class LightweightException extends RuntimeException {
  public Throwable fillInStackTrace() {
    return this;
  }
  
  private int getStackTraceDepth() {
    return 0;
  }
  
  public StackTraceElement[] getStackTrace() {
    return new StackTraceElement[0];
  }
}

The only thing that still will be done is checking for finally in the surrounding scopes. Which is isn't much of a problem really, since you're supposed to use this in action classes and most of the times these are just one or two calls away from your controller. You would otherwise have to manually "bubble out" of a deeper scope also.

Hi Geert,

I'm still not convinced, ok you are now throwing an exception without a stack trace. But, every time an exception is thrown the VM still has to release all the resources for that thread (locks, etc.) and re-acquire them once your thread resumes. This may not be much, but it is something one should keep in mind.

It reminds me of the code I used to write back when I thought that it's a good idea to (mis)use a language feature to achieve a "neat" little trick:

try {
  Foo foo = (Foo)bar;
  foo.something();
}
catch (ClassCastException e) {
  // Do something
}

This is faster than instanceof if you know you're going to get that exception rarely.

Cheers
P.

You can create lightweight exception classes that don't capture any stack trace, by just overriding some methods: snip snip snip

Hi Petar, indeed this has still some overhead, but it's not very different from the overhead that you would get when you bubble up through all the scopes yourself, manually, to deliver a return value. You're also a lot more prone to errors as you have to handle the bubbling correctly in each enclosing scope.

If that's the case, actually any web application that persists its state on the client side uses continuations too, since it "is a representation of the execution state of a program at a certain point in time".

Hi Geert,

How familiar are you with Spring Web Flow's architecture? From your comment above I have doubts that you have done your research (which from seeing you speak is not like you).

Let me see if I can clarify a few things. A SWF "continuation" is more than just an arbitrary clump of data serialized out somewhere, something "any web application could do" as you say. A SWF continuation is a snapshot of the Spring Web Flow virtual machine that represents a paused program called a flow execution. That program is responsible for executing instructions defined in a higher-order domain-specific language (DSL) called a flow definition. The goal of the program is to orchestrate a user conversation with the server.

So if I turn to the trusty definition I use for what a continuation is, I read:

A continuation is a saved snapshot of the executable state of a program at any given point in time. It is possible to restore this state and restart the execution of the program from that point onward, such that the stack trace, all the local variables, and the program counter can reclaim their old values.

Translated to Spring Web Flow terminology...

A flow continuation is a saved snapshot of a flow execution at any given point in time. It is possible to restore this state and resume the flow execution from that point onward, such that the stack and all the local variables reclaim their old values.

How a flow execution is stored and resumed between requests is pluggable. The responsibility for persistence falls on the flow execution repository subsystem; FlowExecutionRepository is the central interface. Michael, you are correct, we do not provide an implementation out-of-the-box that works with a long-term form of storage such as a DB.

In summary, Spring Web Flow exhibits the characteristics we feel required of a continuation-based framework and server. These are:
1. There is a well-defined programming language in play for defining programs. This is the SWF flow definition language, which is a higher-order DSL focused on solving the problem of page flow.
2. There is a runtime environment / platform for executing programs. This is the SWF flow execution, which is based on a finite state-machine, which maintains a stack of flow sessions where each element in the stack represents a running instance of a flow with a pointer to the current step and local variable context.
3. There is a subsystem dedicated to the responsibility of managing the storage and restoration of programs that execute beyond one request.

I hope this provides some more insight into our architecture. For more information on the architecture I recommend reviewing the SWF reference manual, supplimenting with the JavaDocs and sample applications.

Best regards,

Keith

Hi Keith,

I pretty much got the architecture of SWF, but I never developed with it. However, from seeing your clear explanation I seem to have understood it well enough. I didn't mean to be condescending towards your project, if things came across like that, I apologize.

My point is that merely relying on the definition that you use, a lot of things can be named continuations. I didn't say that SWF is like any web application that persists its state on the client side, I just gave that as an extreme example.

Think about what I said for a moment, an url identifies "the point in time" since it will 'restart' the web application at a specific action / component / element .... The parameters, pathinfo and cookies contain the state, which will be used to continue execution with the right values. Now of course SWF does a lot more and provides a mature execution model and state machine, however applying the term 'continuations server' to it feel awkward to me.

As I also mentioned before, RIFE has a state machine too that works independently from native continuations and if you remember well from our talk at JIA, we both agreed that the model was very similar but that the place where the logic is written differs.

Anyway, I realize that I'm probably nitpicking about terminology. I'm just in general concerned about the comprehension of the "continuations" concept. People already have a hard time grasping it in its purest form.

Best regards and congrats on the release,

Geert

Hi Geert,

Just wanted to preface by saying I appreciated your last response. The discussion here has been interesting so far.

Now of course SWF does a lot more and provides a mature execution model and state machine, however applying the term 'continuations server' to it feel awkward to me.

The only part of SWF that is comparable to this abstract idea of a "continuation server" is the flow execution repository subsystem. As mentioned in my previous message, this is the system responsible for managing the persistence of flow executions that remain active for more than one request into the server.

I'd like to expand a little more on exactly what services this subsystem provides, to provide more rationale why I think it may be comparable to what Bruce calls a continuation server, specifically when he refers to Seaside. Hopefully this will dispel some of the awkardness you feel; if not, perhaps you can help us establish some better terminology.

First, there exists a clear distinction between the concept of a conversation and a continuation within SWF. A conversation is a more abstract concept; representing a logical task a client has started that spans more than one request to complete. A continuation is a concrete representation of the state of a conversation at a point in time. It is a manipulatable program; in SWF it's an instance of org.springframework.webflow.execution.FlowExecution. You continue a conversation by accessing a continuation and manipulating it. You can only access a continuation while the overriding conversation remains active.

So given that overview, the flow execution repository is responsible for:

- Tracking ongoing conversations that have started. Each converation is assigned a unique identifier.

- Saving the state of a conversation that remains active after request processing. A conversational state snapshot is obviously what we call a continuation. Each continuation is also assigned its own unique identifier, locally unique within the containing conversation.

- Restoring the state of a conversation on subsequent requests. This requires the client to present a valid two-part key identifying the conversation continuation to restore. By providing a valid key, the client can continue a conversation from a specific point in time.

- Invaliding conversations and all associated continuations "after completion" or accordingly to other rules (timeout, metadata, etc). Conversation invalidation prevents accidental continuation after completion; in other words, it prevents duplicate submits of the same transaction.

- Applying other management functions, some of which can get sophisticated. Examples of these functions include conversation expiry and continuation memory management.

In summary, when you add it all up you get something that seems somewhat like a server; that's basically why I don't think the term continuation server Bruce uses is too far of a stretch. To be honest, I don't generally use that term; rather I read Bruce using it extensively publically when referring to Seaside, which from what I can tell also deals with the same responsibilities/problems outlined above. Perhaps what we have is a "conversation server" after all, since that is what SWF is most interesting in modeling.

One other minor point worth bringing up. Tracking conversational state separately from continuation state also allows us to also have data structures scoped at the conversation level and shared by all continuations. If you consider a typical wizard flow, for example, when you go back in your browser you refer back to a previous continuation representing the state of the flow at that time. If you rely purely on continuation state you lose edits made on subsequent screens--basically you leave the user with perceived undo behavior, which as you know is not always what you want. With conversation scope, the data is preserved even when going back and referring to a continuation representing a point in time in browser history.

I hope this provides some additional insight into our flow execution repository infrastructure and rationale for our lexicon beyond what you gained from browsing our reference documentation.

Cheers,

Keith

I think Keith has an important point bubbling under the surface here. Whether continuations is the correct term or not doesn't *really* matter. As an end user of SWF all I really care about is whether it does the job I need it to do, and I think it is fair to say that the common consensus in the community is that it does and it does so very elegantly.

Rob

Good point, Rob. It doesn't matter as much to the end user, who care most about solid implementation. It does of course matter for communicating abstract concepts independent of implementation.

So when we're talking to SWF users, we're talking concrete SWF concepts; things like flow, flow execution, and flow execution repository, not so much the abstract concepts like conversation, continuation, and conversation server. Communicating in a general sense requires a more abstract lexicon grounded around foundational concepts, and the terms above are the best fit we've found for the problem SWF is solving (independent of implementation specifics).

Keith

Rob, of course it doesn't "really" matter, and I said before that I was nitpicking on terminology. On the other hand, if there are 100 different meanings for the term "continuations", you've just confused everyone a lot and nobody really knows what to expect anymore. I personally think that most of the traction of continuations is that it happens transparently in a native language without any special or external measures. In case of SWF I would just call them "conversation snapshots" I think that brings across what you want to say and doesn't give people the expectation that they would be able to to it in native Java.
Just me 2c

Hi Geert,Just wanted to preface by saying I appreciated your last response. I'd like to expand a little more on exactly what services this subsystem provides, to provide more rationale why I think it may be comparable to what Bruce calls a continuation server, specifically when he refers to Seaside.

Hi Keith, thanks a lot for having taken the time to write this out. It's very clear and informative. I think that instead of introducing an alien concept to your engine, you should use exactly what you use when you explain "SWF continuations" to people: "conversation snapshots".
It sounds as cool to me as continuations, and people don't have the expectation that it would be done in the native language.

Best regards,

Geert

We've considered the term conversation snapshot. It does apply; just like it also applies to you, however, a snapshot to me doesn't capture the essence of a program that can be continued from a certain point, which is what we have.

I particularly find the following description clear:

You continue a conversation by accessing a continuation and manipulating it.

That really clicks for me--it doesn't matter what language the conversation is implemented in.

The term continuation IS abstract. Nowhere in any definition I've seen does it say concrete representations only apply to a "native language". Native is relative, anyway! Conceptually what we're doing fits squarely within its abstract definition; it just fits.

The concept of a continuation is not alien to SWF (alien is also relative isn't it). It's not in the user's face; however, underneath the covers the concerete representation in SWF is called FlowExecutionContinuation (which by default, is an serializable object containing a serialized instance of FlowExecution plus a serializable indentifier).

To me the term continuation simply fits the best the most abstract sense, and FlowExecutionContinuation fits the best in the SWF concerete. A FlowExecution really is a program that could do just about anything; just like a Java method could do just about anything. The program just happens to be written in a Flow DSL not Java, and focuses on the domain of modeling user interactions.

I do understand your concern--your concerned someone reading about SWF's use of this "continuation" concept might think that it is just like Rife's (I remember your blog entry continuations != continuations). To that I say the concept is the same, the language is different, just like Smalltalk is different than Java. And we clearly state that in our FAQ and on forums like these. Finally, when dealing with our users we don't deal in abstract--we primarily talk about specific SWF constructs, anyway.

... Well, Geert, it looks like we agree to disagree, just like we did last April, but who said folks should agree all the time. :-) The best I can do is assure you will be responsible with our use of that abstract term by clearly explaining how it applies to SWF when talking concepts...we simply cannot ignore the term when what we're doing captures the essence of it.

Best regards,

Keith

Greetings, Geert. I hope Rife continues to do well. I think there's a place for both, but like you, my preference too is for the native continuations-in-code. Expressing a flow in native Java rather than XML suits my style, and for many applications is a much simpler expression.

Native continuations give you the holy grail: stateless performance with a stateful programming model. But the XML approach makes refactoring safer for long-duration transactions (publish state; refactor; state still valid), it's more toolable, and more compatible with other view technologies. These are important considerations too. In many ways, it's evolution vs. revolution. I'd go Rife for a new stand-alone project, or Spring if I needed to integrate the enterprise, or Struts, or something similar.

Re. calling it a continuations server, I'm not going to get into the naming debate. ;) I think you're both doing great work. You and Keith both know where I come down on that. We all know that WebFlow uses a state machine and Rife/WebWork use the Rife continuations package. Both approaches are valid; some people say the state machine approach is a continuation in a DSL; others say you need the native language support to call the thing a true continuation server.

For what it's worth, I believe that Seaside in Squeak (a smalltalk dialect) is the benchmark for all of these types of frameworks.

Keep up the good fight...

Our site structure declares logic flows and data flows and the web engine takes care of handling the state transfer, the whole orchestration and 'resuming' the execution after the web request at the correct spot.

Does 'resuming' the execution presumes that application state has not been changed since last request? How you can guarantee this?

Yes. Be glad to. The continuation-style frameworks work by snapshotting a point in time, usually with native language continuations. So the flow of a continuation server is do work, snapshot state, save state in the session, send web page to client (the URL is stamped with a URL identifying the state), a request is sent to the server, the server restores state, and the cycle repeats.

This concept seems very wrong to me. First, what is represented by URL? Is a stateful resource with different views, or is it a specific view of some resource? In the former case you tie client to a specific state of the resource, why? The latter case is even worse, you link to a resource in specific state having specific view. What for?

Since the state that you're storing at the server is just the name of a node in the state machine plus instance variables instead of a partial stack trace, you can persist flows across longer periods of time, safely.

What is the point of persisting flows, again? Especially flows of views?

Very Good job! Thanks for your efforts.
Gurcan

Hi there !

This sounds very, very interesting ! I love the concept !

I'm discovering it along with JSF, which, as you know better than me, has its own "Navigation Model".

How do you position WebFlow w/ this ? I mean, is the thing about using JSF nav for "free browsing" and Flows for real "transactional" parts of the application ?

I'd be glad to know more about this...

Great stuff ! I'll try it out !

Have fun,

Remi

Congratulation guys! This sounds great! I'll give it a try with Struts as soon as I find some time.

 - Yagiz Erkan -
 http://blog.decaresystems.ie