<?xml version="1.0"?>
<!-- 
/*
 * Copyright 2001-2004 The Apache Software Foundation.
 * 
 * Licensed 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.
 */
 -->

<document>

  <properties>
    <title>Services Repository Proposal</title>
  </properties>

<body>

<section name="Description">

  <p>
    The services repository would be a place to store non-core/third party
    Turbine services that could be utilized by anyone developing with the 
    Turbine services framework. There are services that are stored in
    the main Turbine CVS that would be good candidates for the services
    repository: castor, xmlrpc, xslt, webmacro, freemarker, naming.
    These are services that Turbine can function without. Many Turbine
    developers have probably created services but have never offered them
    to the group because they are somewhat specialized: these services would
    be ideal in the repository because they would have a description and
    might be a great starting place for another developer. Or even better,
    a contributed service might be exactly what another developer needs.
  </p>
  
  <p>
    There are also services in other OSS Turbine-based applications that
    would be good candidates for the services repository. Tambora has
    a rule service and processing service that could be useful for other
    Turbine-based B2B solutions, and the URL management and disk caching
    services in Jetspeed are also general purpose services that would be
    very useful to a wide audience of developers.
  </p>

</section>

<section name="Rationale">

  <p>
    It would be nice to try and slim down the primary Turbine CVS.
    There are many services currently in that are not core services. These
    non-core services could easily be stored somewhere else and make the
    primary Turbine CVS easier to navigate and become familiar with.
  </p>

  <p>
    It would be highly desirable to build up an extensive library
    of services. All of these services can't be kept in the primary
    Turbine CVS and so I imagine there are quite a few services out there
    that have not been contributed due to there specialized nature.
    Specialized services are ideal for the repository, if the services
    are kept in a central location and cataloged all parties involved
    will benefit.
  </p>

</section>

<section name="Requirements">
  <p>
    Services would have to be functional from JAR files. For this to work
    the following changes would have to be made:
  </p>
  <ul>
    <li>
      The Services framework would have to be altered to load services
      packaged in the form of JAR files.
    </li>

    <li>
      Dependent services would have to be listed in the manifest so that the 
      the initialization of a service could be deferred until all
      prerequisites of the service have been initialized.
    </li>

    <li>
      The service package in a JAR should state all of its configuration
      options as it may be necessary to have this configuration information
      extracted from the JAR and added to TR.props or whatever future
      configuration mechanisms we devise. It might be nice to have an
      option in Turbine where there is no TR.props to begin with but
      starting Turbine with a certain option would produce a configuration
      that reflected the use of a set of services. Or Turbine would start,
      but would require some configuration from via a little web application
      before Turbine would accept connections from the outside world.
    </li>
  </ul>
</section>

<section name="Scope">

  <p>
    This would primarily affect the services framework, but the tools
    required to pull information from JARS and load the JARS could probably
    be used for loading/configuration sub-applications. We can probably
    borrow a lot of this code from Avalon as I think this is pretty
    much worked out in its service framework.
  </p>

</section>

<section name="Initial Source">
</section>

<section name="Initial Committers">
</section>

</body>
</document>