<?xml version="1.0" encoding="iso-8859-1"?>

<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->

<page>
    <content>
        <p>
            A question which often comes when starting with Cocoon
            is, <em>"How do I implement my business layer?"</em>
        </p>
        <p>
            The short answer: <em>it is up to you</em> ;-)
        </p>
        <p>
            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.
        </p>
        <p>
            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.
        </p>
        <p>
            Here's a brief discussion of possible options. Some are real
            today and some are still - as we like to say here -
            <em>in the pipeline</em>.
        </p>

        <h2>Flowscript code</h2>
        <p>
            Writing your business layer code inside Flowscript might be tempting
            after looking at this tour's examples, but <em>please don't</em>!
        </p>
        <p>
            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.
        </p>

        <h2>Independent Java code</h2>
        <p>
            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.
        </p>
        <p>
            Working in this way however, prevents you from using any Avalon features
            like configuration, logging, and monitoring facilities.
        </p>
        <p>
            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.
        </p>

        <h2>Avalon-based Java code</h2>
        <p>
            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.
        </p>
        <p>
            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.
        </p>
        <p>
            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.
        </p>
        <p>
            Structuring your code in <em>blocks</em>, as is done inside Cocoon,
            will make integration
            easier and should help future migrations to newer versions of Cocoon.
        </p>

        <h2>RMI components</h2>
        <p>
            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.
        </p>
        <p>
            The downside is added complexity and a possible loss of performance, depending on your
            application patterns.
        </p>

        <h2>REST or SOAP backends</h2>
        <p>
            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.
        </p>
        <p>
            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.
        </p>
        <p>
            A good example of a REST backend is the XReporter database reporting framework
            (<a href="http://xreporter.cocoondev.org/">http://xreporter.cocoondev.org/</a>).
        </p>
        <p>
            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...
        </p>

    </content>
</page>