The http://virtualschool.edu/wap system is small (70kb jar file), fast and
flexible enough to do this. As I said before, I built it explicitly to
support large web apps as extensible state machines. One servlet supports
the entire application. New states are plugged in by adding Page classes
and compiling, which is very fast with Jikes.
If new states must be added without compiling, follow the outline in the
documentation for integrating JWAP with a template language such as
Velocity.
On Friday, June 22, 2001, at 01:04 PM, Stuart Hemmings wrote:
> A code snippet would be most useful to see how that would work for us, but
> first other major impacts on the design are:
>
> - The Servlet (front end) code remains generic from storyboard. A client
> navigates the storyboard via a web browser.
> - new 'plugable' Storyboards will arrive in the future and should not
> impact
> the core servlet -hence extensibility
> - the servlet receives data from an RMI server (back end). objects are
> passed via RMI.
> - new 'services' or storyboards added should only affect the back end
> server
> not replace the front end servlet
> - new storyboards could be added through an external file
> - storyboards will use the RMI interface to the objects. The method
> signatures are known but the return sent from the backend could vary on
> front end state or action.
> - it must be reasonable lightweight, fast, scalable, HA, etc.
> - the servlet will also use threads some synchronised but each client
> starts
> a new servlet session.
>
> The problem is that the state-transition rules are complex! One problem is
> in the notation used to code the external states and transitions the state
> machine should follow. It must be felxible yet follow restricted paths.
> Among other things the servlet will follow a traditional "shopping basket"
> pattern but after check-out each item added be require a series of detailed
> steps.
>
> The MVC design pattern has been considerd along with importing states, and
> storyboards from external files, such as the infamous XML files.
>
> Not using a state machine idea impacts the design. The internal servlet
> methods will grow very large since storyboards can become quite complex. We
> have considered reflection but as always the pressure is on to deliver and
> time is short!
>
>
>
>
> Stuart Hemmings
> Imagine Broadband Limited
> p 449 route des Cretes, 06902, Sophia Antipolis, Cote d'Azur, France
>
> e [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> w www.imaginebroadband.com <http://www.imaginebroadband.com>
> This e-mail and any attachments are confidential and may also be
> privileged.
> If you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
>
>
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
> Marchywka
> Sent: 22 June 2001 17:40
> To: [EMAIL PROTECTED]
> Subject: Re: StateMachine vs Extensible Servlet
>
>
> Random logic is always an alternative. Without having the slighest idea
> what you are trying to do, I would point out that a generalized state
> machine itself could be written in very little code. The trick is
> to specify the state transition rules. If you write a (small)
> application-specific compiler and implement a table driven
> state machine, it should be small, fast, and maintainable.
> There can be a start-up time issue if you need to load a large
> state transition table.
>
> What is it that is Servlet specific that is impacting
> your architecture? Are you contemplating subclassing
> issues and don't want a long processing chain
> ( super.doPost() ad infinitum ) ?
>
>
> Mike Marchywka
> Senior Engineer
> EyeWonder
> 2859 Paces Ferry Road
> Suite 1200
> Atlanta GA 30339
> 770-261-5084(W)
> 770-434-7510(H)
> FAX: 770-261-5080
> [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: Stuart Hemmings [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 12:15 PM
> To: [EMAIL PROTECTED]
> Subject: StateMachine vs Extensible Servlet
>
>
> Does anyone have a viable alternative to implementing a 'state machine'
> in a
> Java Servlet. The reasons for the request is to find a suitable method
> by
> which the size of the doGet and doPost methods will reach as new code is
> added to the Servlet and it permits new storyboards (States/actions) to
> be
> added.
>
> Stuart Hemmings
> Imagine Broadband Limited
>
> p Golden Cross House, 8 Duncannon Street, London, WC2N 4JF, United
> Kingdom
> t +44 (0) 2 07 831 7890
> f +44 (0) 2 07 484 5136
> m +44 (0) 7803 034 777
> e [EMAIL PROTECTED]
> w www.imaginebroadband.com
> This e-mail and any attachments are confidential and may also be
> privileged.
> If you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail.
> Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> ________________________________________________________________________
> ___
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
---
For industrial age goods there were checks and credit cards.
For everything else there is http://virtualschool.edu/mybank
Brad Cox [EMAIL PROTECTED] 703 361 4751
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
