Turbine Services

Services are singletons within the Turbine Framework which have pluggable implementation, and are capable of participating in the Turbine startup and shutdown. As Services are Singletons, there is only one instance of each service in the system. Memory or connections are allocated once only and the internal state is common to all requesting clients. Services can access ServletConfig at system startup time to process relative paths and similar functionality, they can also access RunData on the first Turbine doGet execution to get the environment Turbine is operating under and with. Services can also initialize themselves before they are requested by the client for the first time. A Service that is never used will not allocate resources to itself. A Service can also execute actions upon the system being shutdown, such as closing open connections. The Singleton pattern also allows for the Services to be accessed from anywhere within your code.

The Life Cycle of a Service begins with the Services constructor. A Service does not do much in it's constructor. Especially it should not allocate any costly resources like large memory structure, DB or Network connections, etc. The Service may be in the properties file, but unless a client using the application needs the Service in question, there is no point starting the Service.

The services available with Turbine can be found in the org.apache.turbine.services package. Please note that the [TODO]'s below simply mean that these services need more complete documentation, it does not mean that they are still waiting to be implemented.

  • Assembler Broker Service

    Is the Service which allows assemblers such as Screens, Actions, Layout and Scheduled Jobs to be loaded.
  • Avalon Component Service

    Initializes external components which implement the Avalon lifecycle interface, e.g. Torque. See also the Yaafi Component Service
  • Crypto Service

    Provides encryption algorithms like MD5 and SHA message digests as well as old-fashioned Unix crypt.
  • Cache Service

    Provides a persistent Object Storage mechanism within your application.
  • Factory Service

    A Service for the instantiation of objects with either the specified loaders or default class loaders.
  • Intake Service

    A service that provides input validation along with a standard parameter naming framework.
  • JSON-RPC Service

    The JSON-RPC Service supports JavaScript to Java AJAX communications using JSON-RPC-Java.
  • JSP Service

    The JSP Service is the set of classes that process JSP files inside the Turbine Layout/Navigations and Screen structure.
  • Localization Service

    The single point of access to all localization resources.
  • Logging Service

    The Logging Service has been removed and replaced with a commons-logging and log4j combination. Here you find some information how to use this in Turbine.
  • MimeType Service

    The service maintains the mappings between MIME types and corresponding file name extensions as well as between locales and character encoding.
  • Naming Service

    Provides JNDI naming contexts.
  • Pool Service

    A service for the pooling of instantiated Objects, allowing for the recycling and disposal of Objects in the pool.
  • Pull Service

    Manages the creation of application tools that are available to all templates in a Turbine application. The tools can have global scope, request scope or session scope within your application.
  • Resources Service

    The Resources Service has been removed and replaced with commons-configuration. You find some explanation how to use commons-configuration here.
  • RunData Service

    Is the Service which manages the higher level operations surrounding requests and responses.
  • Scheduler Service

    This service manages the schedule queue giving Cron like functionality. The ScheduledJob can be stored in a database or a properties file.
  • Security Service

    A service for the management of Users, Groups, Roles and Permissions in the system, allowing for those Objects to interact with either Database or LDAP backends. The service also allows for the security to be managed without a backend.
  • Servlet Service

    Encapsulates the information provided by the ServletContext API, and makes it available from anywhere in the code.
  • Session Service

    Provides access to Session information for the current web context.
  • Template Service

    The Service for the mapping of templates to their screens and actions.
  • Torque Security Service

    This is an implementation of a Security Service which uses Torque generated peers to access the required security information.
  • UI Service

    The UI (User Interface) Service provides for application skinning.
  • Unique ID Service

    Allows for the creation of Context unique and pseudo random identifiers.
  • Upload Service

    This service manages multipart/form-data POST requests, storing them temporarily in memory or locally. The resultant Objects can be manipulated through a FileItem Object.
  • Velocity Service

    The service for the processing of Velocity Templates from within the Turbine Layout/Navigations and Screen structure.
  • XML-RPC Service

    This service manages xml-rpc calls to a remote Server.
  • XSLT Service

    The service which is used to transform XML with an XSLT stylesheet.
  • Yaafi Component Service

    The Yaafi Component service loads external modules which implement the Avalon lifecycle interfaces. This is a bridge between the Turbine 2.3 we have today and the Fulcrum components that until now have only been available to Turbine 2.4 (yet to be released).

For more information on the Services Package, view the package.html Package Documentation in the Javadocs or in Turbine CVS.