> -----Original Message----- > From: Simon McClenahan [mailto:[EMAIL PROTECTED] > Sent: Monday, November 10, 2003 3:21 PM > To: [EMAIL PROTECTED] > Subject: Developing webapps > > I've been sold on the concept of component oriented design, and read > through the Avalon online documentation. It's obviously a bit overwhelming > at first. I'm trying to figure out how to write a webapp or something > similar, and the software architecture behind it.
<snip/> > What is step 1 for developing a webapp? Simon, Good questions. Hopefully I can help a bit. First off, let's look at web frameworks: If you're interested in Component Oriented Programming and Avalon and you want to develop a web application, then you might want to look at one of these three frameworks to start with: Cocoon : http://cocoon.apache.org Turbine : http://jakarta.apache.org/turbine Keel Framework: http://keelframework.org Each of these three frameworks use Avalon "under the covers." Avalon is designed to be a very low-level framework, thus if you're building a web app from scratch with Avalon, you very well may find yourself reinventing code which these frameworks have already established. The frameworks each use Avalon slightly differently. Cocoon started with a very early Avalon container which is now deprecated (ECM) but is being updated to work with Fortress (if I understand correctly -- I don't keep up with Cocoon much). Turbine had its own service (ie- component) framework, but can now use Avalon components and should be working with Merlin soon (if not already). Keel uses Fortress on the inside to allow all the various services and components to play nice with one another and allow users to swap them. So, you might want to check out one of these frameworks first. That said, there's nothing stopping you from embedding an Avalon container in your servlet(s) or embedding your servlets in an Avalon container. But before you start worrying about that, here are some other ideas and suggestions: - Start by identifying big components and obvious 'services'. I find it easier to start by looking at big units, like say, the PDF converter, as one component. This is a matter of separation of concerns. After dissecting everything this way, I'll then start to see what smaller components I might be interested in. - Cross-cutting concerns (aspects) are handled by container extensions. This is a horrible generalization, but usually in Avalon, cross-cutting concerns (AOP aspects) like logging or security are handled by the container or container extensions (lifecycle extensions). Extension support in Avalon is a bit of a mixed bag in Avalon at the moment since each container handles extensions a little differently. But this is where you'll find anything that resembles aspects. - When working with J2EE ... In J2EE-speak, I like to think of my components/services as implementing the business logic part of the application, ie- replace the EJB's with Avalon components and replace calls over JNDI to calls to the ServiceManager (or use AltRMI and then you can do JNDI lookups of your Avalon services). So for struts, you're Actions could get a ServiceManager from the ServletContext (there are examples of doing this in the mailing list archives) and then the actual business logic of the actions would be handled by looking up the right services. Thinking of it in this way might help you see how to separate out the code. Also, you might want to check out the Enterprise Object Broker project (http://www.enterpriseobjectbroker.org/) which uses Avalon Phoenix and can host Avalon services. They have some neat examples over there. Hopefully, that gives you a place to start with some more questions. :) J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
