xdocs/proposals/services-repository.xml - turbine-core - Git at Google

 <?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>
	<?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>