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
