A question which often comes when starting with Cocoon
is how to implement my business layer.
Here are some suggestions, based on my supersonic tour workshop.
The short answer: it’s 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.
Here’s a brief discussion of possible options. Some are real
today and some are still – as Cocoon folks like to say –
in the pipeline.
Comments are welcome, I do not mean to hold the one and only truth ;-)
Writing your business layer code inside Flowscript might be tempting
after looking at some 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.
Independent java code
As you can see in the Linotype sample, for example, it is very easy to access java
objects from Flowscript code. Just instantiate a java object with
new Packages.com.mycompany.mylogic.MyClass and you’re in business.
Such objects do not necessarily need to know about Cocoon or
Avalon classes, which means that legacy code could be easily integrated,
provided their 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
Avalon-based java code
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
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
REST or SOAP backends
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
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…