Since you mentioned Keel as one of the frameworks, let me just point out the approach there for the benefit of those that may not have looked into it.
What we do in Keel clients is to take a servlet request, wrap it in a "Keel request", send it over to the "Keel server" which executes the business logic (model), creates a "Keel response" and sends back. If needed, the attributes/parameters from KeelResponse can go back into the servlet response . We can (do) use the Cocoon request/response pairs in the same fashion as the Servlet request/response pairs.
On the Keel server side, it is entirely a Fortress container, so you can take advantage of the Avalon lifecycle as well as any reusable components that you write or acquire. Until Spearhead, we are definitely tied to Fortress. The Keel "client"/"server" can be in a single VM, or distributed across multiple VMs/hosts using JMS.
You do go through an additional wrap/unwrap of the request/response. But Keel (and here I'm talking about the architecture we chose, not the project, per se) does provide a very clean separation of the servlet, application containers and Avalon. We have the request/response encapsulation code abstracted into a "connector" of sorts, and have connectors for Struts, Cocoon, Velocity, Axis, CLI and recently started Tapestry. The idea is that regardless of the MVC framework (originally the topic of this discussion - Struts and Avalon), you do not need to change the business logic. To that end, here's the code from a (any) Struts action, all you need is a "model=" parameter in the standard HTTP/servlet request:
WebappClientConnector kcc =
new StrutsClientConnector(
request,
response,
form,
getServlet());
kcc.setLogger(log);
KeelResponse kres = kcc.execute();
The advantage is primarily this: you can write the core of you logic, using Avalon-capable components, but independent of whether it is accessed as a webapp or not. You can easily hook it up to a standard servlet or a Struts action or whatever the flavor of the day is with very little additional plumbing.
Shash
1. Access to Avalon Container from within webapp component:
In this case, the webapp component itself is not an avalon service but
is just a normal Servlet or similar component hosted by a servlet container. Possible solutions:
a) Contextual Access: the Avalon container is loaded into the servlet or
application context
b) Remote Access: the Avalon container is accessed via JNDI or similar protocol.
2. Avalon Web Enabled Components:
In this case, the component _is_ an Avalon service, hosted in an Avalon
Container. The container provides access to web services such as the
HTTP reply and requests (via HTTPClient or Servlet reply/requests). This could be handled in a number of ways:
a) A Servlet (or webapp component like a Struts Action) which implements Avalon lifecycle methods
b) An Avalon service which implements a "WebEnabled" lifecycle extension
In either case you would need the Avalon container to be either embedded in the webapp framework or have the container (or the block) provide support for WebEnabled and Servlet lifecycle extensions. This brings us to the third use case:
3. Avalon Servlet Container: Either a block or a set of container extensions which would provide support of the Servlet API. Essentially a light weight servlet container. Could also supply support for Avalon "WebEnabled" components listed above.
I want to point out that only the first use case allows much portability between servlet containers and application servers. The second case is the beginnings of an Avalon web framework. The real trick would be to allow access to Avalon services and support for Avalon lifecycles while not tying the application to any particular server or container.
I feel I should also mention that there are a couple web frameworks already based on Avalon: - Cocoon (http://coccon.apache.org) - Keel (http://keelframework.org/) - Turbine (http://jakarta.apache.org/turbine) [will be based on Avalon?]
And from what I understand WebWork2 uses XWork which has similarities with Avalon (http://www.opensymphony.com:8668/space/WebWork2)
Okay, did I miss anything? Questions? Comments?
jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
