A question which often comes when starting with Cocoon is, "How do I implement my business layer?"
The short answer: it is up to you ;-)
More precisely, you could say that Cocoon leaves a lot of freedom regarding how to access databases and run business processes or apply business rules.
Similarly, people often ask about "best practices" with Cocoon -- that is, "What's the best way to implement X or Y?" While we generally don't have a set list of best practices, we can provide some simple guidance to help you along your way.
Here's a brief discussion of possible options. Some are real today and some are still - as we like to say here - in the pipeline.
Writing your business layer code inside Flowscript might be tempting after looking at this tour's examples, but please don't!
Flowscript is not meant for more than glue between pages and business code, and its design and future evolution will stay targeted to small glue modules.
As we'll see in our example, it is very easy to access Java objects from Flowscript code. Such objects do not necessarily need to know about Cocoon or Avalon classes, which means that legacy code could be easily integrated, provided there are no class libraries conflicts.
Working in this way however, prevents you from using any Avalon features like configuration, logging, and monitoring facilities.
As such, this is a suboptimal solution, but might be interesting for small applications where you don't want to learn too much about Avalon and Cocoon.
The next step would be to write first-class Cocoon components based on the Avalon framework, allowing your components to use all of the Avalon facilities, and if necessary to access Cocoon components directly.
In this case, your build system will be integrated with the Cocoon build system, and you will tailor your build to include only the required Cocoon blocks.
This is the way to go if you don't mind the tighter coupling between Cocoon, Avalon and your application, and if you are ready to learn these technologies in more detail. The benefits are largely worth it for serious applications.
Structuring your code in blocks, as is done inside Cocoon, will make integration easier and should help future migrations to newer versions of Cocoon.
If you're worried about coupling, RMI components might be an interesting option: in this case, only a small facade will be integrated in Cocoon, and your application will run in its own process with no risks of class library conflicts.
The downside is added complexity and a possible loss of performance, depending on your application patterns.
The next step towards decoupling would be to use REST or SOAP backends to communicate with your business layer, leaving you free to choose the language and framework of your choice to implement the backends. Interoperability with other systems can also be a big advantage in this case.
There are some SOAP helper components in Cocoon today, but we don't see a lot of discussions about them on the mailing lists, so we don't know if their use is widespread.
A good example of a REST backend is the XReporter database reporting framework (http://xreporter.cocoondev.org/).
Recent discussions about a possible integration of SOAP with Flowscript are promising. Being able to transparently access SOAP backends directly from Flowscript would make it possible to create forms-based frontends to SOAP services with a minimal amount of code. Stay tuned...