I took a closer look at Spring Webflow, here are my comments, I took the 
liberty to quote several sources:




Quote:
Have you found as your web application gets more complex, understanding and 
managing the page flow � the orchestration that drives your application use 
cases � gets harder and harder? Are you tired of being forced into very 
particular ways of doing things that don�t give you much reuse? Do you feel 
you�re spending too much time developing your own approaches to generic 
problems like session state management?
(end of quote)




Yes I do, bpm4struts currently tackles all these problems




Quote:
Spring Web Flow aims to be the best solution for the management of web 
application page flow. It is a powerful controller for use when your 
applications demand complex controlled navigations, such as wizards, to guide 
the user through a series of steps within a larger application transaction.
(end of quote)




I'm interested to see how complex process logic such as wizards are implemented 
in a more intuitive way, that would be a nice feature to have




Quote:
Although this is a simple and functional approach, it has a major disadvantage: 
the overall page flow of the web application is not clear from looking at the 
action definitions in the struts-config.xml file. You can�t see the forest � 
the flow � from the trees � the many action and view definitions.
(end of quote)




This is definitely the case, but I feel that Spring webflow has the same 
problem (see the XML example below). Anyway, using bpm4struts and UML the 
problem no longer exists.




Quote:
Spring MVC offers a slightly higher level of functionality: form controllers 
that implement a predefined page flow. Two such controllers are provided out of 
the box: SimpleFormController and AbstractWizardFormController. However, these 
are still specific examples of a more general page flow concept.
(end of quote)




This is interesting indeed, Struts does not support such constructs. I like the 
idea, but I do think that it will only be the best solution (it's what Spring 
Webflow aims to become) when there is room for customization. I guess this can 
be done be extending the default implementation, so that's nice.




Quote:
The page flow in a web application is clearly visible by looking at the 
corresponding web flow definition (in an XML file or Java class)
(end of quote)




Definitely not, the flow descriptor is as hard to read as struts-config.xml




Quote:
Web flows are designed to be self contained. This allows you to see a part of 
your application as a module you can reuse in multiple situations.
(end of quote)




bpm4struts is doing this since 2 years now, using UML use-cases; I also think 
it's wrong to think such modules can be reused in the same way as a Java method 
for example: the problem is that in non-trivial process logic (for which Spring 
Webflow claims to have been written) you always have some kind of context that 
needs to travel with the user, this does not easily go well with the notion of 
losely coupled use-cases (or self-contained modules as it has been called here)



bpm4struts allows different use-cases to access the same session objects, but 
modeling transition parameters would only clutter the use-cases and would tie 
them closely to other use-cases



for these reasons I think that a high degree of reusability of such modules is 
overestimated (don't forget that after server logic has been executed the 
engine must forward to a specific resource, and this changes from use-case to 
use-case, therefore it's easier to simply model each use-case separately, this 
is more work, but easier to maintain and understand - I can tell because I 
started out doing the same thing with bpm4struts, I reverted back to a more 
redundant implementation since the code-generation removes our need to worry 
about duplicate code [for example: similar actions and pages])




Quote:
Web flows capture any reasonable page flow in a web application always using 
the same consistent technique. You're not forced into using specialized 
controllers for very particular situations.

Finally, a web flow is a first-class citizen with a well-defined contract for 
use. It has a clear, observable lifecycle that is managed for you 
automatically. Simply put, the system manages the complexity for you and as a 
result is very easy to use.
(end of quote)




I still think it's easier to model your process logic in UML than having to 
write an XML file, especially when you are refactoring (it's easier to 
reposition a transition in UML than to update the XML to reflect that change), 
but this is a good reason to have a cartridge that will take care of it :-)




Quote:
How does Spring Web Flow Work?



For now it suffices to say that a web flow is composed of a set of states. A 
state is a point in the flow where something happens; for instance, displaying 
a view or executing an action. Each state has one or more transitions that are 
used to move to another state.



A transition is triggered by an event .
(end of quote)




Same as bpm4struts, sounds like they're compatible. By looking at the example 
activity graph () I'm not sure the Spring webflow developers are not well 
considering UML tool compatiblity (not all tools support substates and 
stereotypes on all elements - but they actually should)



Here's an example flow descriptor for Spring Webflow, is this easier to read 
than struts-config.xml ? Not sure, maybe a little. I do think both files look 
very similar.



<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE webflow PUBLIC "-//SPRING//DTD WEBFLOW//EN"

&nbsp; &nbsp;"http&#58;//www.springframework.org/dtd/spring-webflow.dtd">



<webflow id="bookflight" start-state="obtainTripInfo">



&nbsp; &nbsp;<action-state id="obtainTripInfo">

&nbsp; &nbsp;&nbsp; &nbsp;<action bean="bookingActions" 
method="bindAndValidate"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="success" to="suggestItineraries"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="error" to="tryAgain"/>

&nbsp; &nbsp;</action-state>



&nbsp; &nbsp;<action-state id="suggestItineraries">

&nbsp; &nbsp;&nbsp; &nbsp;<action bean="bookingActions"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="success" 
to="displaySuggestedItineraries"/>

&nbsp; &nbsp;</action-state>



&nbsp; &nbsp;<view-state id="displaySuggestedItineraries" 
view="suggestedItenaries">

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="startOver" to="cancel"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="select" to="selectItinerary"/>

&nbsp; &nbsp;</view-state>



&nbsp; &nbsp;<action-state id="selectItinerary">

&nbsp; &nbsp;&nbsp; &nbsp;<action bean="bookingActions"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="success" 
to="isPassengerInfoRequired"/>

&nbsp; &nbsp;</action-state>



&nbsp; &nbsp;<decision-state id="isPassengerInfoRequired">

&nbsp; &nbsp;&nbsp; &nbsp;<if test="$&#123;requestScope.passenger == 
null&#125;" then="enterPassengerInformation"/>

&nbsp; &nbsp;&nbsp; &nbsp;<if 
test="$&#123;requestScope.passenger.preferences.alwaysConfirmPassengerInfo&#125;"

&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;then="enterPassengerInformation" 
else="displayReservationVerification"/>

&nbsp; &nbsp;</decision-state>



&nbsp; &nbsp;<subflow-state id="enterPassengerInformation" flow="passenger">

&nbsp; &nbsp;&nbsp; &nbsp;<attribute-mapper>

&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;<input 
value="$&#123;requestScope.passenger.id&#125;" as="passengerId"/>

&nbsp; &nbsp;&nbsp; &nbsp;</attribute-mapper>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="finish" 
to="displayReservationVerification"/>

&nbsp; &nbsp;</subflow-state>



&nbsp; &nbsp;<view-state id="displayReservationVerification" 
view="reservationVerification">

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="startOver" to="cancel"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="assignSeats" 
to="chooseSeatAssignments"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="book" to="book"/>

&nbsp; &nbsp;</view-state>



&nbsp; &nbsp;<subflow-state id="chooseSeatAssignments" flow="seatAssignments">

&nbsp; &nbsp;&nbsp; &nbsp;<attribute-mapper>

&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;<input 
value="$&#123;requestScope.passenger.id&#125;" as="passengerId"/>

&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;<input name="itinerary"/>

&nbsp; &nbsp;&nbsp; &nbsp;</attribute-mapper>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="finish" 
to="displayReservationVerification"/>

&nbsp; &nbsp;</subflow-state>



&nbsp; &nbsp;<action-state id="book">

&nbsp; &nbsp;&nbsp; &nbsp;<action bean="bookingActions"/>

&nbsp; &nbsp;&nbsp; &nbsp;<transition on="success" to="displayConfirmation"/>

&nbsp; &nbsp;</action-state>



&nbsp; &nbsp;<end-state id="displayConfirmation" 
view="reservationConfirmation"/>



&nbsp; &nbsp;<end-state id="tryAgain" view="tryAgain"/>



&nbsp; &nbsp;<end-state id="cancel" view="home"/>



</webflow>



Let's finish with some things I think are very nice to have, feature-wise that 
is:



1. The FlowExecutionListener construct is an observer that allows you to listen 
and respond to the lifecycle of an executing flow. You can use this feature to 
do anything from state precondition and post condition checks, to auditing and 
security.

2. The mechanism by which the state of an executing flow is saved and restored 
is fully pluggable. HttpSession-based storage is the default, and SWF provides 
two other storage strategies out of the box: one using server-side 
continuation-based session storage, another using full client-side 
serialization. Defining your own custom storage, for example to store flow 
state in a Database, is trivial.

3. As a standalone library, Spring Web Flow is a strong fit for integration 
with other frameworks. Out of the box Spring MVC, Struts, and Portlet MVC 
integration is already provided. JSF and Tapestry integration are expected by 
the final release.

4. With Spring 1.2, exporting beans in an MBeanServer for management and 
monitoring is easy. A strongly typed FlowExecutionMBean management interface 
already exists, and we plan to extend that so global statistics on all flows 
executing on the server can be centrally monitored through a JMX console.





So is it worth writing a cartridge for today ? I'm leaning towards a 'no', I 
think the added value does not outweigh the additional work required to 
maintain it. So let's wait what the future will bring, if this framework has 
released a few versions, is well adopted and proven to handle production-ready 
scenarios it's worth to revise.



On the the other hand, if someone is willing to contribute such a cartridge to 
AndroMDA then I'm more than willing to lend a hand and help him/her find a way 
to complete a first version, wouldn't it be nice to be able to reuse the same 
UML model for different presentation technologies, just like we have for 
persistence technologies ?)
--
Wouter Zoons - [EMAIL PROTECTED]

http://www.andromda.org/
_________________________________________________________
Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=522#522
Posting to http://forum.andromda.org/ is preferred over posting to the mailing 
list!


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Andromda-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/andromda-user

Reply via email to