Quoting "n. alex rupp" <[EMAIL PROTECTED]>: > What about including a Dynamic rules-based workflow engine? One like > Drools? > This is great because it abstracts a lot of the operational control of the > application into the realm of the business person. It seems to me that IoC > is a > good start, but following up with a business rules based control system > would > greatly benefit a lot of companies. When the rules of the business changed, > they could alter the operation of the web application without having to push > their changes and requirements through the developers. >
If we do things right, IMHO workflow support system(s) should be a layer on top of the foundational request handling capability, so you can use it if you need it but it doesn't get in the way if you don't. A rules-based environment is certainly one way to do it; so is scripted dialongs with some sort of continuations (like the Cocoon folks are playing with). > This implies creating management tools, which breaches the question: can we > put > JMX management hooks into Struts 2.0 so that all the different components > and > their configurations can be managed at runtime? > Certainly possible, but if you've come from an environment of creating containers and having full control over class loaders and security managers, you're going to find yourself somewhat frustrated by the limitations of what you can do portably *inside* a webapp :-). > -- > N. Alex Rupp ([EMAIL PROTECTED]) > Craig PS: Alex, it's interesting to note that a lot of the webapp framework folks are all focusing on decomposing their request processors at the same time. The idea we've been playing with that is similar to Shocks is the commons-chain package (in the Jakarta Commons sandbox), and an experimental implementation of the Struts 1.1 request processor in the "contrib/struts-chain" source directory. One thing I'd recommend you think about is decoupling your execute() API from the servlet request and response objects, so you can reuse the basic idea inside the business tier as well. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
