Description
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.
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.
Rationale
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.
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.
Requirements
Services would have to be functional from JAR files. For this to work the following changes would have to be made:
- The Services framework would have to be altered to load services packaged in the form of JAR files.
- 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.
- 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.
Scope
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.