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